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: 148 | Last online: 03.24.2023
Date registered
not specified
    • Gregor has written a new post "Error in spin-spiral calculations for non-zero q vectors" 03.10.2023

      The "Too low eigenvalue detected" error actually indicates that the potential in your calculation got messed up. Typically this is related to an issue in the input, like a very high kmax or too small lattice constants or similar. These exact points don't seem to be an issue in your setup, maybe it is something else. Could you try reducing the MT radii by 3%?

    • Gregor has written a new post "Error in spin-spiral calculations for non-zero q vectors" 03.10.2023

      Actually, please try out the development version. The changes I was talking about are probebly newer than the 6.0 or 6.1 release.

      You can clone the git repository at to get the development version.

    • Gregor has written a new post "Error in spin-spiral calculations for non-zero q vectors" 03.08.2023

      I am aware that you already reported this issue a long time ago. Meanwhile we worked a lot on related parts of the code.
      Could you test whether the problem still occurs with the newest development version of the code?

      What version of the code are you actually using?

      Best, Gregor.

    • Gregor has created the topic "2023 Fleur hands-on tutorial". 02.22.2023

    • Gregor has written a new post "nn.NE.ntype" 02.22.2023

      I now rephrased the error message in the development version to "Number of atom groups in Fleur input file and in the charge density file don't match.". I hope in future this will be more understandable.

    • Gregor has written a new post "nn.NE.ntype" 02.22.2023

      Just for clarification: This error message occurs when the number of atom groups (types) in an old (non hdf5) charge density file is inconsistent with the number of atom groups in the Fleur input file. Such a file inconsistency typically occurs when a Fleur input file is regenerated with slight modifications, but an already existing charge density file in the directory is not removed.

    • Gregor has written a new post "nn.NE.ntype" 02.21.2023

      Did you change the inp.xml file after already having a charge density file in the directory?

    • Gregor has written a new post "nn.NE.ntype" 02.21.2023

      Dear Terry,

      There shouldn't be any limits like that. Actually it looks like an error message no user should get. Could you attach the inp.xml file so that I can investigate this?

    • Gregor has written a new post "Valence occupations" 02.06.2023

      Dear Terry,

      In the out.xml file you find tags "mtCharge" that show the s-, p-, d-, and f-projected charges in the MT spheres of each atom type. Furthermore if you calculate a band structure or a density of states, there are weights in the banddos.hdf file showing these projections energy- or even state-resolved. Does this already answer your question or do you need more?

      Best, Gregor.

      PS: For the data in the banddos.hdf file see that part of the documentation:

    • At the moment this is an experimental feature. Therefore it can only be activated in the code. This is done by setting "lResMax" to 3 or something similar in fleurinput/types_input.f90.
      I totally forgot how the output of this feature looks like. You will have to look into the code to reverse engineer the output. Also: If I remember correctly there probably is a factor of 2
      missing in the output, though you can interpret this in terms of "What are the units?".

      Feel free to check it out and give feedback. If this feature is needed I make using it more comfortable. Note that at the moment I don't know whether this is compatible to MPI parallelization.

    • Gregor has written a new post "Facing the error: Error occurred in subroutine: make_spacegroup " 11.28.2022

      This is a rather new warning in the code.

      When you invoke the input generator one thing that is done is the detection of symmetries in the unit cell. Symmetries may spped-up and stabilize calculations. But most of the time, you also don't rely on them. You have two optione:

      1. You adapt your input such that all values in it are provided with higher precision, which may result in more symmetries detected.
      2. You ignore the warning and go on with your calculation. To do this you can either invoke inpgen with the additional command line option "-warn_only" or, as explained in the terminal output, put a file "JUDFT_WARN_ONLY" in the directory of the calculation. If you proceed in this way the warning is still written out, but the program proceeds and writes out the Fleur input.

    • Gregor has written a new post "There is no Fermi energy generated after the SCF calculation." 11.28.2022

      There probably also is an output like


      first approx. to ef (T=0) : 0.211908 htr (energy of the highest occ. eigenvalue)

      in the out file. You can also take that.

    • Gregor has written a new post "There is no Fermi energy generated after the SCF calculation." 11.28.2022

      The Fermi energy should actually be written out in the lines following the

      fermi energy and band-weighting factors:

      output. If this is not the case it must somehow have gotten lost in the output. But there is another
      point where it definitly is written out: In the out.xml file.

      Please do a

      grep -i Fermi out.xml

      to extract that output.

    • Gregor has written a new post "How to run meta-GGA or hybrid?" 11.15.2022

      Dear Terry,

      For hybrid functionals there is a refactoring of the code at the moment. If you use the development version if the code, the PBE0 functional works, with the exception of calculations with multiple atoms in the unit cell that can be mapped onto each other via inversion symmetry. In that case you would have to perform the calculation without making use of inversion symmetry. The HSE06 functional will be functional again in a few months. We have someone working on it at the moment. Also for hybrid functionals calculations you might have to run fleur with the command line option that disables the use of the progress thread lib. case you get a deadlock otherwise.

      MetaGGAs are not implemented at the moment.

    • Gregor has written a new post "Configure with hdf5" 09.23.2022

      You compiled Fleur correctly, don't worry. It is just that at runtime it also has to be known where to find the library you want to link to. For this there exists an environment variable LD_LIBRARY_PATH. You have to also put the path for the HDF5 library into that environment variable. If I see it correctly this means that you should invoke a command like


      export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/hdf5/lib

      if you are using a bash shell or a z shell. In other terminal shells this will look slightly differently. I suggest to put that line into your .bashrc or .zshrc file if you use one of these shells. With this you don't have to type it in each time before you want to start FLEUR.

    • Gregor has written a new post "Plot spin-dependent Rashba effect" 07.25.2022

      Please also note that this visualization is only possible on the basis of the banddos.hdf file, e.g., with the script above. The association of the states with the two spins is encoded in weights. These are not available for the gnuplot script, which is also often used to plot band structures.

    • Gregor has written a new post "Plot spin-dependent Rashba effect" 07.23.2022

      Dear Jiaqi,

      To see these results it is not needed to switch on l_noco. Leave it set as "F". If the l_noco switch is set to "T", the calculationSetup/coreElectrons/@ctail switch also has to be set to "F". That is what the error message tells you.

      You actually have to do the following things to see the spin-polarization in the band structure:

      1. In the inpgen input you have to select a spin-quantization axis, for which you actually expect to see the effect. For the BiTeCl example you wouldn't see anything interesting if this is the z-axis, as it is set in the tutorial. For that case it would be more reasonable to set both angles to 1.570796327=0.5*Pi, i.e., the y-axis.
      2. In the fleur input file you have to set jspins to 2, just as you did.
      3. When you execute fleur, you obtain a warning because you run a spin-polarized fleur calculation without having a magnetic moment in the setup. Just ignore that warning by invoking fleur with the command-line switch -warn_only.

      With the new inpgen input the input generator will find less symmetries in the system, which means that you get more k-points for the calculation. Also in the fleur calculation you have to set up and solve the problem for both spins. These two aspects imply that the calculation will take much longer than in a non-spinpolarized calculation.

      I attach for the BiTeCl example inputs for the self-consistent field calculation (inp1.xml) and the band structure calculation (inp2.xml) and a slightly modified python script from the fleur website, adapted to visualize the respective effect ( The attached image bandstructure.png shows the visualization you obtain from this. In cases of degenerate bands it may happen that there are sudden color-changes, because the other band comes to the foreground.

      Please note that the band structure plot follows a path from -M over gamma to +M, but both, -M and +M, are denoted as M in the plot.

      I hope this clarifies how to obtain the visualization you want to have.

    • Gregor has written a new post "Jij calculation error" 07.13.2022

      I now reproduced this behavior and there seems to be an issue in the code. I will have a look into this.



Sign up, to leave a comment

Xobor Einfach ein eigenes Xobor Forum erstellen