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.
Please be aware that we will have an online hands-on tutorial on Fleur from Sep 16th to Sep 20th.
If you are interested in participating please consult the following page to obtain more information and a link to the registration page. The registration page assumes that you have an account at some research affiliation, but not all affiliations are listed. You can also register with Github, Google, or ORCID Accounts.
For me all versions of the HDF5 library work. If you have problems with one, just use another. We have more experience with version 1.12 than with version 1.14.
This is a problem with our k-point set generator. I assume that you want to perform the calculation at the Gamma point only. If so, you can overcome the issue by changing the last line of your inpgen input to
1 2 3
&kpt div1=1 div2=1 div3=1 gamma=T /
Let me also add that FLEUR might not be the perfect choice for calculating properties of molecules. FLEUR is a code for crystals, thin films, and for surfaces of crystals. Calculations on single molecules in large boxes are computationally extraordinarily expensive with it. A more natural choice for such systems would be the Siesta code. If you nevertheless want to perform these calculations with FLEUR, you probably need several nodes of a compute cluster and it might also be a good idea to link FLEUR to the ChASE eigensolver and try that one out (maybe via linking to ELSI), though I am unsure whether calculations over multiple compute nodes can be performed with that code path at the moment. The ChASE eigensolver has strengths when the number of eigenfunctions you want to calculate is very small in comparison to the number of basis functions. Single atoms or molecules in a large box are a prototype example for this.
Could you attach the inpgen input? At the moment I have not yet a clear understanding on what is going on there. We have performed calculations on larger unit cells, so that is not in general a problem, though I understand that it is pretty large.
What do you actually want to do with the Wannier functions? If you only want to interpolate the band structure, you don't need an eig.hdf file. The file is needed if you need to keep the phases of wave functions fixed over multiple FLEUR runs with different Wannier jobs.
Also: I think we are missing some documentation on the use of hybrid functionals with FLEUR. Do you know everything you have to do in this context?
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.
A new version of FLEUR (MaX-7.1) has been released today. It is mostly a bugfix release to the previous FLEUR version. Everything should be better with this new release. :)
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.
Also version v0.26 supports the use of local orbitals, though it is slightly less user friendly than in the newer FLEUR versions.
1
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.
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.
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
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.
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.
The configuration of FLEUR with Wannier90 support is broken in the release MaX 7.0. In the develop version of the code this is already fixed. If you need the Wannier90 library together with FLEUR, please switch to the develop version of the code, pull the newest developments and checkout the respective commit with the fix:
With that version of the code (just directly after the MaX7.0 release) the configuration with Wannie90 works again.
Please don't misunderstand what I said. The command line option "-wannier TRUE" for the configure script does not work and also never was functional. You still have to build the Wannier90 library separately from FLEUR and then invoke the configure script with an option adapted from
1 2 3
-libdir ABSOLUTE_PATH_TO_WANNIER90_LIBRARY
where you replace ABSOLUTE_PATH_TO_WANNIER90_LIBRARY with the sbolute path to the directory in which you have the libwannier.a file.
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":
1
inpgen -noco -f myInput.txt
For spin-spiral calculations an alternative is to add something like
1
&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
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.