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

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

[shaymlal dayananda]

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



 

   

 On Sunday, July 9, 2017 10:10 AM, Gavin Abo  wrote:
 

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

Re: [Wien] Charge convergence

[Luis Ogando]

Dear Prof. Marks, Blaha and Dobysheva,

   First of all, thank you very much for your comments.

*Dear Prof. Marks:*

1) The warning message is related to

WARNING: RKmax reduced due to NMATMAX

but I am aware of this. No reasons to worry about.

2) My system is a molecule (as pointed by Prof. Blaha) with 60 C atoms, 5 N
atoms and 35 H atoms. The cell has vacuum along two of the three directions.
   I believe that the large changes in atomic positions are related to
rotations of the H bonds (is there a way to check it ?). It may explain the
"significant" changes in :DIS without disturbing the energy. Do you believe
that this can also explain the small GREED value ?  MSR1a certainly found
soft modes.


*Dear Prof. Blaha:*
1) I thought that once the -cc and -ec criteria are fulfilled, the
optimization process stops changing the structure. Now I know that the stop
criterium is more complex than this (obviously, the forces have to be taken
into account in a minimization process)


*Dear Prof. Dobysheva:*
1) Thank you for your clarification. It will be useful.

   All the best,
 Luis



2017-07-12 7:35 GMT-03:00 Lyudmila Dobysheva :

> 11.07.2017 23:31, Luis Ogando wrote:
>
>> :DIS  :  CHARGE DISTANCE   ( 0.0014560 for atom   33 spin 1)
>> :DIS  :  CHARGE DISTANCE   ( 0.0014130 for atom   33 spin 1)
>>  >> On Tue, Jul 11, 2017 at 9:40 AM, Luis Ogando wrote:
>>
>>> The energy is finally converged, but the charge is not despite the
> fact that its change is below the limit in the last 10 iterations.
>
 ...
>
>> > CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004560
 > CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004130

> If I am not wrong, the convergence is achieved after 3 consecutive
> iterations with changes below the limit, but in my case this is
> happening for more than 10 iterations  without convergence.
>
 A very small addition: dayfile prints here not :DIS, but :DIS minus
> 0.001
> So, these lines show that the criterium ":DIS smaller than 0.001" is not
> fulfilled yet, the convergence is achieved when negative values appear here
> three times.
>
> Best wishes
>   Lyudmila Dobysheva
> --
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
> 426001 Izhevsk, ul.Kirova 132
> RUSSIA
> --
> Tel.:7(3412) 432459(office), 722529(Fax)
> E-mail: l...@ftiudm.ru, lyuk...@mail.ru (office)
> lyuk...@gmail.com (home)
> Skype:  lyuka17 (home), lyuka18 (office)
> http://ftiudm.ru/content/view/25/103/lang,english/
> --
>
___
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 confirmation is needed about mbj+so

[tran]

As I said in my previous email, you can not do minimization
with SO (except if SO is switched off on atoms which are moving
in the unit cell). So, do not use "-so" with "min".


On Wednesday 2017-07-12 15:22, fatima DFT wrote:


Date: Wed, 12 Jul 2017 15:22:33
From: fatima DFT 
Reply-To: A Mailing list for WIEN2k users 
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] A confirmation is needed about mbj+so

Thank you Sir Dr. Tran for reply, I still have some doubts.



   started min -j "run_lapw -ec xxx -cc xxx -fc x -i x"

   My first question:
   Is the above process is okay, can we do that? 
   >From above method, my band gap is in the reasonable agreement with 
Experimental band gap (still
   optimization is going on).


 Why are you executing initso_lapw since the option -so is not used?


I forgot to mention -so with above command. 

 The best is to do first a geometry optimization with a GGA like
 PBE or PBEsol and without SO. Then, at this optimized geometry
 (or at the experimental one if available) do the calculations that you
 want (GGA+SO, mBJ, mBJ+SO).


Okay, so my question is still need one more statment: I have done geometry 
optimization with PBE then applied mBJ. 

Then I have completed -SO calculation in the same directrity where I have done mBJ. SO 
with min -j "run_lapw -so" gave me
accurate band gap while -SO without "min -j" switch gave me overestimated band 
gap.

So my test says: SO with min -j "run_lapw -so *" on a [PBE(opt geometry) + 
mBJ] calculation is the right choice and this
is mBJ+SO. In this case we can do geometry optimization by fixing positions of 
some atoms.

In the second way where we do a geometry optimization with PBE/LDA and then do 
mBJ+SO following below process:

save_lapw
initso_lapw
init_mbj_lapw
run_lapw -so -i 1 -NI (we may avoide -so here)
init_mbj_lapw
0/1/2/3
min -j "run_lapw -so -i 1"  Insted of this step we need to do only 
run_lapw -so .. as mBJ ans -SO are about run in
a single scf step and we can not apply -fc on mBJ.

Sincerely

Ms. 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



___
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 confirmation is needed about mbj+so

[fatima DFT]

Thank you Sir Dr. Tran for reply,
I still have some doubts.



> started min -j "run_lapw -ec xxx -cc xxx -fc x -i x"
>>
>> My first question:
>> Is the above process is okay, can we do that?
>> From above method, my band gap is in the reasonable agreement with
>> Experimental band gap (still optimization is going on).
>>
>
> Why are you executing initso_lapw since the option -so is not used?


I forgot to mention -so with above command.

The best is to do first a geometry optimization with a GGA like
> PBE or PBEsol and without SO. Then, at this optimized geometry
> (or at the experimental one if available) do the calculations that you
> want (GGA+SO, mBJ, mBJ+SO).
>

Okay, so my question is still need one more statment: I have done geometry
optimization with PBE then applied mBJ.

Then I have completed -SO calculation in the same directrity where I have
done mBJ. SO with min -j "run_lapw -so" gave me accurate band gap while
-SO without "min -j" switch gave me overestimated band gap.

So my test says: SO with min -j "run_lapw -so *" on a [PBE(opt
geometry) + mBJ] calculation is the right choice and this is mBJ+SO. In
this case we can do geometry optimization by fixing positions of some atoms.

In the second way where we do a geometry optimization with PBE/LDA and then
do mBJ+SO following below process:

save_lapw
initso_lapw
init_mbj_lapw
run_lapw -so -i 1 -NI (we may avoide -so here)
init_mbj_lapw
0/1/2/3
min -j "run_lapw -so -i 1"  Insted of this step we need to do only
run_lapw -so .. as mBJ ans -SO are about run in a single scf step and
we can not apply -fc on mBJ.

Sincerely

Ms. 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
>
>
___
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] Charge convergence

[Lyudmila Dobysheva]

11.07.2017 23:31, Luis Ogando wrote:

:DIS  :  CHARGE DISTANCE   ( 0.0014560 for atom   33 spin 1)
:DIS  :  CHARGE DISTANCE   ( 0.0014130 for atom   33 spin 1)
 >> On Tue, Jul 11, 2017 at 9:40 AM, Luis Ogando wrote:

The energy is finally converged, but the charge is not despite the
fact that its change is below the limit in the last 10 iterations.

...

> CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004560
> CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004130

If I am not wrong, the convergence is achieved after 3 consecutive
iterations with changes below the limit, but in my case this is
happening for more than 10 iterations  without convergence.


A very small addition: dayfile prints here not :DIS, but :DIS minus 0.001
So, these lines show that the criterium ":DIS smaller than 0.001" is not 
fulfilled yet, the convergence is achieved when negative values appear.


Best wishes
  Lyudmila Dobysheva
--
Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
426001 Izhevsk, ul.Kirova 132
RUSSIA
--
Tel.:7(3412) 432459(office), 722529(Fax)
E-mail: l...@ftiudm.ru, lyuk...@mail.ru (office)
lyuk...@gmail.com (home)
Skype:  lyuka17 (home), lyuka18 (office)
http://ftiudm.ru/content/view/25/103/lang,english/
--
___
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 confirmation is needed about mbj+so

[tran]

I just finished some calculation with PBE/PBE+SO/mBJ+SO.
I know that with mBJ we can not do force optimization.
I know how to do force optimization with -SO


Forces with SO are not available in WIEN2k. Thus, optimization (min)
and SO can be used together only if SO is switched off on the
atoms which require an optimization of their positions.


I have done PBE+mBJ calculation 
save_lapw -d case
initso_lapw and fixed position for some atoms and then 
started min -j "run_lapw -ec xxx -cc xxx -fc x -i x"

My first question:
Is the above process is okay, can we do that? 
From above method, my band gap is in the reasonable agreement with Experimental 
band gap (still optimization is going on).


Why are you executing initso_lapw since the option -so is not used?


As we know the standard process for the mBJ is:
1.init_mbj_lapw
2. run_lapw -i 1 -NI
3. save_lapw **
4. init_mbj_lapw
5. 0/1/2/3
6. run_lapw ...

So my second question: 
If we do a general mBJ and then do -SO calculation after save_lapw in mBJ directory then 
-so will be assumed from the step 6 only. What would be the effect of step 2 
"run_lapw -i 1 -NI" (that have
been done in the case of mBJ and the -SO assumed from step 6).
From above two question, I am not able to find a proper way to follow 
(mBJ)+(SO) or (mBJ+SO)


If your question is "Does it matter to use -so in step 2?", then
the answer is no.


We can do in two ways if I understood it correctly,  first run an mBJ and then 
do scf with -SO is different then doing mBJ+SO in a single scf step. From one 
we can relax the structure while from two
we can not.


The best is to do first a geometry optimization with a GGA like
PBE or PBEsol and without SO. Then, at this optimized geometry
(or at the experimental one if available) do the calculations that you
want (GGA+SO, mBJ, mBJ+SO).___
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