[Wien] Three questions
Peter Blaha
pblaha at theochem.tuwien.ac.at
Sat Sep 22 11:53:04 CEST 2018
When you enter a 50 50 1 mesh, it produces a 50 50 1 mesh. However, it
will use symmetry to reduce this mesh (unless you use -fbz switch).
Most importantly: you are doing SO calculations. So your x kgen must
be replaced by
x kgen -so (otherwise you add inversion).
Am 22.09.2018 um 10:15 schrieb pluto:
> 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-------------------------------------------------------------------------
More information about the Wien
mailing list