Posts: 20
 Last online: 08.23.2022


Dear Gregor,
The MCD group is missing in my banddos.hdf file. I've initially checked this with h5ls r, but your command also gives "NOT FOUND."
Could you please point me to the input file for that automated test, or just attach it here?
Thanks, Kirill



Thank you, Gregor. Please note that the "sum of valence eigenvalues" in "out" and "evsum" 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?


Dear Gregor,
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, Kirill




Thanks a lot for the explanation, Gregor. I'll keep an eye on that numerical randomness. If it doesn't exceed the nanoeV level as in your example, that shouldn't be much of a problem.

Gregor,
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 fourfold anisotropy in a tetragonal material, which is ~ microeV. If precision is somehow lost beyond 7 digits in Hartree units, that would mean fourfold MAE can't be calculated at all, but I think I saw examples for Fe and Ni in some FLEUR tutorials.
Thanks, Kirill

Thank you, Gregor. I'm using a very recent development version which was pulled as follows:
git clone branch develop https://iffgit.fzjuelich.de/fleur/fleur.git fleurdevel
The format of the printout in "out" is different from your example:
sum of valence eigenvalues= 68.027430 sum of weights=124.000000
There are only 6 digits here. Has this just been changed in the last couple of weeks or were you testing with an older version?
Also, this is in Hartree units, right?
Thanks, Kirill



I've been having exactly the same problem with either GCC 9.1 + OpenMPI 3.1 or Intel 19 + OpenMPI 4.0. Has anyone figured out how to fix this?


Dear Daniel and Gregor,
If I put the Bravais lattice vectors as rows in the Bravais_Matrix (as it is printed out), then will the Gvectors be the columns of 2*pi*inverse(Bravais_Matrix)? Maybe you could point out the place in the code where the Cartesian components of the kpoints are calculated?
Neither I nor our cluster support specialist were able to get a working version of the code with HDF support, so I don't have the banddos.hdf file.
Thanks, Kirill


Hi Daniel and Gregor,
I hate to say it, but this last update has made things worse, as you can see in the attached figure. Do you have a test case where it works correctly? I can send you mine if it may be helpful.
Best regards, Kirill [[File:b_field_1011.PNGrightauto]]


Hi Daniel,
It's much better but not quite there yet unless I've screwed something up. The Zeeman splitting is almost but not quite constant, and its magnitude is not quite right either (should be 0.02*27.2=0.544 eV but the average is more like 0.48). See the picture.
Thanks, Kirill
[[File:b_field.PNGnoneauto]]


Dear Daniel,
I have cloned and compiled the develop branch, but it didn't make any difference to the band plot. I do see the difference in vgen/b_field.F90 including vTot%pw(:,1)=vTot%pw(:,1)field%b_field/2.*stars%ustep, suggesting that the changes did get included in the branch that I compiled. So there still appears to be a problem with this update.
And yes, of course the exchange enhancement is generally kdependent (especially in a system that contains different atoms), but not in a oneshot calculation starting with the nonmagnetic state which should have no exchange enhancement at all.
Thanks, Kirill


Dear Daniel,
Sorry for the confusion. I am showing E_downE_up for four bands as a function of the kvector along a line in the BZ for a small value of the Bfield (b_field="0.02"). It's not as a function of the Bfield.
The system is nonmagnetic  it's an Al/As/In zincblende structure with a monolayer of each and a vacuum layer separating Al and In. It's taken purely for test purposes.
It doesn't matter much whether the calculation is oneshot or selfconsistent. I don't remember how I did the plot that I posted, but I get a very similar plot if I do the following: (1) selfconsistent calculation with no SOC which results in a nonmagnetic state; (2) add an entry with b_field to calculationSetup and immediately run FLEUR with band="T". I believe this is supposed to add a Zeeman term to the existing nonmagnetic Hamiltonian and result in spinup and down bands shifted with respect to each other by exactly the Zeeman splitting. Instead I'm getting splitting that is strongly kdependent (as seen in the figure).
Thank you, Kirill




Thank you, Henning. I couldn't find any documentation or examples of the new "tetra" mode  I hope you can help me with this. Do I generate the grid and weights like this?
inpgen inp.xml kpt somename#tetra@gamma@grid=12,12,12
It's not clear how to combine the tags like "tetra" and "gamma", although the above seems to work. (?)
Then I should deploy the mesh as follows, right?
<bzIntegration valenceElectrons="62.00000000" mode="tetra" fermiSmearingEnergy=".00100000"> <kPointListSelection listName="somename"/> </bzIntegration>
and this should work in both selfconsistent and forceTheorem modes?
Thanks, Kirill


