date:20151030

Re: [Wien] x w2w error in WIEN2k.14

2015-10-30 Thread Elias Assmann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2015 03:40 AM, Yue-Wen Fang wrote:
> Step 1. write_inwplot
> 
> Step 2.  x wplot -wf 1 -up
> 
> Step 3. x wplot -wf 1 -dn
> 
> According to the User guide, these three commands should  create 
> case*.psink and case*.psiarg " files, but I found there was no
> data within these files. Could you show me how to export WF for 
> spin-polarized cases?

Do you mean the files existed but were empty?  Then there must have
been some error, and you need to include error messages.

Elias


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJWMzGzAAoJEE/4gtQZfOqPenAP/iQbqOv1E1bVA5EZqVQyz6zn
IzQKts6LmiBefA8BgUqN0PrIxPptC0WdrFy+YSUu/Jua0Q9aFSKwJj0ZfFvhUpNz
YT7Wjf3TcLShhQhhpAAZOZLMaLpLaTJQ0MY126r4OCOI+LABiGKL7gN76X7fuYi0
i5Dk8EKFUfylv9kNjnmRHWaLR3jM+Lv715A0lVIgGAPFTtiKaNkPRH870ni+ihse
fQ67j2UFFY5c5IZ/uo0l8fTZ/ce6vHtPJGxh9Mwpw++0d3Jfi9/XmE9zTZwNgrEk
sL7YbnSES3LNbNLLxTwjhmElMPo08XeopuXQE3K+DCcG9UBDutBSz+I/R2xKMD/u
lo86KwpUHzXbygKaYFGKjVEuBpEsoDD0VYFddz6l8Wk+npi0zJ714EZslmN/n1MH
uEiR4s9nLXSBlg2RyQHiehTAUZULVP3qxRdJjR4/XCKolzJ13I8pUqKLTQXaSD20
GNGweLtIZ+uTfASbSnV6mZKBootm56zhavmjg3XfHheQ9nLxes4/1kw1WLqS0+rc
V6ewnHW9ogGkqRGwXgNj8ACJAjbIZIT748Y5CBogkpI62JS+1GDv8SjZ5Av4564m
1t+2Ta4EWRt2TgBMubMHhgxplZfqhg5owABO6i3zI1tO1unDbhsngc1sLza+HeVA
tjKnOPe/sCWiCrDyDrKV
=E5uQ
-END PGP SIGNATURE-
___
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

Re: [Wien] Bulk vs supercell Plasma frequency

2015-10-30 Thread Peter Blaha

Usually, different properties require different k-meshes. So it should 
be ok to converge the scf with a smaller k-mesh (it still must be a 
"good" one), but use more k-points for a plot of the DOS or optics.


Please repeat the optics calculation with a series of k-meshes and plot 
w_p as funktion of the k-mesh. You should find out in this way the 
converged value.


PS: I know that for Al one needs MANY more k-points to get a converged 
value. No idea about Na.


Am 29.10.2015 um 21:50 schrieb Muhammad Sajjad:

Dear Prof. P Blaha
Thank you very much for yous fruitful suggestions. However, I did not 
change RKmax. For cubic Na only W_p_xx is enough but after making 
supercell (1 1 6) still I need only w_p_xx and forget about w_p_zz, 
though the system is tetragonal now. Is it right I understood?
Second  thing is it principally right that one converges SCF with 
small k-mesh say 30*30*5 and then use the same scf ao get OPTICAL 
properties with k-mesh say 90*90*15? I mean no need to converge scf 
with 90*90*15.

 Kind Regards

On Thu, Oct 29, 2015 at 9:03 PM, Peter Blaha 
> 
wrote:


In principle you are doing thinks now correct.
In reality, however, we use the tetrahedra-method in the
integration of the BZ to calculate a joint-density-of-states. And
for a metal !!! here there is a difference between k-meshes in the
small or large cell. (it is related to the "back-folding" problem
and in the supercell there are less tetrahedra and thus less
possibilities to interpolate for the tetrahedron method than in
the small cell).

In any case, you need to consider two things:

a) You have to decide to which accurcy a certain number should be
calculated. Typically, a plasma frequency would be quoted with one
or two digits after the comma (i.e. 5.9 or at most 5.94 eV).

b) Then you have to converge the numbers with respect to k-mesh
(but also Rkmax !!)
Definitely you should use a ratio of 6:1 for the supercell, but
eventually you need to increase the mesh until there are no
changes within the desired accuracy. In your case, 90x15 is almost
sufficient, but not quite if you want two digits accuracy.

c) in a cubic system, of course it is useless to quote two tensor
components and one is sufficient.




Am 29.10.2015 um 10:35 schrieb Muhammad Sajjad:

Dear Prof. Blaha

I did some calculation for Bulk Na (bcc, space gp #229_Im-3m)
wiht k-mesh 30*30*30 and found the plasma frequency (in
case.outputjoint) as
 Plasma frequencies:

   w_p_xx  w_p_zz[eV]

   5.9446  5.9446

Now I constructed a supercell 1*1*6 (definitely symmetry reduced
and now sp.gp  is 1_P1), used k-mesh 30*30*5 and  found
Plasma frequencies (much deviating from bulk values):

   w_p_xx  w_p_zz[eV]

   5.76146  5.3446

Then used k-mesh 90*90*15 and found
Plasma frequencies (w_p_zz is deviating from bulk w_p_zz ):

   w_p_xx  w_p_zz[eV]

   5.9485  5.8903

I have read the previous post
(https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09782.html)
but it is not speaking about w_p_zz. So when I plot epsilon data
for w_p_xx then it is matching with that of bulk but when I use
w_p_zz  then it is definitely  away from bulk. Should I consider
w_p_zz  or use "number of choice = 1 in case.inop" and plot
epsilon only with w_p_xx ?


Kind Regards
Muhammad Sajjad
Post Doctoral Fellow
KAUST, KSA.


___
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




--
Kind Regards
Muhammad Sajjad
Post Doctoral Fellow
KAUST, KSA.


___
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

Re: [Wien] x w2w error in WIEN2k.14

2015-10-30 Thread Yue-Wen Fang

Hi, Elias, I read the user guide again and found that the instructions of "
*w2waddsp*" said that case.mmn and case.amn files must contain the overlaps
from two spin channels. In my case of 4-atom CoO, I didn't include *spin
orbit coupling*, thus in my previous calculations I just used x wannier90
instead of *x wannier90-so* which can call w2waddsp. Is it possible to give
rise to the errors in my last two emails?

Bests
Fnag

2015-10-30 19:04 GMT+08:00 Yue-Wen Fang :

> Dear Elias,
>
> Thanks for your reminding me of the errors. Yes, I meant that the
> case.psinkup, case.psinkdn, case.psiagraup and case.psiagradn file were
> empty, but it was found that case.outputwplotup and case.outputwplotdn
> files were not empty.
>
> Actually the error files were also empty. After the execution of the two
> commands, it showed that
>
> + x wplot -wf 2 -up -p
>  written on 30Oct2015 at 01:34:44
> NON-ORTHOGONAL AXES
> 0.081u 0.041s 0:00.21 57.1% 0+0k 0+0io 3pf+0w
> + x wplot -wf 2 -dn -p
>  written on 30Oct2015 at 02:29:18
> NON-ORTHOGONAL AXES
> 0.089u 0.034s 0:00.19 57.8% 0+0k 0+0io 2pf+0w
>
> In the *:log* file, it was
>
> Fri Oct 30 19:29:23 CST 2015> (x) wplot -wf 2 -up -p
> Fri Oct 30 19:29:23 CST 2015> (x) wplot -wf 2 -dn -p
>
> But this tool can work for non-spin polarized calcualtions, e.g. GaAs.
>
> Bests
> Fang
>
> 2015-10-30 17:00 GMT+08:00 Elias Assmann :
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/30/2015 03:40 AM, Yue-Wen Fang wrote:
>> > Step 1. write_inwplot
>> >
>> > Step 2.  x wplot -wf 1 -up
>> >
>> > Step 3. x wplot -wf 1 -dn
>> >
>> > According to the User guide, these three commands should  create
>> > case*.psink and case*.psiarg " files, but I found there was no
>> > data within these files. Could you show me how to export WF for
>> > spin-polarized cases?
>>
>> Do you mean the files existed but were empty?  Then there must have
>> been some error, and you need to include error messages.
>>
>> Elias
>>
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJWMzGzAAoJEE/4gtQZfOqPenAP/iQbqOv1E1bVA5EZqVQyz6zn
>> IzQKts6LmiBefA8BgUqN0PrIxPptC0WdrFy+YSUu/Jua0Q9aFSKwJj0ZfFvhUpNz
>> YT7Wjf3TcLShhQhhpAAZOZLMaLpLaTJQ0MY126r4OCOI+LABiGKL7gN76X7fuYi0
>> i5Dk8EKFUfylv9kNjnmRHWaLR3jM+Lv715A0lVIgGAPFTtiKaNkPRH870ni+ihse
>> fQ67j2UFFY5c5IZ/uo0l8fTZ/ce6vHtPJGxh9Mwpw++0d3Jfi9/XmE9zTZwNgrEk
>> sL7YbnSES3LNbNLLxTwjhmElMPo08XeopuXQE3K+DCcG9UBDutBSz+I/R2xKMD/u
>> lo86KwpUHzXbygKaYFGKjVEuBpEsoDD0VYFddz6l8Wk+npi0zJ714EZslmN/n1MH
>> uEiR4s9nLXSBlg2RyQHiehTAUZULVP3qxRdJjR4/XCKolzJ13I8pUqKLTQXaSD20
>> GNGweLtIZ+uTfASbSnV6mZKBootm56zhavmjg3XfHheQ9nLxes4/1kw1WLqS0+rc
>> V6ewnHW9ogGkqRGwXgNj8ACJAjbIZIT748Y5CBogkpI62JS+1GDv8SjZ5Av4564m
>> 1t+2Ta4EWRt2TgBMubMHhgxplZfqhg5owABO6i3zI1tO1unDbhsngc1sLza+HeVA
>> tjKnOPe/sCWiCrDyDrKV
>> =E5uQ
>> -END PGP SIGNATURE-
>> ___
>> 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
>>
>
>
>
> --
>
> 
> Yue-Wen FANG, PhD candidate
> East China Normal University  
>
>
>
>


-- 

Yue-Wen FANG, PhD candidate
East China Normal University  
___
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

Re: [Wien] x w2w error in WIEN2k.14

2015-10-30 Thread Elias Assmann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2015 12:04 PM, Yue-Wen Fang wrote:
> + x wplot -wf 2 -up -p written on 30Oct2015 at 01:34:44 
> NON-ORTHOGONAL AXES

Well, that tells you what happened: ‘wplot’ thinks the axes you
specified are not orthogonal, but you asked it to check the
ORTHOgonality of the axes.  Please double-check your ‘inwplot’ file.

Elias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJWM1XvAAoJEE/4gtQZfOqPrEwP+wQwu3LnKSWhtUxwluxcmyXy
2dF7N+GLJ5Q8jVqIWLX+Ni2CFq0l2KkIlSJPCMe0cV2fie+5JxL7IrKFMz1SeEXs
7BXKRJgB/vqNC4TbJbre6bLXMCpAjz5uC9Klv9jElU7hVt1tefpehCoAN7vXQ2ER
oVcsNqtKjuTcaVsQ5g8X9pGuwj+17J4w8AlKR4xJpNJS57ziEpY1ldDhwl4z+pwV
iU3XNob2pv6+tjm1NmU7E4dZqNQBs85NnM7EacXXHsiFIXEfIVHea5eGgFIMGDUd
YRSNBPQeqZmjY2Hat46LDFd3xvzlp4l+enW5BH1UyOkDBuz9M9mSLyInwX+9QTK+
kf0Qbyf/DUr65KXKC3NIm3bCC+uyHjUn6ygVlGtTY5k8Yly8TNGW4RD5wyEIoIgz
rnrs7QUE5it2rySaAtHekXVCq0V5JALw5f36cHAiGFzX5CkSm9cu08+Y4KQylAiQ
JXa0C8nVikBS/nZ29BFARoSJriNLhsgXqyT+7HV4WZggGNRPOJ1gEVMZxiojdR29
UFIpLRfxoqw3d6DNDP8DgU5+86vyM2tFpSWaiugykUsV1EtIQrtMgN9uoRRDq2O1
qp6ewPEbFgY5P07QWxz7R3n89/qv1Abk/iKr38wm2ctwO1uVsQU1HocxdmlC0YyY
Evj6hnaul8ou9J3rb9jZ
=8DtZ
-END PGP SIGNATURE-
___
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

Re: [Wien] x w2w error in WIEN2k.14

2015-10-30 Thread Yue-Wen Fang

Bingo! I have fixed the error after modifying the 'inwplot' file. Thanks,
Elias!

Bests
Fang

2015-10-30 19:35 GMT+08:00 Elias Assmann :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/30/2015 12:04 PM, Yue-Wen Fang wrote:
> > + x wplot -wf 2 -up -p written on 30Oct2015 at 01:34:44
> > NON-ORTHOGONAL AXES
>
> Well, that tells you what happened: ‘wplot’ thinks the axes you
> specified are not orthogonal, but you asked it to check the
> ORTHOgonality of the axes.  Please double-check your ‘inwplot’ file.
>
> Elias
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJWM1XvAAoJEE/4gtQZfOqPrEwP+wQwu3LnKSWhtUxwluxcmyXy
> 2dF7N+GLJ5Q8jVqIWLX+Ni2CFq0l2KkIlSJPCMe0cV2fie+5JxL7IrKFMz1SeEXs
> 7BXKRJgB/vqNC4TbJbre6bLXMCpAjz5uC9Klv9jElU7hVt1tefpehCoAN7vXQ2ER
> oVcsNqtKjuTcaVsQ5g8X9pGuwj+17J4w8AlKR4xJpNJS57ziEpY1ldDhwl4z+pwV
> iU3XNob2pv6+tjm1NmU7E4dZqNQBs85NnM7EacXXHsiFIXEfIVHea5eGgFIMGDUd
> YRSNBPQeqZmjY2Hat46LDFd3xvzlp4l+enW5BH1UyOkDBuz9M9mSLyInwX+9QTK+
> kf0Qbyf/DUr65KXKC3NIm3bCC+uyHjUn6ygVlGtTY5k8Yly8TNGW4RD5wyEIoIgz
> rnrs7QUE5it2rySaAtHekXVCq0V5JALw5f36cHAiGFzX5CkSm9cu08+Y4KQylAiQ
> JXa0C8nVikBS/nZ29BFARoSJriNLhsgXqyT+7HV4WZggGNRPOJ1gEVMZxiojdR29
> UFIpLRfxoqw3d6DNDP8DgU5+86vyM2tFpSWaiugykUsV1EtIQrtMgN9uoRRDq2O1
> qp6ewPEbFgY5P07QWxz7R3n89/qv1Abk/iKr38wm2ctwO1uVsQU1HocxdmlC0YyY
> Evj6hnaul8ou9J3rb9jZ
> =8DtZ
> -END PGP SIGNATURE-
> ___
> 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
>



-- 

Yue-Wen FANG, PhD candidate
East China Normal University  
___
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

Re: [Wien] runsp -it: lapw1 called thrice?

2015-10-30 Thread Laurence Marks

This is normal. You will see that the second call has no "-it". The shell
script detects if there is a problem with the iterative mode and switches
to non-iterative diagonalization.

---
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
http://www.numis.northwestern.edu
Corrosion in 4D http://MURI4D.numis.northwestern.edu
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
On Oct 30, 2015 06:04, "Elias Assmann"  wrote:

> Hi List,
>
> I started a calculation with ‘runsp … -it -noHinv -min’, and noticed
> that lapw1 was being called three times per cycle: once with ‘-up
> -it’, then ‘-up’, ‘-dn’ without ‘it’ (after the first two, when :MIX
> switched from PRATT to MSE1a).  Is that normal?
>
> Note that the calculation seemed to be running normally; there was a
> *WARNING** from scfm, but I could not find any details about that.
>
>
> Elias
>
>
> From the scf:
>
> :ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.07263654
> :ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.08807566
> :ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.07629953
> :ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.10757386
>
> :DIS  :  ( 0.0516339 for atom5 spin 1)  0.0115736
> :DIS  :  ( 0.2895640 for atom1 spin 1)  0.0590266
> :DIS  :  ( 0.1109556 for atom1 spin 1)  0.0266441
> :DIS  :  ( 0.4511020 for atom2 spin 2)  0.0847330
>
> Here is the :log file (first column is the runtime, I removed the date
> for brevity):
>
>  >   (runsp) options: -p -ec .0001 -cc .0001 -fc 0.5 -i 1000 -it
> -noHinv -orb -min
> 00:00:28 > (x) lapw0 -p
> 00:00:00 > (x) orb -up -p
> 00:00:00 > (x) orb -dn -p
> 00:02:01 > (x) lapw1 -it -up -p -orb -noHinv -c
> 00:01:59 > (x) lapw1 -it -dn -p -orb -noHinv -c
> 00:00:44 > (x) lapw2 -up -p -c -orb
> 00:00:45 > (x) sumpara -up -d
> 00:00:38 > (x) lapw2 -dn -p -c -orb
> 00:00:44 > (x) sumpara -dn -d
> 00:00:41 > (x) lapwdm -up -p -c
> 00:00:00 > (x) sumpara -up -d
> 00:00:42 > (x) lapwdm -dn -p -c
> 00:00:01 > (x) sumpara -dn -d
> 00:00:01 > (x) lcore -up
> 00:00:02 > (x) lcore -dn
> 00:00:11 > (x) mixer -orb
> 00:00:28 > (x) lapw0 -p
> 00:00:00 > (x) orb -up -p
> 00:00:25 > (x) orb -dn -p
> 00:01:06 > (x) lapw1 -it -up -p -orb -noHinv -c
> 00:01:07 > (x) lapw1 -it -dn -p -orb -noHinv -c
> 00:00:44 > (x) lapw2 -up -p -c -orb
> 00:00:45 > (x) sumpara -up -d
> 00:00:45 > (x) lapw2 -dn -p -c -orb
> 00:00:45 > (x) sumpara -dn -d
> 00:00:43 > (x) lapwdm -up -p -c
> 00:00:00 > (x) sumpara -up -d
> 00:00:41 > (x) lapwdm -dn -p -c
> 00:00:00 > (x) sumpara -dn -d
> 00:00:01 > (x) lcore -up
> 00:00:03 > (x) lcore -dn
> 00:00:12 > (x) mixer -orb
> 00:00:28 > (x) lapw0 -p
> 00:00:00 > (x) orb -up -p
> 00:00:28 > (x) orb -dn -p
> 00:01:08 > (x) lapw1 -it -up -p -orb -noHinv -c
> 00:01:59 > (x) lapw1 -up -p -orb -c
> 00:02:01 > (x) lapw1 -dn -p -orb -c
> 00:00:39 > (x) lapw2 -up -p -c -orb
> 00:00:44 > (x) sumpara -up -d
> 00:00:39 > (x) lapw2 -dn -p -c -orb
> 00:00:44 > (x) sumpara -dn -d
> 00:00:40 > (x) lapwdm -up -p -c
> 00:00:01 > (x) sumpara -up -d
> 00:00:40 > (x) lapwdm -dn -p -c
> 00:00:01 > (x) sumpara -dn -d
> 00:00:01 > (x) lcore -up
> 00:00:02 > (x) lcore -dn
> 00:00:14 > (x) mixer -orb
> 00:00:27 > (x) lapw0 -p
> 00:00:00 > (x) orb -up -p
> 00:00:23 > (x) orb -dn -p
> 00:01:07 > (x) lapw1 -it -up -p -orb -noHinv -c
> 00:02:01 > (x) lapw1 -up -p -orb -c
> 00:02:01 > (x) lapw1 -dn -p -orb -c
> 00:00:35 > (x) lapw2 -up -p -c -orb
> 00:00:45 > (x) sumpara -up -d
> 00:00:33 > (x) lapw2 -dn -p -c -orb
> 00:00:45 > (x) sumpara -dn -d
> 00:00:40 > (x) lapwdm -up -p -c
> 00:00:01 > (x) sumpara -up -d
> 00:00:40 > (x) lapwdm -dn -p -c
> 00:00:01 > (x) sumpara -dn -d
> 00:00:01 > (x) lcore -up
> 00:00:02 > (x) lcore -dn
>  > (x) mixer -orb
>
> --
> Elias Assmann
> Institute of Theoretical and Computational Physics
> TU Graz   ⟨https://itp.tugraz.at/⟩
> ___
> 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] runsp -it: lapw1 called thrice?

2015-10-30 Thread Elias Assmann

Hi List,

I started a calculation with ‘runsp … -it -noHinv -min’, and noticed
that lapw1 was being called three times per cycle: once with ‘-up
-it’, then ‘-up’, ‘-dn’ without ‘it’ (after the first two, when :MIX
switched from PRATT to MSE1a).  Is that normal?

Note that the calculation seemed to be running normally; there was a
*WARNING** from scfm, but I could not find any details about that.


Elias


From the scf:

:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.07263654
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.08807566
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.07629953
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.10757386

:DIS  :  ( 0.0516339 for atom5 spin 1)  0.0115736
:DIS  :  ( 0.2895640 for atom1 spin 1)  0.0590266
:DIS  :  ( 0.1109556 for atom1 spin 1)  0.0266441
:DIS  :  ( 0.4511020 for atom2 spin 2)  0.0847330

Here is the :log file (first column is the runtime, I removed the date
for brevity):

 >   (runsp) options: -p -ec .0001 -cc .0001 -fc 0.5 -i 1000 -it
-noHinv -orb -min
00:00:28 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:00 > (x) orb -dn -p
00:02:01 > (x) lapw1 -it -up -p -orb -noHinv -c
00:01:59 > (x) lapw1 -it -dn -p -orb -noHinv -c
00:00:44 > (x) lapw2 -up -p -c -orb
00:00:45 > (x) sumpara -up -d
00:00:38 > (x) lapw2 -dn -p -c -orb
00:00:44 > (x) sumpara -dn -d
00:00:41 > (x) lapwdm -up -p -c
00:00:00 > (x) sumpara -up -d
00:00:42 > (x) lapwdm -dn -p -c
00:00:01 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:02 > (x) lcore -dn
00:00:11 > (x) mixer -orb
00:00:28 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:25 > (x) orb -dn -p
00:01:06 > (x) lapw1 -it -up -p -orb -noHinv -c
00:01:07 > (x) lapw1 -it -dn -p -orb -noHinv -c
00:00:44 > (x) lapw2 -up -p -c -orb
00:00:45 > (x) sumpara -up -d
00:00:45 > (x) lapw2 -dn -p -c -orb
00:00:45 > (x) sumpara -dn -d
00:00:43 > (x) lapwdm -up -p -c
00:00:00 > (x) sumpara -up -d
00:00:41 > (x) lapwdm -dn -p -c
00:00:00 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:03 > (x) lcore -dn
00:00:12 > (x) mixer -orb
00:00:28 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:28 > (x) orb -dn -p
00:01:08 > (x) lapw1 -it -up -p -orb -noHinv -c
00:01:59 > (x) lapw1 -up -p -orb -c
00:02:01 > (x) lapw1 -dn -p -orb -c
00:00:39 > (x) lapw2 -up -p -c -orb
00:00:44 > (x) sumpara -up -d
00:00:39 > (x) lapw2 -dn -p -c -orb
00:00:44 > (x) sumpara -dn -d
00:00:40 > (x) lapwdm -up -p -c
00:00:01 > (x) sumpara -up -d
00:00:40 > (x) lapwdm -dn -p -c
00:00:01 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:02 > (x) lcore -dn
00:00:14 > (x) mixer -orb
00:00:27 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:23 > (x) orb -dn -p
00:01:07 > (x) lapw1 -it -up -p -orb -noHinv -c
00:02:01 > (x) lapw1 -up -p -orb -c
00:02:01 > (x) lapw1 -dn -p -orb -c
00:00:35 > (x) lapw2 -up -p -c -orb
00:00:45 > (x) sumpara -up -d
00:00:33 > (x) lapw2 -dn -p -c -orb
00:00:45 > (x) sumpara -dn -d
00:00:40 > (x) lapwdm -up -p -c
00:00:01 > (x) sumpara -up -d
00:00:40 > (x) lapwdm -dn -p -c
00:00:01 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:02 > (x) lcore -dn
 > (x) mixer -orb

-- 
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz   ⟨https://itp.tugraz.at/⟩
___
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] Mapping primitive cell reciprocal vectors to the conventional cell

2015-10-30 Thread Priyanka Seth


Hello,

I am trying to post-process/visualize my results outside WIEN2K and for 
this I need data on the k-mesh of the conventional unit cell. I 
understand from the manual and the mailing list that different 
structures use either conventional or primitive reciprocal lattice 
vectors. I am studying a structure with the space group '3139_I4/mmm' 
and based on a visualization of the full BZ, and it looks like the 
*klist* files use the primitive reciprocal lattice vectors despite the 
structure being 'B' which I understood uses a conventional reciprocal 
unit cell.


I would like to know if there is any way
1) to ask WIEN2K to work in the conventional unit cell reciprocal basis?
2) to convert from my existing primitive cell *klist to a conventional 
cell *klist: I see that conv2prim converts a conventional struct to the 
primitive cell, is it possible to do the reverse for the reciprocal cell?
3) to access the matrices that I would need to do this transformation by 
hand?


I think all I need is a mapping from the primitive to conventional cell 
k points. I am looking for ways to do this both within WIEN2K, if 
possible, or using external tools/software.


Thank you in advance for your help,
Priyanka Seth
___
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

Re: [Wien] runsp -it: lapw1 called thrice?

2015-10-30 Thread Elias Assmann

On 10/30/2015 01:03 PM, Laurence Marks wrote:
> This is normal. You will see that the second call has no "-it". The
> shell script detects if there is a problem with the iterative mode and
> switches to non-iterative diagonalization.

Thank you for the clarification.  I had never noticed the behavior
before.  I guess this also explains why I sometimes see ‘-it -up; -up;
-dn’, and sometimes ‘-it -up; -it -dn; -dn’.

Elias



-- 
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz   ⟨https://itp.tugraz.at/⟩



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Wien] Mapping primitive cell reciprocal vectors to the conventional cell

2015-10-30 Thread Yue-Wen Fang

Dear Priyanka,

I think what you want to do can all be done by using the tool Xcrysden
which can read the WIEN2k struct files.

In the menu of "Display", you can choose primitive cell or conventional
cell based on your requirements. Besides, you can use the menu "Tools" to
determine the k-path.

Plz have a try and play with it!

Bests
Fang


2015-10-30 20:50 GMT+08:00 Priyanka Seth :

> Hello,
>
> I am trying to post-process/visualize my results outside WIEN2K and for
> this I need data on the k-mesh of the conventional unit cell. I understand
> from the manual and the mailing list that different structures use either
> conventional or primitive reciprocal lattice vectors. I am studying a
> structure with the space group '3139_I4/mmm' and based on a visualization
> of the full BZ, and it looks like the *klist* files use the primitive
> reciprocal lattice vectors despite the structure being 'B' which I
> understood uses a conventional reciprocal unit cell.
>
> I would like to know if there is any way
> 1) to ask WIEN2K to work in the conventional unit cell reciprocal basis?
> 2) to convert from my existing primitive cell *klist to a conventional
> cell *klist: I see that conv2prim converts a conventional struct to the
> primitive cell, is it possible to do the reverse for the reciprocal cell?
> 3) to access the matrices that I would need to do this transformation by
> hand?
>
> I think all I need is a mapping from the primitive to conventional cell k
> points. I am looking for ways to do this both within WIEN2K, if possible,
> or using external tools/software.
>
> Thank you in advance for your help,
> Priyanka Seth
> ___
> 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
>



-- 

Yue-Wen FANG, PhD candidate
East China Normal University  
___
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

Re: [Wien] runsp -it: lapw1 called thrice?

2015-10-30 Thread Peter Blaha


Yes, this can happen.

Towards end of the scf (or when mixer mixes very little, the iterative 
diagonalization may fail with a linear dependency error (Cholesky). This 
is trapped in the run_lapw script and a "normal" lapw1 is restarted.


If it happens more often, one should change the number of bands in the 
iterative diagonalization (NBAND in the bottom of case.in1).


The "WARNINGS" probably come from mixer, where he finds that some mixing 
conditions are strange and issues a warning. Unfortunately, no explicit 
explanation of this warning is printed.




On 10/30/2015 12:03 PM, Elias Assmann wrote:

Hi List,

I started a calculation with ‘runsp … -it -noHinv -min’, and noticed
that lapw1 was being called three times per cycle: once with ‘-up
-it’, then ‘-up’, ‘-dn’ without ‘it’ (after the first two, when :MIX
switched from PRATT to MSE1a).  Is that normal?

Note that the calculation seemed to be running normally; there was a
*WARNING** from scfm, but I could not find any details about that.


Elias


 From the scf:

:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.07263654
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.08807566
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.07629953
:ENE  : *WARNING** TOTAL ENERGY IN Ry =  -222788.10757386

:DIS  :  ( 0.0516339 for atom5 spin 1)  0.0115736
:DIS  :  ( 0.2895640 for atom1 spin 1)  0.0590266
:DIS  :  ( 0.1109556 for atom1 spin 1)  0.0266441
:DIS  :  ( 0.4511020 for atom2 spin 2)  0.0847330

Here is the :log file (first column is the runtime, I removed the date
for brevity):

  >   (runsp) options: -p -ec .0001 -cc .0001 -fc 0.5 -i 1000 -it
-noHinv -orb -min
00:00:28 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:00 > (x) orb -dn -p
00:02:01 > (x) lapw1 -it -up -p -orb -noHinv -c
00:01:59 > (x) lapw1 -it -dn -p -orb -noHinv -c
00:00:44 > (x) lapw2 -up -p -c -orb
00:00:45 > (x) sumpara -up -d
00:00:38 > (x) lapw2 -dn -p -c -orb
00:00:44 > (x) sumpara -dn -d
00:00:41 > (x) lapwdm -up -p -c
00:00:00 > (x) sumpara -up -d
00:00:42 > (x) lapwdm -dn -p -c
00:00:01 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:02 > (x) lcore -dn
00:00:11 > (x) mixer -orb
00:00:28 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:25 > (x) orb -dn -p
00:01:06 > (x) lapw1 -it -up -p -orb -noHinv -c
00:01:07 > (x) lapw1 -it -dn -p -orb -noHinv -c
00:00:44 > (x) lapw2 -up -p -c -orb
00:00:45 > (x) sumpara -up -d
00:00:45 > (x) lapw2 -dn -p -c -orb
00:00:45 > (x) sumpara -dn -d
00:00:43 > (x) lapwdm -up -p -c
00:00:00 > (x) sumpara -up -d
00:00:41 > (x) lapwdm -dn -p -c
00:00:00 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:03 > (x) lcore -dn
00:00:12 > (x) mixer -orb
00:00:28 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:28 > (x) orb -dn -p
00:01:08 > (x) lapw1 -it -up -p -orb -noHinv -c
00:01:59 > (x) lapw1 -up -p -orb -c
00:02:01 > (x) lapw1 -dn -p -orb -c
00:00:39 > (x) lapw2 -up -p -c -orb
00:00:44 > (x) sumpara -up -d
00:00:39 > (x) lapw2 -dn -p -c -orb
00:00:44 > (x) sumpara -dn -d
00:00:40 > (x) lapwdm -up -p -c
00:00:01 > (x) sumpara -up -d
00:00:40 > (x) lapwdm -dn -p -c
00:00:01 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:02 > (x) lcore -dn
00:00:14 > (x) mixer -orb
00:00:27 > (x) lapw0 -p
00:00:00 > (x) orb -up -p
00:00:23 > (x) orb -dn -p
00:01:07 > (x) lapw1 -it -up -p -orb -noHinv -c
00:02:01 > (x) lapw1 -up -p -orb -c
00:02:01 > (x) lapw1 -dn -p -orb -c
00:00:35 > (x) lapw2 -up -p -c -orb
00:00:45 > (x) sumpara -up -d
00:00:33 > (x) lapw2 -dn -p -c -orb
00:00:45 > (x) sumpara -dn -d
00:00:40 > (x) lapwdm -up -p -c
00:00:01 > (x) sumpara -up -d
00:00:40 > (x) lapwdm -dn -p -c
00:00:01 > (x) sumpara -dn -d
00:00:01 > (x) lcore -up
00:00:02 > (x) lcore -dn
  > (x) mixer -orb



--

  P.Blaha
--
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.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--
___
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

Re: [Wien] x w2w error in WIEN2k.14

2015-10-30 Thread Yue-Wen Fang

Dear Elias,

Thanks for your reminding me of the errors. Yes, I meant that the
case.psinkup, case.psinkdn, case.psiagraup and case.psiagradn file were
empty, but it was found that case.outputwplotup and case.outputwplotdn
files were not empty.

Actually the error files were also empty. After the execution of the two
commands, it showed that

+ x wplot -wf 2 -up -p
 written on 30Oct2015 at 01:34:44
NON-ORTHOGONAL AXES
0.081u 0.041s 0:00.21 57.1% 0+0k 0+0io 3pf+0w
+ x wplot -wf 2 -dn -p
 written on 30Oct2015 at 02:29:18
NON-ORTHOGONAL AXES
0.089u 0.034s 0:00.19 57.8% 0+0k 0+0io 2pf+0w

In the *:log* file, it was

Fri Oct 30 19:29:23 CST 2015> (x) wplot -wf 2 -up -p
Fri Oct 30 19:29:23 CST 2015> (x) wplot -wf 2 -dn -p

But this tool can work for non-spin polarized calcualtions, e.g. GaAs.

Bests
Fang

2015-10-30 17:00 GMT+08:00 Elias Assmann :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/30/2015 03:40 AM, Yue-Wen Fang wrote:
> > Step 1. write_inwplot
> >
> > Step 2.  x wplot -wf 1 -up
> >
> > Step 3. x wplot -wf 1 -dn
> >
> > According to the User guide, these three commands should  create
> > case*.psink and case*.psiarg " files, but I found there was no
> > data within these files. Could you show me how to export WF for
> > spin-polarized cases?
>
> Do you mean the files existed but were empty?  Then there must have
> been some error, and you need to include error messages.
>
> Elias
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJWMzGzAAoJEE/4gtQZfOqPenAP/iQbqOv1E1bVA5EZqVQyz6zn
> IzQKts6LmiBefA8BgUqN0PrIxPptC0WdrFy+YSUu/Jua0Q9aFSKwJj0ZfFvhUpNz
> YT7Wjf3TcLShhQhhpAAZOZLMaLpLaTJQ0MY126r4OCOI+LABiGKL7gN76X7fuYi0
> i5Dk8EKFUfylv9kNjnmRHWaLR3jM+Lv715A0lVIgGAPFTtiKaNkPRH870ni+ihse
> fQ67j2UFFY5c5IZ/uo0l8fTZ/ce6vHtPJGxh9Mwpw++0d3Jfi9/XmE9zTZwNgrEk
> sL7YbnSES3LNbNLLxTwjhmElMPo08XeopuXQE3K+DCcG9UBDutBSz+I/R2xKMD/u
> lo86KwpUHzXbygKaYFGKjVEuBpEsoDD0VYFddz6l8Wk+npi0zJ714EZslmN/n1MH
> uEiR4s9nLXSBlg2RyQHiehTAUZULVP3qxRdJjR4/XCKolzJ13I8pUqKLTQXaSD20
> GNGweLtIZ+uTfASbSnV6mZKBootm56zhavmjg3XfHheQ9nLxes4/1kw1WLqS0+rc
> V6ewnHW9ogGkqRGwXgNj8ACJAjbIZIT748Y5CBogkpI62JS+1GDv8SjZ5Av4564m
> 1t+2Ta4EWRt2TgBMubMHhgxplZfqhg5owABO6i3zI1tO1unDbhsngc1sLza+HeVA
> tjKnOPe/sCWiCrDyDrKV
> =E5uQ
> -END PGP SIGNATURE-
> ___
> 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
>



-- 

Yue-Wen FANG, PhD candidate
East China Normal University  
___
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

Re: [Wien] x w2w error in WIEN2k.14

Re: [Wien] Bulk vs supercell Plasma frequency

Re: [Wien] x w2w error in WIEN2k.14

Re: [Wien] x w2w error in WIEN2k.14

Re: [Wien] x w2w error in WIEN2k.14

Re: [Wien] runsp -it: lapw1 called thrice?

[Wien] runsp -it: lapw1 called thrice?

[Wien] Mapping primitive cell reciprocal vectors to the conventional cell

Re: [Wien] runsp -it: lapw1 called thrice?

Re: [Wien] Mapping primitive cell reciprocal vectors to the conventional cell

Re: [Wien] runsp -it: lapw1 called thrice?

Re: [Wien] x w2w error in WIEN2k.14

12 matches

Site Navigation

Mail list logo

Footer information