[Wien] Three questions
pluto
pluto at physics.ucdavis.edu
Sat Sep 22 10:15:41 CEST 2018
Dear Prof. Blaha, Prof. Marks, dear All,
Thank you for your helpful comments.
After several tests I have decided to try a denser mesh, something like
50x50x1. I have problems setting up this mesh.
When using generic magnetization direction all symmetries are removed,
only identity stays, this is what I am using now.
Manual case.klist mesh does not work with TETRA, one needs case.kgen
(lapw1 works, but lapw2 crashes). Is there a way to generate case.kgen
from the manually prepared case.klist? I can probably use TEMP with
manual case.klist, but it would be good to have it working with TETRA.
Next thing I tried was:
x kgen
I entered '0', then entered '50 50 1', then '1' (shift mesh allowed).
That produces 1250 k-points, obviously not 50x50 but rather 50x25.
One can probably get uniform mesh using 'x kgen' and asking for high
number of k-points, e.g. 10000. But then a 3D mesh is created, things
like 43x43x5, with in-plane k-points doubled, beginning pf the file
looks like this:
1 5 5 43 430 2.0 -7.0 1.5
10000 k, div: ( 43 43 5)
2 5 5 129 430 2.0
3 5 5 215 430 2.0
4 5 5 301 430 2.0
5 5 5 387 430 2.0
6 5 15 43 430 2.0
7 5 15 129 430 2.0
8 5 15 215 430 2.0
This is probably not optimal in cases where there is negligible k_z
dispersion.
Best,
Lukasz
PS. Coming back to the symmetry operations issue. This symmetry
operation
-1 0 0 0.00000000
0-1 0 0.00000000
0 0 1 0.00000000
2 B 3
is automatically generated when any generic in-plane M is used (e.g. 4 5
0), I am working with the Fe/MgO(001) system. This symmetry is removed
from case.struct when generic M direction (such as e.g. 4 5 1) is used.
I also don't know what the letter 'B' means, this line is described as
"so. oper. type orig. index" in the case.struct. Certainly band
structures produced with this symmetry present in the case.struct do not
exhibit such symmetry.
-------- Forwarded Message --------
Subject: Re: [Wien] Three questions
Date: Wed, 19 Sep 2018 19:31:29 +0200
From: Peter Blaha <pblaha at theochem.tuwien.ac.at>
Reply-To: A Mailing list for WIEN2k users
<wien at zeus.theochem.tuwien.ac.at>
To: wien at zeus.theochem.tuwien.ac.at
> Could you describe the second symmetry in struct file:
> -1 0 0 0.00000000
> 0-1 0 0.00000000
> 0 0 1 0.00000000
> 2 B 3
>
> Is that generic for SOC?
This is an operation which trnsform x into -x, into -y and leaves z
unchanged. So obviously this is a 2-fold rotation (180 degrees) along
the z direction.
I don't know what you mean by "generic for SOC" ??? For an arbitrary M
direction, most likely nothing will survive except identity.
Forget "PRATT" (except sometimes for one cycle). For metals, bad
convergence usually also means a need for a better k-mesh.
Sometimes some properties are very sensitive, so you need to check the
convergence of this property.
Sometimes a property can depend on E-temp, in particular when very flat
bands (high DOS) close to EF are present and it is a spin-polarized
case.
If you want the T=0 solution, you have to use TETRA and a VERY GOOD
k-mesh. Your results MUST be checked for k-convergence.
When you have transition metals (or even 4f elements) as atoms with the
smallest RMT, RKMAX=7.5 is definitely too small for accurate solutions
with fine details. Use at least 9. Of course, whne your smallest atom
(RMT) is a light sp-element, RKMAX=7.5 might be fine.
> For a series of angles (say every 5 degrees) the results for same
> angles
> are "off", one can see it clearly from plotting 2D sheets of bands,
> since they e.g. exhibit Weyl points that "move around" when M direction
> is changed.
>
> What is strange is, that increasing the convergence criteria from -ec
> 0.0001 -cc 0.001 to -ec 0.0001 -cc 0.0001 may lead to quite dramatic
> changes, while keeping everything else intact.
>
> I tried -fermit 0.004, that again leads to very different dispersions
> for some bands. Now I am trying -fermit 0.00074 (10 meV). I am using
> RKmax 7.5, that should be fine, but maybe I should increase to 9?
>
> Perhaps there is some issue with the default mixer? Sometimes it takes
> many iterations to converge for some M angles, while only few for other
> M angles. I am now testing with the PRATT setting, maybe it will be
> more
> consistent.
>
> Maybe you could advice what else can be tried.
>
> Best,
> Lukasz
>
>
>
>
>
>
>
>
>
> On 9/10/2018 11:49 AM, Peter Blaha wrote:
>>
>>> 1. CHARGE CONVERGENCE: I know this has been discussed before, but it
>>> seems it didn't change in Wien2k_18. Here is a typical example of the
>>> charge convergence history of the last few iterations of FM+SOC
>>> (ferromagnetic + spin orbit coupling) calculation:
>>>
>>> :ENERGY convergence: 0 0.0001 .0001320450000000
>>> :CHARGE convergence: 0 0.001 .0027578
>>> :ENERGY convergence: 1 0.0001 .0000497650000000
>>> :CHARGE convergence: 0 0.001 .0050904
>>> :ENERGY convergence: 1 0.0001 .0000557650000000
>>> :CHARGE convergence: 0 0.001 .0004672
>>> :ENERGY convergence: 1 0.0001 .0000220050000000
>>> :CHARGE convergence: 1 0.001 -.0001786
>>>
>>> Something strange happens with charge convergence, is this OK?
>>
>> This is ok.
>>
>>
>>> 2. LIMITS in inso and in1c files: in order to avoid large vector
>>> files I am changing the energy limits in inso and in1c files for band
>>> structure calculations. SCF is done with default inso and in1c files,
>>> then I do save_lapw, then I edit case.inso and case.in1c files, and
>>> then I do FM+SOC band structure calculation:
>>>
>>> #! /bin/bash
>>> x lapw1 -band -up -p
>>> x lapw1 -band -dn -p
>>> x lapwso -up -p
>>>
>>> I am using emin/emax -0.5 0.5 in both files (inso and in1c) without
>>> changing anything else, then I have bands from limited energy range.
>>> I just want to make sure that this procedure is fine.
>>
>> No, this is NOT ok. You must not change Emax in case.in1c !
>> If you do, your basis set for the spin-orbit step is limited and
>> eigenvalues will change as compared to the scf calculation.
>> You can reduce emax in case.inso if you are not interested in the
>> bands at higher energies.
>>
>>
>>> 3. FM+SOC convergence: I am doing FM+SOC calculations for different
>>> in-plane magnetization M directions in a 2D Fe(001) ferromagnetic
>>> layer. Actually an older Wien2k_14 version was not working well for
>>> this, results for generic M directions were really strange. Wien2k_18
>>> seems much better, however, when starting things from the scratch
>>> (each M angle completely separate calculation) it seems that for some
>>> M angles the result is off, as if it didn't actually properly
>>> converge. I am using a fairly dense mesh for SCF (2000k, 25 25 3),
>>> and -ec 0.0001 -cc 0.001. Should I maybe try -fermit setting in
>>> init_lapw, and what would be a reasonable value? Do I always need to
>>> use instgen_lapw before init_lapw when starting a new case? Should I
>>> perhaps do each next M angle on top of a previously converged M angle
>>> (and save_lapw for each M angle)?
>>
>> Doing separate calculations for different directions may / may not
>> yield correct results.
>> The proper (save) way is to use ONE case.struct file for all cases.
>> i) select all directions of magnetization first.
>> ii) Produce (using init_so) struct files, which are the same for all
>> cases (do not change after init_so) and use this struct file for ALL
>> (also non-so) calculations.
>> This works as:
>> a) generate normal struct file.
>> b) init -b -sp ....
>> c) init_so with first direction, accept the generated structure
>> d) init_so with second direction, accept ...
>> repeat this for all desired directions (or until you have a P1
>> structure (only identity).
>>
>> e) with this setup (no new init_lapw !!!!) execute:
>> runsp -ec ... and save as "non-so"
>> runsp -so ... and save as "so-dir_2"
>> restore non-so; edit case.inso and put the first direction in;
>> runsp -so ... and save as "so-dir_1"
>>
>> In this way, you can also compare the force-theorem (:SUM of first
>> iteration (2 numbers !) with the scf solution.
>>
>>
>>
>>>
>>>
>>> Best,
>>> Lukasz
>>> _______________________________________________
>>> Wien mailing list
>>> Wien at zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>> SEARCH the MAILING-LIST at:
>>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
--
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at WIEN2k: http://www.wien2k.at
WWW:
http://www.imc.tuwien.ac.at/tc_blaha-------------------------------------------------------------------------
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
More information about the Wien
mailing list