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.
[b][/b]
[i][/i]
[u][/u]
[code][/code]
[quote][/quote]
[spoiler][/spoiler]
[url][/url]
[img][/img]
[video][/video]
Smileys
smile
smile2
spook
alien
zunge
rose
shy
clown
devil
death
sick
heart
idee
frage
blush
mad
sad
wink
frown
crazy
grin
hmm
laugh
mund
oh
rolling_eyes
oh2
shocked
cool
[pre][/pre]
Farben
[rot][/rot]
[blau][/blau]
[gruen][/gruen]
[orange][/orange]
[lila][/lila]
[weiss][/weiss]
[schwarz][/schwarz]
Gregor
Posts: 165 | Last online: 02.27.2024
Date registered
04.07.2021
Sex
not specified
    • Gregor has written a new post "the input file of Holmuim" 12.22.2023

      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":

      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

      1
      2
      3
      4
      5
      6
      7
      8
      9
       

      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.

    • Gregor has written a new post "LDA+U: defining density matrix starting points" 12.22.2023

      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.

    • Gregor has written a new post "Error message: Diagonalization via LAPACK failed(zhegvx/dsygvx)" 12.21.2023

      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.

    • Gregor has written a new post "fleur install cannot find libxml2" 10.27.2023

      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:

      1
      2
      3
       

      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:

      1
      2
      3
      4
       

      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.

    • Gregor has written a new post "Error message: Diagonalization via LAPACK failed(zhegvx/dsygvx)" 07.20.2023

      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.

    • Gregor has written a new post "How to calculate magnetization density?" 07.19.2023

      I assume you refer to figure 2 of that paper. I don't know how exactly they visualized this data, but I can tell you how to obtain it. I attach some simple example input for such a Cr layer that I once used for some tutorial. This is not converged with respect to parameters. With that input you first have to obtain a self-consistent density. Then change the iplot parameter in the inp.xml file to 2 and run FLEUR again. This will generate several XCrySDen structure output files containing data on the density, the magnetization density, the direction of the magnetization and so on. In detail you obtain the files denIn_A1.xsf denIn_A2.xsf, denIn_A3.xsf which contain the magnetization in the three directions, denIn_Aabs.xsf for the absolute value of the magnetization, denIn_Aphi.xsf for the in-plane magnetization direction in units of pi, and denIn_Atheta.xsf for the out-of-plane magnetization direction. The visualized data from figure 2 is available in the denIn_Aphi.xsf (for the arrows) and denIn_Aabs.xsf (for the gray-level coding) files. I attach an image with a separate visualization of the data in two plots. The direction here is color-coded on a linear scale and the absolute value of the magnetization density on a logarithmic scale. These are simple visualizations that you can obtain with XCrySDen. The figure in the paper is probably hand-crafted and not just output from some visualization tool. To create a similar plot you might want to look at the Python library matplotlib or even try to create something with Povray or a similar tool allowing a lot of user control. Interpreting the data in an xsf file is not too difficult. This is a simple and well-documented text format and thus directly readable.

    • I think, you went in the right direction in your tries to overcome this problem. When you have a plane-wave basis set all basis functions are orthogonal with respect to each other. We don't have such a PW basis set, but LAPWs. This means we replace the plane waves by some augmentation in some augmentation regions like the MT spheres or the vacuum regions. In unfortuitous calculation setups this may lead to a numerically linearly dependent basis and I believe that this is what is happening in your calculations, at least you seem to be near such a situation. As you already mentioned, the strategy in such a situation is to decrease the volume of the augmentation regions and thus make the interstitial region larger. Another thing you can try is to increase the lmax cutoffs in the MT spheres. I attach an input that is a modification of your input, in which the vacuum boundary is pushed a little bit away, the MT spheres are a little bit reduced (though still larger than in your setup) and the lmax cutoffs are slightly increased. With this I don't get the warning you get. I cannot guarantee that everything is completely fine already, but I guess these are modifications that go in the right directions.I didn't check the electronic structure, so please be skeptical (as you probably already are and should be when performing DFT calculations) and do so yourself. The new parametrization might not be perfect for your application, but now you know the important knobs you can play with. :)

    • Gregor has written a new post "Configure can't detect SpFFT and Libxc" 07.10.2023

      Please show us the exact command lines for invoking the configure script and a clear description on how you compiled the libraries.

    • Gregor has written a new post "Error message: Diagonalization via LAPACK failed(zhegvx/dsygvx)" 06.23.2023

      Sorry, I was on vacation, so it took a bit of time until I could look at your issue.

      There are a number of issues in your inp.xml file. For example you define multiple local orbitals with the same parameters and you also define local orbitals for states that you actually treat as core electron states. But even beyond these aspects you seem to have a tricky system you want to describe. I created a new Input file for the same system that seems to work. Maybe you still have to perform a few adjustments for that input, but it may be a good starting point for you. I attach it. Right now I'm unsure whether there is also some problem on the code level present. It may be that there are issues with local orbitals for your system. The input I provide does not use any local orbitals.

      NOTE: The input I provide has a newer version number than what you used. You might have to adapt it also with respect to this.

    • Gregor has written a new post "Configure.sh can't find mpi" 05.09.2023

      The most probable guess on what went wrong is that probably the wrong compiler was detected and used. If you want to use MPI, you have to use the MPI compiler wrappers. You probably have to write something like

      FC=mpif90

      or similar just at the very beginning of the command line in which you call the configure script: In front of the configure script.

    • Gregor has written a new post "e>vz0 and e >= vz0" 04.17.2023

      The error message indicates that the vacuum energy parameter is above the vacuum potential at an infinite distance from the film. In the old FLEUR this parameter is set in the enpara file.

      If you, however, calculate a metallic film of such a thickness, it is probable that this is due to charge moving around in the film. This can often be overcome by performing some scf iterations with linear mixing and a very small mixing parameter in the beginning. A more elegant and efficient solution would be the use of the Kerker preconditioner, which is available in newer FLEUR releases, but not yet in version v0.26.

    • 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 https://iffgit.fz-juelich.de/fleur/fleur/ 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.

Recipient
Gregor
Subject:


text:

Sign up, to leave a comment


Xobor Einfach ein eigenes Xobor Forum erstellen
Datenschutz