Dear Kirill,

this starts to be slightly embarrassing :-). Gregor pointed out that there might be another problem, this time in the MT-spheres. I committed a fix that I hope will now solve this problem.

Hope this now really fixes the issue.

Daniel

Dear Kirill,

Next try :-) I looked into this again and realized we operated on the wrong variable with the b-field. Hope my second fix is now correct.

Please also be aware that the contribution of the B-field to the total energy is not included correctly as the density-potential integrals that enter into the
total energy are calculated before the modification of the potential. So probably some term M\timesB is missing.

Daniel

Dear Kirill,

thanks for the clarification. After looking into the code I concluded that there might indeed be a bug regarding the treatment of the interstitial. I just committed a fix to the 'develop' branch which hopefully :-) fixes the issue.
I would like to point out that however, that I do not expect the effect to be so straight forward in the fully SCF case, instead the response of the density to the field will add an additional splitting that no longer needs to be the same for all k-points, so I would recommend to check the effect of the fix for a single shot calculation first. You might be right that the difference is small :-)

Hope this helps.

Daniel

While I agree that the magnetic moment should be around 7 for Gd, I cannot tell exactly what went wrong from the data you provide. The input you give is only valid for older versions of FLEUR (cal_symm switch is no longer supported). For me it looks like you will end up with too small MT radii which could indicate that your structure is wrong, but without more detailed info on the actual inp.xml this is only a guess...

Hope this helps,
Daniel

Dear Kirill,

I must confess I am having some problems understanding the details of your issue. I agree that one would expect a uniform splitting of the spin up/spin down states as the first effect of the B-field. However, what exactly are you showing in your plot?
- Is this E_up-E_down for four bands as a function of the B-field?
- Since you have for x=0 (B-field=0?) a splitting you have a magnetic system, what is this in detail?
- Is this the splitting induced by switching on the B-Field and then doing a single iteration or is this the splitting after full SCF for each field situation?
- Is the magnetic moment increased or decreased by the field?

Best regards
Daniel

Yes, the coordinates given here are the same as in the usual k-point lists, relative coordinates in the rez. lattice. Unfortunately, it seems that the rez. lattice is no longer explicitly given in the output. The matrix of the Bravais lattice is given though and the rez. lattice is given by 2*pi*inverse(Bravais_Matrix).

Hope this helps,
Daniel

SOC in combination with magnetism breaks time-inversion symmetry. Hence, you need a k-point set that is constructed without using this symmetry. This should be
straight forward using the input generator (inpgen) as documented in our website starting from your inp.xml.

Hope this helps,
Daniel

The calculation of the DMI interaction actually tries to treat a Spin-spiral with SOC in order to obtain the effect of the SOC on E(q) from which the DMI can be extracted. Since the spin-spiral feature and the SOC feature are conflicting in a usual SCF iteration (SOC breaks the translational symmetry used in the generalized Bloch theorem for spin-spirals) this calculation is performed in perturbation theory (SOC as a perturbation of the spin-spiral) in a mode implemented analogously to the force-theorem modes. I am sorry that is seems to be broken and promise to have a look at the issue ASAP.

Daniel

Dear Adriano,

I am not 100% sure I get the point, but in the workflow the outlined here, the SOC effects are calculated from changes in the eigenvalue sum. The changes in eigenvalues can of course not simply be decomposed in contributions from individual atoms. What you can do, would be to "switch off" SOC for some atoms by e.g. using the "socscale" parameter and then investigate the changes you get. If you do that for many atoms/layers it of course can become a bit of work and these "contributions" you will get there will not simply add up to the full result.
To get such a decomposition of the full SOC effect into additive terms for each atom, I think you would have to do e.g. 1st order perturbation theory in the SOC. Then the changes of the eigenvalues will be due to the expectation values of the changes of the SOC contribution to the Hamiltonian which can be decomposed into individual additive terms. We do this only for the "DMI" force theorem mode which does SOC on top of spin-spiral calculations using perturbation theory.

Hope this is of some help,

Daniel

I am sorry, but I do not understand your request. In the bandstructure output, the information you want to plot is actually available. So it just a matter of your visualization skills to create a colorful bandstructure :-)

Hope this comment is helpful

Daniel

Please have a look at the documentation, e.g. at https://www.flapw.de/MaX-5.1/documentati...ronConfigSetup/
The basic step you want to do is to occupy the initial spins differently for some valence states.

Hope this helps.

Daniel

Just to add a few remarks to Gregor's extensive discussion:
- This problem to solve the problem of the isolated atom (differ) is nearly always due to a "broken" potential, i.e. a potential that is far off.
- You calculate an "asymmetric" film, i.e. a film without z-reflection or inversion symmetry. These setups are very prone to be difficult to converge. In particular, as Gregor already pointed out, initial charge fluctuations can be too large to use standard mixing parameters. While a symmetric film is more simple to simulate in most cases, you of course also have to keep stoichiometry in mind.

Hope this helps,
Daniel

FLEUR actually calculates the core electron levels in each standard self-consistency cycle. Hence, it is relatively straight forward to obtain the core levels for a supercell with e.g. a defect for all core levels of the unit cells. As you said, the absolute values usually are of little use, but by comparison with a suitable reference system one can easily calculate shift which tend to be rather reliable. Please note in addition: Core levels are somewhat sensitive to the radial grid as given by the MT radius, the grid-points and the log. Increment. Hence, keep these values consistent when comparing energies!

FLEUR can also calculate partially occupied core configurations that can be used in a Slater transition state manner to obtain more realistic shifts by also including static screening effects.

Hope this helps,

Daniel

This is an error I have not seen since we introduced OpenMP. As Gregor already said, there could be different options to proceed.
a) there might be a "better" version of the INTEL MPI available (some versions of the intel tools have a compiler option -mt_mpi if I remember correctly)
b) you could of course see if you can get a newer intel toolchain on your machine :-)
c) you could be very brave, comment out the stop and see what happens. I actually do not 100% understand why MPI_THREAD_FUNNELED support (which we require and which
states that only a single task will call the MPI) adds to MPI_THREAD_SINGLE (which you have and which will mean you have only one thread) in terms of the stuff we do.

Daniel

You are trying a rather advanced calculation here. In particular, the l_relaxSQA as well as the l_mtNocoPot feature for such a system is probably not well studied yet. As these different magnetic systems you can describe with these features often are separated by very small energy differences one would expect convergence problems.

I would be worried about convergence in the sense that the "magnetic degrees" of freedom might converge much much slower that the charge. If this is the case you should see a situation in which the charge converges up to some point and then the magnetisation direction continues rotatating very slowly. I believe that this might be a fundamental problem of such calculations and we are currently thinking e.g. about better preconditioners to deal with those.

Of course if you converged to a distance of 1E-5 your convergence is rather already and the problem could also be unrelated to magnetism but be related e.g. to a small instability in the core solver. Perhaps your property of interest is actually converged already?

Hope these comments are helpful :-)
Daniel

The installation procedure of the older FLEUR version is actually pretty different. Basically, you should first adopt the IMakefile, then run imake and if needed change the resulting makefile. Please note that this might require detailed knowledge of how to compile on your system. But let me also point out, that as a new FLEUR user I would strongly recommend against trying to use the older version as little documentation is available, and thus it will be quite difficult to learn how to use this version.

Can you actually indicate why you need to run v0.26?

Daniel

This problem arises because the git could not download the hdf5 sources. This might be due to different reasons. Most probably a connection issue of some kind, e.g. your computer does not allow a git clone or you can not access the server. You could try to run the command
' git submodule init external/hdf5-git ' in your fleur source directory to get more direkt info. You could also verify that a `git clone https://github.com/HDFGroup/hdf5.git` works correctly.

Daniel

Thanks a lot for the report, we will look at this. I will also move this discussion to the Magnetism section.

Daniel

There is a socscaling parameter available in the species section of the inp.xml. You find a very short documentation also at https://www.flapw.de/MaX-5.0/documentati...species-section

Hope this helps,
Daniel

Thanks for this report. I must confess I looked into the code and could not understand why this does not work. We will investigate this in more detail and come back to you. Meanwhile, please change these parameters directly in inp.xml.


EDIT: I think I fixed the bug. Should not be present in the development version/future versions.
Daniel