ELK precision for EOS across periodic table

Elk Users
2013-04-15
2016-01-22
  • Marcin Dulak

    Marcin Dulak - 2013-04-15

    Hi,

    I'm attempting to compare ELK to WIEN across the periodic table,
    using the method from http://molmod.ugent.be/DeltaCodesDFT
    For most elements agreement between EOS from ELK and WIEN is good, better than 1% in volume,
    and 2-5% in bulk modulus, but there are some elements (i use 1.4.22 default species) with problems:

    1. for the 6-th row Cs-Tl elements ELK gives consistently larger volume than WIEN by 1-3%,
    and too low bulk modulus (except Hg, but this one this one is hard to converge due to weak binding).
    These cases are similar to the Au one from the https://sourceforge.net/projects/elk/forums/forum/897820/topic/6240288 thread.
    Example Os_EOS.in attached, for which i'm getting:
    14.5 A**3/atom 380 GPa, while WIEN reference is 14.3 and 401.

    2. it's very hard to get smooth EOS for rare gases - i was not able to get any reasonably stable results from ELK
       Similarly in case of O and N - but in those cases EOS looks quite smooth, it just seems I just don't have enough
       computing resources to obtain converged results.

    3. magnetic systems: Cr, Mn, Fe show close to 2% volume differences. The local moments look OK.

    When excluding those 3 classes of systems i get the average Delta factor of 1.1 meV/atom,
    this is a good result (compare DeltaCodesDFT website).
    The average Delta for the classes 1 and  3 is ~11 (eleven).

    Another fact suggesting that there can be something wrong with the default species for 6th row,
    is that those elements are amongst the ones that give the largest differences for oxides formation energies
    calculated using data from materialsproject.org.
    ELK gives up to 0.5 eV / per unit formula difference wrt to VASP, GPAW, FHI-AIMS for these elements.

    The system worth checking is for example ReO3 (inputs attached) which consists of:
    http://materialsproject.org/materials/547271 , 8 , and 12957.
    I used fixed rmt for oxygen of 1.1 Bohr, and obtained formation energy 7.0 eV with ELK,
    while materialsproject.org value is 6.51, GPAW 6.53, and FHI-AIMS 6.63.

    # Os_EOS.in
    tasks
    0
    scale
    1.00
    xctype
    20
    rgkmax
    10.0
    gmaxvr
    40
    swidth
    0.001
    autokpt
    .true.
    radkpt
    120.0
    avec
    5.21365943 0.00000000 0.00000000
    2.60682972 4.51516152 0.00000000
    0.00000000 0.00000000 8.23342262
    atoms
    1
    'Os.in'
    2
    0.00000000000000 0.00000000000000 0.00000000000000 0.0 0.0 0.0
    0.33333333333333 0.33333333333333 0.50000000000000 0.0 0.0 0.0
    sppath
    '/home/opt/common/elk-species-1.4.22/'
    lradstp
    1
    lmaxapw
    10
    lmaxvr
    7
    lmaxmat
    10
    
    # ReO3.in
    lmaxapw
    10
    maxscl
    1900
    tasks
    0
    lmaxvr
    7
    gmaxvr
    35
    lmaxmat
    10
    lradstp
    1
    autolinengy
    .true.
    vkloff
    0.0833333333333 0.125 0.125
    deband
    0.01
    nempty
    5
    epsengy
    5e-05
    swidth
    0.0036749309468
    trimvg
    .true.
    rgkmax
    9.5
    ngridk
    6 4 4
    autokpt
    .false.
    tforce
    .true.
    stype
    3
    xctype
    20
    avec
    7.17006561823078 0.00000000000000 0.00000000000000
    0.00000000000000 10.13339848591266 0.00000000000000
    0.00000000000000 -0.00242013424015 10.13339820245377
    atoms
    2
    'O.in'
    6
    0.50000000000000 0.23781399936217 0.73781399881019 0.0 0.0 0.0
    0.50000000000000 0.73775699888289 0.76222499984881 0.0 0.0 0.0
    0.50000000000000 0.26222499915915 0.23775700062667 0.0 0.0 0.0
    0.50000000000000 0.76220799992241 0.26220799895103 0.0 0.0 0.0
    0.00000000000000 0.49995300076604 0.50005700004838 0.0 0.0 0.0
    0.00000000000000 0.00005699999940 0.99995299834064 0.0 0.0 0.0
    'Re.in'
    2
    0.50000000000000 0.50001700025927 0.49996999923841 0.0 0.0 0.0
    0.50000000000000 0.99997000050205 0.00001699999998 0.0 0.0 0.0
    sppath
    '/home/opt/common/elk-species-1.4.22/'
    
    # Re.in
    lmaxapw
    10
    maxscl
    1900
    tasks
    0
    lmaxvr
    7
    gmaxvr
    35
    lmaxmat
    10
    lradstp
    1
    autolinengy
    .true.
    vkloff
    0.05 0.05 0.0833333333333
    deband
    0.01
    nempty
    5
    epsengy
    5e-05
    swidth
    0.0036749309468
    trimvg
    .true.
    rgkmax
    9.5
    ngridk
    10 10 6
    autokpt
    .false.
    tforce
    .true.
    stype
    3
    xctype
    20
    avec
    5.25542211149097 0.00000000000000 0.00000000000000
    -2.62771105574549 4.55132906003339 0.00000000000000
    0.00000000000000 0.00000000000000 8.49835520367430
    atoms
    1
    'Re.in'
    2
    0.33333300010604 0.66666700021316 0.25000000111182 0.0 0.0 0.0
    0.66666699991227 0.33333300020204 0.74999999888818 0.0 0.0 0.0
    sppath
    '/home/opt/common/elk-species-1.4.22/'
    
    # O2.in
    lmaxapw
    10
    maxscl
    1900
    tasks
    0
    lmaxvr
    7
    gmaxvr
    35
    lmaxmat
    10
    lradstp
    1
    autolinengy
    .true.
    vkloff
    0.0833333333333 0.0833333333333 0.0833333333333
    deband
    0.01
    nempty
    5
    epsengy
    5e-05
    swidth
    0.0036749309468
    trimvg
    .true.
    rgkmax
    9.5
    ngridk
    6 6 6
    autokpt
    .false.
    tforce
    .true.
    stype
    3
    xctype
    20
    avec
    8.29557190473671 0.00000000000000 0.00000000000000
    3.59600024945352 9.48889490008812 0.00000000000000
    3.59600024945352 2.20837077448425 9.22833812436879
    atoms
    1
    'O.in'
    8
    0.84460899966861 0.27345900004483 0.78608900005473 0.0 0.0 0.0
    0.15539100008960 0.21391100024999 0.72654100020824 0.0 0.0 0.0
    0.15539100033139 0.72654099995517 0.21391099994527 0.0 0.0 0.0
    0.84460899991040 0.78608899975001 0.27345899979176 0.0 0.0 0.0
    0.82168000106354 0.20774800044969 0.20774799963925 0.0 0.0 0.0
    0.17832000121445 0.79225199955031 0.79225200036075 0.0 0.0 0.0
    0.13264099926426 0.14822200075495 0.14822200073749 0.0 0.0 0.0
    0.86735900005467 0.85177799876848 0.85177800131025 0.0 0.0 0.0
    sppath
    '/home/opt/common/elk-species-1.4.22/'
    
     
  • Marcin Dulak

    Marcin Dulak - 2013-05-01

    Hi,

    the differences between ELK and other programs (FHI-AIMS, GPAW) for 6th row elements
    are significantly reduced if all calculations are done non-relativistic (solscf 1000.0 setting in ELK).
    The programs agree then for both EOS parameters (a way below 0.5 % difference in equilibrium volume),
    and formation energies of oxides (difference below 0.1 eV per unit formula).

    For EOS of Osmium I get 15.6  A**3/atom, 287/291 GPa from ELK/FHI-AIMS.
    Due to the fact that the non-relativistic volume is larger i used scale = 1.01, 1.02, 1.03, 1.04 and 1.05.
    The ReO3 formation energy gives 5.7 eV with ELK, and 5.6 eV with FHI-AIMS.

    Can anyone verify these results with non-relativistic WIEN2k?
    What is the source of large discrepancies when performing relativistic calculations?

     
  • Jerzy Goraus

    Jerzy Goraus - 2013-05-03

    Dear Marcin,
    Using FPLO9 I am obtaining following values of bulk modulus within LSDA calculations performed for Os element:
    Non Relativistic: 288.54 GPa /V0=234.449 a.u.^3
    Scalar Relativistic: 385.9 GPa /V0=215.045 a.u.^3
    Fully Relativistic 378.6 GPa /V0=215.96 a.u.^3
    Experimental bulk modulus is of about 395 GPa.
    Osmium is a heavy  element and it does not surprise me that spin-orbit interaction is in that case very important .
    Osmium is just before gold which has golden color due to relativistic effects.

    best regards,
    Jerzy Goraus

     
  • Marcin Dulak

    Marcin Dulak - 2013-05-03

    Dear Jerzy,

    thanks for the results, could you perform the same with PBE?
    From my part let me check your LSDA - which LDA exactly FPLO9 uses?
    The purpose of the project (http://molmod.ugent.be/DeltaCodesDFT) is to compare different programs,
    and it looks like scalar-relativistic ELK calculations for 6th row elements disagree with other programs.

     
  • Jerzy Goraus

    Jerzy Goraus - 2013-05-07

    Dear Marcin
    FPLO9 uses PW92 LSDA and PBE96 GGA.
    The full relativistic GGA results for Os are 332.5 GPa and 225.086 a.u ^3.

    sincerely,
    Jerzy Goraus

     
  • Jerzy Goraus

    Jerzy Goraus - 2013-05-07

    Dear Marcin,
    Look at PHYSICAL REVIEW B 70, 224107 (2004), there the bulk modulus calculated for Os depends strongly on the v/v0 range,
    I think it can explain some discrepancies, btw my FPLO9 calculation for PZ Vxc (as used in mentioned publication) gives
    B0=380.6 GPa and V0=216.15 a.u^3.  All my calculations were performed for the default parameters within FPLO9 and
    V uniformly scaled down  by 1,4,7,10,13,16,19% from V0 taken as experimental value.

    sincerely,
    Jerzy Goraus

     
  • Kurt Lejaeghere

    Kurt Lejaeghere - 2013-05-16

    Hi

    if I perform non-relativistic Wien2k PBE calculations for Os (using the same cell geometry as in http://molmod.ugent.be/DeltaCodesDFT), I get:

    volume: 15.6 A**3/atom
    bulk modulus: 294 GPa

    This corresponds quite well with the ELK and FHI-AIMS non-relativistic results you mentioned: 15.6 A**3/atom, 287/291 GPa.

    The WIEN2k calculations were converged up to a very high accuracy: RKmax of 10, 30000*(122/volume) k-points and RMT of 2.3 a.u (for further settings: see the supplementary material of http://arxiv.org/abs/1204.2733 ).

    Compared to the relativistic results (14.5 A**3/atom and 380 GPa with ELK, while WIEN reference is 14.3 and 401), there certainly seems to be something different with the scalar-relativistic treatment. Especially when you look at the VASP results, which are 14.4 A**3/atom and 387 GPa, it seems that these two LAPW-codes are further apart than PAW and LAPW (which is a good correspondence nevertheless).

    WIEN2k uses a Harmon-Koelling scheme for its scalar-relativistic calculations. Is this different for ELK? It has already been observed that a different scalar-relativistic scheme can introduce quite large differences.

    Regards
    Kurt Lejaeghere

     
  • Marcin Dulak

    Marcin Dulak - 2014-01-18

    Update for elk 2.2.10:

    Got almost the same results for EOS of Os as reported above,
    so the difference ELK wrt Wien/FHI-AIMS is still
    present for the scalar-relativistic case for the default Os species.

    In addition, one also needs to use now (in scalar-relativistic case):

    trimvg
    .true.

    in order to get rid of "Error(rdirac): maximum iterations exceeded"
    as described here https://sourceforge.net/p/elk/discussion/897820/thread/0ef1319d/

     
  • John Kay Dewhurst

    Hi All,

    I ran Os myself using what I think is Wien2k species defaults.

    For PBE I get V0=14.358 A**3/atom and B0=391.8 using Vinet's Universal EOS.

    Here are my energy-volume points as the eos.in file:

     "Osmium"                     : cname
     2                            : natoms
     1                            : etype
     180.0 210.0 1000             : vplt1, vplt2, nvplt
     12                           : nevpt
     179.642960956661       -34563.9798388442     
     182.351101048453       -34563.9827309202     
     185.100066690646       -34563.9849702817     
     187.890473333516       -34563.9865179448     
     190.722945705327       -34563.9874535444     
     193.598117952203       -34563.9877837860     
     196.516633780098       -34563.9875424604     
     199.479146598912       -34563.9867385337     
     202.486319668784       -34563.9853992014     
     205.538826248580       -34563.9835476964     
     208.637349746631       -34563.9812287659     
     211.782583873730       -34563.9784357225
    

    ... and here is my elk.in with the 'usual suspects' set to higher quality:

    tasks
     0
    
    mixtype
     3
    
    epspot
     1.e-7
    
    xctype
     20
    
    rgkmax
     8.0
    
    gmaxvr
     20.0
    
    lmaxapw
     10
    
    lmaxvr
     8
    
    lmaxmat
     7
    
    fracinr
     0.01
    
    ngridk
     16 16 16
    
    avec
     5.21365943 0.00000000 0.00000000
     2.60682972 4.51516152 0.00000000
     0.00000000 0.00000000 8.23342262
    
    scale
     0.975
    
    atoms
     1
     'Os.in'
     2
     0.00000000000000 0.00000000000000 0.00000000000000
     0.33333333333333 0.33333333333333 0.50000000000000
    
    ecvcut
     -3.0
    
    species
      76
     'Os' 'osmium'
      190.23
      2.8
      22
      1  0  1  2
      2  0  1  2
      2  1  1  2
      2  1  2  4
      3  0  1  2
      3  1  1  2
      3  1  2  4
      3  2  2  4
      3  2  3  6
      4  0  1  2
      4  1  1  2
      4  1  2  4
      4  2  2  4
      4  2  3  6
      4  3  3  6
      4  3  4  8
      5  0  1  2
      5  1  1  2
      5  1  2  4
      5  2  2  4
      5  2  3  2
      6  0  1  2
    

    I used the latest version of Elk.

    I seem to recall that Wien2k uses only the radial component of the density when calculating the gradients for GGA. Can someone confirm this? It may account for the remaining small difference.

    Regards,
    Kay.

     
  • John Kay Dewhurst

    In addition: I also remember that Wien2k increases the number of radial mesh points when running GGA. You can simulate this in Elk by using:

    nrmtscf
     2
    

    which doubles the number of radial mesh points for each species.

    In Elk's case, this doubling changes the total energy by 0.02 Ha, but the equilibrium volume and bulk modulus are only changed by a tiny amount (0.03%).

    To summarize

    It's very difficult to find the 'correct result' for solids even for something as simple as LDA. One of the reasons is highlighted above: namely what to do with relativity. You can say "we'll just use scalar relativistic effects", but in both Elk and Wein2k the full Dirac equation is used for the core. To make the two codes consistent, the number of core states should be the same.

    You might also switch on spin-orbit coupling, to make the valence states more Dirac-like. But, strictly speaking, you then have to include non-collinear magnetisation in the calculation. Unlike Elk, Wien2k uses a collinear approximation for this step. So which is the correct approach? It depends on what you define to be correct.

    Also problematic is how Poisson's equation is solved. Both Elk and Wien2k use the method of M. Weinert [J. Math. Phys. 22, 2433 (1981)] for doing this. There is a parameter in this method which controls the polynomial order of the `pseudocharge' density. In Elk this is set to 0.25*gmaxvr*rmt_max. Wien2k may use a difference convention, and this will again affect the results.

    Another example is the fact that by default Elk adds an entropy term to the total energy, which may be significant for metals. I don't know about Wien2k.

    In short, it's very tricky to get codes to agree with each other to arbitrarily high precision. In my opinion it's also not that useful because the largest source of error is usually the exchange-correlation approximation. It's more useful for quantum chemists because they can get much closer to the exact ground state. Poor old solid state physicists can only dream of that kind of precision.

    So long as the codes are within a few percent of each other (preferably within the error due to the exchange-correlation approximation) we can declare success. What is more serious is if codes generate qualitatively different results. This is particularly prevalent with magnetism.

    Regards,
    Kay.

     
  • John Kay Dewhurst

    ...finally, I ran GGA with spin-orbit, and I get V0=14.359 A^3 and B0=387.5 GPa, although to do an even better job, you would have to relax the c/a ratio as well. Thus the spin-orbit seems to have a negligible effect. These results seem to be almost identical with the VASP results stated above (14.4 A^3/atom and 387 GPa).

    Last comment: you should rarely, if ever, have to go beyond rgkmax=8.5. This should cover even the most delicate magnetic cases. Your choice of 10 is way to high for this material.

    Kay.

     
    Last edit: John Kay Dewhurst 2014-01-23
  • Marcin Dulak

    Marcin Dulak - 2014-01-24

    Your Os definition looks to me like the one from 2.2.10 version.
    I took your last input verbatim (without nrmtscf),
    but do not reproduce the volume vs energy points with elk-2.2.10.
    I have verified also the effect of different EOS (Birch,
    SJEOS (http://prb.aps.org/abstract/PRB/v63/i22/e224115)) to be negligible -
    it's really the data points that i get different (compare e.g. the first point at scale=0.975):

    179.643 -34563.9846
    182.4209 -34563.9881
    185.2273 -34563.9908
    188.0624 -34563.9928
    190.9262 -34563.9941
    193.819 -34563.9948
    196.7408 -34563.995
    199.6919 -34563.9945
    202.6723 -34563.9936
    205.6823 -34563.9922
    208.7219 -34563.9902
    

    These points correspond to scale 0.975 to 1.025 (11 points) with step of 0.005.
    Changing ngridk to a more suitable 28 28 16 nor nrmtscf helps.

    By the latest version you mean elk-2.2.10 or some development version?

     
  • John Kay Dewhurst

    Hi Marcin,

    I tried with Elk 2.2.14 (dev) and a freshly downloaded version 2.2.10, with two different compilers (ifort and gfortran), the auto-generated species file and the one in 'elk/species'; and I get exactly the same result in each case.

    I wonder if you have a compiler or library bug. Perhaps someone else could have a go...

    Cheers,
    Kay.

     
  • John Kay Dewhurst

    Hi again,

    I think I figured out what the problem is.

    When I run the code for computing energy-volume points I hack main.f90 and put a loop in there. I also start from small volumes and work up. This means my muffin-tin radius is fixed from the beginning.

    I guess you're using a script, which results in the muffin-tin radius increasing as you change the volume. This is almost certainly the source of the error.

    For these tricky relativistic cases you have to fix a small MT radius and work upwards in volume. The reason is that inside the MT the code is relativistic and outside it's not. Thus as you increase the radius of the MT you're also increasing the region on which the kinetic energy is calculated differently from that of the normal Schrödinger equation. This skews the E-V curve in a way that cannot be converged away. See Phys. Rev. B 63, 035103 (2000).

    Do you agree?

    Cheers,
    Kay.

     
    Last edit: John Kay Dewhurst 2014-01-25
  • Marcin Dulak

    Marcin Dulak - 2014-01-25

    Yes,i confirm i did not fix the RMTs, and when fixed reproduce your result.
    Actually the article you mention discusses this problem, focusing on spin-orbit coupling.

     
  • Marcin Dulak

    Marcin Dulak - 2014-01-26

    There is still something inconsistent in the results: when looking at my original elk-1.4.22 results the RMT was fixed at 2.0 Bohr (that was the default for Os species, it has changed in later elk versions to 2.8 Bohr), and the volume was 14.5 A**3/atom. I ignore bulk modulus for the moment, as it is even more difficult to converge.

    I have verified with elk-2.2.10 the differences between my original input and yours (it would be better if we followed the standard practice of debugging and reuse each other files + make only one change at at time). It looks to me that it is mostly lmaxmat (i had set it to 10 vs yours 7) which in addition to the RMT influences the results. Taking your input with RMT fixed (tried 2.0, 2.20, 2.45 Bohr), with lmaxmat 10, and a more appropriate ngridk 28 28 16, i'm getting volume 14.45 A**3/atom. Boosting further rgkmax/gmaxvr to 9/30 (still without the need of trimvg .true.) gives 14.48 A**3/atom - so almost recovers the original elk-1.4.22 result.

     
    • Lars Nordström

      Lars Nordström - 2014-01-27

      Dear Marcin,

      One of the main issues is to use the same semi-core states as W2k in order to reproduce their results. That is why the ecvcut parameter in Kay's elk.in file is very important.
      This is because your choice to calculate the EOS semi-relativistically where the SOC is very important is an ill posed project since the core states in all codes are calculated relativistically. I know that it is the idea of the DeltaCodesDFT, but still it can give strange results, depending on number of semi-core states, MT radius etc ...
      In short your problem is not due to a bug in Elk!

      Best,
      Lars

       
  • John Kay Dewhurst

    Hi Marcin,

    The main difference between 2.2.10 and 1.4.22 is the radial integration and derivatives are handled slightly differently. In 1.4.22 we used cubic splines and later on we switched to piecewise polynomial fitting to improve stability. You may be able to get even closer if you double up the number of radial points using 'nrmtscf'.

    However, let's keep things in perspective: the largest difference is 14.5-14.45=0.05 = 0.3%. This is perfectly acceptable precision for all intents-and-purposes. You can't converge away the difference any more, because the limits are different for different codes and even different versions.

    I ran Os with PBEsol (supposedly better for solids). The equilibrium volume is 3% smaller than for PBE. That's ten times larger than the error from the change in versions.

    Also I found an article [Journal of Physics: Conference Series 410 (2013) 012049] which reports the bulk modulus of Os calculated with Wien2k as 391 GPa with spin-orbit coupling. This is less than 1% difference w.r.t. Elk: safely within the error from the xc functional, or even the choice of equation-of-state.

    Regards,
    Kay.

     
  • Marcin Dulak

    Marcin Dulak - 2014-02-11

    Thank you Lars, Kay for your additional comments.

    Similarly to https://sourceforge.net/p/elk/discussion/897820/thread/46fc4a6a/ i did not see any significant effect of ecvcut -3.0 (for Os - this puts 5s in core).
    In the supplementary material of DOI:10.1080/10408436.2013.772503 the last core/first valence configuration for Os is given as (4d/5s), so it seems the same as the default elk-2.2.10 species. However I made another elk-species experiment and included 4f in core starting from the default species files - that gave virtually the same semi-relativistic result (14.35/404) as the Wien2k reference (14.32/402). Maybe Wien2k has 4f in core?

    I see also a significant dependence when going to low RMT (~2 Bohr - old default from elk 1.4.22) as Lars mentioned. Moreover, using elk-2.2.10 species and moving 4d into valence gives a volume of 14.63 A**3/atom.

    If my results are correct, this only shows that the core/valence separation
    in 5d metals gives the same order of differences (up to 2% in volume) for EOS (semi-relativistic AND soc) as the differences between different modern pseudopotential sets, or different GGA functionals, e.g. PBE vs PBEsol.
    Similarly I see also a significant influence (order of differences between different GGA functionals) of the core/valence separation on the relativistic formation energies of 5d-metals oxides (see ReO3 in my first post).

    I post my final elk.in - in order to include 4f in the core on has to modify species by hand (i think that's the only way?), and in order to include 4d in valance - generate the species with ecvcut -16.0. I used RMT of 2.45 Bohr in all calculations.

    tasks
    0
    scale
    1.00
    xctype
    20
    rgkmax
    9.0
    gmaxvr
    30
    swidth
    0.001
    ngridk
    28 28 16
    avec
    5.21365943 0.00000000 0.00000000
    2.60682972 4.51516152 0.00000000
    0.00000000 0.00000000 8.23342262
    atoms
    1
    'Os.in'
    2
    0.00000000000000 0.00000000000000 0.00000000000000 0.0 0.0 0.0
    0.33333333333333 0.33333333333333 0.50000000000000 0.0 0.0 0.0
    sppath
    '/home/opt/common/elk-species-1.4.22/'
    lradstp
    1
    lmaxapw
    10
    lmaxvr
    7
    lmaxmat
    10

     
    • Lars Nordström

      Lars Nordström - 2014-02-12

      Hi Marcin!
      Dear Marcin,

      I have not checked what value of ecvcut is optimal, but it should be high enough to keep 4f in core ... It is easier to handle by hand as you seems to have done.

      You state that the core-valence separation has a large impact not only for scalar relativistic but also when including SOC. Please can you provide numbers to prove the latter part - that the equilibrium volumes are as sensitive for the fully relativistic case?

      True, you can get spurious results with SOC arising from sem-core p-states, but that effect is well known and can be avoided if the MT radius is fixed when varying lattice constants. That you get a dependence for the scalar relativistic case is not strange since there is no code that is truly scalar relativistic. They all include SOC for core states!

      Best,
      Lars

       
  • Marcin Dulak

    Marcin Dulak - 2014-02-13

    Dear Lars,

    hopefully you will be able to rectify the results below.

    In order to generate 4f in core species i set nlorb to 7 and remove the lorbl/lorbord 3/3 entry in the elk-2.2.10 Os.in (hope that's right).
    For 5s in core - use ecvcut -3.0, for 4d (in valence ecvcut -16.0.
    I use 5 SJEOS points with scale from 0.98 to 1.02 with step of 0.01.
    Some of the results are (i do not show some additional RMT/rgkmax/gmaxvr checking):

    #method V0 B0
    # 1. these are the reference results
    exp 13.85 425  # http://dx.doi.org/10.1080/10408436.2013.772503
    Wien2k 14.32 402  # http://dx.doi.org/10.1080/10408436.2013.772503
    # The article reports 1% error wrt exp for VASP PBE soc fully relaxed EOS (?)
    #
    # all results below from elk
    # 2. it looks one needs very high lmaxmat
    #
    #PBE: reference elk.in; RMT = 2.45 Bohr (fixed)
    lmaxmat7 14.39 384
    lmaxmat8 14.46 386
    lmaxmat9 14.49 388
    lmaxmat10 14.49 388
    #
    # 3. functionals differ by up to 4% in volume (revPBE vs AM05)
    #
    #reference elk.in; RMT = 2.45 Bohr (fixed), lmaxmat 10
    PBEsol 14.10 420
    AM05 14.00 429
    WC06 14.20 424
    revPBE 14.60 374
    PBE 14.49 388
    PBE_spinorb 14.50 385
    #
    # 4. core/valence separation contributes up to 2% (4f in core vs 4d in valence)
    #
    #PBE: reference elk.in; RMT = 2.45 Bohr (fixed), lmaxmat 10
    semirel 14.49 388
    spinorb 14.50 385
    5s_incore 14.48 386
    5s_incore_spinorb 14.48 379
    4d_inval 14.63 389
    4d_inval_spinorb 14.61 391
    4f_incore 14.35 404
    4f_incore_spinorb 14.36 398
    4f_incore_rmt22 14.34 393  # RMT test 2.2 Bohr (fixed)
    

    Best regards,

    Marcin

     
  • John Kay Dewhurst

    Hi Marcin,

    Thanks for the exhaustive testing: it's interesting to see the variation w.r.t. states in and out of the core. To complete your table, the Wien2k results from Journal of Physics: Conference Series 410 (2013) 012049 are V=14.504 A**3/atom and B=390.74 GPa using PBE with spin-orbit coupling.

    Based on your results I'll increase lmaxmat to 8 for the 'highq' option.

    Regards,
    Kay.

     
  • John Kay Dewhurst

    Update:
    We fixed a problem with the scalar-relativistic part of Elk in version 3.1.12 about six months ago. This now gives

    V = 14.276 A^3/atom
    B = 397.5 GPa
    B' = 4.86

    ...which is in excellent agreement with Wien2k and Fleur. The problem with the Wien2k results of Journal of Physics: Conference Series 410 (2013) 012049 was that early versions of Wien2k required that the user correctly set the linearisation energies. This was often not done properly.

    Regards,
    Kay.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks