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 <pbl...@theochem.tuwien.ac.at>
Reply-To: A Mailing list for WIEN2k users
<wien@zeus.theochem.tuwien.ac.at>
To: wien@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@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@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: bl...@theochem.tuwien.ac.at WIEN2k: http://www.wien2k.at
WWW:
http://www.imc.tuwien.ac.at/tc_blaha-------------------------------------------------------------------------
_______________________________________________
Wien mailing list
Wien@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
