Re: [Wien] error in vorb

[Gavin Abo]

I still don't see any information that can help pinpoint what went 
wrong.  So you have to keep looking.


You say "x orb -up/-dn...it is running without any error".  If that's 
true, I don't think you should be getting that error during the scf 
unless perhaps you didn't run those commands on the same files that 
produced the error. Are you sure your ran the commands in the same 
directory of files from your optimize job that the error is occurring for?


Your dayfile shows that you are using WIEN2k 13.1.  Have you tried the 
same calculation using WIEN2k 16.1?  There have been fixes made to the 
orb package (SRC_orb) [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].  You can also see 
that fixes and updates have been made to the SRC_lapw0 package. This may 
be important as you can see that lapw0 comes before orb in your dayfile. 
If I remember correctly, there was also a bunch of better checks added 
to catch and report errors in the versions that came after 13.1.


There is also a blank line in case.inorb after the nsic line and before 
the U,J list starts that you could try to remove to see if that fixes 
the problem or not, which does not match with the format of case.inorb 
template ($WIENROOT/SRC_templates/case.inorb).


On 7/2/2017 7:21 AM, shamik chakrabarti wrote:

Dear Gavin,

case.dmatup & case.dmatdn files have data & hence size 
greater than 0. Most importantly, when I run x orb -up/-dn...it is 
running without any error. Only during SCF, x orb -up is showing error as;


 Calculating L2NTV_V in 
/home/wien2k/Desktop/Wien_Computations/Shamik/L2NTV_V

on kbiswasw2 with PID 352
using WIEN2k_13.1 (Release 17/6/2013) in 
/home/wien2k/Wien2k_5_7_2015/WIEN2k



start (Sun Jul  2 18:03:35 IST 2017) with lapw0 (40/99 to go)

cycle 1 (Sun Jul  2 18:03:35 IST 2017) (40/99 to go)

>   lapw0 (18:03:35) 135.128u 0.370s 2:18.38 97.9%0+0k 0+230616io 0pf+0w
>   orb -up (18:05:54) 0.010u 0.002s 0:00.01 100.0%0+0k 0+56io 0pf+0w

>   stop error
.

with regards,

On Sun, Jul 2, 2017 at 6:50 PM, shamik chakrabarti 
mailto:shamik...@gmail.com>> wrote:


Dear Gavin,

case.dmatup & case.dmatdn files have data & hence size
greater than 0. Most importantly, when I run x orb -up/-dn...it is
running without any error. Only during SCF, x orb -up is showing
error as;

 Calculating L2NTV_V in
/home/wien2k/Desktop/Wien_Computations/Shamik/L2NTV_V
on kbiswasw2 with PID 352
using WIEN2k_13.1 (Release 17/6/2013) in
/home/wien2k/Wien2k_5_7_2015/WIEN2k


start (Sun Jul  2 18:03:35 IST 2017) with lapw0 (40/99 to go)

cycle 1 (Sun Jul  2 18:03:35 IST 2017) (40/99 to go)

>   lapw0 (18:03:35) 135.128u 0.370s 2:18.38 97.9%0+0k 0+230616io
0pf+0w
>   orb -up (18:05:54) 0.010u 0.002s 0:00.01 100.0%0+0k 0+56io 0pf+0w

>   stop error

I am sending the struct file also herewith this mail for your
consideration.

with regards,

On Sun, Jul 2, 2017 at 1:32 AM, Gavin Abo mailto:gs...@crimson.ua.edu>> wrote:

I'm not seeing anything that is noticeably problematic with
your case.indmc and case.inorb files.  They seem fine.

The "error in vorb" is not informative enough.  So you need to
check yourself for further hints of the problem. [

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10490.html

<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10490.html>
]

Usually, there is a forrtl error and traceback message.  Or
there might be a warning or error message that happened much
earlier in the calculation.

Another possible cause of the "error in vorb"error might be a
problem with a dmat file.  The dmat file(s) have a file size
greater than 0? [

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10492.html

<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10492.html>
]

On 6/30/2017 12:36 AM, shamik chakrabarti wrote:

Dear wien2k users,

   I have tried to run volume optimization of
a 56 atomic system using GGA+U approach. I have applied U to
V (4 atoms) & Ni (8 atoms). However, it is failed to run
indicating "error in vorb" in error file. I am sending the
case.indmc & case.inorb file herewith this mail. Any response
in this regard is eagerly awaited.
Thanks in advance.

with regards,

-- 
Dr. Shamik Chakrabarti

Post Doctoral Research Associate
Dept. of Condensed Matter Physics and  Material Science
S N Bose National Centre for Basic Sciences
Kolkata-700098
INDIA


___
Wien mailing list
   

[Wien] Fwd: Re: error in vorb

[Gavin Abo]

 Forwarded Message 

Subject:Re: [Wien] error in vorb
Date:   Sun, 2 Jul 2017 20:02:22 +0200
From:   Peter Blaha 
To: Gavin Abo 



Do  "lse"  (ls -als *.error)

You should get a list of all error files.

Is there a   orb.error  ??  (a leftover when you called in a wrong way
in a terminal "x orb" (without -up/dn ??

Remove it.

Am 02.07.2017 um 17:14 schrieb Gavin Abo:
I still don't see any information that can help pinpoint what went 
wrong.  So you have to keep looking.


You say "x orb -up/-dn...it is running without any error".  If that's 
true, I don't think you should be getting that error during the scf 
unless perhaps you didn't run those commands on the same files that 
produced the error. Are you sure your ran the commands in the same 
directory of files from your optimize job that the error is occurring for?


Your dayfile shows that you are using WIEN2k 13.1.  Have you tried the 
same calculation using WIEN2k 16.1?  There have been fixes made to the 
orb package (SRC_orb) [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].  You can also see 
that fixes and updates have been made to the SRC_lapw0 package. This may 
be important as you can see that lapw0 comes before orb in your dayfile. 
If I remember correctly, there was also a bunch of better checks added 
to catch and report errors in the versions that came after 13.1.


There is also a blank line in case.inorb after the nsic line and before 
the U,J list starts that you could try to remove to see if that fixes 
the problem or not, which does not match with the format of case.inorb 
template ($WIENROOT/SRC_templates/case.inorb).


On 7/2/2017 7:21 AM, shamik chakrabarti wrote:

Dear Gavin,

case.dmatup & case.dmatdn files have data & hence size 
greater than 0. Most importantly, when I run x orb -up/-dn...it is 
running without any error. Only during SCF, x orb -up is showing error as;


 Calculating L2NTV_V in 
/home/wien2k/Desktop/Wien_Computations/Shamik/L2NTV_V

on kbiswasw2 with PID 352
using WIEN2k_13.1 (Release 17/6/2013) in 
/home/wien2k/Wien2k_5_7_2015/WIEN2k



start (Sun Jul  2 18:03:35 IST 2017) with lapw0 (40/99 to go)

cycle 1 (Sun Jul  2 18:03:35 IST 2017) (40/99 to go)

>   lapw0 (18:03:35) 135.128u 0.370s 2:18.38 97.9%0+0k 0+230616io 0pf+0w
>   orb -up (18:05:54) 0.010u 0.002s 0:00.01 100.0%0+0k 0+56io 0pf+0w

>   stop error
.

with regards,

On Sun, Jul 2, 2017 at 6:50 PM, shamik chakrabarti 
mailto:shamik...@gmail.com>> wrote:


Dear Gavin,

case.dmatup & case.dmatdn files have data & hence size
greater than 0. Most importantly, when I run x orb -up/-dn...it is
running without any error. Only during SCF, x orb -up is showing
error as;

 Calculating L2NTV_V in
/home/wien2k/Desktop/Wien_Computations/Shamik/L2NTV_V
on kbiswasw2 with PID 352
using WIEN2k_13.1 (Release 17/6/2013) in
/home/wien2k/Wien2k_5_7_2015/WIEN2k


start (Sun Jul  2 18:03:35 IST 2017) with lapw0 (40/99 to go)

cycle 1 (Sun Jul  2 18:03:35 IST 2017) (40/99 to go)

>   lapw0 (18:03:35) 135.128u 0.370s 2:18.38 97.9%0+0k 0+230616io
0pf+0w
>   orb -up (18:05:54) 0.010u 0.002s 0:00.01 100.0%0+0k 0+56io 0pf+0w

>   stop error

I am sending the struct file also herewith this mail for your
consideration.

with regards,

On Sun, Jul 2, 2017 at 1:32 AM, Gavin Abo mailto:gs...@crimson.ua.edu>> wrote:

I'm not seeing anything that is noticeably problematic with
your case.indmc and case.inorb files.  They seem fine.

The "error in vorb" is not informative enough.  So you need to
check yourself for further hints of the problem. [

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10490.html

<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10490.html>
]

Usually, there is a forrtl error and traceback message.  Or
there might be a warning or error message that happened much
earlier in the calculation.

Another possible cause of the "error in vorb"error might be a
problem with a dmat file.  The dmat file(s) have a file size
greater than 0? [

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10492.html

<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10492.html>
]

On 6/30/2017 12:36 AM, shamik chakrabarti wrote:

Dear wien2k users,

   I have tried to run volume optimization of
a 56 atomic system using GGA+U approach. I have applied U to
V (4 atoms) & Ni (8 atoms). However, it is failed to run
indicating "error in vorb" in error file. I am sending the
case.indmc & case.inorb file herewith this mail. Any response

[Wien] runsp_lapw -eece error

[Gavin Abo]

Has the use of EECE changed in WIEN2k 16.1 and not been documented?

I believe I have specified case.in0 according to the usersguide:

username@computername:~/wiendata/test$ cat test.in0
TOT  XC_WC (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSS)
NR2V  EECE IFFT (R2V)
   32   32   322.00  1min IFFT-parameters, enhancement factor, 
iprint


I created case.ineece from $WIENROOT/SRC_templates/case.ineece:

username@computername:~/wiendata/test$ cat test.ineece
-12.0  2   emin natom
1 1 2 iatom nlorb lorb
2 1 2 iatom nlorb lorb
EECE  HYBR / EECE mode
0.25  amount of exact exchange

The "runsp_lapw -eece" gives me the error:

username@computername:~/wiendata/test$ runsp_lapw -eece
hup: Command not found.
forrtl: severe (24): end-of-file during read, unit 5, file 
/home/username/wiendata/test/test.in0

Image  PCRoutineLine Source
lapw0  082221C9  Unknown   Unknown Unknown
lapw0  080755EE  MAIN__514 lapw0.F
lapw0  0804A757  Unknown   Unknown Unknown
libc.so.6  56E1FAF3  Unknown   Unknown Unknown

>   stop error

This seems to happen because lapw0 is executed without the "-eece" flag:

username@computername:~/wiendata/test$ x lapw0
forrtl: severe (24): end-of-file during read, unit 5, file 
/home/username/wiendata/test/test.in0

Image  PCRoutineLine Source
lapw0  082221C9  Unknown   Unknown Unknown
lapw0  080755EE  MAIN__514 lapw0.F
lapw0  0804A757  Unknown   Unknown Unknown
libc.so.6  56E3DAF3  Unknown   Unknown Unknown
0.0u 0.0s 0:00.02 50.0% 0+0k 0+24io 0pf+0w
error: command   /home/username/WIEN2k/lapw0 lapw0.def   failed

If lapw0 is executed with the "-eece" flag:

username@computername:~/wiendata/test$ x lapw0 -eece
   0  LAPW0-Error. Check file lapw0.error and case.output0*.
LAPW0 - Error. Check file lapw0.error.
0.0u 0.0s 0:00.01 0.0% 0+0k 0+16io 0pf+0w
username@computername:~/wiendata/test$ cat *.error
 'LAPW0' - can't open unit:  5
 'LAPW0' -filename: test.in0eece
 'LAPW0' -  status: old  form: formatted
Error in LAPW1

This give me the above error as the filename extension seems to have 
changed from ineece to in0eece.


username@computername:~/wiendata/test$ cp test.ineece test.in0eece
username@computername:~/wiendata/test$ x lapw0 -eece
No potential option chosen
0.0u 0.0s 0:00.24 0.0% 0+0k 0+16io 0pf+0w

It seems like I can get past this by changing test.in0 to:

TOT  XC_WC (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSS)
NR2V  EECE IFFT (R2V)
   32   32   322.00  1min IFFT-parameters, enhancement factor, 
iprint


-12.0  2   emin natom
1 1 2 iatom nlorb lorb
2 1 2 iatom nlorb lorb

However, I may be losing the fraction input, as I don't see that read in 
lapw0.F near line 514:


511:  if (switch1 .eq. ' EECE') then
allocate(jeece(nat))
jeece = 0
514:read(5,*) inod, numbeece
read(5,'(a)') errmsg
do j=1,numbeece
  read(5,*) i1, i2, i3
  do jatom=1,nat
if (jatom .eq. i1) jeece(jatom) = 1
  enddo
enddo
  endif
___
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] wien2k 17.1

[Gavin Abo]

username@computername:~/WIEN2k$ sed -n 1p siteconfig_lapw

#!/bin/csh -fx
username@computername:~/WIEN2k$ ./siteconfig
unalias rm
set name = ./siteconfig
set bin = .
if ! ( -d . ) set bin = .
cd .
set bin = `pwd`
pwd
alias define_installdate date >$bin/WIEN2k_INSTALLDATE
alias wait echo "";echo " Press RETURN to continue"; set yn = ($<)
Word too long.
username@computername:~/WIEN2k$ sed -n 1p siteconfig_lapw
#!/bin/tcsh -f
username@computername:~/WIEN2k$ ./siteconfig



   *
   *W I E N*
   *  site configuration   *
   *

  Last configuration: Tue Jul 4 09:32:59 MDT 2017
  Wien Version:   WIEN2k_17.1 (Release 30/6/2017)
  System: unknown


  S   Specify a System
  C   Specify Compiler
  O   Compiling Options (Compiler/Linker, Libraries)
  P   Configure Parallel Execution
  D   Dimension Parameters
  R   Compile/Recompile
  U   Update a package
  L   Perl Path (if not in /usr/bin/perl)
  T   Temp Path

  Q   Quit

  Selection:

On 7/4/2017 7:46 AM, Peter Blaha wrote:

Put -fx  in the first line of siteconfig and rerun.

You will get a long debugging output.

eventually try

#!/bin/tcsh -f in the first line.

Am 04.07.2017 um 15:17 schrieb Dr. K. C. Bhamu:

Thank you Prof. Peter for the new version,

./siteconfig_lapw  give me the error on the terminal without any output:
*Word too long.*

How to short out this issue?

Regards
Bhamu




On Tue, Jul 4, 2017 at 5:29 PM, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> 
wrote:


Dear wien2k users,

A new version of wien2k has been released and is available for 
download.


Wien2k_17.1 contains all known bug fixes and in addition several new
features and enhancements (see http://www.wien2k.at/reg_user/updates
).

In particular there is a new non-local van der Waals module and a
new version of the mixer.

Best regards
--
   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.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





___
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] wien2k 17.1

[Gavin Abo]

Happens on Ubuntu with csh :

username@computername:~/WIEN2k$ which csh
/bin/csh
username@computername:~/WIEN2k$ dpkg -l csh
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  csh20110502-2ub amd64Shell with C-like syntax

It seems to work fine after switching the first line in siteconfig_lapw 
to tcsh.


On 7/4/2017 12:49 PM, Dr. K. C. Bhamu wrote:

Dear Sir,

I just changed "#!/bin/tcsh -f" in first line on ./siteconfigure_lapw 
and everything went perfect on my Laptop.


Sincerely
Bhamu



On Wed, Jul 5, 2017 at 12:01 AM, Peter Blaha 
mailto:pbl...@theochem.tuwien.ac.at>> 
wrote:


It is hard to debug for me, since I cannot reproduce the problem.

The problem is probably the alias   update_makefiles, which spans
over more than 20 lines.

csh --version yileds for me:  tcsh 6.18.01

Somewhere in the internet there is a hint that   pre 6.15 versions
may be limited to 1024 characters

Please check your version.

You may also test the hypothesis of a length problem by editing
siteconfig_lapw and removing all blanks at the beginning of the
lines spanning the alias command. The alias should then be less
than 1024 character.

Regards


Am 04.07.2017 um 17:44 schrieb Gavin Abo:

username@computername:~/WIEN2k$ sed -n 1p siteconfig_lapw

#!/bin/csh -fx
username@computername:~/WIEN2k$ ./siteconfig
unalias rm
set name = ./siteconfig
set bin = .
if ! ( -d . ) set bin = .
cd .
set bin = `pwd`
pwd
alias define_installdate date >$bin/WIEN2k_INSTALLDATE
alias wait echo "";echo " Press RETURN to continue"; set
yn = ($<)
Word too long.
username@computername:~/WIEN2k$ sed -n 1p siteconfig_lapw
#!/bin/tcsh -f
username@computername:~/WIEN2k$ ./siteconfig



*
*W I E N *
*  site configuration*
*

   Last configuration: Tue Jul 4 09:32:59 MDT 2017
   Wien Version:   WIEN2k_17.1 (Release 30/6/2017)
   System: unknown


   S   Specify a System
   C   Specify Compiler
   O   Compiling Options (Compiler/Linker, Libraries)
   P   Configure Parallel Execution
   D   Dimension Parameters
   R   Compile/Recompile
   U   Update a package
   L   Perl Path (if not in /usr/bin/perl)
   T   Temp Path

   Q   Quit

   Selection:

On 7/4/2017 7:46 AM, Peter Blaha wrote:

Put -fx  in the first line of siteconfig and rerun.

You will get a long debugging output.

eventually try

#!/bin/tcsh -f in the first line.

Am 04.07.2017 um 15:17 schrieb Dr. K. C. Bhamu:

Thank you Prof. Peter for the new version,

./siteconfig_lapw  give me the error on the terminal
without any output:
*Word too long.*

How to short out this issue?

Regards
Bhamu




On Tue, Jul 4, 2017 at 5:29 PM, Peter Blaha
mailto:pbl...@theochem.tuwien.ac.at>
<mailto:pbl...@theochem.tuwien.ac.at
<mailto:pbl...@theochem.tuwien.ac.at>>> wrote:

Dear wien2k users,

A new version of wien2k has been released and is
available for download.

Wien2k_17.1 contains all known bug fixes and in
addition several new
features and enhancements (see
http://www.wien2k.at/reg_user/updates
<http://www.wien2k.at/reg_user/updates>
<http://www.wien2k.at/reg_user/updates
<http://www.wien2k.at/reg_user/updates>>).

In particular there is a new non-local van der
Waals module and a
new version of the mixer.

Best regards
--
   P.Blaha

--

Peter BLAHA, Inst.f. Materials Chemistry, TU
Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX:
   

Re: [Wien] error in vorb continues...

[Gavin Abo]

What about L2NTV_V.outputorbup, any problematic messages seen in it 
similar to "Conflict in atom orb. number"  [1]?


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07531.html


On 7/6/2017 8:46 AM, shamik chakrabarti wrote:

Dear Gerhard,

 I have done 0% reduction during a normal SCF run, 
while have done 6% reduction during volume optimization run. No, I 
have not received any other error files other than uporb.error.


with regards,

___
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] Fw: Optical property calculation when spin orbit added

[Gavin Abo]

It has been awhile such that I don't remember, but I believe it was 
recommended not to use runsp_lapw with "-s lapw1 -e lcore" anymore as 
seen inthe post at [1] even though you still find a reference to it in 
the WIEN2k 17.1 usersguide under the optic section "8.17.1 Execution" on 
page 177 [2].


However, the above issue might come later after you have addressed the 
current problem.  The error shows that there is a problem with your 
SCFsp-U-SO.inso.  Do you still have the file in your WIEN2k working 
directory from when it was created by initso_lapw?  Perhaps it got moved 
when you did the save_lapw.


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12365.html


[2] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

On 7/6/2017 9:25 AM, shaymlal dayananda wrote:

Dear Dr. Karel

Thank you very much for your support. I tried your method. But command 
" runsp_lapw -s lapw1 -e lcore -orb -so" didn't complete.

The error is copied below.

 LAPW1 END
3730.384u 22.548s 1:02:35.44 99.9%  0+0k 112072+4310136io 8pf+0w
 LAPW1 END
3711.461u 21.067s 1:02:13.63 99.9%  0+0k 114088+4310888io 12pf+0w
forrtl: severe (64): input conversion error, unit 5, file SCFsp-U-SO.inso
Image  PCRoutine LineSource
lapwso 00477C6A  Unknown Unknown  Unknown
lapwso 00475867  Unknown Unknown  Unknown
lapwso 0041D3C8 init_ 124  init.F
lapwso 00422A66 MAIN__185  
lapwso.F

lapwso 00404706  Unknown Unknown  Unknown
libc.so.6  2B6606CF8D1D  Unknown Unknown  Unknown
lapwso 004045B9  Unknown Unknown  Unknown
0.053u 0.021s 0:00.89 7.8%  0+0k 3032+16io 4pf+0w

>   stop error

I already have completed and saved the SCF for spin polarized 
calculation with hubbard-U and SO. When I follow the interface it 
crashed at "view case.outputjoint". It says /cann't open case.outputjoint/

/
/
Thank you for your great help.

Chami




From: Wien > on behalf of Karel 
Vyborny mailto:vybor...@fzu.cz>>

Sent: Wednesday, July 5, 2017 7:33 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Optical property calculation when spin orbit added

Hello Chami,
here's an example of command sequence I used recently (using version 14)
to calculate case.epsilonup with both SO and Hubbard U.

init_lapw
initso_lapw
runsp_lapw -orb -so
# edit case.in2c (replace TOT by FERMI)
runsp_lapw -s lapw1 -e lcore -orb -so
x optic -c -orb -so -up
x joint -orb -so -up
x kram -up

Hope it helps. Ask me (preferably on my private email) if you also want to
check the input files.

Karel




--- x ---
dr. Karel Vyborny
Fyzikalni ustav AV CR, v.v.i.
Cukrovarnicka 10
Praha 6, CZ-16253
tel: +420220318459


On Tue, 4 Jul 2017, shaymlal dayananda wrote:

> Dear Prof. Blaha and developers.
>
> I am using Wien2k 14.1 version. I need to calculate the optical 
absorption

> spectrum of a SPIN POLARIZED (sp) system with spin orbital (SO) coupling
> and  hubbard-U. I finished a SCF calculation with sp,SO, and hubbard U.
> Now I want to calculate the absorption spectrum. I followed the 
userguide
> and continued with the given steps (pg 173). But it gave me errors. 
When I
> go trough the forum, I noticed some steps are changed. But I 
couldn't catch

> the correct way. I tried several suggestions, but all failed.
>
> Could you please let me know the correct way to follow for absorption
> spectrum for a system with SP, SO and Hubbard-U added. ?
>
> Thank you in advance.
>
> Chami
___
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] Fw: Optical property calculation when spin orbit added

[Gavin Abo]

If you are editing case.inso by hand, for NX and NX1, the X needs 
replaced by a number.  Though, I would think that would want to use the 
nice and easy to use interactive initso script in the terminal. [1]


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10625.html


On 7/6/2017 1:46 PM, shaymlal dayananda wrote:

Dear Dr. Abo

Thank you for your instruction. I already have tried that post in the 
forum. It also gave me the same error for "x lapwso -up".


About the inso file; Yes I do have case.inso in the working directory 
and it is copied bellow. Please have a look on it and please tell me 
if something is wrong in it. In my system I have two uranium and five 
oxygen. If I am correct, I should not add RLO in optics, and so, I 
believe the last three lines are correct.


WFFIL
 4  1  0  llmax,ipr,kpot
 -12.   5.   emin,emax (output energy window)
   0.  1.  0. direction of magnetization (lattice vectors)
 NX   number of atoms for which RLO is added
 NX1   -4.97  0.0005  atom number,e-lo,de (case.in1), repeat 
NX times
 0 0 0 0 0number of atoms for which SO is switch 
off; atoms


Thank you in advance.

Chami


On Thursday, July 6, 2017 12:35 PM, Gavin Abo  
wrote:



It has been awhile such that I don't remember, but I believe it was 
recommended not to use runsp_lapw with "-s lapw1 -e lcore" anymore as 
seen inthe post at [1] even though you still find a reference to it in 
the WIEN2k 17.1 usersguide under the optic section "8.17.1 Execution" 
on page 177 [2].
However, the above issue might come later after you have addressed the 
current problem.  The error shows that there is a problem with your 
SCFsp-U-SO.inso.  Do you still have the file in your WIEN2k working 
directory from when it was created by initso_lapw?  Perhaps it got 
moved when you did the save_lapw.
[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12365.html

[2] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

On 7/6/2017 9:25 AM, shaymlal dayananda wrote:

Dear Dr. Karel

Thank you very much for your support. I tried your method. But 
command " runsp_lapw -s lapw1 -e lcore -orb -so" didn't complete.

The error is copied below.

 LAPW1 END
3730.384u 22.548s 1:02:35.44 99.9% 0+0k 112072+4310136io 8pf+0w
 LAPW1 END
3711.461u 21.067s 1:02:13.63 99.9% 0+0k 114088+4310888io 12pf+0w
forrtl: severe (64): input conversion error, unit 5, file SCFsp-U-SO.inso
Image  PC RoutineLineSource
lapwso 00477C6A Unknown   Unknown  
Unknown
lapwso 00475867 Unknown   Unknown  
Unknown

lapwso 0041D3C8 init_ 124  init.F
lapwso 00422A66 MAIN__185  
lapwso.F
lapwso 00404706 Unknown   Unknown  
Unknown
libc.so.6  2B6606CF8D1D Unknown   Unknown  
Unknown
lapwso 004045B9 Unknown   Unknown  
Unknown

0.053u 0.021s 0:00.89 7.8%  0+0k 3032+16io 4pf+0w

>   stop error

I already have completed and saved the SCF for spin polarized 
calculation with hubbard-U and SO. When I follow the interface it 
crashed at "view case.outputjoint". It says /cann't open 
case.outputjoint/

/
/
Thank you for your great help.

Chami




From: Wien  on behalf of 
Karel Vyborny 

Sent: Wednesday, July 5, 2017 7:33 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Optical property calculation when spin orbit added

Hello Chami,
here's an example of command sequence I used recently (using version 14)
to calculate case.epsilonup with both SO and Hubbard U.

init_lapw
initso_lapw
runsp_lapw -orb -so
# edit case.in2c (replace TOT by FERMI)
runsp_lapw -s lapw1 -e lcore -orb -so
x optic -c -orb -so -up
x joint -orb -so -up
x kram -up

Hope it helps. Ask me (preferably on my private email) if you also 
want to

check the input files.

Karel




--- x ---
dr. Karel Vyborny
Fyzikalni ustav AV CR, v.v.i.
Cukrovarnicka 10
Praha 6, CZ-16253
tel: +420220318459


On Tue, 4 Jul 2017, shaymlal dayananda wrote:

> Dear Prof. Blaha and developers.
>
> I am using Wien2k 14.1 version. I need to calculate the optical 
absorption
> spectrum of a SPIN POLARIZED (sp) system with spin orbital (SO) 
coupling

> and  hubbard-U. I finished a SCF calculation with sp,SO, and hubbard U.
> Now I want to calculate the absorption spectrum. I followed the 
userguide
> and continued with the given steps (pg 173). But it gave me errors. 
When I
> go trough the forum, I noticed some steps are changed. But I 
couldn't catch

> the correct way. I tried several suggestions, but all failed.
>
> Could you please let me know the correct w

Re: [Wien] Fw: Optical property calculation when spin orbit added

[Gavin Abo]

And yes, you should not add RLO (relativistic local orbitals) for optics 
[ http://susi.theochem.tuwien.ac.at/reg_user/limitations/ ].


NX   number of atoms for which *RLO* is added <- 
Should be obvious that this and the NX1 lines related to RLOs should be 
deleted from case.inso for doing optics.


On 7/6/2017 2:14 PM, Gavin Abo wrote:


If you are editing case.inso by hand, for NX and NX1, the X needs 
replaced by a number. Though, I would think that you would want to use 
the nice and easy to use interactive initso script in the terminal. [1]


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10625.html


On 7/6/2017 1:46 PM, shaymlal dayananda wrote:

Dear Dr. Abo

Thank you for your instruction. I already have tried that post in the 
forum. It also gave me the same error for "x lapwso -up".


About the inso file; Yes I do have case.inso in the working directory 
and it is copied bellow. Please have a look on it and please tell me 
if something is wrong in it. In my system I have two uranium and five 
oxygen. If I am correct, I should not add RLO in optics, and so, I 
believe the last three lines are correct.


WFFIL
 4  1  0  llmax,ipr,kpot
 -12.   5.   emin,emax (output energy window)
   0.  1.  0. direction of magnetization (lattice 
vectors)

 NX   number of atoms for which RLO is added
 NX1   -4.97  0.0005  atom number,e-lo,de (case.in1), repeat 
NX times
 0 0 0 0 0number of atoms for which SO is switch 
off; atoms


Thank you in advance.

Chami


On Thursday, July 6, 2017 12:35 PM, Gavin Abo  
wrote:



It has been awhile such that I don't remember, but I believe it was 
recommended not to use runsp_lapw with "-s lapw1 -e lcore" anymore as 
seen inthe post at [1] even though you still find a reference to it 
in the WIEN2k 17.1 usersguide under the optic section "8.17.1 
Execution" on page 177 [2].
However, the above issue might come later after you have addressed 
the current problem.  The error shows that there is a problem with 
your SCFsp-U-SO.inso.  Do you still have the file in your WIEN2k 
working directory from when it was created by initso_lapw?  Perhaps 
it got moved when you did the save_lapw.
[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12365.html

[2] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

On 7/6/2017 9:25 AM, shaymlal dayananda wrote:

Dear Dr. Karel

Thank you very much for your support. I tried your method. But 
command " runsp_lapw -s lapw1 -e lcore -orb -so" didn't complete.

The error is copied below.

 LAPW1 END
3730.384u 22.548s 1:02:35.44 99.9% 0+0k 112072+4310136io 8pf+0w
 LAPW1 END
3711.461u 21.067s 1:02:13.63 99.9% 0+0k 114088+4310888io 12pf+0w
forrtl: severe (64): input conversion error, unit 5, file 
SCFsp-U-SO.inso

Image  PC RoutineLine Source
lapwso 00477C6A Unknown   Unknown  
Unknown
lapwso 00475867 Unknown   Unknown  
Unknown
lapwso 0041D3C8 init_ 124  
init.F
lapwso 00422A66 MAIN__185  
lapwso.F
lapwso 00404706 Unknown   Unknown  
Unknown
libc.so.6  2B6606CF8D1D Unknown   Unknown  
Unknown
lapwso 004045B9 Unknown   Unknown  
Unknown

0.053u 0.021s 0:00.89 7.8%  0+0k 3032+16io 4pf+0w

>   stop error

I already have completed and saved the SCF for spin polarized 
calculation with hubbard-U and SO. When I follow the interface it 
crashed at "view case.outputjoint". It says /cann't open 
case.outputjoint/

/
/
Thank you for your great help.

Chami




From: Wien  on behalf of 
Karel Vyborny 

Sent: Wednesday, July 5, 2017 7:33 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Optical property calculation when spin orbit added

Hello Chami,
here's an example of command sequence I used recently (using version 14)
to calculate case.epsilonup with both SO and Hubbard U.

init_lapw
initso_lapw
runsp_lapw -orb -so
# edit case.in2c (replace TOT by FERMI)
runsp_lapw -s lapw1 -e lcore -orb -so
x optic -c -orb -so -up
x joint -orb -so -up
x kram -up

Hope it helps. Ask me (preferably on my private email) if you also 
want to

check the input files.

Karel




--- x ---
dr. Karel Vyborny
Fyzikalni ustav AV CR, v.v.i.
Cukrovarnicka 10
Praha 6, CZ-16253
tel: +420220318459


On Tue, 4 Jul 2017, shaymlal dayananda wrote:

> Dear Prof. Blaha and developers.
>
> I am using Wien2k 14.1 version. I need to calculate the optical 
absorption
> spectrum of a SPIN POLARIZED (sp) system with spin orbital (SO) 
coupling
> and  hubbard-U. I finished a SCF calculation with sp,SO, and 
hubbard U.
> N

Re: [Wien] Fw: Optical property calculation when spin orbit added

[Gavin Abo]

But now when  "x opticc -so -orb -up " it keep crashing. I do not have 
case.vectorsoup file really. How I create it.?


ERROR:

'OPTIC' -  can't open unit: 10
 'OPTIC' -  filename: /scratch/10820461.yak.local/SCFsp-U-SO.vectorsoup
 'OPTIC' -  status: OLD  form: UNFORMATTED


In "Table 4.3: Input and output files of main programs in an SCF cycle" 
on page 36 of the WIEN2k 17.1 usersguide [1] under the generates column 
for LAPWSO, you should see "case.vectorso" for the non-spin polarized 
case.  From that, it could be inferred that "case.vectorsoup" is 
expected to be created by it for the spin-polarized case.


So, it should have been created when you did "x lapwso -up".

You might check SCRATCH in your .bashrc:

username@computername:~/wiendata/test$ grep "export SCRATCH" ~/.bashrc
export SCRATCH=./ <- This is likely set to 
"/scratch/10820461.yak.local/" in your system instead of "./".


Sometimes the SCRATCH may need to be set to "./" for some programs to 
work correctly [2].


Then, check the uplapwso.def to see the path where it should have been 
created:


username@computername:~/wiendata/test$ grep vectorsoup uplapwso.def
42,'./test.vectorsoup',  'unknown','unformatted',9000 <- Did it create 
the file at a location that is different then 
"/scratch/10820461.yak.local/SCFsp-U-SO.vectorsoup"?


Check that the file exists and has a non-zero size:

username@computername:~/wiendata/test$ ls -l ./test.vectorsoup
-rw-rw-r-- 1 username username 74266 Jul  9 07:38 ./test.vectorsoup

[1] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08044.html 
; http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08892.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] Fw: Optical property calculation when spin orbit added

[Gavin Abo]

You should be able to use "x optic -so [-up]" without "-c", because the 
x script part of the command should automatically detect and add it if 
it is needed [1].  If you are interested in the details of how that is 
done, I think it is lines 377 to 381 in the x_lapw script file of WIEN2k 
17.1.


Also, there should be no difference between "opticc" and "optic -c".

As seen on line 139 in x_lapw, "-c" sets "cmplx = c".

set cmplx = c

On lines 422 to 423, "opticc" also sets "cmplx = c":

else if ($command == opticc) then
  set cmplx = c

So both "opticc" and "optic -c" will run the executable "opticc" as seen 
by lines 1027 to 1028:


case optic:
set exe = $command$cmplx$para

as $command = optic and $cmplx = c such that $command$cmplx = opticc.

[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12330.html


On 7/9/2017 9:15 AM, Dr. K. C. Bhamu wrote:

A correction on "opticc":


On the page number 176 of UG it is mentioned that: "In systems without 
inversion symmetry, the complex version opticc must be executed."


On the page number 177 under the section 8.17.1, we see
run optic: x opticc -so [-up]. So what have followed by Chami was okay.

But, in many threads on the mailing list it is mentioned that for the 
complex system we do not need to add "-c: and recent versions of the 
Wien2k will take care of it. Also, when we run init_lapw for a simple 
case and a complex case, we see for "x dstart" that for simple systems 
wien2k consider only "x dstart" and for complex cases it includes "x 
dstart -c".



Could you please tell me what is the difference between "opticc" and 
"optic -c". Do we really need to add "-c" with optic or the latest 
version of Wien2k will automatically take care about "-c" switch?


Regards
Bhamu


--------
Dr. K. C. Bhamu
(UGC-Dr. D. S. Kothari Postdoc Fellow)
Department of Physics
Goa University, Goa-403 206
India
Mob. No.  +91-9975238952

On Sun, Jul 9, 2017 at 8:24 PM, Gavin Abo <mailto:gs...@crimson.ua.edu>> wrote:




But now when  "x opticc -so -orb -up " it keep crashing. I do not
have case.vectorsoup file really. How I create it.?

ERROR:

'OPTIC' -  can't open unit: 10
 'OPTIC' -  filename:
/scratch/10820461.yak.local/SCFsp-U-SO.vectorsoup
 'OPTIC' -  status: OLD  form: UNFORMATTED


In "Table 4.3: Input and output files of main programs in an SCF
cycle" on page 36 of the WIEN2k 17.1 usersguide [1] under the
generates column for LAPWSO, you should see "case.vectorso" for
the non-spin polarized case.  From that, it could be inferred that
"case.vectorsoup" is expected to be created by it for the
spin-polarized case.

So, it should have been created when you did "x lapwso -up".

You might check SCRATCH in your .bashrc:

username@computername:~/wiendata/test$ grep "export SCRATCH" ~/.bashrc
export SCRATCH=./ <- This is likely set to
"/scratch/10820461.yak.local/" in your system instead of "./".

Sometimes the SCRATCH may need to be set to "./" for some programs
to work correctly [2].

Then, check the uplapwso.def to see the path where it should have
been created:

username@computername:~/wiendata/test$ grep vectorsoup uplapwso.def
42,'./test.vectorsoup',  'unknown','unformatted',9000 <- Did it
create the file at a location that is different then
"/scratch/10820461.yak.local/SCFsp-U-SO.vectorsoup"?

Check that the file exists and has a non-zero size:

username@computername:~/wiendata/test$ ls -l ./test.vectorsoup
-rw-rw-r-- 1 username username 74266 Jul  9 07:38 ./test.vectorsoup

[1]
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
<http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf>
[2]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08044.html
<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08044.html>
;
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08892.html
<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08892.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] Questions in "initso_lapw" when using "runsp_c_lapw" to run my task

[Gavin Abo]

A Hubbard U does not make much sense in a non spin polarized 
calculation - and I seem to recall that this is mentioned in the UG.


Perhaps thinking of run_lapw?

username@usernamecomputer:~/Desktop$ run_lapw -h | grep orb
hup: Command not found.
-so   ->run SCF including spin-orbit coupling

Unlike run_lapw, runsp_c_lapw seems to have this option [1,2]:

username@usernamecomputer:~/Desktop$ runsp_c_lapw -h | grep orb
hup: Command not found.
-so   ->run SCF including spin-orbit coupling
-dm   ->calculate the density matrix (when -so is set, but -orb is not)
-orb  ->use LDA+U, OP or B-ext correction
-orbc ->use LDA+U correction, but with constant V-matrix
-noorbud -> use LDA+U without crossterms up-dn (needs also -so)

initso_lapw is, on the other hand, for spin-orbit interaction - there 
the question if you have a spin polarized case makes sense. This is 
also explained in the UG.


I agree, if not using the -so option ("runsp_c_lapw -so" or 
"runsp_c_lapw -so -orb"), it doesn't seem to make sense to use initso 
with runsp_c_lapw -orb.



My purpose is to use LDA+U to treat no-magnetic system. So I use
"runsp_c_lapw -orb" to run my task, as told by the user_guide. And in
"initso_lapw", it asks me "do you have a spinpolarized case ?" and "do
you want to use the new structure for SO calculations ?". I answer
"Yes" to both the two quetions. I'm not very sure whether what I do is
right. I'd like to listen your experience and advices about this.


In the WIEN2k 17.1 usersguide [3] on page 48 in section "4.5.6 Orbital 
potentials", it says:


If you want to force a non-magnetic solution you can constrain the 
spin-polarization to zero using runsp_c _lapw.


I'm not an expert on such a calculation, but I think that implies that 
you would want to answer No in initso to "do you have a spinpolarized 
case ?" or to "do
you want to use the new structure for SO calculations ?" to force a 
non-magnetic calculation.  My current understanding is that answering 
Yes to both of those questions changes the symmetry.


And, I think it has been said that non-magnetic systems should not lead 
to changing of the symmetry [4]:


In non-magnetic systems, the inclusion of the spin-orbit coupling does 
not lead to lowering of the symmetry.


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07023.html
[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg00318.html

[3] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
[4] 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/novak_lecture_on_spinorbit.pdf

___
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] Fw: Optical property calculation when spin orbit added

[Gavin Abo]

"x lapwso -up" creates uplapwso.def with WIEN2k 17.1.  If your using 
WIEN2k 14.1 as mentioned at


http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16027.html

it seems that version creates lapwso.def instead.

Using "./" is not a requirement, I just suggested trying it.  That is 
because if I recall correctly, there were many reports in the mailing 
list of users having frequent success using "./", but more failures when 
using something else.


Your post below seems to be a mix of unorganized information.

In the error message you previously reported [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16062.html 
], there was:


/scratch/10820461.yak.local/SCFsp-U-SO.vectorsoup

It sounds like this is a result of "export SCRATCH=$PBS_O_WORKDIR" in 
your job script.


The lapwso.def should have the same path above, such that a non-empty 
SCFsp-U-SO.vectorsoup should exist in /scratch/10820461.yak.local/ if it 
was generated by lapwso without any errors.


However, the lapwso.def in your post below has instead:

/global/scratch/WIEN2k/NiO-14/NiO-14.vectorsoup

My guess is this is a result of "export SCRATCH=./" in your job script.  
It sounds like this may have resolved the previous "can't open unit" 
error with SCFsp-U-SO.vectorsoup.  However, you say that the 
case.vectorsoup and case.vectorsodn files now in your working directory 
are empty.  This sounds like some other error has occurred in the 
running of "x lapwso -up".  Did you check the *.error files again to see 
if a new error appeared?


The error when using $PBS_O_WORKDIR, did you check what $PBS_O_WORKDIR 
is (perhaps using echo or a similar technique) each time you run a job 
script?  Is it static and always the same or does itchange every time 
you run a new job (e.g., the 10820461 in "10820461.yak.local" stay the 
same or change to something else like say "10820465")? If it is static, 
you should be able to run separate job scripts for the scf and optic.  
However, if it is dynamically set, I expect that both the scf cycles and 
optic would need to happen in the same job script.  If the path changed 
for each new job and you ran scf and optic calculation separately, this 
might possibly be what caused the error.


The updates page on the WIEN2k website [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ] under 
VERSION_17.1: 30.6.2017 has:


SRC_optic: opmain.f (SO calculations are labeled "SO" in 
case.symmat/mat_diag files to fix normalization)


So with the optic SO calculation that you trying to do [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16062.html 
], this seems to indicate that the older WIEN2k versions (like 14.1) may 
have a normalization issue.  Therefore, it is up to you if want to take 
on the risk and challenges yourself of using an old version instead of 
using 17.1.  I mentioned before about some of the headaches of trying to 
maintain an old version of the code by yourself [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11071.html ].


On 7/12/2017 11:10 AM, shaymlal dayananda wrote:

Dear Dr. Abo And Dr. Bhamu

Thank you very much for your comments and advices. I was trying to 
follow your instructions and waited to see their results before to reply.


After some efforts i could get case.vectorsoup, case.vectorsodn files 
are now in my working directory. But still they are empty.


I am using remote computers and thus I do not have much freedom to do 
my own. Our supporter in the supercomputers adviced me not to add 
"export SCRATCH=./" as (according to him) it send the files to logging 
nodes. Instead he added "export SCRATCH=$PBS_O_WORKDIR" in my 
jobscript. This created the empty case.vectorsoup, case.vectorsodn in 
the working directory.


Could you please tell me ;  Is the requirement of "export SCRATCH=./" 
only to get those files to working directory or does it has any issue 
with those generated files. ??

Further I do not see uplapwso.def in the directory!!

Part of  lapwso.def is below.


4 ,'NiO-14.in1',   'old','formatted',0
5 ,'NiO-14.inso', 'old','formatted',0
6 ,'NiO-14.outputso',   'unknown','formatted',0
8 ,'NiO-14.scfso',   'unknown','formatted',0
9 ,'/global/scratch/WIEN2k/NiO-14/NiO-14.vectordn', 'old',
'unformatted',9000
10 ,'/global/scratch/WIEN2k/NiO-14/NiO-14.vectorup', 'unknown',
'unformatted',9000

18,'NiO-14.vspdn',  'old','formatted',0
19,'NiO-14.vspup',  'unknown','formatted',0
20 ,'NiO-14.struct','old','formatted',0
22,'NiO-14.vnsdn',  'old','formatted',0
23,'NiO-14.vnsup',  'unknown','formatted',0
41,'/global/scratch/WIEN2k/NiO-14/NiO-14.vectorsodn', 
'unknown','unformatted',9000
42,'/global/scratch/WIEN2k/NiO-14/NiO-14.vectorsoup', 
'unknown','unformatted',9000

44,'NiO-14.vect1',  'unknown','unformatted',9000
45,'NiO-14.normsodn',  'unknown','formatted',0

Thank you in advance.

Chami
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://z

Re: [Wien] question

[Gavin Abo]

Do you have this:

username@computername:~/wiendata/test$ run_lapw -orb -dm
hup: Command not found.
ERROR: option -orb does not exist !
ERROR: option -dm does not exist !

As was posted recently, a non-spin polarized calculation (run_lapw) does 
not have -orb [1].


For DFT+U, you have to use either "runsp_lapw -orb" or "runsp_c_lapw 
-orb" [2].  It says exactly that in the WIEN2k 17.1 usersguide [3] in 
section "4.5.6 Orbital potentials" on page 47 were it has:


/Note, you must run spin-polarized in order to use orbital potentials./

Also, "runsp_c_lapw -h" for example gives:

-dm   ->calculate the density matrix (when -so is set, but -orb is not)

So based on the description, -dm could be used if doing DFT+SO:

runsp_c_lapw -so -dm

but "runsp_c_lapw -so -orb -dm" and "runsp_c_lapw -orb -dm" should be 
incorrect and just "runsp_c_lapw -so -orb" (DFT+SO+U) and "runsp_c_lapw 
-orb", respectively.


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16072.html
[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11670.html

[3] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

On 7/14/2017 8:10 AM, Dj Fati wrote:

Could you please suggest an answer to my question
When i do a calculation on the method GGA+U it gives me error 
option-orb does not exixt

option- dm does not exist
thanks
___
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] (no subject)

[Gavin Abo]

There may be two problems.

The first problem could be with wien2wannier.  The WIEN2k 17.1 package 
seems to have a version 1 write_inwf_lapw file:


username@computername:~/Desktop$ cd $WIENROOT
username@computername:~/WIEN2k$ sed -n 29p write_inwf_lapw
__version__ = "$version: v1.0.0-273-gaf9ce6b$"

The version 1 file might not have supported a spin polarized calculation 
(i.e., may not have took a "-up" flag).


The version 2 file might be needed from github [ 
https://github.com/wien2wannier/wien2wannier/blob/master/SRC/write_inwf_lapw 
]:


username@computername:~/WIEN2k$ mv write_inwf_lapw write_inwf_lapw.orig
username@computername:~/WIEN2k$ wget 
https://raw.githubusercontent.com/wien2wannier/wien2wannier/master/SRC/write_inwf_lapw

username@computername:~/WIEN2k$ sed -n 29p write_inwf_lapw
__version__ = "$version: v2.0.0-7-g4c51be8$"
username@computername:~/WIEN2k$ chmod 775 write_inwf_lapw

The second problem could be with BerryPI.  The Wien2Wannier 2.0 User’s 
Guide in section "2.13 write_inwf — prepare input file for w2w" on page 
10 [ 
https://github.com/wien2wannier/wien2wannier/releases/download/v2.0.0/wien2wannier_userguide.pdf 
] has:


write_inwf [-up|-dn] -bands Nmin Nmax [PROJ [PROJ ...]] (noninteractive)

So "write_inwf -up" is needed to create case.inwfup.

However, in the BerryPI output you can see:

[ BerryPI ] Calling command: /usr/bin/python2.7 
/home/ccms/storage/code/write_inwf -mode MMN -bands 1 27


The "-up" seems to be missing in the command, thus, the:

error while processing def file `upw2w.def': file not found, unit 5, 
file /home/ccms/WIEN2k/ali/BiFeO3/96/96.inwfup


It seems to me that the file berrypi [ 
https://github.com/spichardo/BerryPI/blob/master/berrypi ] is not able 
to handle the -up flag yet for write_inwf, but I don't know the Python 
language as well as others.  So I could be wrong.


As was mentioned before, maybe a workaround is copy the case.inwf that 
is created to case.inwfup and case.inwfdn [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15118.html 
] or create them with the version 2 write_inwf and then rerun the 
berrypi command again.


On 7/14/2017 1:42 PM, ali ali wrote:

Dear Elias Assman,
I am working on BerryPI code. After completing scf when I want to run 
the berrypi command it gives the following error. I don't know what to 
do know?  I will be very thankful to you if you guide me.

Best Regards
ccms@ccms:~/WIEN2k/ali/BiFeO3/96$ berrypi -s -k6:6:6
[ BerryPI ] Spin polarization is activated
[ BerryPI ] Proceed with the k-mesh [6, 6, 6]
[ BerryPI ] Starting BerryPI Automation for 96
[ BerryPI ] New working directory: /home/ccms/WIEN2k/ali/BiFeO3/96
[ BerryPI ]  w2kpath = /home/ccms/storage/code
[ BerryPI ]  pypath = /usr/bin/python2.7
[ BerryPI ]  bppath = /home/ccms/storage/code/SRC_BerryPI/BerryPI
[ BerryPI ] +++Version 1.3.3 (Mar 14, 2016)

[ BerryPI ] Python version: 2.7.1
[ BerryPI ] Numpy version: 1.11.0
[ BerryPI ] Copied 96.struct to 96.ksym
[ BerryPI ] Calling command: echo "0 6 6 6 0" | x kgen -fbz
   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.864   0.864 0.682   0.000   
0.000   0.000

  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
 216  k-points generated, ndiv=   6 6   6
KGEN ENDS
0.0u 0.0s 0:00.00 0.0% 0+0k 0+304io 0pf+0w
[ BerryPI ] Calling command: cp 96.klist 96.klist_w90
[ BerryPI ] Calling command: x lapw1 -up
 LAPW1 END
118.8u 1.8s 2:00.69 99.9% 0+0k 0+307072io 0pf+0w
[ BerryPI ] Calling command: x lapw1 -dn
 LAPW1 END
119.3u 1.9s 2:01.30 99.9% 0+0k 0+303720io 0pf+0w
[ BerryPI ] Determine number of bloch bands in spin-polarized mode 
based on *.scf2(up/dn)

[ BerryPI ]   spin = up
[ BerryPI ] Number of bloch bands is [1, 27]
[ BerryPI ]   spin = dn
[ BerryPI ] Number of bloch bands is [1, 22]
[ BerryPI ] Calling command: /usr/bin/python2.7 
/home/ccms/storage/code/write_inwf -mode MMN -bands 1 27

[ BerryPI ] Calling command: write_win
[ BerryPI ] Calling command: /usr/bin/python2.7 
/home/ccms/storage/code/SRC_BerryPI/BerryPI/win2nnkp.py 96

[ BerryPI ]  file 96.scf2up found; will extract the Fermi energy
:FER  : F E R M I - ENERGY(TETRAH.M.)=   0.4563888312
[ BerryPI ]  Ef = 0.4563888312 Ry
[ BerryPI ]  Fermi energy is written to 96.fermiup
[ BerryPI ] Calling command: x w2w -up
/home/ccms/storage/code/w2wc: error while processing def file 
`upw2w.def': file not found, unit 5, file 
/home/ccms/WIEN2k/ali/BiFeO3/96/96.inwfup

0.0u 0.0s 0:00.00 0.0% 0+0k 0+8io 0pf+0w
error: command   /home/ccms/storage/code/w2wc upw2w.def failed
[ BerryPI ] ERROR: in automation of 96
[ BerryPI ] ERROR --> x w2w -up
Command 'x w2w -up ' returned non-zero exit status 9
Traceback (most recent call last):
  File "/home/ccms/storage/code/SRC_BerryPI/BerryPI/berrypi", line 
914, in 

[bAutomationErrorChk,phases

Re: [Wien] The number of bands is less than what I want

[Gavin Abo]

An additional comment:


You might consider upgrading from 13.1 to the latest WIEN2k version 
(17.1) because of the dynamical Emax in case.in1(c) [1].



[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14937.html


[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03255.html


[3] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03257.html



On 7/15/2017 7:26 AM, Xavier Rocquefelte wrote:


Dear Bingrui Peng

What are the eigenvalues and how many bands do you have in the valence 
states.


When you did "x lapw1 -band" what was the energy range of your 
calculation.


Look at the case.output1 file, it contains the eigenvalues for each 
k-points. You will then see the number of bands and energy range.


Cheers

Xavier


Le 15/07/2017 à 12:57, Peng Bingrui a écrit :

Dear wien2k community

I'm running WIEN2K of 13 version on Linux system.

My case.insp is like this:
---
### Figure configuration
 5.0   3.0 # paper offset of plot
10.0  15.0   # xsize,ysize [cm]
 1.0   4# major ticks, minor ticks
 1.0   1# character height, font switch
 1.1   24  # line width, line switch, 
color switch

### Data configuration
-14.0  28.0  2  # energy range, energy switch 
(1:Ry, 2:eV)

1  0.6847884066# Fermi switch,  Fermi-level (in Ry units)
1  99   # number of bands for heavier 
plotting   1,1
0  11.0# jatom, jtype, size  of 
heavier plotting

---

I want to get 99 bands plotted, but there are only 80 bands shown 
when I open case.bands.agr. And note that although I set the energy 
range to be (-14.0, 28.0) , the highest band, is below 12.0 eV, which 
is much lower than 28.0 eV. What should I do to get more bands ?


Thank you very much for your attention.

Sincerely yours,
Bingrui Peng
from the Department of Physics, Nanjing University,
China
___
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] Questions about imposing external magnetic field on no-magnetic system

[Gavin Abo]

I looked at the Landau quantization Wikipedia entry [1]. However, it was 
not clear to me whether this was needed to describe a system with moving 
spin (e.g., oscillating spins).


If so, I think the answer to your question it that your not missing 
anything and WIEN2k does not have an external magnetic field 
implementation for Landau quantization.


In Chapter 10 Landau Quantization on page 182 of the book titled 
"Quantum Hall Effects: Recent Theoretical and Experimental Developments" 
by Zyun F. Ezawa, it mentions that spinless theory is frequently 
considered when the spin degree of freedom can be ignored, such that a 
spin frozen system becomes a good approximation under the condition that 
the Zeeman energy is large.


Previously, I didn't understand Dr. Novak's reference to the frozen spin 
method [2], but it seems now that might be why he mentioned it.


The NMR slides [3,4] do show B_ext in the H_NMR equation, but I don't 
see it described in which input file it is to be included (or if just 
part of a result in an output file).  There is the external magnetic 
field value that can be entered in case.inorb [5].  Perhaps, the NMR 
program also uses that too.


Of note, it was estimated before that a Bext value of a least 1728 T may 
be needed to see any noticeable effect in the plots (if the default 
autoscale-like settings are used) [6].


[1] https://en.wikipedia.org/wiki/Landau_quantization
[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01508.html

[3] http://susi.theochem.tuwien.ac.at/events/ws2015/rolask_nmr.pdf
[4] 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/nmr-chemical-shift.pdf
[5] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12904.html
[6] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11093.html


On 7/15/2017 4:56 AM, Karel Vyborny wrote:
Interesting, I didn't know that WIEN2k can figure out what "band 
structure with B>0" is... I thought there ought to be some Landau 
quantisation which is hard to do except for idealised systems. Am I 
missing something here?


KV


--- x ---
dr. Karel Vyborny
Fyzikalni ustav AV CR, v.v.i.
Cukrovarnicka 10
Praha 6, CZ-16253
tel: +420220318459


On Sat, 15 Jul 2017, Peng Bingrui wrote:


Dear professor Blaha

Thank you very much for your suggestions. However, I'm still kind of
confused, because my purpose is to see the change of band structure 
under
external magnetic field, and l'm wondering whether NMR calculation 
can do

this ? I'm sorry for my limited knowledge as an undergraduate student.

Sincerely yours,
Bingrui Peng
from the Department of Physics, Nanjing University, China

 


From: Wien  on behalf of pieper

Sent: Wednesday, July 12, 2017 1:15:41 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Questions about imposing external magnetic field on
no-magnetic system
In case no one has answered this up to now:

ad 1) The procedure itself is ok. You might want switch on SO first and
converge that without the orbital potential to establish a zero-field
base line. Remember to put in LARGE fields - your off-the-shelf lab
field of 10 T will not show up at any energy precision you can achieve.
Estimate the energy of 1 mu_B in 10 T field in Ry units to see that.

Note that your not-so-recent version of Wien2k is not the best for the
task. The latest version is 17.1. With 16.1 came the NMR package which
should be much better suited to calculate the effects of a magnetic
field.

ad 2) If you apply a magnetic field experimentally in the lab you do it
at all atoms. I suppose you want to model that situation. imho it makes
little sense to exempt one or two of your atoms from the field.

Good luck

---
Dr. Martin Pieper
Karl-Franzens University
Institute of Physics
Universitätsplatz 5
A-8010 Graz
Austria
Tel.: +43-(0)316-380-8564


Am 10.07.2017 12:20, schrieb Peng Bingrui:
> Dear professor Blaha and WIEN2K users
>
> I'm running WIEN2K of 14 version on Linux system. I'm going to impose
> external magnetic field on LaPtBi, a no-magnetic material. The
> procedure that I'm going to use is :
>
> 1、Do a no-SO calculation : runsp_c_lapw.
>
> 2、Do a SO calculation : runsp_c_lapw -so -orb, while including
> external magnetic field as orbital potential in the same time.
>
> My questions are:
>
> 1、Whether this procedure is OK ? If it is not OK, what is the right
> one ?
>
> 2、Which atoms and which orbitals should I treat with orbital
> potential ? The electron configurations of these 3 atoms are: La (5d1
> 6s2) ;  Pt  (4f14 5d9 6s1); Bi (4f14 5d10 6s2 6p3).
>
> Thanks very much for your attention.
>
> Sincerely yours,
>
> Bingrui Peng
>
> from the Department of Physics, Nanjing University, China
___
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.m

Re: [Wien] BoltzTraP transport properties

[Gavin Abo]

Sounds like that fixed the problem for you [1]. If not, do you have 
NOCALC instead of CALC in case.intrans [2,3]?


[1] gather_energy.patch: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13418.html


[2] 
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg04755.html


[3] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10740.html


On 7/20/2017 7:44 PM, Lagoun brahim wrote:

thank you Karima

I gathered the energy's  files

2017-07-21 3:41 GMT+02:00 karima Physique >:


If you run a parallel calculation, you must first lunch the
command: gather_energy.pl 

2017-07-21 3:35 GMT+02:00 Lagoun brahim mailto:b.lag...@lagh-univ.dz>>:

hallo every one

i am doing a  transport properties calculation with
(wien2k14.2+BoltzTraP 1.2.5) code but when i execute: x_trans
BoltzTrP with or without the flags: (-up or -dn or -so) i have
the following error message:
x_trans BoltzTraP
  BoltzTraP vs 1.2.5 =
 LiFePO42
  
forrtl: severe (24): end-of-file during read, unit 48, file
/home/LiFePO42/LiFePO42.engre
Image  PC RoutineLine Source
BoltzTraP  0058BFBA Unknown  
Unknown  Unknown
BoltzTraP  0058AB35 Unknown  
Unknown  Unknown
BoltzTraP  004BAC26 Unknown  
Unknown  Unknown
BoltzTraP  004776E6 Unknown  
Unknown  Unknown
BoltzTraP  00476E59 Unknown  
Unknown  Unknown
BoltzTraP  00497EA4 Unknown  
Unknown  Unknown
BoltzTraP  004084C3 bandstructure_mp_
133 m_bandstructure.F90
BoltzTraP  004126DA MAIN__   
266 BoltzTraP.F90
BoltzTraP  00404A5C Unknown  
Unknown  Unknown
libc.so.6  2AC5C7439B05 Unknown  
Unknown  Unknown
BoltzTraP  00404959 Unknown  
Unknown  Unknown

0.019u 0.006s 0:00.02 50.0% 0+0k 0+8io 0pf+0w


i use ifort compiler + mkl libraries (the same think when i
compile the code with gfortran compiler with blas and lapack)
any suggestion
the tests work very well
thank you in advance

___
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] Inconsistency between case.inwf and case.win

[Gavin Abo]

There was a previous post about the orbital labels in case.win.  You 
should able to view the post at the following link:



http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12320.html


In the NEWS file [1], I see that the latest Wien2Wannier included with 
WIEN2k 17.1 contains several fixes to write_win.



However, I'm not seeing an entry about the orbital labels in case.win.  
Maybe the writing of the orbital labels has been corrected and just not 
documented in the NEW file.  So, the new version would need to be tried 
to see.



[1] https://github.com/wien2wannier/wien2wannier/blob/v2.0.0/NEWS


On 7/22/2017 1:39 AM, Peng Bingrui wrote:

Dear wien2k commuity

I'm using wien2k of 14 version and now I'm working with 
the wien2kwannier interface. I find that there is inconsistency 
between the content in these two files: case.inwf and case.win.


For the projections, I choose:
Gd: d
Pt: s,d
Bi: p

My case.inwf seems to be OK, and it is like this:
---
BOTH # AMN, MMN, or BOTH
 41  93  # min band, max band
  3  28  # LJMAX in exp(ibr) expansion, #WF
2 # Gd:d -> 1:dxy
 1 2 -2   0.   0.70710678
 1 2  2   0.  -0.70710678
2 # Gd:d -> 1:dxz
 1 2 -1   0.70710678   0.
 1 2  1  -0.70710678   0.
2 # Gd:d -> 1:dyz
 1 2 -1   0.   0.70710678
 1 2  1   0.   0.70710678
2 # Gd:d -> 1:dx^2-y^2
 1 2 -2   0.70710678   0.
 1 2  2   0.70710678   0.
1 # Gd:d -> 1:dz^2
 1 2  0   1.   0.
1 # Pt:s,d -> 2:s
 2 0  0   1.   0.
2 # Pt:s,d -> 2:dxy
 2 2 -2   0.   0.70710678
 2 2  2   0.  -0.70710678
2 # Pt:s,d -> 2:dxz
 2 2 -1   0.70710678   0.
 2 2  1  -0.70710678   0.
2 # Pt:s,d -> 2:dyz
 2 2 -1   0.   0.70710678
 2 2  1   0.   0.70710678
2 # Pt:s,d -> 2:dx^2-y^2
 2 2 -2   0.70710678   0.
 2 2  2   0.70710678   0.
1 # Pt:s,d -> 2:dz^2
 2 2  0   1.   0.
2 # Bi:p -> 3:px
 3 1 -1   0.70710678   0.
 3 1  1  -0.70710678   0.
2 # Bi:p -> 3:py
 3 1 -1   0.   0.70710678
 3 1  1   0.   0.70710678
1 # Bi:p -> 3:pz
 3 1  0   1.   0.
 ( only show half of it )

-

However, the content about projections in my case.win is like this:
- 


begin projections
  1:s
  1:s
  1:s
  1:s
  1:s
  2:s
  2:s
  2:s
  2:s
  2:s
  2:s
  3:s
  3:s
  3:s
  1:s
  1:s
  1:s
  1:s
  1:s
  2:s
  2:s
  2:s
  2:s
  2:s
  2:s
  3:s
  3:s
  3:s
end projections
-

It seems to be all s orbitals for projections, which is not what I want.

Does this problem matter ?  As far as I'm concerned, if w2w reads 
information about projections from case.inwf, but not from 
case.win, to calculate the matrix Amn, then it doesn't matter, right ?


Thank you very much for your attention.

Sincerely Yours,
Bingrui Peng
from the Department of Physics, Nanjing University, China
___
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] problem in DOS

[Gavin Abo]

Did you take into account the multiplicity:

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01379.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07956.html
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05127.html

On 7/30/2017 2:55 AM, shaymlal dayananda wrote:

Dear developers and users

I did a electron DOS plot. But the total DOS in the plot is not equal 
to the sum of the DOS of other atoms in the system where it shouldn't 
be. I have attached the graph. I tried figure this out but couldn't 
guess anything. In my system, there are two U-atoms and three equal 
Si-atoms.



Thank you inadvance
Chami
___
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] Error - Fermi level was not found for doping

[Gavin Abo]

As mentioned at

http://qe-forge.org/pipermail/pw_forum/2016-May/109991.html

Maybe this happens when VBM, CBM, and Efermi are the same, and Egap is 0.

In your case.outputtrans, are the values like that under the "OUTPUT 
from BANDANA" section?


If so, I think it was mentioned at

http://cms.mpi.univie.ac.at/vasp-forum/viewtopic.php?f=4&t=9660&p=14325#p14325

that increasing lpfac in case.intrans or fixing a problem with the 
case.energy[up/dn] input may have resolved this.


A common problem with case.energy occurs if a file from the WIEN2k scf 
calculation is not used:


http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11759.html

From a code perspective, it looks like this error may be coming from 
lines in boltztrap-1.2.5\src\fermiintegrals.F90:


  if (iiter > 999 .or. abs(sumelec-sumelec_target) > 1.d-12) then
write (*,*) 'Error - Fermi level was not found for doping ', 
idoping, ' at temperature ', temp

  end if

So it looks like the number of iterations (iiter) became too large 
(i.e., greater than 999) during the search for the Efermi or it looks 
like the absolute value of the difference between the sumelec and 
sumelec_target was greater than zero (where the 1.d-12 is used as a 
tolerance to represent zero as floating-point arithmetic is inherently 
inexact such that floating point numbers might not always compare 
properly for exact equality [ 
https://stackoverflow.com/questions/20764911/floating-point-numbers-equality 
, 
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ 
, http://www.lahey.com/float.htm ]).


On 7/30/2017 11:11 AM, chin Sabsu wrote:

Dear Users,
After successful attempt of electronic, optical and magnetic 
properties, I tried to run Boltztrap calculation.
In an alloyed compound with different doping level concentrations, I 
encountered below error.


"Error - Fermi level was not found for doping"

Please suggest me:
What does it mean and how to overcome this situation.


Thanks in advance and help will be highly appreciated.

Thank you
Chin
___
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] a doubt from threads in case.InM

[Gavin Abo]

Currently too lazy to check, are the data values x y z div (where div is 
the divisor)?


So (x y z)/div:

0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a 
divide by zero error [2], it sounds like the code is able to handle it 
and may be setting any of these divisions to 0.


0.0. 0.0 0.0 1.0 => (0, 0, 0)/1 = (0, 0, 0) <- This may be safer to use.

[1] https://en.wikipedia.org/wiki/Division_by_zero

[2] 
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/392791


On 8/3/2017 9:26 AM, fatima DFT wrote:

Thank you very much Sir.
I feel relax now.
I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0 
0.0 1.0


So I was worried to repeat the calculation by fixing the position with 
0.0. 0.0 0.0 1.0.


On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks 
mailto:l-ma...@northwestern.edu>> wrote:


Inlined

On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT mailto:fatimad...@gmail.com>> wrote:

Dear Prof. Peter, Oleg and Marks,

I have two queries for case.inM

First:

I stuck on case.inM file where I want to fix the positions of
the heavier atom for which I do not want to relax the structure.


A comment: fixing atoms does not do what people think, in general
it does not make the convergence of QM methods faster (it can for
CG). The convergence depends upon the number and density of the
elastic eigenvectors  (PORT) and the elastic-electronic system
(MSR1a).


In one thread Prof Peter


mentioned keeping 0 0 0 0 in the respective row of atom that I
want to constrain. But this four zeros means the entire line
should be zero

0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess   >>> Say
it is for La atom.

As per Prof Marks

and
Prof. Oleg



The only first three number should be zero

0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess

Could you please clear my doubt that:

How the results will differ if I will use "0.0 0.0 0.0 0.0  
#Atom1 Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?



I am 99% confident that they are equivalent.


Second:

If I use "x pairhess" to generate the case.inM then does it
copy the case.inM according to the structure files? I just
tested it for two different structures and I saw two different
kind of case.inM.


Yes, different structures with different symmetries have different
symmetry constrained sites so different case.inM.



Thank you in advance

regards
Fatima




-- 
Professor Laurence Marks

"Research is to see what everybody else has seen, and to think
what nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu  ;
Corrosion in 4D: MURI4D.numis.northwestern.edu

Partner of the CFW 100% program for gender equity,
www.cfw.org/100-percent 
Co-Editor, Acta Cryst A

___
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 

Re: [Wien] a doubt from threads in case.InM

[Gavin Abo]

Ok, thanks.  I know see in the WIEN2k usersguide [1] for the NEWT method 
that the friction parameter ETA should effect the speed of movement when 
the atom is moving by the non-zero steps sizes Delta(1), Delta(2), 
and/or Delta(3) of the input values:


Delta(1) Delta(2) Delta(3) ETA

[1] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf 
(Section "8.15.3 Input" on page 174 of the WIEN2k 17.1 usersguide)
[2] 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/Optimization-Notes.pdf


On 8/4/2017 1:22 AM, Peter Blaha wrote:
It is NOT a divisor ! (does not make sense here). Depending on the 
method the 4th value is not used or is eg. a friction term for damped 
newton dynamics.


On 08/04/2017 02:26 AM, Gavin Abo wrote:

Currently too lazy to check, are the data values x y z div (where div is
the divisor)?

So (x y z)/div:

0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a
divide by zero error [2], it sounds like the code is able to handle it
and may be setting any of these divisions to 0.

0.0. 0.0 0.0 1.0 => (0, 0, 0)/1 = (0, 0, 0) <- This may be safer to use.

[1] https://en.wikipedia.org/wiki/Division_by_zero

[2]
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/392791 



On 8/3/2017 9:26 AM, fatima DFT wrote:

Thank you very much Sir.
I feel relax now.
I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0
0.0 1.0

So I was worried to repeat the calculation by fixing the position with
0.0. 0.0 0.0 1.0.

On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks
mailto:l-ma...@northwestern.edu>> wrote:

Inlined

On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT mailto:fatimad...@gmail.com>> wrote:

Dear Prof. Peter, Oleg and Marks,

I have two queries for case.inM

First:

I stuck on case.inM file where I want to fix the positions of
the heavier atom for which I do not want to relax the 
structure.



A comment: fixing atoms does not do what people think, in general
it does not make the convergence of QM methods faster (it can for
CG). The convergence depends upon the number and density of the
elastic eigenvectors  (PORT) and the elastic-electronic system
(MSR1a).


In one thread Prof Peter
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_msg03285.html&d=DwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=lMntW40NGNoDrUMHYVU-vXvlVw2pGHikT4XpBt9gMhU&s=-6101yYtzjIzQWcsyC0Zc5AQTUAs08Rf0kz5Ifefu7I&e=>
mentioned keeping 0 0 0 0 in the respective row of atom that I
want to constrain. But this four zeros means the entire line
should be zero

0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess >>> Say
it is for La atom.

As per Prof Marks
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_msg12403.html&d=DwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=lMntW40NGNoDrUMHYVU-vXvlVw2pGHikT4XpBt9gMhU&s=0fcEvAFHmpT7ZahxBQYrqD0Xr0DEsgKPFE0Nk-fLeLM&e=>and
Prof. Oleg
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_msg01858.html&d=DwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0&m=lMntW40NGNoDrUMHYVU-vXvlVw2pGHikT4XpBt9gMhU&s=GJxC2Mi9-Fts6rULojSPz0X_acMQL2Oe5Ie7WXILcr0&e=>

The only first three number should be zero

0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess

Could you please clear my doubt that:

How the results will differ if I will use "0.0 0.0 0.0 0.0
#Atom1 Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?


I am 99% confident that they are equivalent.


Second:

If I use "x pairhess" to generate the case.inM then does it
copy the case.inM according to the structure files? I just
tested it for two different structures and I saw two different
kind of case.inM.


Yes, different structures with different symmetries have different
symmetry constrained sites so different case.inM.



Thank you in advance

regards
Fatima




--
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think
what nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu
<http://www.numis.northwestern.edu> ; Corrosion in 4D:
MURI4D.numis.northwestern.edu 
<http://MURI4D.numis.northwestern.edu>

Partner of the CFW 100% program for gender
equity, www.cfw.org/100-percent <http://www.cfw.org/100-percent>
Co-Editor, Acta Crys

Re: [Wien] band gap issue

[Gavin Abo]

Maybe okay?

"Next to :GAP in the scf file there is a warning: if you use a proper 
k-mesh. One always has to check this :GAP value and compare it vs. a 
detailed bandstructure plot, identifying the position of VBM and CBM. If 
the scf k-mesh is course or does not contain Gamma (shifted mesh), the 
quoted :GAP may be too large." [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15445.html ]


On 8/8/2017 4:01 PM, fatima DFT wrote:

Dear List,
I compiled the results of a complex structure with PBE+SO.

Results look okay to me  what about I am worried is:
When  I do grep :GAP *.scf on terminal then it shows band gap ~1.01 
eV. When I see at the plots then it shows band gap ~0.7eV at Gamma point.


Could you please tell me whats wrong here?

Regards
Fatima
___
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] Need to resolve the issue

[Gavin Abo]

Refer to the post at:

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11451.html

On 8/12/2017 7:13 AM, Walayat Khan wrote:

Dear Prof. Blaha and colleagues

I the user of WIEN2k. Now, I am doing SO coupling calculation on GeTe,
but in the first cycle I got error like

  'FERMI' - EFERMI OUT OF ENERGY RANGE
  'FERMI' - STOP IN EFI
  'FERMI' - ENERGY OF LOWER BOUND :   1.79413
  'FERMI' - NUMBER OF STATES AT THE LOWER BOUND   :  87.46042
  'FERMI' - ENERGY OF UPPER BOUND :   1.79413
  'FERMI' - NUMBER OF STATES AT THE UPPER BOUND   :  87.46050
  'FERMI' - ADD   86.36690
  'FERMI' - SOS 0..........000
  'FERMI' - NOS **
**  testerror: Error in Parallel LAPW2

and the structure which I used is Hexagonal
RMT of:  Ge: 2.00 and Te= 1.99(Note: these are automatically accepted radii)

with best regard
wilayat


___
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] problem with the command addjoint-updn_lapw

[Gavin Abo]

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07551.html

On 8/15/2017 8:06 AM, prasad jayasena wrote:

Dear wien2k experts

I am trying to calculate the optical absorption spectrum of my sample. 
I completed the SCF run with hubbard-U and spin orbital coupling in a 
parallel calculation. Then I performed the below through terminal

x lapw1 -p -up -orb
x lapw1 -p -dn -orb
x lapwso -p -up -orb
x lapw2 -p -so -fermi -up
x lapw2 -p -so -fermi -dn
x lcore -up
x lcore -dn
x opticc -p -so -up
x joint -up

But then when I run  "addjoint-updn_lapw" it is giving me  "The 
required files case.jointup/dn are not present (or empty). Exit"


However I am not sure whether I need to do that step. because in the 
userguide it is not there and the comment for optic/joint/ kram is " 
Note: In spin-polarized cases with spin-orbit only one call to optic, 
joint and/or kram (either up or down) is necessary, since the spins 
are not independent any more and both vector-files are used at the 
same time."


But I thought to run addjoint-updn_lapw because it is in the w2web 
calculation. However if i run x kram -up after x joint -up (skipping 
adjoint-updn_lapw) it creates case.absorbup epsilup reflectivityup ant 
etc.



Can someone please answer me whether the adjoint-updn_lapw is not 
required in the SO calculation.? Thank you in advance.


Prasad J
PhD Candidate
University of Regina
___
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] problem of energy gap within mBJ

[Gavin Abo]

In [1], it says:

/In Refs. [77,82] we showed that a correct description of the band gap 
and electric-field gradient (EFG) in Cu2O could only be achieved with 
the hybrid functionals, while the resultsobtained with the LDA, GGA, 
LDA+U, and mBJ methodswere qualitatively wrong./


In TABLE IV of [2], GGA (PBE) gap is 0.53 eV.  In TABLE I of [3], mBJ 
gap is 0.82 eV.


I'm not seeing a WIEN2k value reported for GGA+U, but maybe it is close 
to the 0.79 eV gap (AMF, U = 8 eV) LDA+U calculation [2] or the 0.67 eV 
gap (with U of 7 eV) GGA+U calculation by VASP [4].


The 0.53 eV, 0.82 eV, and 0.67 eV above round up to be approximately 1.0 
eV, which is around the 1.0 eV that you report.


On the other hand, GGA+U+mBJ calculation may give 1.60 eV [6].

[1] https://publik.tuwien.ac.at/files/PubDat_238321.pdf

[2] https://publik.tuwien.ac.at/files/PubDat_197400.pdf

[3] https://publik.tuwien.ac.at/files/PubDat_197196.pdf

[4] http://dx.doi.org/10.1063/1.3231869

[5] http://dx.doi.org/10.1063/1.4798706

[6] http://dx.doi.org/10.1063/1.4798706 (TABLE I)

On 8/18/2017 9:14 PM, halim said wrote:

Dear Prof. Tran,

Hi,


Thank you for your answer, I mean withing GGA, mBJ-GGA, and GGA+U, I 
found the energy gap around 1 eV.


In principle the experimental gap is about 2 eV.

Where is the problem?

Thank you for your help.

Yours sincerely,

Halim Said

I a


Le Vendredi 18 août 2017 23h29, "t...@theochem.tuwien.ac.at" 
 a écrit :



Hi,

What do you mean by 1 eV? Does it mean that all
gaps are at exactly 1.0 eV or in a range like 0.5-1.5 eV?

You can compare your results with those in these two articles:
https://publik.tuwien.ac.at/files/PubDat_197400.pdf
https://publik.tuwien.ac.at/files/PubDat_197196.pdf

Cu2O is a special case for which mBJ and GGA+U are not really
better than GGA.

FT

On Friday 2017-08-18 21:42, halim said wrote:

>Date: Fri, 18 Aug 2017 21:42:24
>From: halim said mailto:halim_sai...@yahoo.fr>>
>Reply-To: A Mailing list for WIEN2k users 
mailto:wien@zeus.theochem.tuwien.ac.at>>
>To: "wien@zeus.theochem.tuwien.ac.at 
" 
mailto:wien@zeus.theochem.tuwien.ac.at>>

>Subject: [Wien] problem of energy gap within mBJ

>
>Dear Professor Peter Blaha, Tran and Wien2k users,
>
>I have computed the energy gap for Cu2O by using GGA, mBJ, and GGA+U, 
I got same energy gap of 1 eV.
>In principle by using mBJ, the energy gap should be increased close 
to expermimental value around 2 eV.
>Why mBJ is giving same value as GGA and it is not improved? even I 
tried GGA+U and the same problem and no thing was changed for all 
approximations.

>
>I would be thankful for your suggestion and answer to solve the problem.
>
>Sincerely yours,
>
>Halim Said

___
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] Re-regarding the spin orbit calculations

[Gavin Abo]

Are you using the latest WIEN2k version? I think this gfortran error 
only occurred in a older WIEN2k version:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11575.html

On 8/30/2017 11:30 PM, mandeep hooda wrote:

Dear Wien2k users,
   I am facing problems in DOS calculations for spin-orbit 
coupling of non-magnetic case. I run the calculations according to youtube 
videos. Calculations converged without any error, but in DOS, it is showing 
error given below, which is difficult to understand. Please give some 
constructive suggestions. Thanking you in advance
At line 30 of file kptin_nv.F (unit = 10, file = './Zr3Te_SO.vectorup')
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, 
possibly use REWIND or BACKSPACE
1.2u 0.0s 0:01.22 99.1% 0+0k 0+27384io 0pf+0w
error: command   /home/csy/wein2k/WEIN2k/lapwso lapwso.def   failed

Regards
Mandeep Kumar Hooda
___
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] regarding to generate struct file of CH3NH3PbI3

[Gavin Abo]

Have you tried


cif2struct CH3NH3PbI3_cubic.cif


on a cif file for it?  For example, the CH3NH3PbI3_cubic.cif at:


https://github.com/WMD-group/hybrid-perovskites/tree/master/2015_ch3nh3pbi3_phonons_PBEsol


On 9/4/2017 3:02 AM, AJAY SINGH VERMA wrote:


Dear Sir,

I have facing some problem to generate strcut file of CH3NH3PbI3 
for cubic structure. Sir please guide me and help to generate struct 
file.


thanks

with regards

ajay singh verma

___
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] Orbital angular momentum band character

[Gavin Abo]

If you are asking about fat band plotting [1,2], there is section 
"3.11.5 Bandstructure with band character plotting / full lines" in the 
WIEN2k 17.1 usersguide [3].


Spaghetti-primavera on the unsupported page [4] might also be of 
interest for band character plotting.


[1] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg1.html


[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04128.html


[3] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

[4] http://susi.theochem.tuwien.ac.at/reg_user/unsupported/

On 9/4/2017 8:32 AM, pl...@physics.ucdavis.edu wrote:

Dear WIEN2k experts,

Is there an easy way to plot orbital angular momentum character of the
bands? Here I mean for example px+ipy and px-ipy, and similar for d and f
levels.

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

Re: [Wien] Orbital angular momentum band character

[Gavin Abo]

There is likely a procedure(s) for what you want either in the WIEN2k 
usersguide or mailing list. For example, see the post at:


http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09389.html

If the QSPLIT in case.inq to 1 that Yundi sent doesn't give what you 
want, I believe there is an option for specifying your own custom 
basis.  I think that is described either in the WIEN2k usersguide or the 
QTL technical report [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13915.html ].


On 9/4/2017 9:50 AM, pl...@physics.ucdavis.edu wrote:

Dear Yundi, Gavin,

Thank you for your comments.

What I need is "fat band" plotting, but with the weight related to the
angular momentum of orbitals (means different orbital basis, as Yundi has
mentioned). So instead of the basis px and py one needs the basis px+ipy
and px-ipy. And I am interested in bands, of course one can trace it
somehow from DOS, but it's not very convenient.


Is there some built-in procedure in one of the programs to calculate and
plot these?

Best,
Lukasz




If you are asking about fat band plotting [1,2], there is section
"3.11.5 Bandstructure with band character plotting / full lines" in the
WIEN2k 17.1 usersguide [3].

Spaghetti-primavera on the unsupported page [4] might also be of
interest for band character plotting.

[1]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg1.html

[2]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04128.html

[3] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

[4] http://susi.theochem.tuwien.ac.at/reg_user/unsupported/

On 9/4/2017 8:32 AM, pl...@physics.ucdavis.edu wrote:

Dear WIEN2k experts,

Is there an easy way to plot orbital angular momentum character of the
bands? Here I mean for example px+ipy and px-ipy, and similar for d and
f
levels.

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

Re: [Wien] Orbital angular momentum band character

[Gavin Abo]

If I read previously referenced post [2] correctly, "x lapw2 -qtl -band" 
can be replaced by "x qtl".


[2] 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04128.html



On 9/4/2017 10:16 AM, Zhu, Jianxin wrote:

Dear Gavin,

But that qtl is for the partial DOS, not for the fat band structure 
plotting.

Have I missed anything here?

Cheers,

Jianxin

From: Wien <mailto:wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Gavin 
Abo mailto:gs...@crimson.ua.edu>>
Reply-To: A Mailing list for WIEN2k users 
mailto:wien@zeus.theochem.tuwien.ac.at>>

Date: Monday, September 4, 2017 at 10:12 AM
To: "wien@zeus.theochem.tuwien.ac.at 
<mailto:wien@zeus.theochem.tuwien.ac.at>" 
mailto:wien@zeus.theochem.tuwien.ac.at>>

Subject: Re: [Wien] Orbital angular momentum band character

There is likely a procedure(s) for what you want either in the WIEN2k 
usersguide or mailing list.  For example, see the post at:


http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09389.html

If the QSPLIT in case.inq to 1 that Yundi sent doesn't give what you 
want, I believe there is an option for specifying your own custom 
basis.  I think that is described either in the WIEN2k usersguide or 
the QTL technical report [ 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13915.html 
].


On 9/4/2017 9:50 AM, pl...@physics.ucdavis.edu wrote:

Dear Yundi, Gavin,

Thank you for your comments.

What I need is "fat band" plotting, but with the weight related to the
angular momentum of orbitals (means different orbital basis, as Yundi has
mentioned). So instead of the basis px and py one needs the basis px+ipy
and px-ipy. And I am interested in bands, of course one can trace it
somehow from DOS, but it's not very convenient.


Is there some built-in procedure in one of the programs to calculate and
plot these?

Best,
Lukasz




If you are asking about fat band plotting [1,2], there is section
"3.11.5 Bandstructure with band character plotting / full lines" in the
WIEN2k 17.1 usersguide [3].

Spaghetti-primavera on the unsupported page [4] might also be of
interest for band character plotting.

[1]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg1.html

[2]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04128.html

[3]http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

[4]http://susi.theochem.tuwien.ac.at/reg_user/unsupported/

On 9/4/2017 8:32 AM,pl...@physics.ucdavis.edu  wrote:

Dear WIEN2k experts,

Is there an easy way to plot orbital angular momentum character of the
bands? Here I mean for example px+ipy and px-ipy, and similar for d and
f
levels.

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

Re: [Wien] About the magnetic moment of vanadium in vanadium sulphide

[Gavin Abo]

The problem is that I want to know if it's possible to get a such 
value of 0.05 MB for atomic magnetic moment for the AFM state of 
vanadium sulphide in NiAs structure.


Correct me if I'm wrong, but I believe you are saying that you opened 
the case.scf file in a text editor or did a "grep -e :MMTOT -e :MMI -e 
:MMINT *.scf", then got the values from the last ITERATION.  The :MMIn 
being the total spin magnetic moment [1,2].


The :MMIn for the V atoms having 0.05 μB or -0.05 μB. The :MMTOT, :MMIn 
for the S atoms, and :MMINT are 0 μB.


Thus, you have some like:

0 (for :MMTOT) = [0.05 μB * multiplicity + -0.05 μB * multiplicity] (for 
:MMIn of V atoms; this showing the canceling moments of an AFM 
configuration [3]) + 0 (for :MMIn of S atoms) + 0 (for :MMINT)



  what was your charge convergence criterion ?


In addition to needing know what was used for -cc, maybe they would also 
need to know how :MMIn behaved in the last several iterations like in 
the posts [4,5].


[1] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12562.html
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10483.html
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13159.html
[4] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09231.html
[5] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09190.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] About the magnetic moment of vanadium in vanadium sulphide

[Gavin Abo]

Perhaps the -ec 0.001 and -cc 0.001 are too large of values.

As I recall, to be well-converged, it is usually best to use about the 
default values seen in the post [1] or WIEN2k 17.1 usersguide [2] as:


-cc 0.0001
-ec 0.0001

It sounded like about the default value for -ec was good unless 
something like -ec 0.1 was desired to reduce numerical noise, but 
anything smaller seemed useless [3,4].


For -cc, 0.1 also may be the lowest limit [5] and quite ambitious to 
try to use [6].


In section "4.5.4 Antiferromagnetic (AFM) calculations" on page 46 in 
the usersguide [2], there is the statement:


"If nothing changes (E-tot and other properties), then you are ok, 
otherwise make sure the scf calculation is well converged (-cc 0.0001 or 
better)."


If I read from the statement correctly, a well converged scf calculation 
typically uses -cc with a value of 0.0001 or smaller. Though, there is a 
realistic limit as mentioned above on how small it could be set.


In [7], it sounded important that the -cc value was low for the :MMIn 
values.


So, maybe the calculation can still converge further such that possibly 
the "MMI for V1" and "MMI for V2" will both become zero when they reach 
better convergence.


[1] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12620.html

[2] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10650.html
[4] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16077.html
[5] 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2008-November/011797.html
[6] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11558.html
[7] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09231.html


On 9/7/2017 9:11 AM, Abderrahmane Reggad wrote:

Hi All

I have used the PBE+EECC calculation for 3 configurations: nm, fm and 
afm I and I found that the afm I is the most stable.


The energy criterion and charge are 0.001 Ry and 0.001 e respectively.

I don't worry about if the material is really antiferromagnetic or 
paramagnetic because of:


1- I found only one experimental study that they found the compound to 
be pauli magnetic and one theoritical study which they found the 
compound to be non magnetic and these two studies are not sufficient 
to judge the compound to be in a such state. The theoritical study 
used the GGA method which is not good for correlated systems.


2- In the anfiferromagnetic state afm I in the NiAs structure for 
vanadium sulphide I found the following results:


MMI for V1: 0.05 MB
MMI for V2 :- 0.05 MB
MMI for S:    0 MB

My questions are now:

what's the definition of non magnetic compound ?

I think we can talk about non magnetic calculation and not about non 
magnetic compounds.


As Blaha said we can't silulate the paramagnetic state or at at least 
it's difficult to do it because we can't orientate the spins randomly 
ang maintain the total magnetic moment equals to zero.


Because of the Hind's prediction and because the impaired number of 
the V2+ ion to equal 3 I believe the atomic magnetic moment to be 
different from zero.


Best regards
___
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] Error in WIENNCM running in parallel mode

[Gavin Abo]

You might try checking the lapw2.error file. Does it show a problem with 
the case.energy_1 file like in the post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07963.html

If you have that same error, it might be that lapw1 failed in generating 
the case.energy_1.  There are other files you may need to look for error 
messages in as mentioned before in the mailing list archive [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15549.html 
].


On 9/7/2017 5:32 PM, Jianpeng Liu wrote:

Dear Wien2k/Wienncm users and developers,

I am learning to use wienncm to run some noncollinear-magnetism 
calculations. I have compiled the code without any error report, and 
the code runs well in serial mode. But if I run the same calculation 
in parallel mode,  the calculation is always aborted at the lapw2 
step, and  I got the following error:


FERMI - Error
cp: cannot stat `.in.tmp': No such file or directory
rm: cannot remove `.in.tmp': No such file or directory
rm: cannot remove `.in.tmp1': No such file or directory

The following is the .machine file:

granularity:1
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91

I would appreciate your help.

Best,
Jianpeng
___
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] Error in WIENNCM running in parallel mode

[Gavin Abo]

Sorry, I currently don't know the answer to your question.  Maybe 
someone else does.


I don't know what version of WIEN2k that the WIENncm was branched and 
then modified from or what the last WIEN2k version it was kept up to 
date with.


The WIENncm page [ http://susi.theochem.tuwien.ac.at/reg_user/ncm/ ] 
shows the publication to cite being in 2004.  So it could be using code 
as old or older then the latest WIEN2k version that existed in 2004. 
Though, the WIENNCM/DOC/ncmdoc.pdf file is dated 2006.  So it may 
contain WIEN2k code as new as 2006.


Therefore, the WIENncm code might suffer from the same WIEN2k bugs found 
since 2006:


http://susi.theochem.tuwien.ac.at/reg_user/updates/

Perhaps the problem is caused by a possible bug in the lapw1cpara script 
similar to what was reported for the lapw1para script in the 2009 post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01365.html

Maybe you could try the proposed fix to see if it resolves the problem 
or not, which I think was given in the post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01385.html

You could also give the lapw1cpara script from WIEN2k 17.1 a try, but it 
might be that it has new changes making it not compatible with WIENncm.


On 9/8/2017 12:00 AM, Jianpeng Liu wrote:

Dear Gavin,

Thank you for your prompt replay. I have checked that energy_1 has 
been properly generated. The lapw2.error says:

 'FERMI' - number of k-points inconsistent when reading kgen
 'FERMI' - check IN1 and KGEN files!

I have generated the k mesh using initncm, and set the total number of 
k points in BZ as 216 (the system is body-centered tetragonal, and 
there is no symmetry of the magnetic state, so there is also 216 k 
points in the irreducible BZ). I set up the .machines file to divide 
the 216 points to 12 processors, 18 k points for each processor. Then 
there is the problem: there are 18 k points in case.klist_1 ... 
case.klist_11, but in case.klist_12, there are only 16 k points, i.e., 
2 kpoints are just missing. This is probably why the system complains 
with the k point error?


Later I tried to change the method of determining the Fermi level from 
the linear-tetrahedra method to Gaussian smearing, with eval=0.0005Ry, 
then everything works. Still, two k points are missing in 
case.klist_12, but now the calculation runs well with 12 processors. 
Can I ask why the linear tetrahedra method fails, and why the two k 
points are missing?


Best,
Jianpeng



On Thu, Sep 7, 2017 at 9:17 PM, Gavin Abo <mailto:gs...@crimson.ua.edu>> wrote:


You might try checking the lapw2.error file. Does it show a
problem with the case.energy_1 file like in the post at:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07963.html
<https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07963.html>

If you have that same error, it might be that lapw1 failed in
generating the case.energy_1.  There are other files you may need
to look for error messages in as mentioned before in the mailing
list archive [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15549.html
<https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15549.html>
].


On 9/7/2017 5:32 PM, Jianpeng Liu wrote:

Dear Wien2k/Wienncm users and developers,

I am learning to use wienncm to run some noncollinear-magnetism
calculations. I have compiled the code without any error report,
and the code runs well in serial mode. But if I run the same
calculation in parallel mode, the calculation is always aborted
at the lapw2 step, and  I got the following error:

FERMI - Error
cp: cannot stat `.in.tmp': No such file or directory
rm: cannot remove `.in.tmp': No such file or directory
rm: cannot remove `.in.tmp1': No such file or directory

The following is the .machine file:

granularity:1
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91
1:node91

I would appreciate your help.

Best,
Jianpeng


___
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] PBS run

[Gavin Abo]

Does lapw0 exist in your WIEN2k directory (/home/sjana/WIEN2k_14.2)?

Maybe #PBS -V is needed [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15985.html 
].


On 9/8/2017 1:42 AM, Subrata Jana wrote:

Dear All,
 I am trying to run WIEN2k parallel. My shell script is looking like 
this. However, in the out.log file it is showing

--
lapw0: Command not found.

>   stop error
---

please help.

### script ##

#!/bin/bash
#PBS -N wien2k
#PBS -o out.log
#PBS -j oe
#PBS -l nodes=1:ppn=1

# Load Intel environment
source 
/apps/intel_2016_u2/compilers_and_libraries_2016.2.181/linux/bin/compilervars.sh 
intel64


cd /home/sjana/WIEN2k/PBE/C_pbe
rm -f .machines
echo '#' > .machines
echo 'granularity:1' >>.machines
awk '{print "1:"$1":1"}' $PBS_NODEFILE >>.machines
echo 'extrafine:1' >>.machines
/home/sjana/WIEN2k_14.2/run_lapw -p -i 40 -ec .0001 -I

Regards,
S. Jana

___
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] PBS run

[Gavin Abo]

It look like something is wrong with this line [ 
https://stackoverflow.com/questions/26816605/awk-fatal-cannot-open-file-for-reading-no-such-file-or-directory 
]:


awk '{print "1:"$1":1"}' $PBS_NODEFILE >>.machines

Maybe quotes are needed around the $PBS_NODEFILE:

awk '{print "1:"$1":1"}' "$PBS_NODEFILE" >>.machines

On 9/8/2017 2:20 AM, Subrata Jana wrote:

Hi Gavin Abo,
I change my job script as follows:

#
#!/bin/bash
#PBS -N wien2k
#PBS -o out.log
#PBS -j oe
#PBS -l nodes=1:ppn=1

# Load Intel environment
source 
/apps/intel_2016_u2/compilers_and_libraries_2016.2.181/linux/bin/compilervars.sh 
intel64


cd /home/sjana/WIEN2k/PBE/C_pbe
rm -f .machines
echo '#' > .machines
*echo -n 'lapw0:' > .machines*
echo 'granularity:1' >>.machines
awk '{print "1:"$1":1"}' $PBS_NODEFILE >>.machines
echo 'extrafine:1' >>.machines
/home/sjana/WIEN2k_14.2/run_lapw -p -i 40 -ec .0001 -I
###

Now the out.log

awk: cmd. line:1: fatal: cannot open file `-np' for reading (No such 
file or directory)

ssh: Could not resolve hostname granularity: Name or service not known^M

>   stop error

Regards,
S. Jana







___
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] problem when running berrypi

[Gavin Abo]

I cannot recall if BerryPI works with Python 2.6.  You can try it, but 
maybe it doesn't work as section "8.2 BerryPI (Modern theory of 
polarization)" in the WIEN2k 17.1 usersguide on page 149 has:


"It consists of a set of Python scripts (*requires* *Python 2.7* and the 
NumPi library) and uses wien2wannier for the calculation of overlap 
integrals."


The current error, however, doesn't look like it is caused by Python 2.6.

In your config.py, there is:

#fix for location of python file locations when executing from the 
python commandline

DEFAULT_BIN_PATH=/home/ha/SRC_BerryPI/BerryPI

#Fix for python path to make sure it grabs the latest version
DEFAULT_PYTHON_PATH=/usr/bin/python

As Oleg mentioned, the current error will most likely be resolved if you 
edit it and add single quotes to those lines:


#fix for location of python file locations when executing from the 
python commandline

DEFAULT_BIN_PATH='/home/ha/SRC_BerryPI/BerryPI'

#Fix for python path to make sure it grabs the latest version
DEFAULT_PYTHON_PATH='/usr/bin/python'

On 9/7/2017 8:40 PM, halim said wrote:

Dear Prof Oleg,


Thank you for your suggestion, I don't work on personal computer and 
Python2.6 version is installed.

Is it ok? please find config.py as attached file.

Your suggestion is very much appreciated.

Looking forward for your answer.

All my best,

Halim


Le Jeudi 7 septembre 2017 21h49, "Rubel, Oleg"  a 
écrit :



Ok. Can you reply with config.py file attached?

I remember python being picky about single quote signs for the text 
variable enclosures.


...
#fix for location of python file locations when executing from the 
python commandline

DEFAULT_BIN_PATH='/home/rubel/BerryPI'

#Fix for python path to make sure it grabs the latest version
DEFAULT_PYTHON_PATH='/software/CentOS-6/tools/python-2.7.3/bin/python’
…

Also check
[rubel@lg-1r14-n04  GaN-W]$ which berrypi

Here is what I have:
alias berrypi='/software/CentOS-6/tools/python-2.7.3/bin/python 
/home/rubel/BerryPI/berrypi'

    /software/CentOS-6/tools/python-2.7.3/bin/python

Thanks
Oleg

> On Sep 7, 2017, at 14:28, halim said > wrote:

>
> Dear Prof Oleg,
>
> Thank you for your answer. I changed the path in config.py and set 
it  as in the mentioned folder, also the folder 
home/ha/SRC_BerryPI/BerryPI

> exists.
>
> The same error occurs after changing the path, please what to do to 
solve the problem?

>
> I appreciate your help.
>
> Halim
>
>
> Le Jeudi 7 septembre 2017 19h23, "Rubel, Oleg" > a écrit :

>
>
> Please check that the folder /home/ha/SRC_BerryPI/BerryPI
> really exists. Your error message suggests that it can be 
/home/ha/WIEN2k/SRC_BerryPI/BerryPI

> In this case you should edit DEFAULT_BIN_PATH in config.py
>
> I hope it will fix your problem
> Oleg
>
> > On Sep 7, 2017, at 12:11, halim said > wrote:

> >
> > Dear Wien2k  users community,
> >
> > I am facing problem when running berrypi, i followed the example 
of GaN, but i am getting this error. How to solve it.

> >
> > gan> berrypi -k6:6:6
> > Traceback (most recent call last):
> >  File "/home/ha/WIEN2k/SRC_BerryPI/BerryPI/berrypi", line 25, in 


> >    import submoduleProcess as b_PySubProcess
> >  File "/home/ha/WIEN2k/SRC_BerryPI/BerryPI/submoduleProcess.py", 
line 11, in 

> >    from config import BERRY_DEFAULT_CONSOLE_PREFIX as DEFAULT_PREFIX
> >  File "/home/ha/WIEN2k/SRC_BerryPI/BerryPI/config.py", line 14
> > DEFAULT_BIN_PATH=/home/ha/SRC_BerryPI/BerryPI
> >                      ^
> > SyntaxError: invalid syntax
> >
> >
> >
> > I would be thankful for your suggestion and answer to solve the 
problem.

> >
> > Looking forward your answer.
> >
> > Halim Said
>
> >
> >
> >
> >
> >
> > ___
> > 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


___
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.theoc

Re: [Wien] PBS run

[Gavin Abo]

You might have a look at the "WIEN2k-notes of the University of Texas" 
document (slide 7) at:


http://susi.theochem.tuwien.ac.at/reg_user/faq/pbs.html

The line:

echo -n 'lapw0:' > .machines

It looks like that writes to the .machines file:

lapw0:

However, you need to have it write the "machine names" after it. So 
something like:


lapw0:gamma:2 delta:2 epsilon:4

However, you are having it write:

lapw0:granularity:1

Thus, the error about it not being able to find and connect to a 
hostname called "granularity".


On 9/8/2017 2:41 AM, Subrata Jana wrote:

Hi Gavin Abo,
It looks I am facing the same problem.

##

#!/bin/bash
#PBS -N wien2k
#PBS -o out.log
#PBS -j oe
#PBS -l nodes=1:ppn=1

# Load Intel environment
source 
/apps/intel_2016_u2/compilers_and_libraries_2016.2.181/linux/bin/compilervars.sh 
intel64

export OMP_NUM_THREADS=1
cd /home/sjana/WIEN2k/PBE/C_pbe
rm -f .machines

#source 
/apps/intel_2016_u2/compilers_and_libraries_2016.2.181/linux/bin/compilervars.sh 
intel64


cd /home/sjana/WIEN2k/PBE/C_pbe
rm -f .machines
echo '#' > .machines
echo -n 'lapw0:' > .machines
echo 'granularity:1' >>.machines
#awk '{print "1:"$1":1"}' $PBS_NODEFILE >>.machines
awk '{print "1:"$1":1"}' "$PBS_NODEFILE" >>.machines
echo 'extrafine:1' >>.machines
#/home/sjana/WIEN2k_14.2/run_lapw -p -i 40 -ec .0001 -I
run_lapw -p -i 40 -ec .0001 -I
#

My .machines file looks like


lapw0:granularity:1
1:r8n3:1
extrafine:1


out.log

ssh: Could not resolve hostname granularity: Name or service not known^M

>   stop error

Regards,
S. Jana
___
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] Regarding to generate CH3NH3PbI3 cubic struct file for space group Pm-3m (221)

[Gavin Abo]

A brief view in XCrySDen of


Spacegroup: 221_Pm-3m

a = b = c = 6.3391

alpha = beta = gamma = 90

Pb (0, 0, 0)

I (0, 0.072, 0.5)

C (0.426, 0.426, 0.5) or (0.574, 0.574, 0.5)

N (0.627, 0.627, 0.5)


from the article titled "CH_3 NH_3 PbI_3 , A Potential Solar Cell 
Candidate: Structural and Spectroscopic Investigations" [ 
http://pubs.acs.org/doi/abs/10.1021/acs.jpca.6b09718 ] shows overlapping 
atoms indicating that this structure may have a partial occupancy.


WIEN2k does not accept case.struct files having a partial occupancy.  
Reference the links in the post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13806.html

On 9/8/2017 3:44 AM, AJAY SINGH VERMA wrote:

Dear Sir,
thanks for your guidance about the cif files.
but i am trying to generate a struct file for CH3NH3PbI3 cubic with 
space group Pm-3m (221).

I am facing the problem in the position OR coordinates of C & H
Kindly help me.
thanks



___
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] problem when running berrypi

[Gavin Abo]

In WIEN2k_14/SRC_BerryPI/BerryPI/Installation/readme.org, there should be:

* Dependencies
  - WIEN2k (tested against 13.1 Release 25 June 2013) <- wien2k14 
instead of 13.1 should be okay here

  - WIEN2WANNIER (tested against v1.0-beta2)
  - Python (tested against 2.7.4)
  - NumPy (tested against 1.6.2)

As the readme.org file shows, yes, WIEN2WANNIER is needed for BerryPI.  
I believe WIEN2WANNIER should already be compiled from when you 
installed WIEN2k_14.  If not, you should be able to compile the program 
in WIEN2k_14/SRC_w2w.


Though, if it were me doing a BerryPI calculation, I would use WIEN2k 
17.1 as Oleg mentioned.  That is because 17.1 is an important update 
that removed bugs from WIEN2k that were found in the older versions [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].


The WIEN2WANNIER has also evolved as mentioned by Oleg.  However, the 
WIEN2WANNIER and BerryPI packages included in WIEN2k 17.1 might still be 
older versions that are slightly broken and incompatible with each other 
[ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16099.html 
].


So I would replace the WIEN2WANNIER and BerryPI packages in WIEN2k 17.1 
or use instead the latest github versions:


https://github.com/wien2wannier/wien2wannier
https://github.com/spichardo/BerryPI

It doesn't look like the Dependencies on the BerryPI Installation page [ 
https://github.com/spichardo/BerryPI/wiki/Installation ] have been 
update yet for WIEN2k 17.1.


I believe for BerryPI 1.3.4 (Jul 15, 2017) [ 
https://github.com/spichardo/BerryPI/blob/master/version.info ], they 
may now be:


* Dependencies
  - WIEN2k (17.1 Release 4 July 2017 [ 
http://susi.theochem.tuwien.ac.at/index.html ])
  - WIEN2WANNIER (2.0.1 [ 
https://github.com/wien2wannier/wien2wannier/blob/master/NEWS ])

  - Python (tested against 2.7.4)
  - NumPy (tested against 1.6.2)

On 9/8/2017 9:04 PM, halim said wrote:

Dear Professor   Gavin,

Thank you for your suggestion, but for my case I am working with 
wien2k14, also you said that I need to use wien2wannier, should I 
compiled and use it with BerryPi?


I appreciate for your answer.


Regards,

Halim
___
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] bash script to run initso_lapw for different M-axis

[Gavin Abo]

For the (100), (101), (102), and (103), you could try a for loop in bash 
[ 
https://stackoverflow.com/questions/24366305/how-to-write-a-bash-script-with-a-for-loop-that-creates-multiple-text-files-with 
]; for example:


create_initso_inputfile.sh
--
#!/bin/bash

for i in {100,101,102,103}; do
echo $i > input$i.txt
echo "11-15,17,18,22-26" >> input$i.txt
echo "N" >> input$i.txt
echo "8" >> input$i.txt
echo "y" >> input$i.txt
echo "150" >> input$i.txt
echo "N" >> input$i.txt
done
--

The above bash script creates the input data in separate files 
input100.txt, input101.txt, input102.txt, and input103.txt. Though, you 
could instead modify it to output a input.txt in separate directories.


Then, you could try redirecting the files [ 
https://en.wikipedia.org/wiki/Redirection_(computing) ] as input to 
initso in your job scripts; for example, try in the 100 job script:


initso_lapw < input100.txt

(note: If the text editor opens of case.inso or case.in1 for example 
stop the initso_lapw script from finishing, then the editor lines might 
need commented out in initso_lapw or make_inso_lapw. )


Alternatively, you could also try using echo or printf in your job 
script like was described before, with kgen as the example, in the 
mailing list posts at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14196.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14171.html

On 9/16/2017 8:04 AM, venkatesh chandragiri wrote:



Dear Wien2k users,


I want to run the SO caculations to plot the energies for different 
angles of M-axis orientations. So I have re-initilize the SO 
calcualtions for each M-axis using "initso_lapw" and need to submit 
the job in each time in a queue using a pbs script. But this takes me 
a lot of effort (re-initiliation of initso_lapw for each M-axis)and 
for each time submitting the job is taking more time to have its own 
turn to run. As it seems to me all other paramaters are similar, 
except the M-axis values, Is there any unique way to run SO 
calculations by giving M-axis values , A= 
{(100),(101,)(102),(103)..etc} in a seperate file, such that for a 
give i=1 to n (n= size of A), the wien2k do the initso_lapw and run 
the SO calculatons. After finishing each ith SO run, the pbs script 
takes the output (using grep command) into another file (output.txt). 
May be this was in similar to the optimize_job script.


Could anybody suggest me how to write a bash script to read the 
parameters from input.txt when running initso-lapw for each ith run.


input.txt
==

initso_lapw

A  = {(100),(101,)(102),(103)..etc} # M-axis orientations

11-15,17,18,22-26 # list of atoms for which SO was not applied

N # no for RLO

8 # Emax value

y # yes, to generate the new structure for a given M-axis

y # yes, to use newly generated structure

150 # number of k-points

N # no for re-run the kgen

=

thanks in advance.

with best regards,

venkatesh


___
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] errors NMR calculations

[Gavin Abo]

What version of WIEN2k did this occur in?

Perhaps the error

syntax error near unexpected token `makescratch_lapw'

is due to the x_lapw script in older WIEN2k versions (such as 13.1 and 
14.2) that used to use makescratch_lapw like for example coming during 
the running of "x lapw1 -nmr" seen in the post:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10975.html

FYI, the WIEN2k updates page [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ] shows that WIEN2k 
17.1 has fixes and improvements to x_nmr and SRC_nmr for nmr calculations.


On 9/16/2017 6:22 AM, halim said wrote:



Dear Wien2k  users community,


I am facing problem when running NM for semiconductor, I got these 
errors for running and some lines are listed below:



*x_nmr_lapw -mode in1*


:WARNINIG  ATOM=   1  L= 2  HIGH OVERLAP between radial functions 0.85 
setting new lo energy:  0.30
:WARNINIG  ATOM=   1  L= 2  HIGH OVERLAP between radial functions 0.70 
setting new lo energy:  0.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.99 
setting new lo energy:  0.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.99 
setting new lo energy:  0.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.98 
setting new lo energy:  1.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.96 
setting new lo energy:  1.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.95 
setting new lo energy:  2.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.93 
setting new lo energy:  2.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.90 
setting new lo energy:  3.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.87 
setting new lo energy:  3.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.84 
setting new lo energy:  4.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.80 
setting new lo energy:  4.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.76 
setting new lo energy:  5.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.72 
setting new lo energy:  5.80
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.67 
setting new lo energy:  6.30
:WARNINIG  ATOM=   2  L= 0  HIGH OVERLAP between radial functions 0.63 
setting new lo energy:  6.80



NUMBER OF RADIAL FUNCTIONS IN case.in1_nmr
ATOM     L=0     L=1     L=2     L=3
 1       9       9      10       9
 2      10       9       9


*x_nmr_lapw -p*



gn/nmr_q0/./tmpsshc4w1: line 2: syntax error near unexpected token 
`makescratch_lapw'



gn/nmr_pqx/./tmpsshc4w12: line 2: syntax error near unexpected token 
`makescratch_lapw'


gn/nmr_mqz/./tmpsshc4w29: line 2: syntax error near unexpected token 
`makescratch_lapw'



gn/gn.xim_1
Image              PC                Routine    Line        Source
nmrc               01510344  Unknown         Unknown  Unknown
nmrc               015361E0  Unknown         Unknown  Unknown
nmrc               0049DAF5  sumpara_             38  sumpara.f
nmrc               00413DA9  MAIN__             35  nmr.f
nmrc               00400FEE  Unknown         Unknown  Unknown
nmrc               015BACC1  Unknown         Unknown  Unknown
nmrc               00400ED1  Unknown         Unknown  Unknown

forrtl: severe (24): end-of-file during read, unit 54, file 
/lustre/scratch/tmp/x_larefa

/gan/gn/gn.current_int_x
Image              PC                Routine    Line        Source
nmrc               01510344  Unknown         Unknown  Unknown
nmrc               01531F03  Unknown           Unknown  Unknown
nmrc               004411FB  read_current_int_          80 
 read_current_tmp_.F
nmrc               0045E2C3  integrate_current          34 
 integrate_current_tm

p_.F
nmrc               00413E8C  MAIN__               44  nmr.f
nmrc               00400FEE  Unknown           Unknown  Unknown
nmrc               015BACC1  Unknown           Unknown  Unknown
nmrc               00400ED1  Unknown           Unknown  Unknown





I would be thankful for your suggestion and answer to solve the problem.

Looking forward your answer.

Halim Said
___
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] Hardware (i7-7700k?) for WIEN2k

[Gavin Abo]

Some additional comments:

If you need an idea of about how computational intensive a WIEN2k 
calculation might be for around 60 atoms per cell or more.  The links 
below and links in those posts might be helpful:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14035.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01420.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05784.html

The hardware specifications for the i7-7700K and E5-2623 v3 processors 
should be at the links:


https://ark.intel.com/products/97129/Intel-Core-i7-7700K-Processor-8M-Cache-up-to-4_50-GHz
http://ark.intel.com/products/83354/Intel-Xeon-Processor-E5-2623-v3-10M-Cache-3_00-GHz

The specifications look fairly similar.  So maybe there would not be too 
much of a difference in the WIEN2k calculation run times between the two.


The i7-7700K supports a Max Memory Size of 64 GB.  The E5-2623 v3 could 
have a major advantage when it comes to supporting a Max Memory Size of 
768 GB.  However, if the motherboard the E5-2623 v3 goes on does not 
have memory expansion slots for more than 64 GB or if you never plan to 
add additional memory modules to increase the memory beyond 64 GB, then 
that would not matter.


The i7-7700K does have about a 1 GHz faster processor frequency and it 
looks like it supports a faster RAM (DDR4-2133/2400, while the E5-2623 
v3 supports a slower DDR4 with frequency of 1600 or 1866 MHz).  So this 
might give it better performance than the i7-7700K if the calculation 
uses less than 64 GB of RAM.  Above 64 GB, the workstation would likely 
use virtual memory and disk caching may significantly slow a calculation 
(whereas the E5-2623 v3 with more than 64 GB should extend the limit of 
this RAM bottleneck).  The i7-7700K also supports DDR3L-1333/1600.  If 
both the i7-7700K and E5-2623 v3 workstations happen to use the same 
DDR3 1600 RAM, then no speed up or slow down is expected from the RAM 
frequency.


More importantly than all that may be the launch date for the E5-2623 v3 
of Q3'14, while Q1'17 for the i7-7700K.  The Xeon E5-2623 v3 has been 
around awhile.  So Linux distributions most likely have drivers that 
support this processor.  With the i7-7700K being so new, you might have 
to be more cautious.  If you decide to get the i7-7700K, I recommend 
checking that the Linux distribution, compiler (in particular if you 
plan to use a non-Intel compiler like gfortran), and libraries (such as 
a blas library with the non-Intel compiler) that you will be using are 
able to support and recognize the processor.


As an example, I think it was the Intel HD Graphics 530 onboard the 
Intel Skylake processors when they were first launched that didn't have 
a good Linux driver [ 
https://askubuntu.com/questions/698168/cant-get-intel-hd-graphics-530-skylake-i7-6700-to-work 
]. If I recall correctly, the graphics were broken (or of poor quality) 
for several months until the drivers were finally released.


Of note, there is also seems to be a E5-2623 v4:

http://ark.intel.com/products/92980/Intel-Xeon-Processor-E5-2623-v4-10M-Cache-2_60-GHz

On 9/18/2017 6:54 PM, Yundi Quan wrote:

hi,

4 cores with 8 threads is probably OK for using WIEN2k to study 
transition metal oxides. For post-processing tools, such as 
wien2wannier, it requires more memory. But 64 GB is enough in most 
cases. I once bought a Dell XPS with 4 cores and 8 threads, 16 GB 
memory back in 2011. It worked well for most of my calculations. Hope 
this helps.





On Mon, Sep 18, 2017 at 2:44 PM, Karsten Küpper > wrote:


Dear WIEN2k-community,

We want to buy a workstation dedicated to run WIEN2k.
Our aim is to calculate mostly transition metal oxides with unit
cells ranging from 24 - 128 atoms supercells.
We are thinking about a workstation with at least 4 cores, at
least 64 GB RAM, and a 1TB SSD as a starting point.

1) May that be a reasonable choice?

2) Has anybody experiences with the i7-7700K 4.2 GHz (maybe also
compared to Intel-Xeon E5-2623 processors),  as there is no
benchmark test available on the WIEN2k homepage by now.

Thanks for your efforts in advance!

Kind regards
Karsten Küpper

___
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] bash script to run initso_lapw for different M-axis

[Gavin Abo]

It is of course recommended to use the latest WIEN2k version because of 
the bugs found since WIEN2k 13.1 [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].


If you want to leave the code untouched, you could try changing the 
EDITOR line in your .bashrc file (note: remember to open and use a new 
terminal so that it loads and uses the new .bashrc settings).  For 
example, you might have something like:


export EDITOR="gedit"

You could change that line to:

export EDITOR=""

However, this would give you an error messages like:

case.inso: Permission denied.

You could also change that line to:

export EDITOR="noeditor"

This should output error messages like:

noeditor: Command not found.

So you would have to chose which error message you prefer to see.  Since 
you wouldn't be interacting with an editor when using a job script, you 
could just ignore those error messages.


If you don't want the error messages, you would have to edit the 
scripts.  In SRC/make_inso_lapw of WIEN2k 13.1, on line 191, you should see:


editor $file.inso

You could comment it out by changing the line to:

#editor $file.inso

Similarly, line 195:

#editor $filein1

In SRC/initso_lapw, line 196:

#editor $file.outsymso

Line 234 and 266:

#editor $file.klist

Instead of using comment symbols (#), a better way may be to do 
something like:


set editorstate = 0 # 0: Set editor OFF, 1: set editor ON

if ($editorstate) editor $file.inso

However, I cannot test or describe all the changes right now for what 
would be needed for using this alternate set and if statement approach.


On 9/18/2017 5:57 PM, venkatesh chandragiri wrote:

Dear Prof. Gavin,

Thank you again for the script to create the input for initso_lapw  
and it works fine now. However, the initso_lapw is asking to edit the 
following files.


1. case.inso

2. case.in1

3. case.outsymso

4. case.klist

Hence, kindly let me know (paste the script lines) to avoid the 
editing of those above files and continue the initso_lapw in 
background itself.


thank you and looking forward to your reply.

with best regards,

venkatesh
___
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] relaxation

[Gavin Abo]

See option "[7] VARY A, B, C and Gamma (4D-case) (monoclinic lattice)" 
in section "5.3.1 Lattice parameters (Volume, c/a, lattice parameters)" 
on page 74 of the WIEN2k 17.1 usersguide [ 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ].


Since there are so many degrees of freedom (is a calculation for 4 
dimensions), the calculation is likely very computational expensive.  
Hopefully you have a cluster with many cores.


That should be just lattice parameter optimization.  If atomic position 
optimization is need as well, that may require even more computation.  
The "Structure optimization-notes (pdf)" on the textbook page [ 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/ ], I think 
describes simultaneous optimization of lattice parameters and atomic 
positions with a simpler case as an example pretty well.


On 9/18/2017 5:49 AM, Shalika R. Bhandari wrote:

Hi sir,
I want to learn the steps  optimisation of monoclinic crystal ?


___
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] multiple fatbands plot

[Gavin Abo]

For the TiC example in the WIEN2k usersguide, jtype of 6 should 
correspond to t2g.



What is 11 and 12 in your case?  Not sure if 11 or 12 are too high of a 
number and don't correspond to anything.



The "line switch" might need to be set to 2 in your case.insp and 
sometimes I think the circle size (size of heavier plotting) of 0.2 
might be too small to show the fat bands.  You might have to increase it 
so that it doesn't hide itself as a thin line.



On 9/18/2017 9:30 PM, Wen Fong Goh wrote:


Hi, how do you plot multiple fatbands? I tried adding another line in 
case.insp after jatom jtype ... line but it doesn't work.


2 11    0.2    # jatom, jtype, size  of heavier 
plotting
2 12    0.2    # jatom, jtype, size  of heavier 
plotting
___
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] multiple fatbands plot

[Gavin Abo]

I forgot, you may be right that WIEN2k can only plot one band character 
at a time.  To plot more than one, you might need to create your own 
plot using a graphing software (like Origin, gnuplot, matlab, etc.) or 
use Spaghetti-primavera.  See the unsupported page for Spaghetti-primavera:



http://susi.theochem.tuwien.ac.at/reg_user/unsupported/


On 9/19/2017 1:14 AM, Wen Fong Goh wrote:


11 and 12 correspond to dxz and dyz (not quite t2g in cubic sym.). 
Ideally, I would like to have a fatband for dxz and another (different 
color) for dyz. What I found is even though line 11 (jatom jtype ...) 
is repeated, only the last line will be plotted, it can easily be 
checked by setting the size on the first line to be large.


2 11    2.0    # jatom, jtype, size  of heavier 
plotting
2 12    0.2    # jatom, jtype, size  of heavier 
plotting



For the TiC example in the WIEN2k usersguide, jtype of 6 should 
correspond to t2g. What is 11 and 12 in your case?  Not sure if 11 or 
12 are too high of a number and don't correspond to anything.


The "line switch" might need to be set to 2 in your case.insp and 
sometimes I think the circle size (size of heavier plotting) of 0.2 
might be too small to show the fat bands.  You might have to increase 
it so that it doesn't hide itself as a thin line.

On 9/18/2017 9:30 PM, Wen Fong Goh wrote:

Hi, how do you plot multiple fatbands? I tried adding another line
in case.insp after jatom jtype ... line but it doesn't work. 2
11    0.2    # jatom, jtype, size  of heavier
plotting 2 12    0.2    # jatom, jtype, size 
of heavier plotting 


___
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 -- A Mailing list for WIEN2k users 


zeus.theochem.tuwien.ac.at
Your email address: Your name (optional): You may enter a privacy 
password below. This provides only mild security, but should prevent 
others from messing with ...


wien - The Mail Archive 


www.mail-archive.com
Messages by Thread [Wien] problem of energy gap within mBJ halim said. 
Re: [Wien] problem of energy gap within mBJ tran; Re: [Wien] problem 
of energy gap within mBJ ...





___
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] bash script to run initso_lapw for different M-axis

[Gavin Abo]

I don't know everything about SO.  You can read more about the 
EFG-MATRIX is a NULLMATRIX error in the posts at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03446.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04411.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06048.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09677.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05035.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04409.html

This error is in WIEN2k 13.1, right? Does it happen in WIEN2k 17.1? On 
the updates page [ http://susi.theochem.tuwien.ac.at/reg_user/updates/ 
], you can see changes such as to init_so_lapw, make_inso_lapw, 
SRC_lapwso, and SRC_symmetso since WIEN2k 13.1.  It may be that 17.1 
already has a fix that will resolve this error.


The Error in Parallel LAPW2 might just be a result of the lapw0 error.

On 9/19/2017 8:40 PM, venkatesh chandragiri wrote:

Dear Prof. Victor and Prof. Gavin,

thanks for your reply. The script sent by Prof. Gavin works fine. I 
just kept , editor ="noeditor"   in my .bashrc file. Now the editor is 
not opening. However, while running this script there was error as 
given below (although it is not connected with the error in the script 
write-up).


==

>   lapw2 -up -p   -c -so   (10:13:36) running LAPW2 in parallel mode
**  LAPW2 crashed!
0.232u 0.242s 0:00.54 87.0% 0+0k 0+392io 0pf+0w
error: command   /public/home/venkatesh/WIEN2k/lapw2cpara -up -c -so 
uplapw2.def   failed

>   stop error



uplapw2.error

=

'FERMI5' -  emax too low in vector-file
**  testerror: Error in Parallel LAPW2

=

The case.dayfile at the earlier shows

==

>   lapw0 -p    (10:12:50) starting parallel lapw0 at Wed Sep 20 
10:12:50 CST 2017

 .machine0 : processors
running lapw0 in single mode
 WARNING: The EFG-MATRIX is a NULLMATRIX !
 WARNING: The EFG-MATRIX is a NULLMATRIX !

=

I am using k-point parallization  to run soc calcualtions

The SOC calculations for single M-axis works well through regular 
procedure (200 axis). However, when I used the script to run for i3 
{200,201,202,103}, the above error appears for all cases.


Kindly suggest me the possible reason for this error

thanking you

with best regards,

venkatesh
___
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] Problem of permission to submit the program and que setting

[Gavin Abo]

Since I don't have a system with Rocks and qsub, I cannot be of much 
help.  That looks like it might be a Grid Engine error and not a WIEN2k 
error, so you might get better help resolving that error on a Grid 
Engine mailing list [1] or a Rocks mailing list [2].


It looks like qsub doesn't allow the 'root' account to submit jobs [3].  
Did you run qsub under as root?  If so, that may be the cause of the 
error. The solution may be to run instead qsub under a 'user' account.


[1] http://gridengine.org/mailman/listinfo/users
[2] https://lists.sdsc.edu/mailman/listinfo/npaci-rocks-discussion
[3] 
https://stackoverflow.com/questions/37733095/unable-to-run-jobs-on-cfncluster


On 9/19/2017 4:04 AM, sharma.krishnaswaroop wrote:


Dear Prof. Blaha/WIEN users
Sorry incomplete message was sent by mistake. We are trying to set up 
a small cluster for WIEN2K , by using one server and 4 nodes, all i5 
intel desktops. We have successfully installed Rocks 6.2 and WIEN2K 
16.1. We are finding problem in que setting. We are using SGE for 
queing and have defined through qmon the administrative host, submit 
host and execution hosts. But when we submit a job by using qsub 
command it give error with the message "Unable to run job: job 
rejected: root@cluster.local is not allowed to submit jobs. Exiting." 
We tried to find out a solution from User guide and Frequently asked 
questions, but could not get a solution. Could any body help us to 
solve the problem and successfully instal the cluster.

With thanks in anticipation.
Dr. K. S. Sharma
The IIS UNIVERSITY JAIPUR INDIA

___
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] Segfault in runsp -so (lapw1), gfortran 6.4 on mac os sierra

[Gavin Abo]

In your traceback, there is:

#1 0x1090555ec in zlatd4_ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4427


On line 4427 of SRC_lapwso/lap_bp.f in WIEN2k 17.1, there is:

ABP(I1I)

In the same file,

Line 4212 has:

COMPLEX*16   ABP( * )

Line 4242-4243 has:

!  ABP (input/output) COMPLEX*16 array,
!  dimension (1:n*(n+1)/2+(n/hb+1)*hb*(hb-1)/2)

In SRC_lapwso/hmsec.F, line 4 has:

USE param

Line 771 has:

allocate (hso(num2))

In hmsec, it looks like the zhhevx call passes hso to variable AP that 
later gets passed to ABP.


In SRC_lapwso/modules.F:

MODULE param
INTEGER   :: num2= 0

Line 205 in SRC_lapwso/lapwso.F:

  num2= nume2*(nume2+1)/2+(nume2/hblock+1)*(hblock*(hblock-1)/2)

I'm not completely sure, but I wonder if the error is caused because in 
PROGRAM lapwso of lapwso.F there is not a line:


USE param

On 9/20/2017 5:52 AM, Hugo Strand wrote:
Adding debug symbols in lapwso with "-g -ggdb" gives the full 
backtrace showing line numbers in the source code where the invalid 
memory access occurs (lap_bp.f:4427), see below.


Best, Hugo

[NiO] $ runsp -so
STOP  LAPW0 END
Note: The following floating-point exceptions are signalling: 
IEEE_UNDERFLOW_FLAG

STOP  LAPW1 END
Note: The following floating-point exceptions are signalling: 
IEEE_UNDERFLOW_FLAG

STOP  LAPW1 END
ASAN:DEADLYSIGNAL
=
==50875==ERROR: AddressSanitizer: SEGV on unknown address 
0x00088d7a3c70 (pc 0x7fffaca48086 bp 0x7fff56c4fff0 sp 0x7fff56c4fff0 T0)
    #0 0x7fffaca48085 in APL_stbmvUTN_AVX 
(/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib+0xa5085)
    #1 0x1090555ec in zlatd4_ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4427
    #2 0x109051ece in zhhtr4_ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:3933
    #3 0x10905133f in zhhtrd_ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4164
    #4 0x109068425 in zhhevx_ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:3244
    #5 0x1090032c6 in hmsec_ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/hmsec.F:790
    #6 0x10902750b in MAIN__ 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lapwso.F:592
    #7 0x109027b74 in main 
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lapwso.F:2

    #8 0x7fffc511b234 in start (/usr/lib/system/libdyld.dylib+0x5234)
    #9 0x1  ()

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
(/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib+0xa5085) 
in APL_stbmvUTN_AVX

==50875==ABORTING

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1092a8e26
#1  0x1092a85ec
#2  0x7fffc532ab39

>   stop error
___
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] how to simulate the energy of Oxygen molecule

[Gavin Abo]

http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000880.html
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000882.html

On 9/20/2017 4:44 AM, shamik chakrabarti wrote:

Dear wien2k users,

    How to simulate the ground state energy of 
Oxygen molecule (O2) in wien2k?..We can create a 20 Angstorm unit cell 
& put an oxygen atom at the centre, but then in which position another 
oxygen atom can sit?


Thanks in advance.

with regards,

--
Dr. Shamik Chakrabarti
Post Doctoral Research Associate
Dept. of Condensed Matter Physics and  Material Science
S N Bose National Centre for Basic Sciences
Kolkata-700098
INDIA
___
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] Fwd: how to simulate the energy of Oxygen molecule

[Gavin Abo]

My opinion is that your first struct file with a = b = 30 bohr = 
15.87531 ang and c = 40 bohr = 21.16708 ang was better expect for the 
bond length as Gerhard mentioned.


I would probably put the O atoms around the center in-between z = 0 and 
z = 1.  In other words, the first atom at:


z = 0.5 + delta_z

where delta_z = [(bond length)/2]/c = [1.208 ang/2]/21.16708 ang = 
0.02853488


Therefore, (0,0,z) = (0,0,0.52853488)

Then, the second O atom I would put at (0.5 - delta_z) = 0.47146512.

Such that, (0,0, 1-z) = (0,0,0.47146512)

Checking the bond length with distance formula [ 
http://mathworld.wolfram.com/Distance.html ]:


d = sqrt [(0-0)^2+(0-0)^2+(0.52853488-0.47146512)^2] = 0.05706976
d = 0.05706976*21.16708 ang = 1.208 ang

On 9/22/2017 8:31 AM, shamik chakrabarti wrote:

Dear Gavin, Gerhard & Wien2k users,

I am sending the modified structure file for O2 molecule. Please have 
a look at it & suggest me that whether it is right.


Thanks in advance.

with regards,


On Fri, Sep 22, 2017 at 5:01 PM, Fecher, Gerhard <mailto:fec...@uni-mainz.de>> wrote:


I think 4.4 Angström between two oxygen atoms would be a rather
large bond length for O2
shouldn't you give the z parameter in multiples (fractions) of the
lattice parameters ?

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at
<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>] im Auftrag von
shamik chakrabarti [shamik...@gmail.com <mailto:shamik...@gmail.com>]
Gesendet: Freitag, 22. September 2017 12:16
An: A Mailing list for WIEN2k users
Betreff: [Wien] Fwd:  how to simulate the energy of Oxygen molecule

-- Forwarded message --
From: shamik chakrabarti mailto:shamik...@gmail.com><mailto:shamik...@gmail.com
<mailto:shamik...@gmail.com>>>
Date: Fri, Sep 22, 2017 at 3:45 PM
Subject: Fwd: [Wien] how to simulate the energy of Oxygen molecule
To: A Mailing list for WIEN2k users
mailto:wien@zeus.theochem.tuwien.ac.at><mailto:wien@zeus.theochem.tuwien.ac.at
<mailto:wien@zeus.theochem.tuwien.ac.at>>>



-- Forwarded message --
From: shamik chakrabarti mailto:shamik...@gmail.com><mailto:shamik...@gmail.com
<mailto:shamik...@gmail.com>>>
Date: Fri, Sep 22, 2017 at 3:42 PM
Subject: Re: [Wien] how to simulate the energy of Oxygen molecule
To: A Mailing list for WIEN2k users
mailto:wien@zeus.theochem.tuwien.ac.at><mailto:wien@zeus.theochem.tuwien.ac.at
<mailto:wien@zeus.theochem.tuwien.ac.at>>>


Dear Gavin,

             Thank you for your response. By following the advice
given in the link, I have prepared the O2 cell. I am sending the
struct file & the image (generated in vesta) of the structure
herewith this mail. I have replace z by 1.208/2 where 1.208 is the
bond length of O2 (O-O distance) molecule. Please look at the
    structure & advice if the structure is correct or not.

with regards,

On Fri, Sep 22, 2017 at 1:18 PM, Gavin Abo mailto:gs...@crimson.ua.edu><mailto:gs...@crimson.ua.edu
<mailto:gs...@crimson.ua.edu>>> wrote:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000880.html
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000880.html>
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000882.html
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000882.html>


On 9/20/2017 4:44 AM, shamik chakrabarti wrote:
Dear wien2k users,

                        How to simulate the ground state energy of
Oxygen molecule (O2) in wien2k?..We can create a 20 Angstorm unit
cell & put an oxygen atom at the centre, but then in which
position another oxygen atom can sit?

Thanks in advance.

with regards,

--
Dr. Shamik Chakrabarti
Post Doctoral Research Associate
Dept. of Condensed Matter Physics and  Material Science
S N Bose National Centre for Basic Sciences
Kolkata-700098
INDIA

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

<mailto:Wien@zeus.theochem.tuwien.ac.at><mailto:Wien@zeus.theochem.tuwien.ac.at
<mailto:Wien@zeus.theochem.tuwien.ac.at>>
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
<http:

Re: [Wien] hmsec.F:(.text+0x3057): undefined reference to `pzheevr_'

[Gavin Abo]

composer_xe_2013.1.117 => This is update 1 of the 2013 composer xe [ 
https://software.intel.com/en-us/articles/intel-fortran-composer-xe-2013-release-notes 
].


The MKL 11.0 update 2 release notes [ 
https://software.intel.com/en-us/articles/intel-mkl-110-release-notes ] has:


ScaLAPACK

Updated version to 2.0.2. New functions introduced include:

P?SYEVR/P?HEEVR: MRRR (Multiple Relatively Robust Representations) algorithm

This seems to indicate that your ifort/mkl version is barely too old.  
It looks like update 2 of the 2013 composer xe or a newer version of the 
ifort/mkl is needed to be able to use the pzheevr function [ 
http://scc.ustc.edu.cn/zlsc/tc4600/intel/2015.1.133/mkl/mklman/GUID-B5DEF9B1-C3B5-4D24-A776-744D282039CA.htm 
].


Please note: There are cases, where the old Scalapack diagonalization 
fails." => This strongly suggests that the best solution is to upgrade 
to a newer version of the Intel Fortran compiler and mkl.


If you compare hmsec.F from WIEN2k 14 and 16.1 (using a program like 
WinMerge [ http://winmerge.org/ ]), you can clearly see that you most 
likely should not use the 14 version of the file in 16.1.


The hmsec.F that is in the hmsec.F.gz file is the replacement file for 
WIEN2k 16.1, which is in Prof. Blaha's post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15213.html

This file seems to be identical to the one in WIEN2k 17.1  So, you could 
also instead copy the file from WIEN2k 17.1 to 16.1, or better yet 
should be to just use WIEN2k 17.1


As was previously described, the -Dold_scalapack has to be added to the 
parallel options (FPOPT) in 16.1 with the replacement file or in 17.1 if 
a ifort/mkl version  2013.1.117 or older is used.


On 9/28/2017 2:25 PM, Dr. K. C. Bhamu wrote:

A temperately solution what I see is:

If I copy below files/modules from Wien2k_14 (not from Wien2k_16) into 
respective SRC dir and compiles I see not error or warning.


Could you please confirm whether this is fine or I should not do this? 
If I should avoid this then I am waiting for your advice for a 
possible solution.


*lapw1*:


seclr4.* .

lapw1_mpi


*lapwso:*

hmsec.* .

lapwso_mpi


Regards
Bhamu



On Thu, Sep 28, 2017 at 11:08 PM, Dr. K. C. Bhamu > wrote:


Dear Prof. Peter,
Below warning message is already mentioned in the mailing list
some time ago and I tried all possibilities but I could not fix it.

In one of the link you advised :

"The attached hmsec.F for lapwso contains the old and new
Scalapack routines.

Add -Dold_scalapack to the parallel compiler options.

Please note: There are cases, where the old Scalapack
diagonalization fails."





hmsec.o: In function `hmsec_':
hmsec.F:(.text+0x3057): undefined reference to `pzheevr_'
hmsec.F:(.text+0x37b0): undefined reference to `pzheevr_'


Its Intel Xeon Phi coprocessors based cluster and mkl is
composer_xe_2013.1.117 with mpiifort and miicc


Could you please tell me how to overcome below issue?

Kind regards
Bhamu

___
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] hmsec.F:(.text+0x3057): undefined reference to `pzheevr_'

[Gavin Abo]

I'm able to reproduce your new compile.msg errors below from hmsec.F in 
WIEN2k 17.1 with the -Dold_scalapack switch.


This seems to be because the & (continue line feed) symbol is missing on 
line 723 and 756. There also might be too many spaces in line 724.


Try placing that attached patch file (hmsec.patch) into the SRC_lapwso 
directory of WIEN2k 17.1, then while in that directory in a terminal run:


patch -b hmsec.F hmsec.patch

Then, do a recompile in siteconfig, it should remove those errors.

Note: I get some other errors (from 'parallel_mp_init_parallel_') after 
those, but hopefully it is just on my system only as my blacs for 
parallel is apparently not currently setup correctly.


SRC_lapwso/compile.msg:
...
mpiifort -O1 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML 
-Dold_scalapack -traceback -assume buffered_io 
-I/opt/intel/composer_xe_2013.1.117/mkl/include -DParallel -c hmsec.F
hmsec.F(723): error #5082: Syntax error, found END-OF-STATEMENT when 
expecting one of: ( * ) :: ,   
  ...

   abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec,
--^
hmsec.F(724): error #5276: Unbalanced parentheses
   pWORK1,ipLWORK, pRWORK1, ipLRWORK,pIWORK1,ipLIWORK, 
pIFAIL,pICLUSTR,pGAP,INFO)

---^
hmsec.F(756): error #5082: Syntax error, found END-OF-STATEMENT when 
expecting one of: ( * ) :: ,   
  ...

 abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec,
^
hmsec.F(757): error #5276: Unbalanced parentheses
pWORK,pLWORK,pRWORK,pLRWORK,pIWORK,pLIWORK,pIFAIL,pICLUSTR,pGAP,INFO)
-^
...

On 9/29/2017 4:29 AM, Dr. K. C. Bhamu wrote:

Dear Gavin

Thanks for you detailed advice. Unfortunetly is could not solve the issue,

What I did is I added  "-pthread" to linker's option and I do not see 
any warning/error message.

Hope it should be fine.


regards
Bhamu
723,724c723,724
abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec, &
>pWORK1,ipLWORK, pRWORK1, 
> ipLRWORK,pIWORK1,ipLIWORK,pIFAIL,pICLUSTR,pGAP,INFO)
756c756
<  abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec,
---
>  abstol,neig,pNZ_vec,en,porfac,vec,1,1,DESC_vec, &
___
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] Electron density plot in 111&110 plane.

[Gavin Abo]

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08516.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08572.html

On 10/3/2017 3:14 AM, Krishnaveni. S wrote:

Dear Wien 2k users.
I am working on Heusler alloys.To plot electron density for 100 plane 
is given user guide.Without using X_Crysden,how to change case.in5 
file to plot electron density for 110,&111plane.

Thanks all in advance.

___
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] mixer error with gfortran

[Gavin Abo]

It looks like you are using WIEN2k 14.2.  Do you have the mixer write 
patch applied:



https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13760.html


There might have been other bugs too [ 
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].  Have you tried a 
new WIEN2k version?  The new version might have a code fix.



On 10/4/2017 8:17 AM, Md. Fhokrul Islam wrote:


Hi Marks,


Thanks you for your reply. I did check 
Tic.scf1up/dn,  TiC.scf2up/dn and TiC.lapwso files but all of these


files look ok. There is no error. Only error message I got in 
TiC.dayfile that I mentioned earlier:



Last three line of TiC.dayfile:


>   lcore -dn   (15:43:38) 0.017u 0.003s 0:00.13 7.6%   0+0k 0+264io 0pf+0w

>   mixer       (15:43:38) 0.037u 0.007s 0:00.13 23.0% 0+0k 0+32io 0pf+0w
error: command   /bionano2/Wien2k14.2/mixer mixer.def  failed

As I mentioned earlier it occurs only when I do spin-orbit calculation.



Thanks,

Fhokrul




*From:* Wien  on behalf of 
Laurence Marks 

*Sent:* Wednesday, October 4, 2017 11:38 AM
*To:* A Mailing list for WIEN2k users
*Subject:* Re: [Wien] mixer error with gfortran
Normally this means that one of the other programs (lapwso, lapw2 etc) 
crashed. Please check the *.error files & *.dayfile


---
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what 
nobody else has thought", Albert Szent-Gyorgi

http://www.numis.northwestern.edu
Marks Group 
www.numis.northwestern.edu
The Marks Research Group. Welcome to the Marks Research Group. We work 
on a wide range of different topics involving nanoscale materials, 
combining advanced ...




Corrosion in 4D http://MURI4D.numis.northwestern.edu 




Understanding Corrosion in 4D 
muri4d.numis.northwestern.edu
HOME Vision; Foci. NiAl Alloys; MoSi Alloys; Aqueous Corrosion; Tools. 
Atomic 3D Tomography; In-Situ Microscopy; Multiscale Computation; 
Scanning Probe; Pico Scale ...




Partner of the CFW 100% gender equity project, www.cfw.org/100-percent 

100 Percent Project - Chicago Foundation for Women 


www.cfw.org
The 100% Project About a year ago, we began a series of conversations 
with Chicagoans from every walk of life—women and men, young and old, …




Co-Editor, Acta Cryst A

On Oct 4, 2017 06:36, "Md. Fhokrul Islam" > wrote:


Hi Wien2k users,


I am trying to do TiC calculation as mentioned in the userguide
with Wien2k compiled with gfortran.

It works fine without spin-orbit (SO) coupling but if I add SO it
crashes in the 1st cycle with 'mixer error'.


error: command  /bionano2/Wien2k14.2/mixer mixer.def   failed


There is no other error message or error file. However, if I
do the same TiC calculation in another

machine with an intel compiled Wien2k, this problem does not
arise. So I am not sure why there

is a mixer error with gfortran for TiC when I do spin-orbit
calculation.


I tried another test calculation with GaAs but this one works fine
with gfortran.


Any suggestion will be appreciated.



Thanks,

Fhokrul

___
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] Optical properties with SO coupling

[Gavin Abo]

Dear Jaro,

I thought the spin-polarized SO optic normalization was broken in older 
versions of WIEN2k and was fixed in 17.1:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html

Is it still broken?

Kind Regards,

Gavin

On 10/3/2017 4:30 PM, Jaroslav Hamrle wrote:

Hallo,

to calculate optical properties of Ni, after calculating electronic 
structure being spin-polarized and being with spin-orbit, do:


1) create both case.inop (your file looks correct) and case.injoint

Example of case.injoint is:
 example of case.injoint ===
    1     : LOWER,UPPER and (optional) UPPER-VAL 
BANDINDEX

   0.    0.00100   1. : EMIN DE EMAX FOR ENERGYGRID IN ryd
eV    : output units  eV / ryd  / cm-1
 4    : SWITCH
 9    : NUMBER OF COLUMNS
   0.1  0.1  0.3  : BROADENING (FOR DRUDE MODEL - switch 
6,7 -

ONLY)

SWITCH:

   0...JOINTDOS FOR EACH BAND COMBINATION
   1...JOINTDOS AS SUM OVER ALL BAND COMBINATIONS
   2...DOS FOR EACH BAND
   3...DOS AS SUM OVER ALL BANDS
   4...Im(EPSILON)
   5...Im(EPSILON) for each band combination
   6...INTRABAND contributions
   7...INTRABAND contributions including band analysis
= end example case.injoint 

Now, you have to decide if you want to calculate optics at finer 
k-mesh than electronic structure, or the same mesh. In case electronic 
structure is calculated with k-mesh 30x30x30, it is good enough for 
Imxy and MOKE.


2a) when keeping the same k-mesh for optical calculations as for 
electronic structure, do:


  x lapw2 -p -fermi -up -so
  x optic -p -up -so   (your command in your email is opticc, i.e. 
complex variant of command optic; opticc should be used when the 
structure lacks point symmetry, which Ni does not)

  x joint -up
  x kram -up

2b) when you want mesh for optical calculations to be finer, do:
  x kgen -so (to generate finer mesh)
  in third line in case.in2, change value of TETRA to be 101
  x lapw1 -p -up
  x lapw1 -p -dn
  x lapwso -up -p
  x lapw2 -p -fermi -up -so
  x optic -so -up -p
  x joint -up -p
  x kram -up


3) When using w2k version 17.1, there is a bug in the function joint 
when electronic structure is spin-polarized case with so. In this 
case, all optical constant outgoing function joint have half values 
for w2k ver 17.1 compared to previous w2k versions. So either use w2k 
version 16.1 or smaller, or with w2k version 17.1, simply multiply all 
optical constants by factor 2.


Hoping it helps
Best regards

Jaro
___
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] Installation problem

[Gavin Abo]

Below in your post, you have:

-L../SRC_lib  -lopenblas -llapack

Looking at the following post:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15090.html

It looks like you need:

-L../SRC_lib -llapack_lapw -L/opt/OpenBLAS/lib -lopenblas

On 10/3/2017 3:03 AM, Rajneesh Chaurasiya wrote:

Dear Sir,

I choose the compiler (gfortran compiler+openblas) and then compiler 
and linker options (R_LIB) i used -lopenblas -llapack -lpthread. but 
still found the similar error as previous one.

i don't have system admin but also i don't have root password of cluster.

4.o vxc26.o vxclm2.o vxcpw2.o vxi35.o vxi35a.o vx_screened.o wc05.o 
workf1.o W2kutils.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o ylm.o 
-ffree-form -O2 -ffree-line-length-none -L../SRC_lib  -lopenblas 
-llapack -lpthread

/usr/bin/ld: cannot find -llapack
collect2: ld returned 1 exit status
make[1]: *** [lapw0] Error 1
make[1]: Leaving directory 
`/home/IITJHOME/faculty/phy/ambeshst/software/Wien2k/SRC_lapw0'

make: *** [seq] Error 2
make: Warning: File `Makefile' has modification time 1e+05 s in the future
make: *** No rule to make target `complex'.  Stop.
Copying programs
WARNING: no executable found in SRC_lapw0. Check compile.msg in this 
directory


done.

Compile time errors (if any) were:
make[1]: *** [lapw0] Error 1
make: *** [seq] Error 2
grep: No match.
grep: No match.

___
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] LAPWDM crashed - forrtl: severe (39): error during read, unit 9, file .../.vectorup

[Gavin Abo]

Try a different ifort compiler version or a different compiler (such as 
gfortran).  That error is likely to be caused by a bug in the version of 
the compiler that you are using:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14923.html

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15459.html

On 10/4/2017 7:09 AM, Rui Mario da Silva Costa wrote:


Dear WIEN2k users,

I am trying to do an AFM GGA+U simulation on GdMnO3, for this I 
created a supercell to define the up and down spins and every time I 
run the simulation with U, it crashes in the first cycle with the 
message "forrtl: severe (39): error during read, unit 9, file 
(...)/case.vectorup" and the .dayfile says "LAPWDM crashed".


I tried doing the simulations in serial and parallel mode but both 
give the same error and without the "-orb" option the simulation runs 
fine. Also, if I try to do a ferromagnetic simulation in the original 
structure (i.e., no supercell) with U, the simulation runs fine as well.


I am running WIEN2k_14.2 and have the 2016.3.210 ifort version.

*1) Output error*

forrtl: severe (39): error during read, unit 9, file 
/home/meu-pc/WIEN2k/GdMnO3_AFM/./GdMnO3_AFM.vectorup_1

Image PC Routine Line Source
lapwdmc 0042D1F3 Unknown Unknown Unknown
lapwdmc 0044A634 Unknown Unknown Unknown
lapwdmc 0040F170 l2main_ 141 l2main_tmp.f
lapwdmc 004146CC MAIN__ 267 lapwdm.f
lapwdmc 00402F1E Unknown Unknown Unknown
libc.so.6 2B216F519F45 Unknown Unknown Unknown
lapwdmc 00402E29 Unknown Unknown Unknown

forrtl: severe (39): error during read, unit 9, file 
/home/meu-pc/WIEN2k/GdMnO3_AFM/./GdMnO3_AFM.vectorup_2

(...)

forrtl: severe (39): error during read, unit 9, file 
/home/meu-pc/WIEN2k/GdMnO3_AFM/./GdMnO3_AFM.vectorup_3

(...)

forrtl: severe (39): error during read, unit 9, file 
/home/meu-pc/WIEN2k/GdMnO3_AFM/./GdMnO3_AFM.vectorup_4

(...)

forrtl: severe (39): error during read, unit 9, file 
/home/meu-pc/WIEN2k/GdMnO3_AFM/./GdMnO3_AFM.vectorup_5

(...)

*2) .dayfile*

start (Wed Oct 4 11:46:56 WEST 2017) with lapw0 (40/99 to go)
cycle 1 (Wed Oct 4 11:46:56 WEST 2017) (40/99 to go)
(...)
> lapw2 -dn -p -c -orb (11:53:37) running LAPW2 in parallel mode
localhost 11.0u 0.4s 0:11.86 97.2% 0+0k 8+80808io 0pf+0w
localhost 10.9u 0.4s 0:11.45 99.3% 0+0k 0+70680io 0pf+0w
localhost 11.0u 0.3s 0:11.94 95.3% 0+0k 0+70680io 0pf+0w
localhost 10.9u 0.4s 0:11.55 98.6% 0+0k 0+70680io 0pf+0w
localhost 5.1u 0.1s 0:05.28 99.2% 0+0k 8+70680io 0pf+0w
Summary of lapw2para:
localhost user=48.9 wallclock=52.08
52.1u 1.9s 0:21.79 248.3% 0+0k 24+436080io 0pf+0w
> lapwdm -up -p -c (11:53:59) running LAPWDM in parallel mode
** LAPWDM crashed!
0.0u 0.0s 0:06.37 1.8% 0+0k 0+880io 0pf+0w
error: command /home/meu-pc/Programs/WIEN2k/WIEN2k_14.2/lapwdmcpara 
-up -c uplapwdm.def failed


> stop error

*3) uplapwdm_x.error files, x=1,2,3,4,5*

Error in LAPW2DM

*4) uplapwdm.error file*

**  Error in Parallel LAPWDM

*5) ls -alsrt *vector**

165624 -rw-r--r-- 1 meu-pc meu-pc 169595850 Oct 4 11:05 
GdMnO3_AFM.vectorup
165628 -rw-r--r-- 1 meu-pc meu-pc 169596218 Oct 4 11:11 
GdMnO3_AFM.vectordn
36824 -rw-r--r-- 1 meu-pc meu-pc 37705040 Oct 4 11:49 
GdMnO3_AFM.vectorup_2
36824 -rw-r--r-- 1 meu-pc meu-pc 37705040 Oct 4 11:49 
GdMnO3_AFM.vectorup_4
36700 -rw-r--r-- 1 meu-pc meu-pc 37580076 Oct 4 11:49 
GdMnO3_AFM.vectorup_1
36672 -rw-r--r-- 1 meu-pc meu-pc 37551036 Oct 4 11:49 
GdMnO3_AFM.vectorup_3
18548 -rw-r--r-- 1 meu-pc meu-pc 18989834 Oct 4 11:50 
GdMnO3_AFM.vectorup_5
36824 -rw-r--r-- 1 meu-pc meu-pc 37704960 Oct 4 11:52 
GdMnO3_AFM.vectordn_4
36652 -rw-r--r-- 1 meu-pc meu-pc 37530544 Oct 4 11:52 
GdMnO3_AFM.vectordn_1
36672 -rw-r--r-- 1 meu-pc meu-pc 37551036 Oct 4 11:52 
GdMnO3_AFM.vectordn_3
36824 -rw-r--r-- 1 meu-pc meu-pc 37704960 Oct 4 11:52 
GdMnO3_AFM.vectordn_2
18548 -rw-r--r-- 1 meu-pc meu-pc 18989834 Oct 4 11:53 
GdMnO3_AFM.vectordn_5


I found that the 14.2 WIEN2k version gave an error in LAPW2DM and that 
it has a patch 
(https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12595.html) 
but that was for simulations with spin-orbit, which mine do not have. 
Does this have anything to do with my error, if not, what can I do to 
fix this?


Thank you for your help.

Best regards,
Rui Costa.

___
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] Optical properties with SO coupling

[Gavin Abo]

Ok, probably we have to wait until Prof. Blaha can have a look at it.

In the post for the spin-polarized case, it looks like only opmain.f was 
corrected:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html

Maybe this only fixed the sqrt(2) in the plasma frequency, but the 
factor of 2 may be missing as you report.


In the post for the non-spin polarized case, it looks like joint.f may 
be where it was corrected with a factor of 2:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15724.html

On 10/5/2017 1:57 AM, Jaroslav Hamrle wrote:

Dear Gavin,

I will describe my observation:
I have calculated optical (epzz) and magneto-optical (K, for example 
K=epxy for M001) spectra of permittivity elements for bcc Fe.
The electronic structure calculations are spin polarized, with 
spin-orbit, run by commands:


runsp_lapw -p
runsp_lapw -p -so -cc 0.01 -ec 0.001 -s lapw1
x lapw2 -p -fermi -up -so
x optic -p -up -so
x joint -p -up

For w2k version 16.1, the calculated spectra corresponds to the 
experimental spectra (for both epzz and K).
For w2k version 17.1, the calculated spectra are half-value for both 
epzz and K, compared to the experiment.


Figures comparing spectra are here:

http://alma.karlov.mff.cuni.cz/hamrle/w2kfig/Fe_Imepzz_compare.pdf
http://alma.karlov.mff.cuni.cz/hamrle/w2kfig/Fe_ReK_compare.pdf

In this example, I used permittivity spectra read directly from 
case.jointup files (I do not use output of kram).

In the figures:
  - solid (noisy) line is output from case.jointup
  - the symbols are smeared spectra
  - black '+' are the experimental spectra
  - blue 'o' and red 'x' are spectra calculated by w2k version 17
  - green '+' and yellow '*' are spectra calculated by w2k version 16
  - y-axis denotes permittivity*E (in eV).

That is why I have concluded that joint function in w2k version 17 has 
a bug in calculation of the optical permittivity. But I have not 
tested non-magnetic cases, I did it only for bcc Fe (sp+so).


Hoping it helps.
If I can help more, please let me know..

With my regards

Jaro



On 04/10/17 16:40, Gavin Abo wrote:


Dear Jaro,

I thought the spin-polarized SO optic normalization was broken in 
older versions of WIEN2k and was fixed in 17.1:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html

Is it still broken?

Kind Regards,

Gavin

On 10/3/2017 4:30 PM, Jaroslav Hamrle wrote:

Hallo,

to calculate optical properties of Ni, after calculating electronic 
structure being spin-polarized and being with spin-orbit, do:


1) create both case.inop (your file looks correct) and case.injoint

Example of case.injoint is:
 example of case.injoint ===
    1     : LOWER,UPPER and (optional) UPPER-VAL 
BANDINDEX

   0.    0.00100   1. : EMIN DE EMAX FOR ENERGYGRID IN ryd
eV    : output units  eV / ryd  / cm-1
 4    : SWITCH
 9    : NUMBER OF COLUMNS
   0.1  0.1  0.3  : BROADENING (FOR DRUDE MODEL - switch 
6,7 -

ONLY)

SWITCH:

   0...JOINTDOS FOR EACH BAND COMBINATION
   1...JOINTDOS AS SUM OVER ALL BAND COMBINATIONS
   2...DOS FOR EACH BAND
   3...DOS AS SUM OVER ALL BANDS
   4...Im(EPSILON)
   5...Im(EPSILON) for each band combination
   6...INTRABAND contributions
   7...INTRABAND contributions including band analysis
= end example case.injoint 

Now, you have to decide if you want to calculate optics at finer 
k-mesh than electronic structure, or the same mesh. In case 
electronic structure is calculated with k-mesh 30x30x30, it is good 
enough for Imxy and MOKE.


2a) when keeping the same k-mesh for optical calculations as for 
electronic structure, do:


  x lapw2 -p -fermi -up -so
  x optic -p -up -so   (your command in your email is opticc,  i.e. 
complex variant of command optic; opticc should be used when the 
structure lacks point symmetry, which Ni does not)

  x joint -up
  x kram -up

2b) when you want mesh for optical calculations to be finer, do:
  x kgen -so (to generate finer mesh)
  in third line in case.in2, change value of TETRA to be 101
  x lapw1 -p -up
  x lapw1 -p -dn
  x lapwso -up -p
  x lapw2 -p -fermi -up -so
  x optic -so -up -p
  x joint -up -p
  x kram -up


3) When using w2k version 17.1, there is a bug in the function joint 
when electronic structure is spin-polarized case with so. In this 
case, all optical constant outgoing function joint have half values 
for w2k ver 17.1 compared to previous w2k versions. So either use 
w2k version 16.1 or smaller, or with w2k version 17.1, simply 
multiply all optical constants by factor 2.


Hoping it helps
Best regards

Jaro



___
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-arch

Re: [Wien] Primitive Brillouin zone of Monoclinic base-centered structure

[Gavin Abo]

I don't know if it helps or not:

I could be wrong, but I believe XCrySDen has a bug for the b-centered 
monoclinic:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06205.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12479.html

However, I haven't looked into it further.

The "International Tables for Crystallography" [ 
http://dx.doi.org/10.1107/9780955360206001 ] likely contains a 
transformation (rotation matrix) that you could use, but I don't know 
what volume or page it would be on.  Maybe it is in "Part 5. 
Transformations in crystallography" of Volume A [ 
http://it.iucr.org/Ab/contents/ ].


On 10/5/2017 5:01 AM, Marcelo Barbosa wrote:

Dear Sirs,

I tried the following solution to my problem but it seems that 
changing the space group to P1 makes the Primitive Brillouin Zone to 
be equal to the Conventional Brillouin zone.
However, for a base-centered monoclinic structure, they are not equal 
and to get the right band structure one must use the Primitive 
Brillouin zone high symmetry points (as have been shown in 
https://doi.org/10.1016/j.commatsci.2010.05.010).


In that article, they have a table with all the symmetry points for a 
base-centered monoclinic structure.
Unfortunately, they consider the lattice vectors with alpha < 90º 
instead of the gamma != 90º required by WIEN2k.

How can I transform those points from one representation to another?
And if I can calculate those points, can I manually choose them in 
XCrysden to generate the klist file instead of choosing them from the 
3D image (since the image is wrong)?


Best regards,
Marcelo

On 22 Sep 2017, at 19:09, Yundi Quan > wrote:


It happens sometimes. One possible workaround is to set the space 
group to P1 and use the same a, b, c, alpha, beta and gamma. That way 
you can select k-points and use the for C2/m structure.


On Fri, Sep 22, 2017 at 4:00 AM, Marcelo Barbosa 
mailto:marcelo.b.barb...@gmail.com>> wrote:


Dear Sirs,

I’m trying to get the Brillouin zone and high-symmetry points of
Ga2O3, which has a monoclinic base-centered lattice.
However, after plotting it using XCrysDen, one of the vectors
(b*) doesn’t go through the center of any plane in the Brillouin
zone (see figure in attachment).
Since the Brillouin zone is defined has the Wigner-Seitz cell of
the reciprocal lattice, shouldn’t all the reciprocal vectors go
through the center of the planes by definition?

To generate the structure, I used the following .cif file (CIF
) but since the
parameters in the file are in the C 2/m representation, I started
by running "x sgroup” to get the structure with the parameters in
the B 2/m representation (as WIEN2k requires).

Thank you for your help.

Best regards,
Marcelo



___
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] Optical properties with SO coupling

[Gavin Abo]

FYI, if I remember correctly, addjoint is not used with SO for optic:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07551.html

I don't see "x lapwso -up" in your steps below.  Maybe that is needed:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12365.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16054.html

On 10/5/2017 7:14 AM, Fecher, Gerhard wrote:

Hi Jaroslav,
if you check only case.jointup it has possibly only half the value because the 
other half is supposed to be in case.jointdn
(with SO they should be the same)

Did you try to copy case.jointup to case.jointdn (or run in addition everything 
for dn)
and then addjoint
then the factor 2 is included in the case.joint

The problem with spinpolarisation and SO is that case.jointup is the only 
necessary and produced, however, kram expects that case.joint exists
that's why one has to do the copy by hand (not rename, then the factor 2 will 
be missing, again !)
(one might also run optic and joint both in addition for dn, before addjoint)

Indeed, it would be nice if this behaviopur could be changed (maybe by some 
switch(es) to kram : e.g.: -so -up)




Just for curiosity, I wonder whether and how crossterms are respected, the 
selcction rules on the total angular momentum j' = j, j+-1 together with those 
on the magnetic quantum number mj
allow spin flip transitions even though the dipole operator does not act on the 
spin !

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Jaroslav 
Hamrle [ham...@karlov.mff.cuni.cz]
Gesendet: Donnerstag, 5. Oktober 2017 09:57
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] Optical properties with SO coupling

Dear Gavin,

I will describe my observation:
I have calculated optical (epzz) and magneto-optical (K, for example K=epxy for 
M001) spectra of permittivity elements for bcc Fe.
The electronic structure calculations are spin polarized, with spin-orbit, run 
by commands:

runsp_lapw -p
runsp_lapw -p -so -cc 0.01 -ec 0.001 -s lapw1
x lapw2 -p -fermi -up -so
x optic -p -up -so
x joint -p -up

For w2k version 16.1, the calculated spectra corresponds to the experimental 
spectra (for both epzz and K).
For w2k version 17.1, the calculated spectra are half-value for both epzz and 
K, compared to the experiment.

Figures comparing spectra are here:

http://alma.karlov.mff.cuni.cz/hamrle/w2kfig/Fe_Imepzz_compare.pdf
http://alma.karlov.mff.cuni.cz/hamrle/w2kfig/Fe_ReK_compare.pdf

In this example, I used permittivity spectra read directly from case.jointup 
files (I do not use output of kram).
In the figures:
   - solid (noisy) line is output from case.jointup
   - the symbols are smeared spectra
   - black '+' are the experimental spectra
   - blue 'o' and red 'x' are spectra calculated by w2k version 17
   - green '+' and yellow '*' are spectra calculated by w2k version 16
   - y-axis denotes permittivity*E (in eV).

That is why I have concluded that joint function in w2k version 17 has a bug in 
calculation of the optical permittivity. But I have not tested non-magnetic 
cases, I did it only for bcc Fe (sp+so).

Hoping it helps.
If I can help more, please let me know..

With my regards

Jaro



On 04/10/17 16:40, Gavin Abo wrote:

Dear Jaro,

I thought the spin-polarized SO optic normalization was broken in older 
versions of WIEN2k and was fixed in 17.1:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html

Is it still broken?

Kind Regards,

Gavin

On 10/3/2017 4:30 PM, Jaroslav Hamrle wrote:
Hallo,

to calculate optical properties of Ni, after calculating electronic structure 
being spin-polarized and being with spin-orbit, do:

1) create both case.inop (your file looks correct) and case.injoint

Example of case.injoint is:
 example of case.injoint ===
 1     : LOWER,UPPER and (optional) UPPER-VAL BANDINDEX
0.0.00100   1. : EMIN DE EMAX FOR ENERGYGRID IN ryd
eV: output units  eV / ryd  / cm-1
  4: SWITCH
  9: NUMBER OF COLUMNS
0.1  0.1  0.3  : BROADENING (FOR DRUDE MODEL - switch 6,7 -
ONLY)

SWITCH:

0...JOINTDOS FOR EACH BAND COMBINATION
1...JOINTDOS AS SUM OVER ALL BAND COMBINATIONS
2...DOS FOR EACH BAND
3...DOS AS SUM OVER ALL BANDS
4...Im(EPSILON)
5...Im(EPSILON) for each band combination
6...INTR

Re: [Wien] Optical properties with SO coupling

[Gavin Abo]

Ok, your suggestion sounds good to me.

The WIEN2k 17.1 usersguide [1] states on page 177 in section "8.17 OPTIC 
(calculating optical properties)":


"In spin-polarized cases with spin-orbit only one call to optic, joint 
and/or kram (either up or down) is necessary, since the spins are not 
independent any more and both vector-files are used at the same time."


Unless something has changed [2], if I understand the above statement 
correctly, only the "x kram -up" should be used to use case.jointup for 
the spin-polarized SO case (similar to point 2 marked below in your 
post).  So it may be that this type of calculation is a more recent 
enhancement to the w2web interface (i.e., previous could only be done in 
the terminal only or with the 'single program' feature in w2web), such 
that it might be missing the "-up" for the kram step.


[1] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11186.html


On 10/5/2017 10:19 AM, Fecher, Gerhard wrote:

Hallo Gavin,
kram is looking for case.joint, but with spinpolarized SO you create only 
case.jointup, this was my main concern !

my suggestion was to create something like x joint -up -so or kram -up -so such 
that
  either joint creates with spinpolarized SO the case.joint
  or (point 2) kram uses the case.jointup in case of spinpolarized SO 
calculations

In spinpolarized cases one has to use addjoint otherwise one has no case.joint, 
(it seems this happens independent whether one uses SO or not)
or one has to play other tricks.
I just mentioned that this may tell you probably why there is a factor of 2 
difference in the results.

Note: I checked only with W2WEB not with the command line as I am not at my 
Linux computer


Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

___
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] Optical properties with SO coupling

[Gavin Abo]

First, WIEN2k 14.1 is expected to essentially give incorrect results for 
optical property calculations (because the normalization was not 
correct).  Thus, the bug reports:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15724.html

Thus, to use the corrected code, you would have to use WIEN2k 17.1. 
However, there seems to still be a slight bug in WIEN2k 17.1 with just a 
spin-polarized SO optic calculation as was recently discussed (where the 
results are off by a factor of 2):


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16524.html

Second, see section "5.10.12 addjoint-updn_lapw" of the WIEN2k 17.1 
usersguide on page 102.  It states there that this is only used with a 
spin-polarized calculation (runsp_lapw) when it says:


"It should be called for spin-polarized optics calculations ..."

So, you don't use it with a non-spin polarized calculation (run_lapw).

The addjoint-updn_lapw is also not used with SO calculations [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07551.html 
]:


run_lapw -so
runsp_lapw -so

I suggest that you read the post about how Imag(epsilon) can be plotted 
separately, but not the Real(epsilon):


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12116.html

On 10/6/2017 11:34 PM, lokanath patra wrote:

So what I understood is:
If I want to calculate the total optical properties of the compound, I 
have to run addjoint_updn -lapw then I should proceed with x kram.
If I want to calculate the spin resolved optical properties, then I 
have to run x joint -up/dn and then x kram -up/dn. No need to run 
addjoint_updn -lapw.

(I am using Wien2k version 14.1)

Correct me if I am wrong.

Regards,
Lokanath.

___
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] COOP

[Gavin Abo]

You may want to contact Prof. Dronskowski's group and ask if they are 
doing any development of the COHP/COOP LOBSTER program for WIEN2k.  As 
it says "Other codes may follow…" on their website:


http://schmeling.ac.rwth-aachen.de/cohp/

If you are good at programming, you may want to ask them what VASP files 
are needed as input to their LOBSTER program.


If it doesn't require much data as input, maybe you can write your own 
program to extract any needed information from the WIEN2k files and 
write out the VASP files that LOBSTER needs or search the internet to 
see if you can find any conversion tools/programs/scripts that can help 
with that.


VESTA [ http://jp-minerals.org/vesta/en/ ] should be able to convert the 
WIEN2k case.struct file to the VASP POSCAR (or case.vasp).


Attached is my wien2chgcar script.  It is not well tested.  So use it 
cautiously.


In a terminal, this perl script is ran with:

wien2chgcar case.vasp case.rho3d >> CHGCAR

The script needs two files as input:

1. case.vasp: This is from the case.struct conversion using VESTA
2. case.rho3d: This is the file created by the wien2venus.py script [ 
http://www.nims.go.jp/cmsc/staff/arai/wien/venus.html ]


The script outputs a VASP file: CHGCAR

The script was made to create the CHGCAR file just with the data needed 
as input for chgfilt, which converts CHGCAR to an OpenDx readable format 
[ https://hp.physnet.uni-hamburg.de/group_magno/sokatov/vasp.php ].


To help create wien2chgcar, I think I found the CHGCAR file format on 
the internet:


https://cms.mpi.univie.ac.at/vasp/vasp/CHGCAR_file.html
https://cms.mpi.univie.ac.at/vasp-forum/viewtopic.php?t=12631

If you need a description of the EIGENVAL file format for writing a 
code, it looks like it is described in the following VASP forum thread:


https://cms.mpi.univie.ac.at/vasp-forum/viewtopic.php?t=7

On 10/9/2017 5:08 AM, ben amara imen wrote:

Dear

I don't know whether or not wien2k can calculate COOP (Crystal Orbital 
Overlap Populations)?. Thanks
#!/usr/bin/perl
#
# Used to convert Wien2k data to VASP's CHGCAR file
#
# usage: wien2chgcar file.vasp file.rho3d
#
# output to stdout
#
# To redirect stdout to a file:
# wien2chgcar file.vasp file.rho3d >> CHGCAR_outfilename
#
#
#Requires case.vasp and case.rho3d
#case.rho3d is created with the wien2venus.py script
#case.struct is opened in VESTA and exported as case.vasp
#

#Reads case.vasp
open FILE1,$ARGV[0];
  $line1 = ;
  $line2 = ;
  $line3 = ;
  $line4 = ;
  $line5 = ;
  $line6 = ;
  @line7 = split(' ',);
  @linestofile1end = ;
close FILE1;

#Sums the number of atoms of each element to get the total number of atoms
$natoms=0;
foreach $i (@line7){
$natoms+=$i;
}

open FILE2,$ARGV[1];
  $line1f2 = ;
  $line2f2 = ;
  $line3f2 = ;
  @line4f2 = split(' ',);
  @linestofile2end = ;
close(FILE2);

#Combines case.vasp and case.rho3d to create CHGCAR_case
print $line1;
print $line2;
print $line3;
print $line4;
print $line5;
print '',$natoms,"\n";
print @linestofile1end,"\n";
print $line4f2[0],' ',$line4f2[1],' ',$line4f2[2],"\n";
print @linestofile2end;
___
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] Problem with prepare_xsf_lapw

[Gavin Abo]

I suspect that the LAPW0 error comes first before the case.rho_74 
error.  However, I could be wrong as I'm not that familiar with the 
nlvdw calculations.


It would help a little to know where those error appear.  The standard 
output/error file from the job?


R2V files not present, which are required for mBJ or NLvdW => I think 
this indicates that it cannot find the file case.r2v_nlvdw.


What does your case.innlvdw look like?  Do you have the "calculation of 
the potential (T or F)" line set to T.  If it set to T, I think it looks 
for case.r2v_nlvdw.  If you have it set, to F, it might look for 
case.r2v or case.r2v_grr instead.  If it cannot find this file, maybe it 
causes this error.


16  LAPW0-Error. Check file lapw0.error and case.output0*. => Did you 
check lapw0.error and case.output files as it says; any warning, error, 
or something odd (NaN, *, etc.) in them?


What about the case.dayfile?  Is there any "input conversion error" for 
case.r2v_nlvdw like in the post at the following link:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16383.html

On 10/10/2017 9:09 AM, Luigi Maduro - TNW wrote:


Dear WIEN2k users,

I am running WIEN2k 17.1 on Beowulf style clusters with a CentOS 7 
Linux system. I am using WIEN2k to get optical properties of MoS2 
using the non-local van der Waals functionals in WIEN2k 17.1.


I am using a 2x2x1 supercell with Rkmax=6.5 and 1 kpoint under the 
influence of the optB88-vdW functional. I have no problems when 
running the code in sequential mode.


Whenever I try to use parallel computation the code crashes. In order 
to manage jobs the clusters use the Torque (PBS implementation) queue 
manager. I have written a bash script (similar to the one in the FAQ 
page) to append the nodes in the .machines file. In the calculations I 
am using 1 node and 20 processors. Whenever I use the –nlvdw switch in 
the run_lapw command the script crashes. I get the following error:


Traceback (most recent call last):

  File "/home/WIEN2k_2/prepare_xsf_lapw", line 360, in 

    write_xsf_grid(xcrzeilen, gridmatrix)

  File "/home/WIEN2k_2/prepare_xsf_lapw", line 299, in write_xsf_grid

    rho = open(os.path.basename(os.getcwd())+".rho_"+str(i+1),"r")

IOError: [Errno 2] No such file or directory: 'case.rho_74'

NLVDW END (case.inxsf created)

[1] Done  mpirun -np 20 -machinefile 
.machinenlvdw /home/WIEN2k_2/nlvdw_mpi nlvdw.def >> .time00


Child with myid of   19 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  19  LAPW0-Error. Check file lapw0.error and case.output0*.

application called MPI_Abort(MPI_COMM_WORLD, 1714408384) - process 19

Child with myid of   16 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  16  LAPW0-Error. Check file lapw0.error and case.output0*.

Child with myid of   18 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  18  LAPW0-Error. Check file lapw0.error and case.output0*.

Child with myid of   12 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  12  LAPW0-Error. Check file lapw0.error and case.output0*.

Child with myid of   15 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  15  LAPW0-Error. Check file lapw0.error and case.output0*.

Child with myid of   17 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  17  LAPW0-Error. Check file lapw0.error and case.output0*.

Child with myid of   13 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  13  LAPW0-Error. Check file lapw0.error and case.output0*.

application called MPI_Abort(MPI_COMM_WORLD, -1249474368) - process 16

application called MPI_Abort(MPI_COMM_WORLD, -1730723776) - process 12

application called MPI_Abort(MPI_COMM_WORLD, 58291520) - process 18

Child with myid of   14 has an error

'LAPW0' - R2V files not present, which are required for mBJ or NLvdW

  14  LAPW0-Error. Check file lapw0.error and case.output0*.

I noticed that there is indeed no case.rho_74 file. Additionally the 
files case.tmp_74, case.output5_74, and case.rho_onedim_74 are missing.


However, the files case.def_74, case.in5_74 are in the directory where 
I am doing my calculation. I think there might be something missing in 
the prepare_xsf_lapw file, but I cannot seem to correct the problem. I 
cannot find anything related to the problems I  am having with 
prepare_xsf_lapw in the mailing list.


Any help is appreciated!
Regards,

Luigi Maduro

___
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] static linking of ifort-libraries

[Gavin Abo]

See the Intel MKL Link Line Advisor:

https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor

In the "Select dynamic or static linking" drop down box, you could 
select "Static" instead of "Dynamic".


On 10/10/2017 10:20 AM, Nacir GUECHI wrote:

Dear wien2k users,
I want to install wien2k-17 version with static linking of all 
libraries. so, how set *compiler options*, *Linker Flags*, 
*Preprocessor flags* and *R_LIBS (**LAPACK+BLAS*) ?

-
i used for dynamic compilation ifort and icc  (version 15) with the 
following settings:


*O   Compiler options*: -O1 -FR -mp1 -w -prec_div -pc80 -pad -ip 
-DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)/include

*L   Linker Flags*: $(FOPT) -L$(MKLROOT)/lib/$(MKL_TARGET_ARCH) -pthread
*P   Preprocessor flags* '-DParallel'
*R   R_LIBS (LAPACK+BLAS)*: -lmkl_lapack95_lp64 -lmkl_intel_lp64 
-lmkl_intel_thread -lmkl_core -openmp -lpthread

-

Best regards;
N. GUECHI
___
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] problem with MPI parallization of LAWP1: FERMI - Error

[Gavin Abo]

Your .machines file seems okay.


The error indicates that LAPW1 failed.  Other than that, the error 
message doesn't look much more helpful.



I'm guessing that is from the standard output/error file for the job.


What about the case.dayfile, *.error files, or hidden dot files [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15549.html 
], any additional error messages in them that would help indicate 
further why it failed?



You can search the mailing list archive [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/maillist.html 
] for the "orte_base_help_aggregate" or other keywords.



For example, perhaps lapw1_mpi was compiled with the wrong blacs library:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07254.html


On 10/11/2017 2:27 AM, saqib wrote:


Dear WIEN2K users,


I am currently trying to run a calculation for large organic molecule 
on WIEN 14.2. Due to nature of my system, K-point parallization is 
useless so I have to use MPI parallization.


I am using following .machines file to run on node 'fermi' with 4 cores:


lapw0:fermi:4
1:fermi:4
granularity:1
extrafine:1

While lapw0 runs without any problem, LAPW1/LAPW2 crashes with 
following message:

.
.
[fermi:119828] 3 more processes have sent help message 
help-mpi-api.txt / mpi-abort
[fermi:119828] Set MCA parameter "orte_base_help_aggregate" to 0 to 
see all help / error messages

mptest.scf1_1: No such file or directory.
grep: *scf1*: No such file or directory
FERMI - Error
cp: cannot stat `.in.tmp': No such file or directory

The same calculation runs without any problem for a single core. I 
will really appreciate if someone can help me resolve this issue.


with best regards
Saqib Javaid
UNIST, Korea.
___
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] Problem with Wien2k 17 installation

[Gavin Abo]

Enter in the terminal:

echo $WIENROOT

Does it return

/cluster/home/lokanath/lib/w215

or

/cluster/home/lokanath/lib/w217

Also:

echo $PATH

Does it contain:

/cluster/home/lokanath/lib/w215:/cluster/home/lokanath/lib/w217

when it should contain only the:

/cluster/home/lokanath/lib/w217

The "source ~/.bashrc" likely can add the w217 line to the PATH, but it 
might not be able to remove w215 from the PATH.  To remove the w215, you 
have to close and open a new terminal or restart the computer so that 
the previous environmental variables are wiped and then the new .bashrc 
is loaded.


On 10/12/2017 6:13 AM, lokanath patra wrote:

Dear Fhokul,

Thanks for your reply.

This is the Wien2k part of the .bashrc file.

# added by WIEN2k: BEGIN
# 
alias lsi="ls -aslp *.in*"
alias lso="ls -aslp *.output*"
alias lsd="ls -aslp *.def"
alias lsc="ls -aslp *.clm*"
alias lss="ls -aslp *.scf* */*.scf"
alias lse="ls -aslp *.error"
alias LS="ls -aslp | grep /"
alias pslapw="ps -ef |grep "lapw""
alias cdw="cd /usit/abel/u1/lokanath/WIEN2k"
export OMP_NUM_THREADS=1
#export LD_LIBRARY_PATH=.
export EDITOR="vi"
export SCRATCH=./
export WIENROOT=/cluster/home/lokanath/lib/w217
export W2WEB_CASE_BASEDIR=/usit/abel/u1/lokanath/WIEN2k
export STRUCTEDIT_PATH=$WIENROOT/SRC_structeditor/bin
export PDFREADER=acroread
export 
PATH=$WIENROOT:$STRUCTEDIT_PATH:$WIENROOT/SRC_IRelast/script-elastic:$PATH:.

export OCTAVE_EXEC_PATH=${PATH}::
export OCTAVE_PATH=${STRUCTEDIT_PATH}::

export PATH=$PATH:$WIENROOT:.
ulimit -s unlimited
alias octave="octave -p $OCTAVE_PATH"
# 
# added by WIEN2k: END

After that I did source .bashrc

Still I am getting the old version in case.scf file.

Regards,
Lokanath


On Thu, Oct 12, 2017 at 5:14 PM, Md. Fhokrul Islam > wrote:


Looks like you haven't changed $WIENROOT in your .bashrc (or
whatever shell you are using).

You need to change the $WIENROOT to the path of the new directory
where you have installed

Wien2k17.1.


$WIENROOT = /cluster/home/lokanath/lib/w217



Fhokrul




*From:* Wien mailto:wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of
lokanath patra mailto:lokanath.patra...@gmail.com>>
*Sent:* Thursday, October 12, 2017 7:27 AM
*To:* A Mailing list for WIEN2k users
*Subject:* [Wien] Problem with Wien2k 17 installation
Dear all,

I have installed Wien2k 17. To start with some test calculation, I
performed spin polarized calculations with Ni. Everything running
fine. But when I checked the case.scf file, it's still showing the
old version like following.
*
*
*:LABEL1: Calculations in /cluster/home/lokanath/WIEN2k/Ni*
*:LABEL2: on login-0-1.local at Mon Oct  2 20:22:29 CEST 2017*
*:LABEL3: using WIEN2k_14.2 (Release 15/10/2014) in
/cluster/home/lokanath/lib/w215*
*:LABEL4: using the command: runsp_lapw -so -ec 0.0001 -NI*

I have installed Wien2k in /cluster/home/lokanath/lib/w217.

What might be the error??

Thank you and Regards,
Lokanath

-- 
Lokanath Patra

Ph.D Scholar
Dept. of Physics
School of Applied and Basic Sciences
Central University of Tamil Nadu
Thiruvarur
Tamil Nadu - 610101
Ph no - +91-8675834507



Virus-free. www.avg.com





___
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





--
Lokanath Patra
Ph.D Scholar
Dept. of Physics
School of Applied and Basic Sciences
Central University of Tamil Nadu
Thiruvarur
Tamil Nadu - 610101
Ph no - +91-8675834507
___
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] Optimization of monoclinic structure

[Gavin Abo]

I don't remember.  Probably all parameters are fixed except for one of 
them, then this is repeated separately for each parameter:


A, B, C fixed with changing GAMMA value, then
A, B, GAMMA fixed with changing C value, then
...
B, C, GAMMA fixed with changing A value

"x optimize" or OrthoOpt probably automatically set up the set of 
calculations in this way in a job script like optimize.job and then the 
job script is used to run all the calculations [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16418.html 
].


From the sounds of it, you are setting up each calculation by hand 
instead of using one of the above scripts/programs to help with that.


For monoclinic optimization, make sure the monoclinic angle (i.e., the 
one angle that is not equal to 90) is set as gamma.  As maybe this could 
cause the "SELECT" error due a symmetry break [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12124.html 
].


The "SELECT" error could also be caused by other things.  See the "NO 
ENERGY LIMITS FOUND IN SELECT" on page 231 under section "12 Trouble 
shooting" in the WIEN2k 17.1 usersguide [ 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ], 
where is says:


"Usually this happens when your input is not ok, or for very ill 
conditioned problems (very rare), or more likely, when “Ghostbands” 
appeared (or some states were missing) because of bad energy parameters 
in case.in1."


input is not ok => In an optimization, you are distorting the structure 
(changing the lattice parameters).  It is probably straightforward that 
if you distort a structure too much (% change is too large)  while you 
are doing this, you could possible generate a bad case.struct file.


As the above sentence also says, it could be caused by ghost bands. To 
help with that, there is section "12.1 Ghost bands" starting on page 232 
in the WIEN2k usersguide.


A related error might be the QTL-B error.  Refer to the links found in 
the post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12625.html

On 10/15/2017 8:26 PM, Shalika R. Bhandari wrote:

Dear all, Thank you for your suggestions .
 Now I have a bit confusion like while optimizing monoclinic structure 
does A, B,C,and GAMMA changes at the same time or we need to do them 
separately?
Also while running optimization, after first cycle it shows ERROR and 
stops running. LIKE THIS..

46.9u 0.0s 0:47.75 98.4% 0+0k 3696+40656io 12pf+0w
1.3u 0.0s 0:01.59 89.3% 0+0k 73552+35336io 6pf+0w
clmextrapol_lapw has generated a new RELAX.clmdn
hup: Command not found.
changing RELAX.in2c
changing RELAX.in2_ls
changing RELAX.in2_st
changing RELAX.in2_sy
 LAPW0 END
SELECT - Error

>   stop error
ERROR status in RELAX_mon1.00

I Want some more suggestions to resolve this problem sir.

___
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] updated email for -SP+SO case

[Gavin Abo]

See eval on page 135 in section "7.8.3 Input" of the WIEN2k 17.1 
usersguide [1] where it states:


"if efmod is set to TETRA, eval .ge. 100 specifies the use of the 
standard tetrahedron method instead of the modified one"


If eval is 0.101, then it is less than 100.  Whereas, if eval is 101, 
then it is greater than 100.  So for a metallic [2], it should be:


TETRA    101.0  (GAUSS,ROOT,TEMP,TETRA,ALL  eval)

For spin-polarized spin orbit calculation, it should be 'y' [3,4].

[1] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09872.html
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14849.html
[4] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16073.html


On 10/19/2017 7:42 AM, Dr. K. C. Bhamu wrote:

Hello,

Sorry for interrupting you. The last email was in the draft and sent 
by mistake. As I already know the solution of two queries among them.



The updated query is:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16510.html


2b) when you want mesh for optical calculations to be finer, do:
   x kgen -so (to generate finer mesh)
   in third line in case.in2,*change value of TETRA to be 101* 
>> what does he mean by changing the value of TETRA?



The third line in case.in2 is "TETRA 0.000  
(GAUSS,ROOT,TEMP,TETRA,ALL  eval)". May be he adviced to replace 
0.000 by 0.101. Is it?





When I initialied the case, I got two messages:




NOTE: Files for -orb (PbCrO3_fm.indm(c),inorb,dmatup/dn) must be 
adapted manually
Do you want to use the new structure for SO calculations ? (y/N)y >>> 
I accepted it. is it always okay?


Bhamu
___
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] updated email for -SP+SO case

[Gavin Abo]

For my comments, see below.


I got the point but I still have some doubts.

My system is half metallic. For  -up it is metallic while for -dn 
channel it is a semiconductor.


So in case of semiconductor, the value of tetra in case.in2/c could be 
same

(TETRA    0.000  (GAUSS,ROOT,TEMP,TETRA,ALL eval)
while for a metallic case, it should be
TETRA    101.0  (GAUSS,ROOT,TEMP,TETRA,ALL eval).


This is for -sp without -so as you mention below, right?  If so, that is 
probably okay.  Or to be "safe", use the 101 [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14472.html 
].



steps followd:


runsp_lapw -p -ec 0.0001 -so  -cc 0.0001 -i 300 -NI

x kgen -so :  increase k-points.

Query: 1:  For optical properties (assuming that for -up state it is 
metallic and for other it is semiconductor):


#
x_lapw lapw1 -p -up   (with TETRA   101.0)
x_lapw lapw1 -p -dn    (with TETRA   0.000)
x_lapw lapwso -up -p  (with TETRA   101.0)
x_lapw lapw2 -p -fermi -up -so   (with TETRA   101.0)
x_lapw lapw2 -p -fermi -dn -so   (with TETRA   0.000)
x_lapw optic -so -up -p   (with TETRA   101.0)
x_lapw optic -so -dn -p    (with TETRA   0.000)
x_lapw joint -up -p  (with TETRA   101.0)
x_lapw joint -dn -p    (with TETRA   0.000)
addjoint_updn_lapw
x_lapw kram

Is the above steps are right?  I am in doubt as there is not lapwso 
-dn used.


No, see next comment below.


I got confused from the thread provided  Prof. Peter.


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16552.html

where he  suggested to follow:

runsp -so         # spin-polarized + SO
x optic -up -so
x joint -up
x kram -up    (n*o addjoint-updn*)

provided that I use "joint.f" provided in above thread.

As he also did not mention lapw1, lapwso, lapw2, etc.

Please correct me in above steps.


Yes, I would use that provided "joint.f" with WIEN2k 17.1 and utilize 
those steps in that thread.  Select OPTIC from the menu in w2web, there 
you should see that the kgen, lapw1, and lapw2 steps are "optional" 
unless you are changing the k-mesh.  For changing the k-mesh, it looks 
like that would need [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12365.html 
]:


x kgen -so
x lapw1 -up
x lapwso -up

For brevity, it seems that the lapw2 step was omitted in that post. So 
you could add it:


x lapw2 -fermi -up -so


Next query is for band structure:


Query: 2 For bands

I followed below steps to calculate the dispersion curve:


x_lapw lapw1 -band -p -up
x_lapw lapw1 -band -p -dn
x_lapw lapwso -p -up >>> I did not use lapwso -dn as it is not supported.


You don't use lapwso -dn, because lapwso mixes the spin up and dn 
together [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03239.html 
, 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg00607.html 
].


The -up switch on lapwso just tells the program it needs to run for a 
spin-polarized case [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg02807.html 
].



x_lapw lapw2 -so -band -qtl -p -up
x_lapw lapw2 -so -band -qtl -p -dn
x_lapw spaghetti -so -p -up
x_lapw spaghetti -so -p -dn
(results are same when I use -c with lapw1, lapw2 and lapwso;   tested 
as it used case.in2c file)


If you using the x script with a program such as lapw2 like above (i.e., 
the "x program" lines seen above), it is recommended not use the "-c" 
flag.  This is because WIEN2k will automatically detect what it should 
be and adds it internally if it is needed [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16066.html 
].  It is able to this by checking if the case directory has the 
case.in1 and case.in2 files (non-complex) or a case.in1c and case.in2c 
files (complex).  So be careful not to create those files by hand 
yourself (unless you know what your doing), you should let the init_lapw 
script (or possibly other scripts) do that.


The system is PbCrO3. For  -sp (without -so) case it is semiconductor 
for -up state while metallic for -dn state.


In case of -sp+-so (with above steps), it is metallic for both stated 
(-up and -dn).


Where have I mistaken?


I'm not an expert on half metallics with optic, so I could be wrong.  
However, it looks like you answered your own question.  For the -sp 
without -so, it looks like you can do the -up state for the 
semiconductor and -dn state for the metallic.  This you could do for the 
Imag(epsilon) as it can be plotted separately, but the Real(epsilon) 
would need to be combined [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16536.html 
].


For the -sp with -so, the spin orbit couples the spin up and dn 
together.  So it seems that you can only get a single mixed 
metallic-semiconductor case as you have mentioned above.


___
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.c

Re: [Wien] updated email for -SP+SO case

[Gavin Abo]

1. Another user had to calculate plasma frequency for a half metallic [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07695.html 
].  So it is likely that you need to do it to.


2. Yes, you must recompile the optic package after replacing joint.f 
because it is a Fortran source code file and not a script, .


3. Sorry, I don't know.

Instead of plotting the spin up/dn band structure next to the DOS

https://www.researchgate.net/figure/257076112_fig8_FIG-8-Total-DOS-and-Band-Structure-of-Co-2-TiSb-using-the-LSDAU

it may be that you need to plot the fat band structure and PDOS (partial 
DOS) next to each other.


I don't know of WIEN2k program or script to do that.  So you would 
likely have to plot it by hand in software like Origin [ 
http://www.originlab.com/ ].  Or if you're good a programming, maybe you 
could make a script similar to what someone had did for VASP:


http://gvallver.perso.univ-pau.fr/?p=587

Spaghetti-primavera on the unsupported page [ 
http://susi.theochem.tuwien.ac.at/reg_user/unsupported/ ] might be 
helpful for creating the fat band (or band-character) plot.


COHP or COOP might also help with this:

http://schmeling.ac.rwth-aachen.de/cohp/index.php?menuID=2

Unfortunately, that is not currently implement for WIEN2k:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16542.html

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16543.html


On 10/21/2017 3:06 PM, Dr. K. C. Bhamu wrote:

Thank you very much Gavin for more clarification.

Now I have few more queries, please see :


For the -sp with -so, the spin orbit couples the spin up and dn 
together.  So it seems that you can only get a single mixed 
metallic-semiconductor case as you have mentioned above.


1. As the system is halfmetal, should I follow the steps to be done 
for metals (calculations of plasma frequency)? I am not sure for this 
as we are changing TETRA to 101.0.

2. Need to recompile optic package? I am 100 % sure just for confirmation.

3.  As mnetioned in one of the thread of prof. Prof. peter (and your 
above statment):

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg00607.html


" X spaghetti -so -up   or   -dn gives the "same" bandstructure, only 
the "fat-band" representation will be different, since up and dn-spin 
projections are different.


So how we correlate density of states with band structure  as we are 
able to get DOS for -up and -dn ?




Kind regards

Bhamu


___
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] why we need to divide plasma frequency by root(2)?

[Gavin Abo]

I could be wrong, but I think you just need to take the sqrt(2) of each 
plasma frequency:


2.074/sqrt(2) 2.074/sqrt(2) 1.264/sqrt(2)

then put them in case.inkram (not case.injoint).

You should be able to use multiple plasma frequencies in case.inkram but 
don't forget to add a Gamma for drude value for each of the plasma 
frequencies [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14495.html 
].


On 10/21/2017 4:29 PM, Dr. K. C. Bhamu wrote:



-case.injoint
xx
xx
1 >> correction
2.0740 2.0740 1.2640
xx
---

were xx means no change in lines of case.inkram.



At page numer  164 under section "8.11 KRAM (Kramers-Kronig
transformation) in UG"


*"For a metal, the Plasma-frequencies (intraband transitions) for
up and dn should be added, but then divided by√2, before using x
kram." *

Does it mean that we need to add all three components and then
divide by root(2) and put a single number
[(2.074+2.074+1.264)/root(2)=3.88] instead of all three in
case.injoint?


kind regards

Bhamu

___
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] fermi wave vector Kf

[Gavin Abo]

Is Kf the radius to the fermi surface [1]?

If so, maybe you can extract it from a fermi surface calculation [2] using:

a) XCrySDen [3]

or

b) FSGEN [4]

I have also seen the PW91 GGA equation [5]:

kF = (3*pi^2*n)^(1/3)

In a terminal, if you do:

cd $WIENROOT/SRC_lapw0

grep TKF *

In the output, you should see for example:

vxi35.f: TKF = 2.D0*(3.D0*PI2*D)**THRD

From above, it looks like TKF = 2*kF, where D = n.

Though, it is noted that the vxi35.f code might be for another 
functional other than PW91 GGA. So you would have to test and determine 
yourself which functional(s) and/or nuances that line of code is for.  
Also, I'm not seeing TKF written to any output file.  So you would 
likely have to add your own code to output the TKF values, such as with 
a WRITE statement [6].


Hope that helps and good luck.

[1] 
https://www.fhi-berlin.mpg.de/~wolf/femtoweb/teaching/WS0506-wolf-festk/WS0506/material/free_electron3_4.pdf
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg02526.html

[3] http://www.xcrysden.org/doc/fermi.html
[4] Section "8.7 FSGEN (Fermi-surface generation)" on page 159 in the 
WIEN2k 17.1 usersguide ( 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf )
[5] Equation 29 in chapter "Derivation of a Generalized Gradient 
Approximation: The PW91 Density Functional" of the book titled 
"Electronic Density Functional Theory:Recent Progress and New 
Directions" ( http://www.springer.com/us/book/9780306458347 )
[6] Intel Fortran Compiler 17.0 Developer Guide and Reference ( 
https://software.intel.com/en-us/node/680026 )


On 10/22/2017 1:00 AM, Amir Zayyani wrote:

Dear Prof. P. Blaha

I want to know where the exact amount of fermi wave vector Kf is and in which 
file i can find it


Best Regards

Zayyani

___
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] error

[Gavin Abo]

As the error message tells you, it cannot find the dstart executable 
file.  Either you need to compile to create the file with siteconfig, 
fix the WIENROOT (and/or PATH) variables in your .bashrc, or try the 
pre-compiled executables (WIEN2k_17.1_executables.tar.gz).




Did you run siteconfig and successfully compile (with no error messages) 
to create the dstart executable file?


Did you run userconfig_lapw? Is the WIENROOT variable in your .bashrc 
pointing to the correct location of where you installed WIEN2k?  Is it 
the /home/maslan/WIENROOT?


Or did you copy the dstart file in WIEN2k_17.1_executables.tar.gz to the 
base directory created from extracting WIEN2k_17.1.tar?


Did search youtube and watch how to install WIEN2k:

https://www.youtube.com/watch?v=kg5S0am3C-k

Did you read the lecture note slides on how to install WIEN2k:

http://susi.theochem.tuwien.ac.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/WIEN2k-installation.pdf

Did you watch the workshop video "Installation of Wien2k, parallelization":

http://susi.theochem.tuwien.ac.at/onlineworkshop/

Did you read section "III Installation of the WIEN2k package and 
Dimensioning of programs" in the WIEN2k 17.1 usersguide:


http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf

Do an internet search or search the mailing list archive [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/maillist.html 
], as there is likely other help information not listed here.


On 10/24/2017 11:38 AM, Metin Aslan wrote:

Hi all, I am a new Wien2k user.

I got this error by initialize calc.

"/home/maslan/WIENROOT/dstart : Command not found"

how can I solve this problem.

Thanks.

Metin Aslan

___
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] negative eps-1 and very large value of eps-2

[Gavin Abo]

Thanks Dr. Fecher.

Sorry, this might be due to my mistake in the post:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16609.html

where the lapw1 -dn should be added:

x kgen -so
x lapw1 -up
x lapw1 -dn
x lapwso -up

A silly mistake where I forget that both the lapw1 -up and lapw1 -dn are 
both needed so that lapwso can mix both the up and dn.  Hard to do that 
when there is only the up output from lapw1 as input to lapwso.


Yeah, I probably should have checked a :log file for runsp -so [ 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2008-June/011017.html ] 
that shows the


(x) lapw1 -up
(x) lapw1 -dn
(x) lapwso -up

or checked the case.dayfile like what was mentioned before for a proper 
sequence:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg10757.html

On 10/27/2017 12:25 AM, Fecher, Gerhard wrote:

If your case is spinpolarised why don't you run
lapw1 -dn
before running lapwso ?

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

___
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] why we need to divide plasma frequency by root(2)?

[Gavin Abo]

Thanks.

So if understand correctly, the w_pl^2(up-spin) is what is outputted in 
case.outputjointup for a spin-polarized spin orbit calculation by line 
859 of joint.f in the post:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16552.html

So, w_pl^2(dn-spin) = w_pl^2(up-spin).  Plugging that into the SP 
(without spin orbit) plasma frequency equation from your post below:


w_pl = sqrt( w_pl^2(up-spin) + w_pl^2(up-spin) )
w_pl = sqrt(2*w_pl^2(up-spin) )
w_pl = sqrt(2)*w_pl(up-spin)  <= This showing why we need to get rid of 
the sqrt(2) by dividing the sqrt(2)*w_pl(up-spin) by the sqrt(2) to get 
the plasma frequency w_pl equal to w_pl(up-spin).


So one needs to calculate (w_pl^2(up-spin) + w_pl^2(up-spin))/sqrt(2) 
[or (2*w_pl^2(up-spin))/sqrt(2)] to get the plasma frequency like in the 
post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16017.html

So the mistake I made was the missing multiplication by 2 in my previous 
post:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16615.html

2*2.074/sqrt(2) 2*2.074/sqrt(2) 2*1.264/sqrt(2)

or

2.933 2.933 1.788

Or do I still have something not quite right?

On 10/27/2017 12:44 AM, Fecher, Gerhard wrote:

The optics programm tells about the SP Plasma frequencies:
w_pl = sqrt( w_pl^2(up-spin) + w_pl^2(dn-spin) )

where does this come from
remember the classical approach where the plasma frequency is proportional to 
root(n) with n being the density of free electrons (number of electrons per 
Volume)
now what do you have in the SP case ? Shouldn't that be root/n_up+n_dn) ?
The programm however delivers  w_up proportional to root(n_up) and w_dn prop to 
root(n_dn) and you see where the above equation is comming from

Finally show what happens when the two densities are equal  n_up=n_dn and you 
see where the root(2) is coming from and when to use it

(Note that the root(2) is here not because of surface plasmons)

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Gavin Abo 
[gs...@crimson.ua.edu]
Gesendet: Sonntag, 22. Oktober 2017 00:42
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] why we need to divide plasma frequency by root(2)?

I could be wrong, but I think you just need to take the sqrt(2) of each plasma 
frequency:

2.074/sqrt(2) 2.074/sqrt(2) 1.264/sqrt(2)

then put them in case.inkram (not case.injoint).

You should be able to use multiple plasma frequencies in case.inkram but don't 
forget to add a Gamma for drude value for each of the plasma frequencies [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14495.html ].

On 10/21/2017 4:29 PM, Dr. K. C. Bhamu wrote:

-case.injoint
xx
xx
1  >> correction
2.0740  2.0740  1.2640
xx
---

were xx means no change in lines of case.inkram.



At page numer  164 under section "8.11 KRAM (Kramers-Kronig transformation) in 
UG"


"For a metal, the Plasma-frequencies (intraband transitions) for up and dn should be 
added, but then divided by√2, before using x kram."

Does it mean that we need to add all three components and then divide by 
root(2) and put a single number [(2.074+2.074+1.264)/root(2)=3.88] instead of 
all three in case.injoint?


kind regards

Bhamu
___
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] why we need to divide plasma frequency by root(2)?

[Gavin Abo]

Sorry, in line 859 I saw plasm2 and totally overlooked the SQRT:

858:   if(SPIN.and.(ASO.eq.'SO')) then
859: WRITE(6,618) (SQRT(plasm2(npcol(i))),i=1,LCOL)

So what I previously posted was nonsense.  In looks like w_pl(up-spin) 
is what is outputted in case.outputjointup for a spin-polarized spin 
orbit calculation.


So, w_pl^2(dn-spin) = w_pl^2(up-spin).  Plugging that into the SP 
(without spin orbit) plasma frequency equation:


w_pl = sqrt( w_pl^2(up-spin) + w_pl^2(up-spin) )
w_pl = sqrt(2*w_pl^2(up-spin) )
w_pl = sqrt(2)*sqrt(w_pl^2(up-spin))
w_pl = sqrt(2)*w_pl(up-spin)

sqrt(2)*2.074 sqrt(2)*2.074 sqrt(2)*1.264

or case.inkram I think would need to be:

2.933 2.933 1.788

Note: Since sqrt(2) = 2/sqrt(2) [ 
http://mathforum.org/library/drmath/view/58248.html ], the above 
equation could also be written as:


w_pl = 2*w_pl(up-spin)/sqrt(2)

On 10/27/2017 10:53 AM, Gavin Abo wrote:


Thanks.

So if understand correctly, the w_pl^2(up-spin) is what is outputted 
in case.outputjointup for a spin-polarized spin orbit calculation by 
line 859 of joint.f in the post:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16552.html

So, w_pl^2(dn-spin) = w_pl^2(up-spin).  Plugging that into the SP 
(without spin orbit) plasma frequency equation from your post below:


w_pl = sqrt( w_pl^2(up-spin) + w_pl^2(up-spin) )
w_pl = sqrt(2*w_pl^2(up-spin) )
w_pl = sqrt(2)*w_pl(up-spin)  <= This showing why we need to get rid 
of the sqrt(2) by dividing the sqrt(2)*w_pl(up-spin) by the sqrt(2) to 
get the plasma frequency w_pl equal to w_pl(up-spin).


So one needs to calculate (w_pl^2(up-spin) + w_pl^2(up-spin))/sqrt(2) 
[or (2*w_pl^2(up-spin))/sqrt(2)] to get the plasma frequency like in 
the post at:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16017.html

So the mistake I made was the missing multiplication by 2 in my 
previous post:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16615.html

2*2.074/sqrt(2) 2*2.074/sqrt(2) 2*1.264/sqrt(2)

or

2.933 2.933 1.788

Or do I still have something not quite right?

On 10/27/2017 12:44 AM, Fecher, Gerhard wrote:

The optics programm tells about the SP Plasma frequencies:
w_pl = sqrt( w_pl^2(up-spin) + w_pl^2(dn-spin) )

where does this come from
remember the classical approach where the plasma frequency is proportional to 
root(n) with n being the density of free electrons (number of electrons per 
Volume)
now what do you have in the SP case ? Shouldn't that be root/n_up+n_dn) ?
The programm however delivers  w_up proportional to root(n_up) and w_dn prop to 
root(n_dn) and you see where the above equation is comming from

Finally show what happens when the two densities are equal  n_up=n_dn and you 
see where the root(2) is coming from and when to use it

(Note that the root(2) is here not because of surface plasmons)

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Gavin Abo 
[gs...@crimson.ua.edu]
Gesendet: Sonntag, 22. Oktober 2017 00:42
An:wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] why we need to divide plasma frequency by root(2)?

I could be wrong, but I think you just need to take the sqrt(2) of each plasma 
frequency:

2.074/sqrt(2) 2.074/sqrt(2) 1.264/sqrt(2)

then put them in case.inkram (not case.injoint).

You should be able to use multiple plasma frequencies in case.inkram but don't 
forget to add a Gamma for drude value for each of the plasma frequencies 
[https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14495.html  ].

On 10/21/2017 4:29 PM, Dr. K. C. Bhamu wrote:

-case.injoint
xx
xx
1  >> correction
2.0740  2.0740  1.2640
xx
---

were xx means no change in lines of case.inkram.



At page numer  164 under section "8.11 KRAM (Kramers-Kronig transformation) in 
UG"


"For a metal, the Plasma-frequencies (intraband transitions) for up and dn should be 
added, but then divided by√2, before using x kram."

Does it mean that we need to add all three components and then divide by 
root(2) and put a single number [(2.074+2.074+1.264)/root(2)=3.88] instead of 
all three in case.injoint?


kind regards

Bhamu
___
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.

Re: [Wien] BerryPi

[Gavin Abo]

Yes, the WIEN2k limitations page [ 
http://susi.theochem.tuwien.ac.at/reg_user/limitations/ ] lists that the 
optic package doesn't work with RLOs.


On 10/27/2017 8:45 AM, Dr. K. C. Bhamu wrote:

Hii,

I saw it but is is not helpful. Out procedure differs in many ways.

Here the person is doing -sp+-so for Pt and he is not adding RLOs, 
using TETRA 0.000, and taking plasma frequency as such from 
outputjoint file


while I am using RLO for Pb, TETRA 101 and sqrt(2)(w_pl).

I do not know if I do not apply RLO on Pb then how it will help me, 
rest of his procedure I have followed but could not get results.




Regards
Bhamu


On Fri, Oct 27, 2017 at 11:03 AM, lokanath patra 
mailto:lokanath.patra...@gmail.com>> wrote:


Dear Dr. Bhamu

In this tutorial video for optical properties with so coupling,
they are using x kgen with so symmetry. So I think we should use
-so tag.
https://www.youtube.com/watch?v=lDW7cy1oZR4&t=147s


Check page no 135 of the UG to know about changing tetra.

Regards
Lokanath



___
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] The magnetic structure for zinc blende non magnetic structure

[Gavin Abo]

For the 122 I-42d struct file at:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16579.html

Did you look at it in VESTA [ 
http://jp-minerals.org/vesta/en/download.html ] and compare it the 
zinc-blende AFIII structure at the link of your previous post:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16580.html

In VESTA, if you rotate the structure so that the c axis is pointing 
downward (in the -z direction) and set the direction of the spins so 
that Ni1, as defined in the struct file, is pointing up (in the -c 
direction) and Ni2 is pointing dn (in the c direction).  They look like 
they are exactly the same to me except of course for the atom types 
being different (Ni instead of Mn and S instead of Te).


On 10/28/2017 8:30 AM, Abderrahmane Reggad wrote:

Dear Delamora

I still waiting for my answer


Best regards

___
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] Querry in a resultant structure

[Gavin Abo]

The spacegroup 11 struct in the post

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16619.html

is likely slightly wrong for what you want to do.

Take the AFM III picture from your link in the post

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16630.html

and compare it to the struct viewed in VESTA (attached file 
NiS-MnP-afmIII.vesta).


If you rotate the view of the structure so that the a axis points down 
(in the -z direction), then the AFM III and struct file pictures look 
the same with the up and dn aligned along the a axis (or -/+ x directions).


The problem I see with this is that WIEN2k only allows the up and dn to 
be defined in the +z direction and -z direction (or along c axis), 
respectively.


WIENncm most likely could handle the up and dn along the x axis. 
However, usually experience in both electronic structure theory and 
programming (e.g., Fortran and C) is need to use WIENncm.  Your current 
question suggests you might currently lack the skills that would be 
needed to use it.  This is because WIENncm has very limited support [ 
http://susi.theochem.tuwien.ac.at/reg_user/ncm/ ].  So a user of it 
needs to be able to do so with little to no help.


One solution to use WIEN2k in your case, may be to use the rotateall 
function of the structeditor (refer to section 9.28 in the WIEN2k 17.1 
usersguide).


Or another possible solution should be to calculate by hand what the 
structure parameters would need to be after rotating the structure so 
that the up and dn are aligned along the z axis.
#VESTA_FORMAT_VERSION 3.3.0


CRYSTAL

TITLE
NiS-MnP-afmIII

GROUP
1 1 P 1
SYMOP
 0.00  0.00  0.00  1  0  0   0  1  0   0  0  1   1
 -1.0 -1.0 -1.0  0 0 0  0 0 0  0 0 0
TRANM 0
 0.00  0.00  0.00  1  0  0   0  1  0   0  0  1
LTRANSL
 -1
 0.00  0.00  0.00  0.00  0.00  0.00
LORIENT
 -1   0   0   0   0
 1.00  0.00  0.00  1.00  0.00  0.00
 0.00  0.00  1.00  0.00  0.00  1.00
LMATRIX
 1.00  0.00  0.00  0.00
 0.00  1.00  0.00  0.00
 0.00  0.00  1.00  0.00
 0.00  0.00  0.00  1.00
 0.00  0.00  0.00
CELLP
  5.820074   5.294696   3.632391  90.00  90.00  90.00
  0.00   0.00   0.00   0.00   0.00   0.00
STRUC
  1 NiNi1  1.   0.250212   0.14   0.251a   1
0.00   0.00   0.00  0.00
  2 NiNi1  1.   0.749788   0.86   0.751a   1
0.00   0.00   0.00  0.00
  3 NiNi2  1.   0.750247   0.500126   0.751a   1
0.00   0.00   0.00  0.00
  4 NiNi2  1.   0.249753   0.499874   0.251a   1
0.00   0.00   0.00  0.00
  5  S S1  1.   0.089864   0.750125   0.751a   1
0.00   0.00   0.00  0.00
  6  S S1  1.   0.910136   0.249875   0.251a   1
0.00   0.00   0.00  0.00
  7  S S2  1.   0.410140   0.250125   0.751a   1
0.00   0.00   0.00  0.00
  8  S S2  1.   0.589860   0.749875   0.251a   1
0.00   0.00   0.00  0.00
  0 0 0 0 0 0 0
THERI 0
  1Ni1  1.00
  2Ni1  1.00
  3Ni2  1.00
  4Ni2  1.00
  5 S1  1.00
  6 S1  1.00
  7 S2  1.00
  8 S2  1.00
  0 0 0
SHAPE
  0   0   0   0   0.00  0   192   192   192   192
BOUND
   01 01 01
  0   0   0   0  0
SBOND
  0 0 0 0
SITET
  1Ni1  1.2500 183 187 189 183 187 189 204  1
  2Ni1  1.2500 183 187 189 183 187 189 204  1
  3Ni2  1.2500 183 187 189 183 187 189 204  1
  4Ni2  1.2500 183 187 189 183 187 189 204  1
  5 S1  1.0400 255 250   0 255 250   0 204  1
  6 S1  1.0400 255 250   0 255 250   0 204  1
  7 S2  1.0400 255 250   0 255 250   0 204  1
  8 S2  1.0400 255 250   0 255 250   0 204  1
  0 0 0 0 0 0
VECTR
   1   -1.00.00.0 0
1   0000
2   0000
 0 0 0 0 0
   21.00.00.0 0
3   0000
4   0000
 0 0 0 0 0
 0 0 0 0 0
VECTT
   1  0.250 255   0   0 1
   2  0.250 255   0   0 1
 0 0 0 0 0
SPLAN
  0   0   0   0
LBLAT
0 1 2 3 4 5 6 7  -1
LBLSP
 -1
DLATM
 -1
DLBND
 -1
DLPLY
 -1
PLN2D
  0   0   0   0
ATOMT
  1 Ni  1.2500 183 187 189 183 187 189 204
  2  S  1.0400 255 250   0 255 250   0 204
  0 0 0 0 0 0
SCENE
-0.026724  0.999626 -0.005734  0.00
-0.996986 -0.027070 -0.072699  0.00
-0.072827  0.003774  0.997337  0.00
 0.00  

[Wien] BoltzTraP2

[Gavin Abo]

All,

Just curious, has anyone heard if the new BoltzTraP2 package will remain 
a private code or if it is just not ready yet for public release?


The BoltzTraP website

https://www.imc.tuwien.ac.at//forschungsbereich_theoretische_chemie/forschungsgruppen/prof_dr_gkh_madsen_theoretical_materials_chemistry/boltztrap/

and the blank workshop conclusion slide at

http://susi.theochem.tuwien.ac.at/events/ws2017/

don't seem to provide any hints about that.

Thanks in advance,

Gavin
___
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] BoltzTraP2

[Gavin Abo]

Sorry, it is not clear to me what you are asking.

As far as I know, BoltzTrap and the new BoltzTrap2 are 'serial' programs.

By "implement parallel BoltzTrap", are you asking about how to use the 
WIEN2k parallel output from an scf calculation (run[sp]_lapw -p) with 
BoltzTrap?


There is currently a gather_energy.pl script [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13418.html 
] for combining the parallel energy files of WIEN2k into a serial one 
that can be used with BoltzTrap.


Note that on the website at

http://blog.levilentz.com/boltztrap-tutorial-for-quantum-espresso/

there is:

/"finally how to run Boltztrap in parallel mode?"-Muthu
/

/I am not sure you can run this is parallel. Unless you have a huge 
number of tangled bands, you really shouldn’t need to. Further, if you 
do have such a system, only consider the mobility of the bands near the 
fermi energy as those will be the only ones participating in electronic 
mobility (in general).-Levi/


Or are asking how to program the BoltzTrap source code to make parts of 
it parallel?


If your trying to rewrite parts of the code to parallelize it, I think 
Intel has some documentation for doing that with their ifort or icc 
compilers. For example, see:


https://software.intel.com/en-us/mpi-developer-guide-linux-compiling-an-mpi-program

Some universities might have courses or hold seminars on programing for 
code parallelization.


There should also be coding school companies that offer online courses.  
If you happen to work for a software company, your company might be 
paying one of those online coding schools to give you access to those 
courses.  Maybe, even some universities do that too.  Your library or 
department could likely tell you what is available to you.  As an 
example, the "High-performance Computing in C++" course website for 
Pluralsight mentions it covers MPI and parallelization topics:


https://www.pluralsight.com/courses/cpp-high-performance-computing

However, I haven't taken the above course, so I cannot vouch for whether 
it would be helpful or not for parallelizing the BolzTrap source code.  
There may be a more appropriate course or tutorial that you could find 
yourself somewhere else on the web.


On 10/29/2017 3:36 PM, Kamil Klier wrote:
I'd like to join this inquiry, with specifics on how to implement 
parallel BoltzTrap and whether a link to graphic (ps ?) could be mads 
available.


With thanks,

Kamil

On Sat, Oct 28, 2017 at 10:15 PM, Gavin Abo <mailto:gs...@crimson.ua.edu>> wrote:


All,

Just curious, has anyone heard if the new BoltzTraP2 package will
remain a private code or if it is just not ready yet for public
release?

The BoltzTraP website


https://www.imc.tuwien.ac.at//forschungsbereich_theoretische_chemie/forschungsgruppen/prof_dr_gkh_madsen_theoretical_materials_chemistry/boltztrap/

<https://www.imc.tuwien.ac.at//forschungsbereich_theoretische_chemie/forschungsgruppen/prof_dr_gkh_madsen_theoretical_materials_chemistry/boltztrap/>

and the blank workshop conclusion slide at

http://susi.theochem.tuwien.ac.at/events/ws2017/
<http://susi.theochem.tuwien.ac.at/events/ws2017/>

don't seem to provide any hints about that.

Thanks in advance,

Gavin

___
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] configuring static linking with siteconfig

[Gavin Abo]

In WIEN2k versions older than 17.1, I think the advanced user could 
directly modify WIEN2k_OPTIONS (or OPTIONS), then run siteconfig to load 
the file and just do a save to propagate the settings to the Makefiles.  
I think it might be with the parallel settings that the new 
auto-generation in siteconfig_lapw changed it so that also no longer works.


On line 2036 in siteconfig_lapw, there should be:

    set SCALAPACK_LIBNAME = 'mkl_scalapack_lp64'

Have you tried changing it to:

    set SCALAPACK_LIBNAME = 'ibscalapack.a'

Similarly, maybe try changing line 2795:

    set fftwlibspara = "-l${FFTW_LIBNAME}_mpi"

to say

    set fftwlibspara = "-lfftw3_mpi.a"

On 10/30/2017 3:21 AM, Pavel Ondračka wrote:

Dear Wien2k mailing list,

what is the recomended way to link Wien2k with static libs using the
siteconfig script? For example when I go to "SCALAPACK Settings" I
would like to link with static libscalapack.a, however I can only set
the SCALAPACKROOT and SCALAPACK_LIBNAME and the final SCALAPACK_LIBS is
autogenerated to link with a dynamical library. Is there a way to edit
the SCALAPACK_LIBS and link with a static library without editing the
generated makefiles manually? BTW similar problems is with fftw
settings...

Best regards
Pavel Ondračka

___
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] Use only gamma sampling

[Gavin Abo]

Did the VASP article use the pre-compiler flag -DNGXhalf [1], which is 
used for large supercells and molecules with only 1 k-point (Gamma) and 
is roughly twice as fast and uses half the memory [2]?  As far as I 
know, WIEN2k doesn't have a similar pre-compiler flag to this.


Or did they use Gamma in their VASP KPOINTS file [3]?  The KPOINTS file 
might be similar to WIEN2k's case.klist that is created with "x kgen" [4].


[1] 
https://cms.mpi.univie.ac.at/vasp/vasp/Pre_compiler_flags_overview_parallel_version_Gamma_point_only_version.html

[2] https://www.nsc.liu.se/~pla/blog/2011/06/28/vaspcompile/
[3] https://cms.mpi.univie.ac.at/vasp/vasp/Automatic_k_mesh_generation.html
[4] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01026.html


On 11/2/2017 10:59 AM, Chouaib AHMANI FERDI wrote:

Greetings Wien2k users,

I came across an article which is about some first principle 
calculations on olivine LiFe2O3 doped with Cr (x=0.03), For this 
purpose, they had to construct a supercell 2x2x2, they ended with 224 
atoms in the cell.

This is a passage of the article :
  "Only one Gamma point sampling in the first Brillouin zone was used 
for this large supercell, which gives approximately the same accuracy 
in total energy per atom as the 60 k points sampling for the 28-atom 
orthorhombic LiFePO4"


They used VASP for these calculations.

I hope someone would show me how to perform the one Gamma point 
sampling using Wien2k ?


Faithfully,

--
AHMANI FERDI Chouaïb
"Laboratoire Matériaux Nanomatériaux Nanomagnétisme
  et Enseignement des Sciences"
Ecole Normale Supérieure
Université Mohammed V, Rabat.
Tel : +212 6 94 59 57 60
___
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] open shell case [Si and Ge]

[Gavin Abo]

Feel free to correct me if I'm wrong, but I think Si and Ge have an even 
number of electrons (or paired electrons).


For Si, 4 electrons in the 3s^2 3p^2.  For Ge, 4 electrons in the 4s^2 
4p^2. [1]


This making them closed shell [2].

In Prof. Blaha's example for free atoms [3], spin-polarized (runsp_lapw) 
is used for open shell (or non-closed shell [4]) Li (1 electron in 2s^1) 
and B (3 electron in 2s^2 2p^1) and non-spin polarized is used for 
closed shell Be (2 electron in 2s^2).


I don't know why it is fluctuating, diverging?  Is the box you used 
containing the free atom large enough?  I remember that 12x12x12 
angstrom usually might be large enough [5].


[1] 
https://en.wikipedia.org/wiki/Electron_configurations_of_the_elements_(data_page)
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11320.html
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16691.html

[4] http://susi.theochem.tuwien.ac.at/reg_user/faq/cohesive.html
[5] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12815.html


On 11/2/2017 7:06 PM, chin Sabsu wrote:

Dear Peter Sir,

Do Si [S^23P^4]  and Ge [4S^24P^2] are also an open shell case?

Because my Si atomization energy is fluctuating without -sp switch 
after 55 scf cycles also.




Sincerely

Chin
___
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] Large cell instgen_lapw : word too long

[Gavin Abo]

Yes, you can run mpi on your single PC.  If I remember correctly, lapw1 
(and maybe also lapw2) is usually slower than lapw0 , so you will want 
to run them in parallel.


However, several PC on a GB-network might run calculations faster than 
your single PC as was mentioned before [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09334.html 
].


If you can find a company, university, or research center to collaborate 
with that has an Infiniband based cluster, that should be even better.



On 11/3/2017 5:04 AM, Chouaib AHMANI FERDI wrote:

Thank you for your reply.

I tried the conversions between struct and cif files, but the 
structures remains the same. 336 atomes!


I don't have MPI installed because I never had to use it, will it 
allow for example to run lapw0 on multiple cores in my single PC ?


___
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] error in dstart

[Gavin Abo]

Seems a bit odd.  Usually, if you see that error, it first occurs 
earlier during initialization (i.e., dstart in init_lapw) or during a 
lapw step during the scf calculation [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04721.html 
].


It depends a bit on how you configure and use your system.

First, I would check that the libmkl_intel_lp64.so exists in my Intel 
ifort installation:
username@computername:~/Desktop$ ls -l 
/opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so
-rwxr-xr-x 1 root root 6797610 Oct 11  2013 
/opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so


Next, I would locate where my compilervars.sh exists in my Intel ifort 
installation:


username@computername:~/Desktop$ ls -l /opt/intel/bin/compilervars.sh
lrwxrwxrwx 1 root root 33 Feb 20  2016 /opt/intel/bin/compilervars.sh -> 
../composerxe/bin/compilervars.sh


Then, I would check if my source line exists and is correct in my 
.bashrc file [ 
https://software.intel.com/en-us/articles/setting-up-the-build-environment-for-using-intel-c-or-fortran-compilers 
]:


username@computername:~/Desktop$ grep "compilervars.sh" ~/.bashrc
source /opt/intel/bin/compilervars.sh intel64

Note: The above paths might be different and could change depending on 
the Intel ifort version you are using and were you set it to be installed.


There might be a few old systems out there were the .bashrc doesn't 
work, such that a conf file might need to be used instead [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08016.html 
].


Following that, I would close and open a new terminal, or restart the 
system, to reload the new .bashrc settings [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16577.html 
].


If using a queuing system, I would check the queuing system's 
documentation and internet to see if my job script needs anything 
special to propagate my environmental variables out to the nodes. For 
example, PBS might need a directive command added to the job script [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16338.html 
]: #PBS -V


If using w2web, I would either kill w2web, or restart the system, then 
execute w2web again to reload the new .bashrc settings for it [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07979.html 
].


Another possible solution should be to use static instead of dynamic 
linking:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08510.html
http://www.ghfecher.de/Fecher_CompileIntel.pdf
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16548.html

However, this currently may be more difficult to do with the latest 
WIEN2k 17.1 version:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16669.html

On 11/5/2017 1:39 AM, Sri Muralikrishna Molli, Physics, SSSIHL wrote:

Dear All

While running a band structure calculation, I got the following error:

/dstart: error while loading shared libraries: libmkl_intel_lp64.so: 
cannot open shared object file: No such file or directory/


Could someone help me to resolve this issue?

Thanks and Regards

Muralikrishna M
___
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] WARNING During SCF Calculations

[Gavin Abo]

How did you recompile?

Using sitconfig:

username@computername:~/Desktop$ cd $WIENROOT
username@computername:~/WIEN2k$ ./siteconfig

   *
   *    W I E N    *
   *  site configuration   *
   *
...
  D   Dimension Parameters
...

  Selection: D

***
   *  (Re-)Dimension parameters  *
***

...

    Change parameters in:

    1   lapw1  (e.g. NMATMAX, NUME)
    A   all programs (usually not necessary)

    Q   to quit

 Selection: A
  PARAMETER  (NMATMAX=   19000)
  PARAMETER  (NUME=   6000)

Which parameter to change? (q to quit): NMATMAX


 set value for NMATMAX=4
...

The present values are:
  PARAMETER  (NMATMAX=   4)
  PARAMETER  (NUME=   6000)

    Change parameters in:

    1   lapw1  (e.g. NMATMAX, NUME)
    A   all programs (usually not necessary)

    Q   to quit

 Selection: Q

*
   *    W I E N    *
   *  site configuration   *
   *

...
  R   Compile/Recompile
...

  Selection: R

***
   *  Compile/Recompile programs *
***

 M   Compile programs with modified parameters
 A   Compile all programs
 S   Select program

 Q   Quit

 Selection: M

...
Compile time errors (if any) were:
   <- Should be 
blank lines here showing no compiler errors.


Check file   compile.msg   in the corresponding SRC_* directory for the
compilation log and more info on any compilation problem.

or do navigate to the lapw1 directory and do:

username@computername:~/Desktop$ cd $WIENROOT/SRC_lapw1
username@computername:~/WIEN2k/SRC_lapw1$ make clean
username@computername:~/WIEN2k/SRC_lapw1$ make all
username@computername:~/WIEN2k/SRC_lapw1$ cp lapw1 lapw1c lapw1_mpi 
lapw1c_mpi ..


Are there WIEN2k installation files at more than one location on your 
system?  Is the system using the one you expect?  For example, maybe do:


username@computername:~/Desktop$ which lapw1

Does the output show it pointing your lapw1 file or to a different one 
installed on the cluster?


On 11/5/2017 7:26 AM, sandeep Kumar wrote:

Dear Professor Peter Blaha and WIEN2k users,

According to your suggestion, I have changed NMATMAX value and 
recompile it but still, I am facing the same problem.


These are the details which I have used during installations of  
WIEN2k_17.1 version:


WIEN_2K COMPLIER:

fortran:ifort
c:icc
parallel:mpiifort

WIEN2k_OPTIONS

current:FOPT:-O1 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML 
-traceback -assume buffered_io -I$(MKLROOT)/include
current:FPOPT:-O1 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML 
-traceback -assume buffered_io -I$(MKLROOT)/include

current:LDFLAGS:$(FOPT) -L$(MKLROOT)/lib/$(MKL_TARGET_ARCH) -pthread
current:DPARALLEL:'-DParallel'
current:R_LIBS:-lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread 
-lmkl_core -openmp -lpthread

current:FFTWROOT:/home/qnt/sandeep/fftw/
current:FFTW_VERSION:FFTW3
current:FFTW_LIB:lib
current:FFTW_LIBNAME:fftw3
current:LIBXCROOT:/home/qnt/sandeep/libxc/
current:LIBXC_FORTRAN:xcf03
current:LIBXC_LIBNAME:xc
current:SCALAPACKROOT:/opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/
current:SCALAPACK_LIBNAME:mkl_scalapack_lp64
current:BLACSROOT:/opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/
current:BLACS_LIBNAME:mkl_blacs_intelmpi_lp64
current:ELPAROOT:
current:ELPA_VERSION:
current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
current:CORES_PER_NODE:1
current:MKL_TARGET_ARCH:intel64


 $WIENROOT/SRC_lapw1/param.inc:

!
!     Constant parameter definition
!
      INTEGER            LMAX,  LMMX, LOMAX, restrict_output
      INTEGER            NATO, NDIF,  NKPTSTART, NMATMAX,  NRAD
      INTEGER            NSYM, NUME,NVEC1, NVEC2, NVEC3
      INTEGER NWAV,NMATIT,NUMEIT,HB,NMATBL,nloat
      PARAMETER          (LMAX=   13)
      PARAMETER          (LMMX=  120)
      PARAMETER          (LOMAX=   3)
      PARAMETER          (NKPTSTART= 100)
      PARAMETER          (NMATMAX=   4)
      PARAMETER          (NRAD=  881)
      PARAMETER          (NSYM=   48)
      PARAMETER          (NUME=   8000)
      PARAMETER          (NVEC1=  35)
      PARAMETER          (NVEC2=  35)
      PARAMETER          (NVEC3=   95)
!      PARAMETER          (nloat= 60)      !  should be 3 for only one LO
      PARAMETER          

Re: [Wien] WARNING During SCF Calculations

[Gavin Abo]

You say that the ":WARN : WARNING: RKmax reduced due to NMATMAX" message 
went away in the case.scf. The MATRIX SIZE is quite a bit less than the 
4 that you set for NMATMAX. So yes, it looks okay (correct) now.  
The 6.99 not being exactly 7.0 is normal.  As was said before on the 
mailing list, it is not an issue [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14226.html 
].


On 11/6/2017 12:54 AM, sandeep Kumar wrote:

Dear Dr. Gavin Abo and WIEN2k users,

Thank you very much for your suggestions. I compile siteconfigure as 
you suggested and I found there was no error during SCF calculations. 
I used RKmax = 7.0 but I got it 6.99. Is it correct now?


:RKM: MATRIX SIZE 16869LOs:1064  RKM= 6.99  WEIGHT= 1.00 PGR:


Thanks
Sandeep Kumar
___
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] :WARN : WARNING: RKmax reduced due to NMATMAX

[Gavin Abo]

As mentioned, you can keep increasing NMATMAX until the "WARNING: RKmax 
reduced due to NMATMAX" message goes away.


However, a trick I found, is to use "x lapw1 -nmat_only":

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08134.html

Although, keep in mind that the value you set for NMATMAX depends on the 
amount of physical free RAM your computer has, which is why it is best 
to set a value corresponding to less than the maximum amount of RAM your 
system has.  If you set it higher than the amount free memory, you might 
start getting virtual memory errors or you calculation might become very 
very slow when your system tries to compensate for the lack of fast RAM 
by caching memory to the slow hard disk drive.


On 11/6/2017 3:41 AM, Lyudmila Dobysheva wrote:

  6 Nov 2017, 14:37 +04:00 оfrom chin Sabsu :
Original RKMAX was 7.0 with  NMATMAX (NUM) up to 25000 (8000)  and the output 
is:
:RKM  : MATRIX SIZE 24995LOs:  10  RKM= 5.68  WEIGHT= 1.00  PGR:
  Original RKMAX was 7.0 with  NMATMAX (NUM) was 19000 (6000) and the output is:
:RKM  : MATRIX SIZE 18985LOs:  10  RKM= 5.18  WEIGHT= 1.00  PGR:

So you can see that rkm is actually increasing with your nmatmax. Either reduce 
rkmax or further increase the parameter.




On Monday, 6 November 2017 12:22 AM, chin Sabsu  wrote:


Dear Sir,

I am running the O2 molecule (F-cell) on an i5desktop with 8GM memory, Ubuntu 
16.04, Wien2k_17.1.

I am getting the error:  :WARN :  WARNING: RKmax reduced due to NMATMAX

After scratching the mailing list I supposed to overcome this issue if I 
increase NMATMAX and NUM value but it also not helpful.

My default NMATMAX (NUM) was 19000 (6000) I increased NMATMAX (NUM) up to 25000 
(8000) but still getting the same warning.


Please help me.

Cell size is 15Ang x 18 Ang with one k-point.

Thanks in Advance!

Regards
Chin


___
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


Lyudmila
___
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] :WARN : WARNING: RKmax reduced due to NMATMAX

[Gavin Abo]

To make that calculation feasible, it looks like you need a better 
computing system like a small cluster and mpi.


If ~8 GB is your total RAM, keep in mind that the Linux operating might 
use around 1 GB.  Using top [ 
https://superuser.com/questions/282867/why-does-the-memory-usage-in-top-not-add-up 
] or a system monitor [ 
https://askubuntu.com/questions/29757/what-can-replace-system-monitoring-in-the-top-gnome-panel-in-unity 
], you can check for any unnecessary processes and kill them to try to 
gain back more "free" memory.  Though, while this might help a little 
with memory, it likely won't help with the speed issue.


For speed, you likely need mpi or iterative diagonalization.  Are using 
iterative diagonalization (runsp -it) as was mentioned before:


http://zeus.theochem.tuwien.ac.at/pipermail/wien/2017-November/027303.html

If none of that helps, it looks like your stuck with doing less accurate 
calculations using small RKmax values.


On 11/6/2017 9:24 AM, chin Sabsu wrote:

Thank you Sir,


As per memory test, I got the figure: 46743  it means ~4.5 GB RAM is 
enough to run the case. But my system is having ~8 GB RAM:


7.6 GiB
Intel® Core™ i5-3570K CPU @ 3.40GHz × 4
Intel® Ivybridge Desktop


Dear Lyudmila Dobysheva

I increase NMATMAX upto45000 and NUME at 1. At this value, it gave 
me lapw1 error while at NMATMAX (NUME)=35000(8000) it taking too much 
time and even after three hrs lapw1 is running.


I want to keep consistent RKMAX with the literature. Otherwise, my job 
is to calculate the thermodynamic stability and for the same, I need 
the cohessive energy of O also.




Can I use RKmax 6.0 for O2 and for others I am tacking 7. If not then 
what should I do to run this O2 system?



Chin
___
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] A problem with band structure calculations: lapw1c

[Gavin Abo]

This might be because of the bugs that were reported before.  Are you 
using the fixed band.pl and scf.pl files from the post:



https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16069.html


On 11/8/2017 12:42 PM, Osama Yassin wrote:


Dear Prof Blaha


I'm doing some calculations on Fe-doped ZnS (cubic with SG 216) using 
Wien2k 17.1.


1- I set the k-mesh to 10x10x10 which correspond to 47 k-points.

2- The scf ended successfully.

3- Upon trying to plot the band structure I got the following error

forrtl: severe (24): end-of-file during read, unit 5, file 
/home/osama/osama.in1c
Image  PCRoutineLineSource
lapw1c 00461D5C  Unknown   Unknown  Unknown
lapw1c 00498EF9  Unknown   Unknown  Unknown
lapw1c 0043C27E  parallel_mp_init_  75  
modules_tmp_.F
lapw1c 0041677E  gtfnam_89  
gtfnam_tmp_.F
lapw1c 0042F625  MAIN__ 35  lapw1_tmp_.F
lapw1c 0040446E  Unknown   Unknown  Unknown
libc-2.23.so   2AEDC7201731  __libc_start_main Unknown  Unknown
lapw1c 00404369  Unknown   Unknown  Unknown
0.003u 0.003s 0:00.00 0.0%  0+0k 0+0io 0pf+0w
error: command   /home/osama/Wien2k171/lapw1c uplapw1.def   failed

this means it calls lapw1c instead of lapw1. Why this is happening 
since the calculations are in a complex mode?. in another words, why 
w2web does set the command line: x lapw1 -band -up instead of x lapw1c 
-band - up?



If the command *x ** lapw1c -band -up  is executed* *from the terminal 
everything run  without error.*


*
*

*Can you please clarify me this situation. Am I doing something wrong 
or it is a bug?.*


*
*

*Best wishes*

*
*

*Osama
*

___
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] :WARN : WARNING: RKmax reduced due to NMATMAX

[Gavin Abo]

Regarding the "foreach" error in WIEN2k 17.1 when starting directly an 
iterative diagonalization, I believe you can safely ignore it if it 
occurs only in cycle 1.  It looks like this is because there is not yet 
a case.vector/up/dn that the vec2old_lapw script can copy to 
case.vector.old/up.old/dn.old.  By ignoring the "foreach" message(s) and 
from what is seen in the terminal, it seems like it is performing full 
diagonalization in cycle 1 and continuing with iterative diagonalization 
[1] after that just fine:


username@computername:~/Desktop/TESTit$ ls
TESTit.struct
username@computername:~/Desktop/TESTit$ init_lapw -b
...
username@computername:~/Desktop/TESTit$ run_lapw -it
hup: Command not found.
 LAPW0 END
foreach: No match.
 LAPW1 END
 LAPW2 END
 CORE  END
 MIXER END
ec cc and fc_conv 0 1 1
in cycle 2    ETEST: 0   CTEST: 0
hup: Command not found.
 LAPW0 END
 LAPW1 END
 LAPW2 END
 CORE  END
 MIXER END
ec cc and fc_conv 0 1 1

A quote from [2], says:

"Often the best performance can be obtained by first running to a crude 
convergence, next doing a ``full diagonalization'' and finally 
continuing iteratively to self consistency. (e. g. use first: run_lapw 
-it -fc 10 and then run_lapw -it -fc 1)."


So, if you happen to start an iterative diagonalization calculation from 
a previous crude calculation, it looks like you will not have the 
"foreach" error:


username@computername:~/Desktop/TESTitcrude$ ls
TESTitcrude.struct
username@computername:~/Desktop/TESTitcrude$ init_lapw -b
...
username@computername:~/Desktop/TESTitcrude$ run_lapw -i 1
hup: Command not found.
 LAPW0 END
 LAPW1 END
 LAPW2 END
 CORE  END
 MIXER END
ec cc and fc_conv 0 1 1

>   energy in SCF NOT CONVERGED
username@computername:~/Desktop/TESTitcrude$ save_lapw -d crude_calc
...
username@computername:~/Desktop/TESTitcrude$ run_lapw -it
hup: Command not found.
 LAPW0 END
 LAPW1 END
 LAPW2 END
 CORE  END
 MIXER END
ec cc and fc_conv 0 1 1
in cycle 2    ETEST: 0   CTEST: 0
hup: Command not found.
 LAPW0 END
 LAPW1 END
 LAPW2 END
 CORE  END
 MIXER END
ec cc and fc_conv 0 1 1

[1] 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2007-September/009717.html
[2] 
http://68.98.155.183:81/usersguide/7_SCF_cycle.html#SECTION0542


On 11/7/2017 6:43 AM, chin Sabsu wrote:

Thank you Sir,

runsp_lapw -it gave me an error:  foreach. So I am running with 
runsp_lapw   script.


If I run it with Rkmax=6 then it does not show me any warning. At the 
FAQ of Wienk page standard RMT for O is 6.5 but it also gave me RKmax 
reduced warning.


If someone advises me that I can take RKMAX=6 for O2 system then only 
I can proceed.


I do not have any good facility.
___
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] Large cell instgen_lapw : word too long

[Gavin Abo]

That error message looks like it might be from Open MPI:

https://github.com/open-mpi/ompi/issues/3380

Meaning, if you intended to compile with intelmpi, it looks like you may 
have something compiled incorrectly with Open MPI instead of with 
intelmpi.  Did you use the right blacs library in the parallel compiler 
settings in siteconfig for intelmpi?  Did you compile FFTW3 with intelmpi?


On 11/10/2017 8:26 AM, Chouaib AHMANI FERDI wrote:

Dear all,

Thank you for the replies.

I installed intel parallel studio 2017, which contains a fortran 
compiler, MKL, Scalapack, blacs, intelmpi, then I configured FFTW3 so 
that F77 compiler is ifort and enabled mpi. After that i compiled the 
wien2k programs with no error in sight, so far so good.


I wanted now to test it on a 4 cores machine Corei3 (I did not want to 
risk anything with the program already installed in the 32 cores 
shared memory machine).
I set 10 kpoints (3 inequivalent atoms for the test) which left me 
with klist = 1

I set .machines file like so :
1:localhost:2 #so that 2 cores would take the job

The SCF stops with this error in the dayfile :

running LAPW1 in parallel mode (using .machines)
1 number_of_parallel_jobs
localhost localhost(1)-
Primary job terminated normally, but 1 process returned a non-zero 
exit code.. Per user-direction, the job has been aborted.---

-
mpirun detected that one or more processes exited with non-zero 
status, thus the job to be terminated. The first process to do so was:


Exit code: 127
...
LAPW2 crashed!

FYI : I tried the OMP_NUM_THREADS=2 and it worked ~ 189 % CPU
But giving 1 kpoint job to 2 cores has not.

I red all the mailing list I could find about this subject but none of 
them really helped.


May someone point out where is the problem ?

Faithfylly,
___
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] Generating struct from space group and coordinates

[Gavin Abo]

I did this rather quickly. So you will have to double check if it looks 
correct or not.



It looks like both your lattice parameters and atomic positions are in 
the R-3 hexagonal setting.  So enter in SETSTRU [ 
http://www.cryst.ehu.es/cryst/setstru.html ]:



# Comments start with #
# Space Group ITA number
148
# Lattice parameters
6.8275 6.8275 20.5619 90 90 120
# Number of independent atoms in the asymmetric unit
3
# [atom type] [number] [WP] [x] [y] [z]
Te 1 - 0.00367 0.36633 0.08513
Ge 2 - 0   0   0.059
Cr 3 - 0   0   0.3302


Click Transform Structure


Select R-3: h for initial and R-3:r for Final.  Then, SETSTRU should 
output the rhombohedral settings:



Final Setting: R-3:r (148)148 #R-3:r
7.9066 7.9066 7.9066 51.16 51.16 51.16
3
Te    1    -    0.088800    0.447790    -0.281200
Ge    2    -    0.059000    0.059000    0.059000
Cr    3    -    0.330200    0.330200    0.330200

In StructGen, select 148_R-3 for the spacegroup.


Enter the "hexagonal" for the lattice parameters:


a = 6.8275 ang, b = 6.8275 ang, c = 20.5619 ang, alpha = 90 deg, beta = 
90 deg, gamma = 120 deg



For the atomic positions, enter the inequivalent "rhombohedral" positions:


Te 0.088800    0.447790    -0.281200
Ge 0.059000    0.059000    0.059000
Cr 0.330200    0.330200    0.330200


After you save the structure and come back and view in StructGen again, 
take note of the StructGen message under Inequivalent Atoms:


"positions must be specified in rhombohedral coordinates"


See if the structure looks okay now (for example in XCrySDen or VESTA).

Reference: 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12704.html


On 11/12/2017 8:55 AM, Md. Fhokrul Islam wrote:


Dear Wien2k users,


I am trying to build the struct file of Cr2Ge2Te6 crystal from space 
group and atomic position using w2web.

I have obtained the information about this crystal from springer database
http://materials.springer.com/isp/crystallographic/docs/sd_1622000

Space group: 148 (R-3 h)
Lattice constants a, b, c:  0.68275 (nm), 0.68275 (nm), 2.05619 (nm)
Angle alpha, beta, gamma:  90, 90, 120

atom  Wychoff           x         y                z
Te   18f 0.00367 0.36633 0.08513
Ge      6c 0         0       0.059
Cr    6c 0 0         0.3302

But if I use the coordinates of each of these three atoms and space 
group in w2web, I don't get the correct crystal structure.
Although I have managed to get the structure from other online sources 
but I am wondering if anyone can tell me how can

I use these info to generate the structure usingw2web.


Thanks,
Fhokrul
___
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] HDLO and LVNS

[Gavin Abo]

I believe HD stands for high derivative.  See where it says high 
derivative LO (HDLO) in the Computer Physics Communications Vol. 220 p. 
230 (2017) article:



https://doi.org/10.1016/j.cpc.2017.07.008

On 11/12/2017 8:22 AM, delamora wrote:

Dear Peter Blaha,
In the 17.1 version the HDLO and LVNS appear;
    atom 1 has a large sphere , consider setting HDLOs and/or 
larger LVNS

I searched in the usersguide and I did not find much information;
ForLVNS there is no explanation, all I found is in 5.1.3;
-lvns L -> in batch mode: LVNS_max (default: 4)
and for HDLO it is not clear what 'HD' stand for

Cheers

Pablo de la Mora


___
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