[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20170712/799f80f4/attachment-0001.html>