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: 136 | Last online: 11.28.2022
Date registered
04.07.2021
Sex
not specified
    • 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

      1
      2
      3
      4
       

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

      1
       
      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

      1
       
      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. ...in 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

      1
      2
      3
       

      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 (plotBands.py). 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.

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

      Dear sureshravi,

      Could you also attach the kpts.xml and sym.xml files? I try to reproduce the problem and have not yet
      succeeded in doing this. Maybe there is an issue in those files and I just don't see that.

      Best, Gregor.

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

      Do you start the calculation with MPI parallelization? If yes, please try it without such parallelization. I think, a few versions ago we had a related force theorem issue that probably yields the error you show.

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

      This is really strange. I actually use a newer Fleur version. Maybe it is an issue with your older version.
      The inp.xml file validates, so I don't understand why Fleur complains about a "Closing xml element inconsistency".
      I don't see that.

      Besides that your unit cell definition stays wrong. The first idea was that you use the wrong units, but maybe
      that was the wrong cause. You want to define a two-atom unit cell of an fcc crystal, correct? But such a unit cell
      does not have the shape of a single-atom fcc unit cell. I think you construct a primitive fcc unit cell, but put two
      atoms in it.

      Just have a look at the MT radii of the Fe atoms. Those are only 1.31 Bohr in your inp.xml file. You can safely assume
      that every Fe MT sphere with a MT radius below 2.0 Bohr belongs to a pathologic setup.

      EDIT: Maybe the XML error is related to the out.xml file. But if there was an error in this older Fleur version
      it is fixed by now.

      EDIT2: I think if you want to have a 2-atom fcc unit cell, the shape would typically be a tetragonal unit cell ('tP').
      The lattice parameter 'a' would be the distance between an atom at a corner and the nearest atom at a face center
      in a conventional fcc unit cell. The lattice parameter 'c' would be the lattice constant of the fcc unit cell.

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

      @mahendra: Please try to delete all files in the directory that start with "mixing_hi".

      ...so:

      1
      2
      3
       

      rm mixing_hi*
       
       

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

      @sureshravi: I had a look at the inp.xml file you attached. With that I don't obtain an xml inconsistency as you do. But I obtain

      1
      2
      3
      4
      5
      6
       

      ************juDFT-Warning*****************
      Error message: You lost too much charge
      Error from PE:0/1
      *****************************************
       
       


      That is probably due to a way too small lattice constant. I guess you specified the unit cell in terms of Angstrom, but you need to define it in Bohr radii.

      Are you sure you actually used the correct input files? Could you show me the output of invoking

      1
      2
      3
       

      xmllint --xinclude --valid --schema FleurInputSchema.xsd inp.xml
       
       


      In the directory in which you have the inp.xml file?

    • Gregor has written a new post "Mossbauer parameters" 07.06.2022

      I made a small test on Fe with probably a bad choice for the lattice constant and surely not converged numerical parameters. ...but with the 3s as core electrons. I attach the input files (as txt files).

      I obtain:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
       

      MUE KAP ITER ENERGY (Hart) HF (KG)
      1s1/2 -1/2 -1 3 -256.5187575
      1s1/2 1/2 -1 3 -256.5192286
      1s -3.985
      2s1/2 -1/2 -1 3 -29.5092746
      2s1/2 1/2 -1 3 -29.4658118
      2s -565.229
      2p3/2 -3/2 -2 3 -24.8960406
      2p3/2 -1/2 -2 3 -24.8844792
      2p1/2 -1/2 1 4 -25.3333177
      2p3/2 1/2 -2 3 -24.8734691
      2p1/2 1/2 1 4 -25.3440155
      2p3/2 3/2 -2 3 -24.8629372
      2p 1.598
      3s1/2 -1/2 -1 3 -2.8694887
      3s1/2 1/2 -1 3 -2.7715449
      3s 300.324
      3p3/2 -3/2 -2 3 -1.6030014
      3p3/2 -1/2 -2 4 -1.5368805
      3p1/2 -1/2 1 4 -1.6302347
      3p3/2 1/2 -2 4 -1.5206076
      3p1/2 1/2 1 4 -1.6467269
      3p3/2 3/2 -2 3 -1.5077791
      3p -0.818
      HFTOT: -268.110
       
       



      Considering the bad parametrization I guess this is okay. ...and you are right. For this calculation the 3s should be described as core electrons.

      Please compare your changed input to the one I have attached to see where the differences are. When moving an electron from a valence description to a core electron description one often makes mistakes, because this is related to several changes that have to be consistent.

    • Gregor has written a new post "Mossbauer parameters" 07.06.2022

      Dear Zhiwei,

      Of course, this depends on which electrons are treated as core electrons. Could you attach the inp.xml file for which you obtain an error? I will have a look at it.

    • Gregor has written a new post "Mossbauer parameters" 07.01.2022

      Dear Zhiwei,

      The hyperfine field feature is part of an alternative relativistic solver that one can use for the core electrons. It is activated by setting calculationSetup/coreElectrons/@kcrel to "T".

      The output is kind of hidden. You find it in the out file (not out.xml). An example is this:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
       

      MUE KAP ITER ENERGY (Hart) HF (KG)
      1s1/2 -1/2 -1 3 -256.5483122
      1s1/2 1/2 -1 3 -256.5487774
      1s -4.115
      2s1/2 -1/2 -1 3 -29.5354043
      2s1/2 1/2 -1 3 -29.4920797
      2s -563.449
      2p3/2 -3/2 -2 2 -24.9224060
      2p3/2 -1/2 -2 3 -24.9108822
      2p1/2 -1/2 1 4 -25.3597744
      2p3/2 1/2 -2 3 -24.8999061
      2p1/2 1/2 1 4 -25.3704393
      2p3/2 3/2 -2 3 -24.8894053
      2p 1.592
       
       


      The HF entry which you only see for each shell is the hyperfine field in kG.

    • Gregor has written a new post "How to converge b_cons_x in nocoinp file" 06.27.2022

      What version of Fleur are you using for this?

      (Please note that we have vacation season and it may take a while until an expert is available to answer your question. The version number of the Fleur version determines which expert you need.)

    • Gregor has written a new post "Wannierise after a hybrid functional calculation" 06.27.2022

      You can always add the -eig hdf command line switch.

      Also: I am unsure, but I guess it should be possible to simply combine our Wannier functionality with hybrid functionals calculations (Note that at the moment only PBE0 is working).

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

      There also is a first line

      1
      2
      3
       

      <?xml version="1.0" encoding="UTF-8" standalone="no"?>
       
       


      missing.

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

      I don't know how you created that inp.xml file, but all

      1
      2
      3
       

      <xi:include
       
       


      lines are broken. Did you remove / modify them intentionally?

      I don't know what files you actually use to start the calculation. If you also have a kpts.xml and sym.xml file you have to add the following to the inp.xml file:

      1.

      Directly below the line

      1
      2
      3
       

      <!-- k-points included here -->
       
       


      place

      1
      2
      3
       

      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="kpts.xml"> </xi:include>
       
       


      2. Directly below the line

      1
      2
      3
       

      <!-- symmetry operations included here -->
       
       


      place

      1
      2
      3
       

      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="sym.xml"> </xi:include>
       
       


      3. Replace

      1
      2
      3
      4
       

      <xi:fallback/>
      </xi:include>
       
       


      by

      1
      2
      3
       

      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="relax.xml"> <xi:fallback/> </xi:include>
       
       



      I don't know whether there is more broken in your input. But if something like this is broken I would suggest to actually regenerate the inp.xml file with the input generator. However, you can try out whether adding the lines above helps.

Recipient
Gregor
Subject:


text:

Sign up, to leave a comment


Xobor Einfach ein eigenes Xobor Forum erstellen
Datenschutz