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.
Posts: 49 | Last online: 09.24.2021
Date registered
not specified
    • Gregor has written a new post "k-point path" Yesterday

      The reciprocal lattice is written out to the banddos.hdf file. In the user guide you can find instructions on how to print a band structure from that file. This implies usage of the reciprocal lattice vectors.

    • Gregor has written a new post "Missing time-reversal symmetry in soc calculation" 09.20.2021

      You may want to specify a spin-quantization axis in the inpgen input to automatically generate a compatible k-point set. It should also be possible to just create a new k-point set with the inp.xml file in which SOC is activated.

    • Gregor has written a new post "Convergence problem in rare-earth system" 09.08.2021

      Dear xiuxian,

      Could you give us an impression on how bad the convergence looks like? As mentioned in another discussion I don't use
      the old Fleur version. For the new Fleur version I modified the input slightly (and also switched off LDA+U) and see a slowly
      converging system, but there seems to be progress. After about 50 iterations I am at a charge density distance of about 0.1.

      Does it look much worse for you? What I do and what is probably not done in the old Fleur version is that I delete the mixing
      history every 15 iterations (The broyd files in the old Fleur version). That may make a difference.

      I also saw that your usage of LDA+U is uncommon in the sense that the J value is 0.0. There are formulations of LDA+U that
      abstract from a J and work with an effective U that is slightly different, but typically J is about 0.8 to 1.0. Also please be aware
      that the LDA+U approach can stabilize different states, depending on the initial density matrix and how you deal with the
      density matrix. It may give hints to inspect which states are occupied. Maybe you get a problematic configuration and have
      to guide the LDA+U calculation into another configuration.

    • Gregor has written a new post "Error when creat charge density" 09.01.2021

      Strange. I could imagine that this is due to different tolerances in different parts of the code. You provide pi/2 with a certain precision. This may be detected and corrected to "pi/2" at some places but not at others, leading to inconsistencies. But that is just a guess. Could you attach the inp, kpts, and sym.out files? I cannot generate them myselves because nowadays I only work with much newer versions of Fleur. I will make another person, more familiar with the here-used Fleur version, aware of this discussion.

    • Gregor has written a new post "Error when creat charge density" 08.31.2021

      Did you generate the fleur input in a directory that only contains the inpgen input? It may be that you had files in the directory that were actually made for a different set of symmetry operations. Then you get inconsistent input that may lead to such an error.

    • Gregor has written a new post "Problems with FLEUR installation after OS reintstall" 08.24.2021

      This is strange. Sorry for not replying in the last days. I was/am on vacation. We will investigate this behavior. Thank you for reporting the cause of the problem.

    • Gregor has written a new post "Problems with FLEUR installation after OS reintstall" 08.14.2021

      It is difficult to directly understand this. We probably have to check several different possible causes. Could you first provide the output of calling:



      Sometimes there is trouble with the c compiler if the locale is not set properly.

    • Gregor has written a new post "State occupations" 08.11.2021

      One more comment: The single electron in the 4s shell in Cu is actually correct. When you take a look at a periodic table that shows the alectron configuration of Cu in a solid, you see that this is [Ar] 3d10 4s1. The full occupation of the 3d states is implicit because these are specified as velance states and no other occupation for them is provided.

    • Gregor has written a new post "State occupations" 08.10.2021

      These are just default values obtained from a simple algorithm (maybe some numbers are even hard-coded, based on experience). There is a slight difference in their meaning for core states and for valence states. Typically they are only written out for partially filled valence states, but one can also specify these occupations for other states. Core electron states and valence states, for which these numbers are not specified, are assumed to be fully occupied. Actually, we are in the process of invetigating whether these default occupations should be changed to obtain better starting densities.

      For both valence and core states they are used for determining the starting density for your calculation. For the valence states these numbers are not used for anything else. There are some situations where you might want to change them before running a calculation. An example is the case where you want to perform a magnetic calculation but realized that you lose the magnetic moment during the calculation. Then it sometimes helps to increase the starting magnetic moment, which is implicitly defined by these numbers. You may also want to change them if you intend to have an antiferromagnetic starting density, though in that case you can also use the atomSpecies/species/electronConfig/@spinFlip switch to swap the meaning of spin-up and spin-down occupations for a certain species.

      For the core electrons the occupation numbers are used even after the creating the starting density in every iteration when occupying the states for generating the charge density. Your calculation may be based on core holes where you remove a single electron from the core and put it into the valence window.

    • Gregor has written a new post "something wrong with stars%kmxq_fft or nq3_fft" 07.05.2021

      Dear Terry,

      The new star genereator, we are working on, is not yet in a git commit. But there is a simple solution to your problem, I hope.

      Please try to replace in your inpgen input file the line


      &input cartesian=f film=t /



      &input cartesian=f film=t symor=t /

      The problem is that the star generator at the moment cannot deal with certain symmetry operations, mostly nonsymorphic symmetries for film systems. The symor=t option tells the input generator to ignore nonsymmorphic symmetries. In the end there will be only two symmetry operations in your sym.xml file instead of 4. But that is no problem.

    • Gregor has written a new post "Layer resolved Magnetic Anisotropy Energy" 06.21.2021

      Yes, you have to find out by yourself which atom types ("atomGroup" in the inp.xml file) belong to each layer. The atomGroups in the inp.xml file have the same order as the numeration of the atom types suggests. So you can just have a look at the atom positions of each atomGroup and then count. Atom types are not the same as atom species.

    • Gregor has written a new post "Layer resolved Magnetic Anisotropy Energy" 06.19.2021

      I understand the figure caption such that this is an approach with the socscale parameter, though not in the sense that SOC is switched off in specific layers, but in the sense that it is only switched on in the the respective layer.

    • Gregor has written a new post "Layer resolved Magnetic Anisotropy Energy" 06.18.2021

      Another remark:

      The magnetic force theorem is an approximative technique. Of course, it is more precise to calculate the MAE on the basis of the total energies from self-consistent solutions for the different configurations of the SQA. But I guess you are aware of this.

    • Gregor has written a new post "Layer resolved Magnetic Anisotropy Energy" 06.18.2021

      I am not familiar with such calculations. In general magnetocrystalline anisotropy is an effect due to spin-orbit coupling. Since this is a relativistic effect it mostly plays a role within the inner parts of the MT spheres of the atoms. What you could do is to identify which atoms are in which layers and switch on or off the inclusion of SOC in the treatment of these atoms. As described at you could use the socscale parameter for such a calculation. If you compare the MAE with and without SOC at certain atoms this may give you the quantities you are interested in. But this is just a guess: As mentioned I am not familiar with layer-resolved MAEs and I don't know whether the approach I sketch actually gives you what you want to see. This is something you have to think about in detail. I am not aware of any other mechanism to calculate a layer-resolved MAE with Fleur.

    • Gregor has written a new post "configure with hdf5 error" 06.16.2021

      How did you download Fleur? The -hdf TRUE option is only avalible if you clone it from the git repository:


      git clone --branch release

      and then it should work.

      If it doesn't work with that starting point we need to have a closer look at the output of the configure script call and the error messages. Could you prvovide that data?

      (Note: This hint actually came from Matthias.)

    • Gregor has written a new post "波段输出" 06.15.2021

      I think, px, py, pz can nicely be distinguished by this approach.

    • Gregor has written a new post "波段输出" 06.15.2021

      @Henning: How do you compare s character with maybe d character? The point is that s-like states typically are very delocalized wheras d-like states are rather localized. This gives them a larger weight on a certain atom. This becomes relevant if the character is not 100% clear, e.g., if there is some hybridization. Could you provide somewhere the formular with which you decide on the color? Maybe in the documentation? ...or, of course, here?

    • Gregor has written a new post "Advice on Hardware optimized for FLEUR calculations" 06.11.2021

      It is great to hear that you get good results and benefit from it!

      In general the performance of Fleur depends on the hardware as well as on the software infrastructure of compilers and libraries. The more exotic your hardware is the more problematic is getting a good software infrastructure that works and gives good performance. Of course, we always work on making Fleur more performant on every type of hardware it is used on. This implies that the best hardware may come with problems now but has large benefits in a few years. But I guess you want to have a solution now and not sometime in the future.

      1. I think for a normal Fleur user computations on GPU hardware should be avoided at the moment. This is because the available software infrastructure still needs some development to make flawless installation and usage of the code possible. Also we probably have to tune a few more code sections to such setups.

      2. The next choice is Intel or AMD hardware. Fleur works on both but there are differences. Traditionally many of the used software libraries and also Fleur itself was mainly used on Intel hardware. This means that it is easy to get good performance out of such a setup. For AMD hardware the choice of software libraries, compilers, and compiler options again is critical to get good performance. But the issue is much smaller than for GPU hardware. Our inhouse cluster bought last year actually uses AMD EPYC CPUs. You should also know that the AMD processors get their performance advantage over Intel processors mainly by having more cores. This means that you have to take care to choose good parallelization schemes on such hardware to get the best out of it.

      3. For our inhouse cluster we have 128 GB RAM for 32 CPU cores on each node. That should be a good RAM/cores ratio.

    • Gregor has written a new post "Error message: Error in expression" 06.11.2021

      I made an issue for this ( ) so that we don't forget to fix the problem and you can see when it gets fixed. Thank you for reporting this problem!

    • Gregor has written a new post "Error message: Error in expression" 06.11.2021

      I can reproduce this. It is coming from the k-point set. Just have a look into the kpts.xml file and you will immediately see the problem. Somehow the z-coordinates get messed up. This obviously shouldn't happen and obviously is a bug. I'll investigate this, but here is a quick fix.

      1. Replace the content of your kpts.xml file with


      <kPointList name="default" count="1" nx="1" ny="1" nz="1" type="mesh">
      <kPoint weight=" 1.0000000000000"> 0.0 0.0 0.0</kPoint>

      This will give you a trivial parsable k-point set.

      2. Invoke the input generator with


      inpgen -inp.xml -kpt

      This will generate another default k-point set. The new default k-point set has correct entries.

      3. Change the selected k-point set in the inp.xml file to the newly generated k-point set. The name will probably be "default-2".



Sign up, to leave a comment

Xobor Einfach ein eigenes Xobor Forum erstellen