This is the user forum of the DFT FLAPW code FLEUR. It is meant to be used as a place to asks questions to other users and the developers, to provide feedback and suggestions. The documentation of the code can be found at the FLEUR homepage.
Thank you, Gregor. Please note that the "sum of valence eigenvalues" in "out" and "ev-sum" in "out.xml" still differ by a factor of 2. (Those in "out.xml" are twice smaller.) I assume the correct output is in "out" - is that correct?
Thank you for your response. I have a somewhat related question: is there a recommended procedure for calculating MAE with LDA+U based on the force theorem? I'm not sure whether the force theorem mode (forceTheorem in the input file) for the magnetic anisotropy is compatible with LDA+U.
Thanks a lot for the explanation, Gregor. I'll keep an eye on that numerical randomness. If it doesn't exceed the nano-eV level as in your example, that shouldn't be much of a problem.
I looked in the code and found that the output format in "out" is different for the tetrahedron (f20.6) and histogram (f20.10) methods.
Coming back to your other point, could you please explain why you think precision can be lost in the "force theorem" calculation of MAE? Aren't all potential parameters supposed to be the same for the different orientations of the magnetization? I'm trying to calculate four-fold anisotropy in a tetragonal material, which is ~ micro-eV. If precision is somehow lost beyond 7 digits in Hartree units, that would mean four-fold MAE can't be calculated at all, but I think I saw examples for Fe and Ni in some FLEUR tutorials.
1. When I use the <forceTheorem> field in the input file to calculate magnetic anisotropy, the "sum of valence eigenvalues" for each angle in the "out" file is exactly twice larger than the "ev-sum" printed in out.xml in the <Forcetheorem_MAE> field. The value in "out" is close to "first approx. to seigv (T=0)". In both out and out.xml the data are claimed to be in Hartree. Is there an inconsistency? Which value is in which units?
2. The printout in out.xml for MAE has seven decimal digits, which is not enough. I tried and failed to add a couple digits in forcetheorem/mae.F90. I changed the format from f12.7 to f14.9 in "WRITE(attributes(3),'(f14.9)') this%evsum(n)" but what else should be done to the call to writeXMLElementForm? I tried leaving it as is or changing the last argument to RESHAPE((/5,3,6,12,12,14/),(/3,2/)) but either way it fails to execute.
When a small magnetic field is added as <fields b_field="0.02"/> in the calculationSetup group, in a system without SOC I expect a uniform splitting of spin-up and spin-down bands. Based on the implementation in vgen/b_field.F90, I expect the splitting to be equal to the value of b_field (in Hartree units). For the 0.02 example, it should be 0.544 eV. I have tested it for a benchmark system and found the Zeeman splitting for some 4 bands that is shown in the plot. There are 2 issues: (1) the splitting is non-uniform, and (2) it is about twice smaller than expected, unless FLEUR switched to Rydberg units at some point. The same non-uniformity is present whether I first iterate to self-consistency or just take a nonmagnetic calculation and plot the bands with the b_field tag included (in which latter case the splitting should be exactly uniform). Again, SOC is turned off: <soc l_soc="F"...>.
Please advise whether I'm doing something wrong or there's something wrong with the b_field implementation.
do I understand correctly that k-points are given as fractions of G-vectors? Are the G-vectors printed out anywhere? I need to know the coordinates of the k-points used for the band plot in Cartesian coordinates.
I wanted to use tetrahedron integration for the calculation of magnetic anisotropy, but it looks like the generation of the k-point set quickly gets impossibly slow as the mesh is made more dense. I tried looking into the code and it seems like it tries to produce a somewhat optimized set of k-points instead of just taking a regular mesh, so I'm not sure what the input should be; the manual doesn't offer any help on this. I use version MaX-R4, and here's my BZ integration part in inp.xml:
The "out" file has this line: "coordinates of 1296 kpoints in cart. units", where 1296=12x12x9 so it seems like the input is used one way or another. This calculation (for FePt) completes fine, but for nx="24" ny="24" nz="18" the generation of the k-point set is already extremely slow and it looks like it will take hours. This is obviously not what it should be - other codes can produce tetrahedron sets in milliseconds for such meshes.