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 "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?

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

Dear Gregor,

How can I clone that commit? If I run "git clone https://iffgit.fz-juelich.de/fleur/fleur...dc2e827de0"; it redirects to https://iffgit.fz-juelich.de/users/sign_in and fails.

Thanks,
Kirill

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.

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 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.

Thanks,
Kirill

Thank you, Gregor. I'm using a very recent development version which was pulled as follows:

git clone --branch develop https://iffgit.fz-juelich.de/fleur/fleur.git fleur-devel

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 G-vectors 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 k-points 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.PNG|right|auto]]

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.PNG|none|auto]]

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 k-dependent (especially in a system that contains different atoms), but not in a one-shot 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_down-E_up for four bands as a function of the k-vector along a line in the BZ for a small value of the B-field (b_field="0.02"). It's not as a function of the B-field.

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 one-shot or self-consistent. 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) self-consistent 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 spin-up and down bands shifted with respect to each other by exactly the Zeeman splitting. Instead I'm getting splitting that is strongly k-dependent (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 self-consistent and forceTheorem modes?

Thanks,
Kirill