[Wien] Three questions

[Lukasz Plucinski]

Dear Prof. Blaha, dear All,

I tried what you have suggested and still have some problems.

Could you describe the second symmetry in struct file:

    2      NUMBER OF SYMMETRY OPERATIONS
  1 0 0 0.00000000
  0 1 0 0.00000000
  0 0 1 0.00000000
        1   A   1 so. oper.  type  orig. index
-1 0 0 0.00000000
  0-1 0 0.00000000
  0 0 1 0.00000000
        2   B   3

Is that generic for SOC?

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
>