[Wien] initso - convergence jump after reduction of symmetry

Vojtech Chlan chlan at mbox.troja.mff.cuni.cz
Thu May 28 13:58:31 CEST 2015


Dear prof. Blaha,

thank you very much for the fixed symmetso; after running some more 
tests I am happy to say that the jumps reduced tremendously. Only a 
small jump now remains, probably connected with the CLM(R) part of 
density files. Anyway, I believe that now with the new symmetso it will 
be possible to continue after initso even for more complex structures 
(e.g., 100+ atoms).

If someone is interested the tests are described below.

Best regards
Vojtech


As a test case I used rhombohedral antiferromagnetic FeF3 (SG #148, R-3).

Firstl, reproduced the jump with old symmetso using steps:
1) start from converged hisym
2) initso with (3 5 7), leave Emax at 2.5, copy all the *_so files
3) runsp_lapw -p -orb -I -cc 0.00001
As expected, large jump occured and subsequently the scf crashed in 4th 
iteration:
:DIS  :  CHARGE DISTANCE       ( 5.5460638 for atom    2 spin 2)      
3.5299069
:DIS  :  CHARGE DISTANCE       ( 5.4495877 for atom    1 spin 2)      
5.3681200
:DIS  :  CHARGE DISTANCE       ( 5.3167277 for atom    1 spin 2)      
5.2076606


Now, using the fixed symmetso and following exactly the same steps 
produced much smaller jump and converged within a few iterations:
:DIS  :  CHARGE DISTANCE       ( 0.0265515 for atom    2 spin 1)      
0.0348338
:DIS  :  CHARGE DISTANCE       ( 0.0611098 for atom    3 spin 2)      
0.1550994
:DIS  :  CHARGE DISTANCE       ( 0.0593840 for atom    3 spin 2)      
0.1500394
:DIS  :  CHARGE DISTANCE       ( 0.1954766 for atom    3 spin 2)      
0.4753107
:DIS  :  CHARGE DISTANCE       ( 0.2505027 for atom    3 spin 2)      
0.5898240
:DIS  :  CHARGE DISTANCE       ( 0.1139920 for atom    4 spin 1)      
0.2875368
:DIS  :  CHARGE DISTANCE       ( 0.0835918 for atom    4 spin 1)      
0.2053963
:DIS  :  CHARGE DISTANCE       ( 0.0637785 for atom    3 spin 2)      
0.1722495
:DIS  :  CHARGE DISTANCE       ( 0.0671636 for atom    3 spin 2)      
0.1724862
:DIS  :  CHARGE DISTANCE       ( 0.0561695 for atom    3 spin 2)      
0.1454023
:DIS  :  CHARGE DISTANCE       ( 0.0216516 for atom    1 spin 2)      
0.0290190
:DIS  :  CHARGE DISTANCE       ( 0.0152166 for atom    1 spin 2)      
0.0160854
:DIS  :  CHARGE DISTANCE       ( 0.0084897 for atom    1 spin 2)      
0.0088889
:DIS  :  CHARGE DISTANCE       ( 0.0025667 for atom    1 spin 2)      
0.0026985
:DIS  :  CHARGE DISTANCE       ( 0.0015687 for atom    1 spin 2)      
0.0017820
:DIS  :  CHARGE DISTANCE       ( 0.0001951 for atom    1 spin 1)      
0.0004541
:DIS  :  CHARGE DISTANCE       ( 0.0001265 for atom    1 spin 1)      
0.0002052
:DIS  :  CHARGE DISTANCE       ( 0.0000507 for atom    1 spin 1)      
0.0000872
:DIS  :  CHARGE DISTANCE       ( 0.0000190 for atom    4 spin 2)      
0.0000436
:DIS  :  CHARGE DISTANCE       ( 0.0000113 for atom    2 spin 2)      
0.0000173
:DIS  :  CHARGE DISTANCE       ( 0.0000069 for atom    1 spin 1)      
0.0000123


I am a Fortran illiterate but as far as I understand this fix in 
symmetso corrects the plane-waves part of density files, while the 
CLM(R) parts remain the same. So I tried a few more tests. I converged 
the structure in low symmetry from scratch in order to obtain CLMs in 
the final low-symmetry basis. Checked that it reached the same energy as 
in the original high symmetry:
:ENE  : ********** TOTAL ENERGY IN Ry =        -6289.92473283 (hisym)
:ENE  : ********** TOTAL ENERGY IN Ry =        -6289.92473386 (lowsym)

Then I used the fixed symmetso and on top of it I replaced the CLM(R) of 
iron atoms (these are the only species where LMs were changed, fluorines 
are already at lowest symmetry), i.e.:
1) start from converged hisym
2) initso with (3 5 7), leave Emax at 2.5, copy all the *_so files
3) replace CLM(R) of irons with those from well converged "lowsym" 
calculation.
4) runsp_lapw -p -orb -I -cc 0.00001
A further improvement, though small:
:DIS  :  CHARGE DISTANCE       ( 0.0265633 for atom    1 spin 2)      
0.0348425
:DIS  :  CHARGE DISTANCE       ( 0.0579934 for atom    3 spin 2)      
0.1431763
:DIS  :  CHARGE DISTANCE       ( 0.0583868 for atom    3 spin 2)      
0.1447817
:DIS  :  CHARGE DISTANCE       ( 0.0700905 for atom    1 spin 2)      
0.1198294
:DIS  :  CHARGE DISTANCE       ( 0.0697802 for atom    1 spin 2)      
0.1168461
:DIS  :  CHARGE DISTANCE       ( 0.0299499 for atom    1 spin 2)      
0.0588715
:DIS  :  CHARGE DISTANCE       ( 0.0243737 for atom    4 spin 1)      
0.0569459
:DIS  :  CHARGE DISTANCE       ( 0.0147642 for atom    3 spin 2)      
0.0347052
:DIS  :  CHARGE DISTANCE       ( 0.0146602 for atom    3 spin 2)      
0.0352172
:DIS  :  CHARGE DISTANCE       ( 0.0149405 for atom    3 spin 2)      
0.0360313
:DIS  :  CHARGE DISTANCE       ( 0.0044088 for atom    3 spin 2)      
0.0101669
:DIS  :  CHARGE DISTANCE       ( 0.0023543 for atom    5 spin 1)      
0.0052931
:DIS  :  CHARGE DISTANCE       ( 0.0012384 for atom    4 spin 2)      
0.0031746
:DIS  :  CHARGE DISTANCE       ( 0.0003420 for atom    3 spin 1)      
0.0009373
:DIS  :  CHARGE DISTANCE       ( 0.0002330 for atom    2 spin 2)      
0.0005261
:DIS  :  CHARGE DISTANCE       ( 0.0001594 for atom    2 spin 2)      
0.0004024
:DIS  :  CHARGE DISTANCE       ( 0.0000265 for atom    1 spin 1)      
0.0000696
:DIS  :  CHARGE DISTANCE       ( 0.0000173 for atom    1 spin 1)      
0.0000423
:DIS  :  CHARGE DISTANCE       ( 0.0000115 for atom    1 spin 1)      
0.0000145
:DIS  :  CHARGE DISTANCE       ( 0.0000046 for atom    2 spin 2)      
0.0000067


I also tried playing with vorb and dmat files, but these do not seem to 
make it better nor worse - probably expectable, as at least dmat is 
represented in global coordinates system.





On 18-May-15 13:47, Peter Blaha wrote:
> We recently fixed one problem in SRC_symmetso connected with the 
> reduction of symmetry and splitting of equivalent atoms into 
> no-equivalent ones.
>
> Replace clmchange.f  with the attached file and recompile.
>
> Regards
>
> On 05/18/2015 01:36 PM, Vojtech Chlan wrote:
>> Dear WIEN2k community,
>>
>> I am facing a problem with disturbance of convergence when the symmetry
>> of the structure is lowered (e.g., by initso_lapw).
>>
>> It is well known in spin-polarized calculations that introducing the
>> spin-orbit interaction may reduce symmetry - in dependence on whether
>> the chosen direction of magnetization is compatible with present
>> elements of symetry or not. In spin-polarized cases where the symmetry
>> is not reduced, e.g. uniaxial structure with magnetization parallel to
>> the axis, the process is usually quite smooth: After well converged
>> runsp_lapw and initso call, the subsequent "runsp_lapw -so" calculation
>> starts almost converged and usually converges within a few iterations
>> (at least when no really heavy elements are present so that the
>> spin-orbit coupling is rather weak).
>>
>> However in cases where the symmetry is reduced during initso (symmetso),
>> the continuation by runsp_lapw -so is not so smooth. According to my
>> experience there is often a substantial jump in the charge distance, the
>> magnetic moment may start to collapse etc. In fact, the jump in
>> convergence is present regardless the -so switch (or other parameters
>> that are usually changed during initso, e.g., Emax).
>>
>> To illustrate this behaviour I did a few tests on barium hexagonal
>> ferrite (SG #194, P63/mmc):
>> Firstly, it was fully converged with quite standard parameters - using
>> PBE-GGA+U (U=4.5eV, J=0), with RKM=6.0, 100 k-points; wien version 14.2
>> was used.
>> Now, since there is the hexagonal axis (direction 001), starting initso
>> and setting the magnetization in 001 naturally does not reduce symmetry.
>> As expected, everything is nice and smooth when one starts runsp_lapw
>> -so .... there is only :DIS = 0.015 in the first iteration and the
>> calculation converges within a few iterations.
>> But when I set magnetization in direction 100, which kills half of the
>> symmetry operations (and 11 non-equivalent atoms become 15), the first
>> iteration starts with a jump in :DIS = 2.31. The -so switch is
>> irrelevant, the jump is there even for runsp_lapw without the -so 
>> switch.
>>
>> My (naive) understanding of the origin of this jump is that it arises
>> from the change of basis for those atom sorts that became nonequivalent.
>> The inclusion of magnetization reduces also the local point group
>> symmetries of atoms (also often accompanied by change in rotation
>> matrices), which sumsequently changes their lists of LM expansions in
>> case.in2 file. The increase of LMs in expansion then manifests after
>> first iteration also in CLM files and one gets a jump in convergence.
>>
>> When such changes concern only a few atoms in the structure or the
>> change in basis is small, it seems the calculation can often be
>> converged despite the jump. However when more and more atoms have their
>> expansions changed the jump becomes higher, eventually, for large
>> structures and in cases where the magnetization strips the structure of
>> almost all symmetries the jump becomes irrecoverable: the calculations
>> (with or without -so) crash typically in second iteration (when the new
>> LMs are first mixed) or even in first (in SELECT), in some cases the
>> runs survive without a crash but the potentials go all crazy and for
>> example magnetic moments collapse (anyway the convergence fails). I have
>> partially learned to live with that and partially learned to circumvent
>> this by reducing the symmetry not all at once, but in steps (and
>> re-converge in between) and by using other tricks to avoid crash and
>> maintain convergence. However, currently I try to switch on the
>> spin-orbit in a system too large where this simply does not help.
>>
>> I can be all wrong, blaming the change in LMs, but I could not find any
>> other cause for the jump. And I believe I cannot touch the LM expansions
>> as they are given by the point group symmetry of the site.
>>
>> I made a few naive attempts to fool some routines (mixer, clmextrapol)
>> into translating the clm files into ones with a new set of LMs, but
>> without proper knowledge of what I was doing, I naturally only ended up
>> with nonsenses and segmentation faults.
>>
>> Is there any possibility to "smoothly renormalize" the density for a
>> changed set of LMs?
>> Well, perhaps I am blind to some completely different and obvious
>> solution, so any help would be appreciated.
>>
>> Best regards
>> Vojtech
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20150528/f9558d80/attachment.html>


More information about the Wien mailing list