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@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

_______________________________________________
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

Reply via email to