You mean, you want to use the self-consistent density from FLEUR and use it for a single-shot calculation to obtain some property with QE? That is not possible because of many reasons. First, on the technical side the storage of the density for the different codes uses different formats. Next, a density you obtain from and use in pseudopotential calculations, like in QE, differs strongly from an all-electron density, as you have with FLEUR. For example because of the presence or absence of core electrons in the calculations.

If you want to use multiple codes, common approaches might be to do a structural optimization with one code and another part of the calculation with another. For example, you might want to perform a structural optimization with QE and then investigate some magnetic property, for example some spin-spiral dispersion with FLEUR. Different codes have different feature sets and strengths. By combining them you could get the best of different worlds. Such approaches would use self-consistent densities for each code separately. You might also perform the same calculations with different codes, just to check the agreement of the results, maybe just for a subset of very important calculations.

With respect to an xsf->bxsf conversion, that was just a guess from me. If you can't find something like that, it probably doesn't exist. Maybe you can write a converter on your own. At least the xsf file format is rather simple. I don't know how the bxsf file format looks like.

In general: If we write out xsf density files for plotting, they are really just for plotting. They don't have the resolution in the vicinity of each atom, that would be needed to perform some serious calculation with it.

Also see equation 11 in https://www.doi.org/10.1103/PhysRevLett.77.3865 for the theoretical background on this approach.

That subroutine can be called for spin-up and spin-down separately, which is performed in

https://iffgit.fz-juelich.de/fleur/fleur...pot/easypbe.f90

For noncollinear calculations the projection on up and down spin is locally performed according to the local magnetization direction.

I hope this helps.

Dear PatrizioGraziosi,

We typically write out the structure in a file struct.xsf. When you perform density plotting, you also obtain the charge density (and you can also get the potential) as an XSF file. These files can be read in by xcrysden.

We don't support the bxsf file format, but it might be that xsf can be converted to bxsf, maybe by xcrysden. Beyond the mentioned quantities we don't write out other quantities to an xsf-like format.

Dear bailing80,

Also version v0.26 supports the use of local orbitals, though it is slightly less user friendly than in the newer FLEUR versions.

0.34058072  electrons lost from core.
 

That is a gigantic amount of core electrons reaching out of the MT sphere. You have to remove the highest core electron states from the core electron treatment and add them to the valence electron treatment.

If you want to avoid using local orbitals, it may also be an option to move the conventional LAPW energy parameter for the respective l-channel down to the states in question. At least, if you don't have other valence electrons with the same l-character. You can set the energy parameters in the 'enpara' file.

This issue should be fixed in the newest development version.

Dear Ling Bai,

Could you paste the actual FLEUR input file that you use, not the inpgen input file?

The inwint error message essentially hints at a messed-up the potential. This may, for example, be due to a ghost band. You are using an old FLEUR version where we had a rather aggressive parameter setup. In your case it may be that you need local orbitals for the 4p states and that you cannot really describe them as code electrons. I would like to have a look at the FLEUR input file to see whether this assumption about your setup is correct. You might also have a look at how many core electrons are extended to beyond the MT sphere boundary. Just "grep lost out" to get that data. Everything above 0.01 electrons may be problematic.

Best, Gregor.

Dear Yule,

The calculation of the exchange and correlation energy is not general to GGA, but depends on the choice of the actual functional. It is also not local to a specific section of the code. For example, for the PBE functional you can find relevant code parts in

https://iffgit.fz-juelich.de/fleur/fleur...-pot/corpbe.f90

https://iffgit.fz-juelich.de/fleur/fleur...pot/excepbe.f90

https://iffgit.fz-juelich.de/fleur/fleur...pot/vxcepbe.f90

and the driver routine

https://iffgit.fz-juelich.de/fleur/fleur...pot/easypbe.f90

I hope this helps.

Dear Yule,

Discrepancies in the definition of q points and the spin-spiral dispersion relation can stem from 3 causes...

1. It may be a matter of the coordinate system in which the respective code expects the q-points to be provided. In FLEUR we expect the q-vector in terms of reciprocal lattice vectors. Other codes may expect them in terms of cartesian coordinates. If you multiply the vector (0.5,0.5,0) with the reciprocal Bravais matrix you obtain a vector that is only in the z-component nonzero. You then have the q-vector in cartesian coordinates. As said, it may be that some other code or some specification in the literature uses cartesian coordinates.

2. The unit cell of your system may be specified in different ways, which then also affects the reciprocal Bravais matrix. The q-vector of (0.5,0.5,0.0) is related to the common specification of the primitive unit cell of an fcc crystal. This, of course, is not unique. You can also specify other primitive unit cells for fcc crystals and you may also work with a conventional unit cell containing more atoms.

3. I was asking about the output file, because in versions 6.x of FLEUR we had a bug that affected the spin-spiral dispersion if you also have local orbitals as part of the used basis set. If that is the case I would suggest to use the newest development version of the code. Please check whether these two conditions - version MaX 6.x of the code and local orbitals - may be a cause for the discrepancy.

Best, Gregor.

Dear Cathy,

I assume you are referring to the evaluation of gradients in non-collinear calculations. If this is not the case, please clarify what you are actually interested in.

For the evaluation of gradients we offer two different approaches. You can see this in multiple files. For example in the file https://iffgit.fz-juelich.de/fleur/fleur...tofrom_grid.F90 the switch l_rdm controls which of the two approaches is used.

Best,

Gregor.

Dear Yule,

Could you please attach an out.xml file (you might have to add a .txt suffix) so that I can better understand what is happening!?

Dear zakiari12²²²²²,

To add default input for calculations on noncollinear magnetism to your FLEUR input file, you have to invoke the input generator with the command line option "-noco":

inpgen -noco -f myInput.txt
 

For spin-spiral calculations an alternative is to add something like

&qss 0.5 0.3 0.4 /
 

or some other axis to the bottom of your inpgen input file and invoke the input generator in the normal way without the need for the "-noco" option.

A third option to obtain noco input in your FLEUR input file is to add vectorial magnetic moments to your inpgen input, e.g., something like

bcc Cr strange magnetization
 
&lattice latsys='cP' a0=1.8897269 a=2.87100 /
 
2
24.0 0.0 0.0 0.0 : 1.7 0.0 0.0
24.1 0.5 0.5 0.5 : 0.0 1.7 0.0
 
 

and invoke inpgen again without the need for the "-noco" option.

Please note that certain noco changes in your FLEUR input file after generation may break the symmetry of the system. For such cases it is an option to invoke the input generator additionally with the "-nosym" command line switch.

I hope this helps, otherwise please clarify your question a little bit more.

Best, Gregor.

Dear Mohammed,

I hope, this question is also answered by my answer to your other question at Question regarding how code writes the n_mmp_mat_out file for LDA+U calculations

If not, please clarify your question a little more.

Best, Gregor.

Dear Mohammed,

There are blocks of 7x7 complex numbers (2 real numbers per entry) in the n_mmp_mat_out file. Each block belongs to a certain U and spin value that you specified for the calculation. The order is [U_1,Spin1], [U_2,Spin1], [U_1,Spin2], [U_2,Spin2]. So first you see data for every U for spin-up, then all the data for spin-down.

The blocks contain entries for m=-3 to m=+3 for rows and colums. If you specified a U for d states (l=2) then the outer edge of this matrix is all (0.0,0.0), because only the entries from m=-2 to m=+2 are needed. Beyond this the entries should be the same as what you see in the out.xml file.

You can modify the density matrix that FLEUR uses by copying the n_mmp_mat_out file to a file "n_mmp_mat". Whenever such a file is present it will be read in as the density matrix and then the code will directly rename it to n_mmp_mat_old. Otherwise the density matrix will be read in from the cdn.hdf file. Of course, the density matrix changes over the iterations. If you want to keep it fixed you have to adjust the mixing for LDA+U to linear mixing with a mixing parameter of 0.0. This is sometimes done to stabilize a certain occupation before allowing the density matrix to adjust to find the self-consistent solution for that configuration.

Please also have a look at the LDA+U documentation on the FLEUR website: https://www.flapw.de/MaX-7.0/documentation/ldaU/

Best, Gregor.

Dear vini,

I just retried the calculation for q=0.0 and q=0.5 with the new MaX 7.0 release of FLEUR. Your inputs with and without LOs now lead to energy differences between these two q values that agree with a deviation of about 1-2%. So: The bug with spin spirals and LOs is fixed in this new release.

What I also saw is that the energy difference is twice the value that you showed in the plot. Maybe you write mRy, but use mHtr which is actually directly available as output or you write out the energy difference per Gd atom or something similar.

Best, Gregor.

1. There are 2 aspects of libxml2 that have to be available. On the one hand you need the .so file and on the other you need some C header files. When you install libxml2 these might be in two different packages, if you use some package manager, e.g. one with the name libxml2 and one with the name libxml2-dev or similar.

2. We found that you really need a ".so" file. A ".so.2" file is somehow never found. Please check whether you have one available and if not make a symbolic link with the ".so" name to the ".so.2" file in a directory that you specify by libdir. Only specify the directory in libdir, not the file.

3. If you don't have the header files and are not able to put it in a global directory, but only in a local one, you have to specify the include directory for these files explicitly. There is one more problem here: What you specify as "-includedir" is not used by the C compiler. You thus have to directly add it to the compiler command that you can put directly in front of the configure script call, e.g. something like:

CC="gcc -I/myhome/mylibxml2includedirectory/" ./configure.sh ...
 
 

I hope that helps. If not: Please provide more output from the configure script call. Up to now it is not yet completely clear what is actually missing. There are two lines from the configure script. Something like:

XML Library found for linking:TRUE
XML Library found for C:TRUE
 
 

If FALSE, the upper one indicates a problem in the detection of the ".so" files, the lower one a problem about the C header files.

I did calculations for both setups and for q=(0.0 0.5 0.0) and q=(0.0 0.0 0.0). At the moment I cannot really say what is going wrong, but the calculation with LOs looks slightly suspicious to me because of two observations. 1) The Fermi energy changes a lot between the two different q. 2) A considerable amount of charge has to be "corrected" for the q=(0.0 0.5 0.0) calculation, i.e., the output of the valence charge is inaccurate and thus it has to be automatically corrected. I'm unsure about the cause for this. It might be a good idea to investigate the band structures and density of states for both setups for the q=(0.0 0.5 0.0) case. Maybe there is something wrong in one of them. At first sight the l-projected charges in the MT spheres seem to be reasonable in all calculations. But as mentioned, probably in one of the setup something is going wrong.