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: 116 | Last online: 06.25.2022
Date registered
04.07.2021
Sex
not specified
    • Gregor has written a new post "SOC in second variation" 06.20.2022

      For second variation SOC you are correct. For first variation SOC you have to activate both switches. ...don't forget that you have "numbands" as another convergence parameter in 2nd variation SOC calculations.

    • Gregor has written a new post "question about an error on out file using fleurmax6" 06.10.2022

      Your enpara file probably doesn't fit to the Fleur input file. For most purposes we don't use an explicit enpara file anymore. I guess you have it as a leftover from a calculation with an older fleur version in the same directory. Could you try starting with a fresh input in a new directory?

      Especially with these integer numbers in the enpara file everything that is parameterized there is already parameterized in the newer Fleur input file. These are the "energyParameters" entries in the atomSpecies section of the Fleur input file. See, e.g., https://www.flapw.de/MaX-6.0/documentati...species-section

    • Gregor has written a new post "Non-symmetric thin-film setup" 06.03.2022

      Just determine the maximal and minimal z coordinates, maxZ, minZ, in your set of atoms and calculate

      centerZ = (maxZ+minZ) / 2.

      Then subtract centerZ from all z coordinates in your list.

      It doesn't matter whether certain atoms are magnetic or special in another way. only the atom coordinates are of relevance in this strategy.

      For certain calculations it may also be advisable to set up a film unit cell that is symmetric with respect to the z=0 plane and the atom coordinates and types. But this is not necessarily needed.

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

      With respect to the papers: We actually have code to calculate hyperfine fields in the code. It is employed by using a different core electron solver, which is done by setting the input parameter kcrel to 1. But this code is rarely used I thus have to check whether it is still correct. ...I will also beautify the output. The other Mössbauer parameters are probably not yet calculated by the code.

      At the moment the output for the hyperfine fields is shell-resolved, i.e., one obtains contributions from 1s, 2s, 2p, 3s, 3p and so on. Does such an output fit your needs?

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

      Dear Zhiwei,

      I start to investigate this right now. I hope I find enough time to implement it.

      Is my understanding correct that you need output for

      1. isomer shift
      2. quadrupole splitting
      3. magnetic hyperfine field

      Could you clarify on whether I am missing something or you only need a subset of these quantities?

      You mentioned that you also need the electric field gradient?

      Best, Gregor.

    • Gregor has written a new post "question about the error "inwint"" 05.02.2022

      The numbers are not necessarily too large, but you could try to perform a few iterations with straight mixing and a very small mixing parameter before trying anything else.

    • Gregor has written a new post "question about the error "inwint"" 05.02.2022

      The inwint error essentially means that the potential is messed up. You somehow ended up
      in an unphysical situation. This is often due to issues in the parametrization, though I could
      at least verify that your inpgen input is reasonable. I cannot say anything about the VCA part.
      Maybe someone else can have a look at that.

      One may also end up in such a situation if the convergence process is problematic. Did the
      error occur in the first iteration or after many iterations? In the latter case: How strongly did
      the density change in the iterations before?

    • Gregor has written a new post "XMCD spectrum" 04.23.2022

      This is a two-stage test. The input files for this are found in the fleur/tests/inputfiles/CoMCDXML/ subdirectory of your Fleur folder. The first part of the test is run with the inp.xml file, then its content is replaced by the content of the inp2.xml file and Fleur ist started again. After the 2nd stage you should have the banddos.hdf file with the related output available.

    • Gregor has written a new post "XMCD spectrum" 04.20.2022

      Dear kirill,

      While we did not use the MCD feature in practice lately, one of our automatized tests should be sensitive to this feature. So it may be very operational, but I would always have a look at whether the results make sense.

      Performing the automatized test by hand also yields a banddos.hdf file that seems to have the related contents:

      1
      2
      3
      4
      5
      6
      7
      8
      9
       

      gregor@analyticalEngine:~/Fleur-git-dev-2/test$ h5ls banddos.hdf/MCD/DOS
      At1NC10cir Dataset {2, 1321}
      At1NC10neg Dataset {2, 1321}
      At1NC10pos Dataset {2, 1321}
      At1NC1cir Dataset {2, 1321}
      At1NC1neg Dataset {2, 1321}
      [...]
       
       



      Please have a look at the location in the hdf5 file I specified in the h5ls command. Maybe you were expecting it somewhere else?

    • Gregor has written a new post "Orbital polarization correction" 04.08.2022

      I actually never thought about this. I think, there is at least no stop built into the code for this case. I suggest to test for a few related cases how good the agreement between force theorem MAE calculations and conventional self-consistent MAE calculations is, just to get a feeling for this.

      So, just perform a few self-consistent calculations with different SQAs and compare the total energies instead of the eigenvalue sums in the force theorem mode.

    • Gregor has written a new post "Magnetic anisotropy, force theorem" 04.08.2022

      I now fixed the problem with commit: https://iffgit.fz-juelich.de/fleur/fleur...92be8df89dd361c

      This was only related to the output of the valence eigenvalue sum in the case of spin-orbit coupling calculations without activating noncollinear magnetism.

    • Gregor has written a new post "Magnetic anisotropy, force theorem" 04.07.2022

      That is what I wrote about a few days ago. I have not yet fixed this, but what I can say is that the eigenvalue sum in the MAE output in the out.xml file is more consistent with a calculation without SOC than the other output. It was actually explicitly fixed some time ago to have only half that value. I still have to figure out where the factor 2 in the other output comes from.

    • Gregor has written a new post "Magnetic anisotropy, force theorem" 04.07.2022

      I never cloned a certain commit. I suggest to clone the repository and then checkout the commit, i.e., with

      1
      2
      3
      4
       

      git checkout develop
      git checkout <commitHash>
       
       



      where you replace <commitHash> with the actual commit hash. You probably don't even need the second line. At the moment the develop branch should be stable.

    • Gregor has written a new post "Magnetic anisotropy, force theorem" 04.01.2022

      Dear kirill,

      In commit https://iffgit.fz-juelich.de/fleur/fleur...185ecdc2e827de0 I now added two more digits to the ev-sum output from MAE force theorem calculations. At the moment I start to believe that the new number for ev-sum in the MAE output in the out.xml file is correct. It may be that for the other places and in the old fleur version there is a double-counting of the valence states in this context. At least the new number seems to be more in agreement with calculations without SOC. I have to analyze this a little more.

    • Gregor has written a new post "Orbital polarization correction" 03.30.2022

      Dear kirill,

      Is this related to that approach? If so: No, we don't have this implemented. The suggestion would be to take the LDA+U path.

    • Gregor has written a new post "nearest-neighboring exchange coupling " 03.30.2022

      Dear yang,

      Fleur can be used for this purpose, but more in the sense that the results from Fleur calculations can be used in a manual postprocessing step to calculate these parameters. How this is done in detail depends on your use case. The simplest approach is to perform calculations with different magnetic configurations and then set up a system of linear equations constructed from the different configurations, the total energies of these calculations, and the respective coupling constants. You then obtain the coupling constants by solving this system of linear equations.

      For other cases a good starting point for the calculation of exchange coupling parameters is a set of calculations for different spin-spirals. Such an approach is suggested in this paper. Fleur explicitly supports such calculations in terms of the magnetic force theorem. The usage of this feature is sketched here.

    • Gregor has written a new post "Changelog for Version 6.0" 03.30.2022

      The progress in the parallelization scaling for the Hybrid functionals is illustrated in that publication: https://doi.org/10.3389/fmats.2022.851458

    • Gregor has written a new post "MaX-5.1 vs. MaX-6.0" 03.30.2022

      Dear Terry,

      There actually is no nice summary. But I mentioned some things in this other discussion: Changelog for Version 6.0

    • Gregor has written a new post "GGA MAE and GGA+U MAE" 03.15.2022

      All of the parameters mentioned on the linked site are important. If you have an insulating material the k-point set convergence and the related Fermi smearing are probably not very demanding.

      At first I would concentrate on the Kmax convergence, then lmax and lnonsph. Then you could check by adding some local orbitals whether the linearization error is of relevance here and finally I would check out the numbands convergence, which is definitely of relevance for such calculations with spin-orbit coupling.

      As an indicator of whether (most) parameters are nicely converged you can also vary the MT radii slightly (reduction by 5-10%) and observe whether this leaves the results stable.

Recipient
Gregor
Subject:


text:

Sign up, to leave a comment


Xobor Einfach ein eigenes Xobor Forum erstellen
Datenschutz