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.
Your enpara file probably doesn't fit to the Fleur input file. For most purposes we don't use an explicit enpara file anymore. I guess you have it as a leftover from a calculation with an older fleur version in the same directory. Could you try starting with a fresh input in a new directory?
Especially with these integer numbers in the enpara file everything that is parameterized there is already parameterized in the newer Fleur input file. These are the "energyParameters" entries in the atomSpecies section of the Fleur input file. See, e.g., https://www.flapw.de/MaX-6.0/documentati...species-section
Just determine the maximal and minimal z coordinates, maxZ, minZ, in your set of atoms and calculate
centerZ = (maxZ+minZ) / 2.
Then subtract centerZ from all z coordinates in your list.
It doesn't matter whether certain atoms are magnetic or special in another way. only the atom coordinates are of relevance in this strategy.
For certain calculations it may also be advisable to set up a film unit cell that is symmetric with respect to the z=0 plane and the atom coordinates and types. But this is not necessarily needed.
With respect to the papers: We actually have code to calculate hyperfine fields in the code. It is employed by using a different core electron solver, which is done by setting the input parameter kcrel to 1. But this code is rarely used I thus have to check whether it is still correct. ...I will also beautify the output. The other Mössbauer parameters are probably not yet calculated by the code.
At the moment the output for the hyperfine fields is shell-resolved, i.e., one obtains contributions from 1s, 2s, 2p, 3s, 3p and so on. Does such an output fit your needs?
The numbers are not necessarily too large, but you could try to perform a few iterations with straight mixing and a very small mixing parameter before trying anything else.
The inwint error essentially means that the potential is messed up. You somehow ended up in an unphysical situation. This is often due to issues in the parametrization, though I could at least verify that your inpgen input is reasonable. I cannot say anything about the VCA part. Maybe someone else can have a look at that.
One may also end up in such a situation if the convergence process is problematic. Did the error occur in the first iteration or after many iterations? In the latter case: How strongly did the density change in the iterations before?
This is a two-stage test. The input files for this are found in the fleur/tests/inputfiles/CoMCDXML/ subdirectory of your Fleur folder. The first part of the test is run with the inp.xml file, then its content is replaced by the content of the inp2.xml file and Fleur ist started again. After the 2nd stage you should have the banddos.hdf file with the related output available.
While we did not use the MCD feature in practice lately, one of our automatized tests should be sensitive to this feature. So it may be very operational, but I would always have a look at whether the results make sense.
Performing the automatized test by hand also yields a banddos.hdf file that seems to have the related contents:
I actually never thought about this. I think, there is at least no stop built into the code for this case. I suggest to test for a few related cases how good the agreement between force theorem MAE calculations and conventional self-consistent MAE calculations is, just to get a feeling for this.
So, just perform a few self-consistent calculations with different SQAs and compare the total energies instead of the eigenvalue sums in the force theorem mode.
This was only related to the output of the valence eigenvalue sum in the case of spin-orbit coupling calculations without activating noncollinear magnetism.
That is what I wrote about a few days ago. I have not yet fixed this, but what I can say is that the eigenvalue sum in the MAE output in the out.xml file is more consistent with a calculation without SOC than the other output. It was actually explicitly fixed some time ago to have only half that value. I still have to figure out where the factor 2 in the other output comes from.
I never cloned a certain commit. I suggest to clone the repository and then checkout the commit, i.e., with
1 2 3 4
git checkout develop git checkout <commitHash>
where you replace <commitHash> with the actual commit hash. You probably don't even need the second line. At the moment the develop branch should be stable.
In commit https://iffgit.fz-juelich.de/fleur/fleur...185ecdc2e827de0 I now added two more digits to the ev-sum output from MAE force theorem calculations. At the moment I start to believe that the new number for ev-sum in the MAE output in the out.xml file is correct. It may be that for the other places and in the old fleur version there is a double-counting of the valence states in this context. At least the new number seems to be more in agreement with calculations without SOC. I have to analyze this a little more.
Fleur can be used for this purpose, but more in the sense that the results from Fleur calculations can be used in a manual postprocessing step to calculate these parameters. How this is done in detail depends on your use case. The simplest approach is to perform calculations with different magnetic configurations and then set up a system of linear equations constructed from the different configurations, the total energies of these calculations, and the respective coupling constants. You then obtain the coupling constants by solving this system of linear equations.
For other cases a good starting point for the calculation of exchange coupling parameters is a set of calculations for different spin-spirals. Such an approach is suggested in this paper. Fleur explicitly supports such calculations in terms of the magnetic force theorem. The usage of this feature is sketched here.
All of the parameters mentioned on the linked site are important. If you have an insulating material the k-point set convergence and the related Fermi smearing are probably not very demanding.
At first I would concentrate on the Kmax convergence, then lmax and lnonsph. Then you could check by adding some local orbitals whether the linearization error is of relevance here and finally I would check out the numbands convergence, which is definitely of relevance for such calculations with spin-orbit coupling.
As an indicator of whether (most) parameters are nicely converged you can also vary the MT radii slightly (reduction by 5-10%) and observe whether this leaves the results stable.
The MAE is a quantity that is difficult to converge due to different reasons, one of them is that it is tiny. In this context one has to try a lot to gain some experience on how to choose the parameters. I suggest to at least investigate all the parameters mentioned on this site. I also don't know what literature source you take for comparison. Make sure that everything mentioned there is in agreement to what you coose in your calculation, for example the XC functional. In general the FLAPW method implemented in Fleur is one of the most precise implementations of DFT. If you make everything correct you provide the reference in this context. There may, however also be other approaches besides DFT and the FLAPW method implies many parameters so that it is a challenge to make everything correct.