Bug report

[asmith97]

Description

I'm having an Issue installing the code. I'm using solid_dmft VERSION 3.0.9 that I cloned from github today with git clone https://github.com/flatironinstitute/solid_dmft solid_dmft.src. I installed Triqs in a conda environment, and also installed scipy. (As an aside, I also had to install pytest to run the tests, and it wasn't included in the installation instructions, so it might be easier for people if that was just included in step 2 as the prerequisites as well, but perhaps this was just an issue for me. Regardless, it was easy to see the issue and fix). After these initial downloads/installations and steps 2-4 in the installation instructions, I ran make test and failed several tests. The first test case failed because of ImportError: cannot import name 'determine' from 'solid_dmft.dmft_tools.afm_mappingI found that the file that it searches for the determine function in has a function called determine_afm_mapping When I replaced the import of determine in /global/home/users/alex_smith/software/solid_dmft.src/test/python//test_afm_mapping.pywith import determine_afm_mapping as determine, that test ended up passing. Is determine_afm_mapping the correct function that should be called?

After this change, test cases 1-7 all passed, but 8-11 all failed. They said that ModuleNotFoundError: No module named 'triqs_dft_tools', so presumably triqs_dft_tools also has to be installed. I installed triqs_dft_tools following the instructions on its webpage to install it with conda, but then I still ran into an issue because at one point it says Test 8: cannot import name 'gf_struct_flatten' from 'triqs_dft_tools.block_structure' and the other failed tests had the same issue. I couldn’t find gf_struct_flatten in /triqs_dft_tools/block_structure.py, but I could find it in block_structure.py in the unstable branch of triqs_dft_tools. To test it out, I tried copy/pasting the gf_struct_flatten function from the unstable branch to the version that was installed with conda. That helped with the import error. Is the unstable branch (or at least this snippet from the unstable branch) what one is supposed to be using?

After adding gf_struct_flatten, I still had those last few tests fail, but this time it was because the impurity solvers weren't installed. (As an aside, the link to CTHYB in https://triqs.github.io/dft_tools/1.4/install.html was broken for me, but I was able to find https://triqs.github.io/cthyb/latest/ by googling). It was easy enough to fix this by installing it with conda, but it might also make the installation take less time if you were told to install it and triqs_dft_tools from the outset rather than doing it after they failed. After doing this, I ended up with an error TypeError: __init__() got an unexpected keyword argument 'delta_interface' in the two cthyb tests (I didn't install the HubbardI solver, since I figured that I might as well try to debug one of them at a time). It looks like the unstable branch of the cthyb package has the delta_interface keyword argument, but the 3.0.x version does not. I compared the code in the solver.py file in the version 3 branch and in the unstable branch, and both files were identical except for __init__ in unstable having the extra keyword argument and some associated code to deal with delta_interface. I'm guessing if I were to copy this code over then it might work like it did with gf_struct_flattten, although I couldn't tell if the unstable branch version of cthyb might rely on other code that has changed between the branches, so I haven't tried doing this. Nor have I tried just using the unstable branches.

Should one take the unstable branches of triqs_dft_tools, triqs_cthyb, and hubbardI? It seemed like this was probably the case based on the errors I was getting in the tests, but it wasn't mentioned in the installation instructions, so I couldn't tell if it would be a mistake to try everything with the unstable branches. Hopefully I haven't missed somewhere where this is mentioned.

[the-hampel]

Hi @asmith97 ,

thank you for your report! Indeed the installation instructions were still incomplete. I updated those in commit f7c954d71ed12cb1717f864b903a56fb4844f7e1 and the changes should now be live on the documentation. Sorry for that. In short: yes pytest has to be installed to run the tests (added to prereq now). I think you went down an unfortunate path there, because everything should have worked using the branch 3.0.x of solid_dmft, which is compatible with version 3.0.x of all necessary triqs applications. I made this now more clear in the installation instructions in point 2 (https://flatironinstitute.github.io/solid_dmft/install.html). The unstable branch is only compatible with the unstable branch of triqs and all applications. This is why you had problems with gf_struct_flatten and delta_interface. Those are only available in dft_tools/unstable and cthyb/unstable. Please use version 3.0.x of solid_dmft to get rid of these problems together with triqs/3.0.x and cthyb/3.0.x (stable releases). We will soon release version 3.1 which should make the new features available. I will also make the default branch of solid_dmft reflect the current default branch of triqs.

Thanks for reporting the problem with the test_afm_mapping. I fixed this in c8a95d1 .

Please try with solid_dmft/3.0.x again and report back if there are any further problems.

Best, Alex

[the-hampel]

Hi @asmith97 , has the issue been resolved for you? Or do you still have problems installing solid_dmft? Best, Alex

[asmith97]

Yes, thank you very much! It's been working now and it passes the tests. I'm sorry for the late reply, after I got it installed successfully I wanted to try running one of the examples before replying to make sure that it was working outside the tests, but I was only able to try out the example over the past couple of days.

I'm not sure if this thread is the best place for this, or if it would be more appropriate to start a new one, but I ran into some issues with the CaFeO3 example provided in the /doc/tutorials directory. The VASP calculation in 1_dft_scf ran fine (as expected since that was a normal VASP calculation), but the calculation in 2_dmft_csc gave me some issues.

First, the Juypter notebook for the tutorial says to use mpirun -n 32 python3 uni_dmft.py, but I couldn't find a uni_dmft.py while looking through the folders, using the find command in the src and build directories, and also searching on github. I tried instead to use solid_dmft in solid_dmft.build/bin/solid_dmft, and that seemed like it was probably correct since it actually managed to produce some sensible output (for example, it started printing Reading the config file dmft_config.ini and then printed out a bunch of input parameters and it even started the VASP calculation that it was supposed to start. I wasn't, however, able to get this to work with mpirun. When I used mpirun and specified the number of tasks, it seemed like it would run the program that number of times rather than running the program once and having parts of it computed in parallel. I saw repeated text that was in multiples of the number of mpi tasks that I ran. I don't really know enough about mpi in python to be able to tell what was causing it. I was running it with mpirun -np 16 python3 solid_dmft based on modifying the suggestion from the tutorial. I think I tried running it with both -np and -n. I'm not able to test it again right now because all of the nodes are being used up.

When I switched to just running a single task on a single node and calling "python3 solid_dmft" rather than using mpirun is when I was able to get it to run and produce the sensible looking output. Things were ok until after the VASP calculation finished when I got the following:

DAV:   8    -0.145101326048E+03   -0.16641E-05   -0.16642E-05 47208   0.127E-02
 writing the density matrix to GAMMA
  solid-dmft: DFT cycle took   980.1816 seconds
!!! WARNING !!!: Error reading E-Fermi from LOCPROJ, trying DOSCAR
Read parameters:

then there were several lines with text like 14 -> {'label': 'dx2-y2', 'isite': 7, 'l': 2, 'm': 4} and then

Found POSCAR, title line: Ca Fe  O
  Total number of ions: 20
  Number of types: 3
  Number of ions for each type: [4, 4, 12]

    Total number of k-points: 245
   Total number of tetrahedra: 1470
!!! WARNING !!!: Error reading from EIGENVAL, trying LOCPROJ
!!! WARNING !!!: Error reading from Efermi from DOSCAR, trying LOCPROJ

That's what was written to standard out. Standard error had this:

cat job.10657985.err 
Starting run with 1 MPI rank(s) at : 2022-01-28 11:48:49.788863
Traceback (most recent call last):
  File "/global/home/users/asmith/.conda/envs/solid_dmft/lib/python3.8/site-packages/triqs_dft_tools/converters/plovasp/vaspio.py", line 88, in __init__
    self.doscar.from_file(vasp_dir)
  File "/global/home/users/asmith/.conda/envs/solid_dmft/lib/python3.8/site-packages/triqs_dft_tools/converters/plovasp/vaspio.py", line 646, in from_file
    sline = next(f).split()
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/global/home/users/alex_smith/software/solid_dmft.build/bin/solid_dmft", line 45, in <module>
    run_solid_dmft.main(sys.argv)
  File "/global/home/users/alex_smith/.conda/envs/solid_dmft/lib/python3.8/site-packages/solid_dmft/main.py", line 100, in main
    csc_flow_control(general_params, solver_params, dft_params, advanced_params)
  File "/global/home/users/alex_smith/.conda/envs/solid_dmft/lib/python3.8/site-packages/solid_dmft/csc_flow.py", line 314, in csc_flow_control
    _run_plo_converter(general_params)
  File "/global/home/users/alex_smith/.conda/envs/solid_dmft/lib/python3.8/site-packages/solid_dmft/csc_flow.py", line 61, in _run_plo_converter
    plo_converter.generate_and_output_as_text(general_params['plo_cfg'], vasp_dir='./')
  File "/global/home/users/alex_smith/.conda/envs/solid_dmft/lib/python3.8/site-packages/triqs_dft_tools/converters/plovasp/converter.py", line 57, in generate_and_output_as_text
    vasp_data = vaspio.VaspData(vasp_dir, efermi_required=efermi_required)
  File "/global/home/users/alex_smith/.conda/envs/solid_dmft/lib/python3.8/site-packages/triqs_dft_tools/converters/plovasp/vaspio.py", line 93, in __init__
    self.plocar.efermi
AttributeError: 'Plocar' object has no attribute 'efermi'

I checked my triqs_dft_tools, and it looks the same as the github version 3.0.x. It looks like the self.efermi = float(sline[4]) didn't end up finding the Fermi energy since the exception about reading the Fermi energy from LOCPROJ was raised. When it tried to read it from the DOSCAR, that also failed

The DOSCAR is short, so I've included it here:

20  20   1   0
  0.1051688E+02  0.5330110E-09  0.5321210E-09  0.7416010E-09  0.5000000E-15
  1.000000000000000E-004
  CAR 
 CaFeO3 R1+0.20   

It's missing the line "E(max), E(min), (the energy range in which the DOS is given), NEDOS, E(fermi), 1.0000" as the VASP wiki says should be there, which makes me not sure if the issue is a VASP issue or a solid_dmft issue here. I've ran many calculations with this compilation of VASP, so it should work fine, although maybe something is off with interfacing it with solid_dmft. When I compare my OUTCAR to the reference OUTCAR, mine ran 8 electron minimization steps whereas the reference ran 7.

My energy without entropy and energy(sigma->0) were -145.10132438, and the reference had -145.10121111, so the calculations seemed to have been proceeding pretty similarly. My integrated charge (the tot part of the table) was 143.363 and the reference value was 143.364, so again they were basically the same. My optimized coefficients for linear combined projectors in the seventh iteration were also basically identical to the reference. Finally, the BZINTS: Fermi energy line for the reference is identical to mine in both the seventh and extra eighth iteration that mine ran. The first line of the OUTCAR with the vasp version is the same for mine and the reference, so that wouldn't be causing the issue either.

Between the issue when using mpirun and the thing with VASP, I wasn't sure if I was doing something wrong in setting up and running the calculation. Hopefully I've described it well enough. I hope I'm not wasting your time with something silly that I'm doing wrong, but I tried my best to go through the code and the documentation to try to sort out what was going wrong.

[merkelm]

Hi, the tutorials are still work in progress but we plan to have a full series of tutorials from one-shot calculations to CSC ones, which should be ready within the next months. That's why currently there are a bunch of inconsistencies in the tutorials, sorry for that.

In the meantime, taking a look at the examples might be more helpful. I'd suggest starting with the SVO one-shot folder. This way, you also won't have the problem with reading the Fermi energy from Vasp.

This problem with the Fermi energy can be fixed if you modify the Vasp code as described in the dft_tools documentation. And finally, the mpirun command should work as follows: mpirun -n 16 solid_dmft.

I hope this helped. Let us know if you have any other problems or questions! Cheers, Max