Re: [Wien] Problem with k-parallel

[Peter Blaha]

Just put it to /tmp.

(There was a suggestion in the mailing list that someone wanted to 
change /tmp to some other directory, which is tedious in the old 
versions. With a variable $tmp_dir  this is "easy" to change and will be 
active in the next release.



On 03/09/2016 04:27 PM, Maciej Polak wrote:

Dear Prof. Blaha,

Thank you for your answer. I found the appropriate part of my lapw2para and 
substituted it with what you suggested.
However, one of the changes that I notice here is that you changed tmp for 
$tmp_dir. This $tmp_dir is a new variable which is not recognized by my script 
(tmp_dir: Undefined variable.). What is the meaning of this variable?

Thank you again for finding the time to reply to my email.

Best regards,

Maciej Polak

P.S In case you need it, I post the unmodified part of my code:


set i = 1
while ($i <= $maxproc)
# if ($debug > 0) echo -n "$i "
  cp $def.def /tmp/.tmp.$user.$$
  #subsituting in files:
  cat  /tmp/.tmp1.$user.$$
  sed "s/vector_${i}dn_$i/vectordn_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
  sed "s/vector_${i}up_$i/vectorup_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
  sed "s/vector_${i}so_$i/vectorso_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
  sed "s/energy_${i}up_$i/energyup_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
  sed "s/energy_${i}dn_$i/energydn_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
  sed "s/energy_${i}so_$i/energyso_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
  sed "s/energyso_${i}dn_$i/energysodn_${i}/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$u$
  sed "s/energy_${i}dum_$i/energydum_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$
  sed "s/vector_${i}so_${i}dn_$i/vectorsodn_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2$
  sed "s/vector_${i}dum_${i}dn_$i/vectordumdn_$i/" /tmp/.tmp2.$user.$$>"$def"_$$
  @ i ++
end


W dniu 09/03/16 13:45 Peter Blaha  napisał:


Hi,

Yes, we had have recently also such a problem. It comes from slow disk I/O.

A fie like /tmp/.tmp2.mpolak.50255

is a temporary file created by lapw2para and is used when we modify the 
lapw2_xx.def files by a couple of sed commands.

Because of this I've reduced the sed commands in my version of lapw2para. 
Unfortunately, I cannot post the script because it will not be compatible with 
your WIEN2k version, but I can tell you what we did and since then these errors 
did not show up anymore.

Please identify the following lines in your lapw2para and modify it like shown 
below:
...
#creating def files
set i = 1
while ($i <= $maxproc)
# if ($debug > 0) echo -n "$i "
cp $def.def $tmp_dir/.tmp.$user.$$
#subsituting in files:
cat <$tmp_dir/.script.$user.$$
s/vectorso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/vectorso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/vectordum$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/vectordum$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/vector$dnup'/vector${dnup}_$i'/w $tmp_dir/.mist.$user.$$
s/vector$updn'/vector${updn}_$i'/w $tmp_dir/.mist.$user.$$
s/energyso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/energyso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/energydum/&_$i/w $tmp_dir/.mist.$user.$$
s/energy$dnup'/energy${dnup}_$i'/w $tmp_dir/.mist.$user.$$
s/energy$updn'/energy${updn}_$i'/w $tmp_dir/.mist.$user.$$
s/\(weigh$dnup\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
s/\(weigh$updn\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
s/\(weightaverso$updn\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
s/normso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/normso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/output2${updn}$eece/&_$i/w $tmp_dir/.mist.$user.$$
s/clmval${updn}$eece/&_$i/w $tmp_dir/.mist.$user.$$
s/vrespval$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/dmat$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/scf2$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/help$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/almblm$updn/&_$i/w $tmp_dir/.mist.$user.$$

theend

sed -f $tmp_dir/.script.$user.$$ $tmp_dir/.tmp.$user.$$ > 
$tmp_dir/.tmp1.$user.$$
mv $tmp_dir/.tmp1.$user.$$ "$def"_$i.def

# sed 

Re: [Wien] Problem with k-parallel

[Maciej Polak]

Dear Prof. Blaha,

Thank you for your answer. I found the appropriate part of my lapw2para and 
substituted it with what you suggested.
However, one of the changes that I notice here is that you changed tmp for 
$tmp_dir. This $tmp_dir is a new variable which is not recognized by my script 
(tmp_dir: Undefined variable.). What is the meaning of this variable?

Thank you again for finding the time to reply to my email.

Best regards,

Maciej Polak

P.S In case you need it, I post the unmodified part of my code:


set i = 1
while ($i <= $maxproc)
# if ($debug > 0) echo -n "$i "
 cp $def.def /tmp/.tmp.$user.$$
 #subsituting in files:
 cat  /tmp/.tmp1.$user.$$
 sed "s/vector_${i}dn_$i/vectordn_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
 sed "s/vector_${i}up_$i/vectorup_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
 sed "s/vector_${i}so_$i/vectorso_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
 sed "s/energy_${i}up_$i/energyup_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
 sed "s/energy_${i}dn_$i/energydn_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
 sed "s/energy_${i}so_$i/energyso_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
 sed "s/energyso_${i}dn_$i/energysodn_${i}/" /tmp/.tmp1.$user.$$>/tmp/.tmp2.$u$
 sed "s/energy_${i}dum_$i/energydum_$i/" /tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$
 sed "s/vector_${i}so_${i}dn_$i/vectorsodn_$i/" /tmp/.tmp1.$user.$$>/tmp/.tmp2$
 sed "s/vector_${i}dum_${i}dn_$i/vectordumdn_$i/" /tmp/.tmp2.$user.$$>"$def"_$$
 @ i ++
end


W dniu 09/03/16 13:45 Peter Blaha  napisał:
> 
> Hi,
> 
> Yes, we had have recently also such a problem. It comes from slow disk I/O.
> 
> A fie like /tmp/.tmp2.mpolak.50255
> 
> is a temporary file created by lapw2para and is used when we modify the 
> lapw2_xx.def files by a couple of sed commands.
> 
> Because of this I've reduced the sed commands in my version of lapw2para. 
> Unfortunately, I cannot post the script because it will not be compatible 
> with your WIEN2k version, but I can tell you what we did and since then these 
> errors did not show up anymore.
> 
> Please identify the following lines in your lapw2para and modify it like 
> shown below:
> ...
> #creating def files
> set i = 1
> while ($i <= $maxproc)
> # if ($debug > 0) echo -n "$i "
> cp $def.def $tmp_dir/.tmp.$user.$$
> #subsituting in files:
> cat <$tmp_dir/.script.$user.$$
> s/vectorso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
> s/vectorso$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/vectordum$dnup/&_$i/w $tmp_dir/.mist.$user.$$
> s/vectordum$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/vector$dnup'/vector${dnup}_$i'/w $tmp_dir/.mist.$user.$$
> s/vector$updn'/vector${updn}_$i'/w $tmp_dir/.mist.$user.$$
> s/energyso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
> s/energyso$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/energydum/&_$i/w $tmp_dir/.mist.$user.$$
> s/energy$dnup'/energy${dnup}_$i'/w $tmp_dir/.mist.$user.$$
> s/energy$updn'/energy${updn}_$i'/w $tmp_dir/.mist.$user.$$
> s/\(weigh$dnup\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
> s/\(weigh$updn\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
> s/\(weightaverso$updn\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
> s/normso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
> s/normso$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/output2${updn}$eece/&_$i/w $tmp_dir/.mist.$user.$$
> s/clmval${updn}$eece/&_$i/w $tmp_dir/.mist.$user.$$
> s/vrespval$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/dmat$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/scf2$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/help$updn/&_$i/w $tmp_dir/.mist.$user.$$
> s/almblm$updn/&_$i/w $tmp_dir/.mist.$user.$$
> 
> theend
> 
> sed -f $tmp_dir/.script.$user.$$ $tmp_dir/.tmp.$user.$$ > 
> $tmp_dir/.tmp1.$user.$$
> mv $tmp_dir/.tmp1.$user.$$ "$def"_$i.def
> 
> # sed "s/vector_${i}dn_$i/vectordn_$i/" 
> $tmp_dir/.tmp1.$user.$$>$tmp_dir/.tmp2.$user.$$
> # sed "s/vector_${i}up_$i/vectorup_$i/" 
> $tmp_dir/.tmp2.$user.$$>$tmp_dir/.tmp1.$user.$$
> # sed 

Re: [Wien] Regarding mBJ plus U

[sikander Azam]

Dear Gavin abin
The constant value is not from beginning ,i get the constant value after
120 cycles.
Regards
Sikander
On 9 Mar 2016 06:28, "Peter Blaha"  wrote:

> mBJ works very well for bandgaps of s,p and even 3d electrons. HOwever, it
> is too weak to handle the atomic-like 4f electrons properly.
>
> xxx+U can handle the 4f electrons, but still very often the gap is too
> small (because it is then determined by the "other electrons" in 4f
> compounds), or one would need an unphysically large value of U.
>
> A combination of mBJ+U with a rather moderate U value looks quite good in
> many cases 
>
> Am 08.03.2016 um 22:37 schrieb Fecher, Gerhard:
>
>> May be it is off-topic, but what is the physics behind mBJ+U ?
>> or is that just a question on why a feature of Wien2k does not work as
>> expected ?
>>
>> 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-boun...@zeus.theochem.tuwien.ac.at [
>> wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Laurence Marks [
>> l-ma...@northwestern.edu]
>> Gesendet: Dienstag, 8. März 2016 18:20
>> An: A Mailing list for WIEN2k users
>> Betreff: Re: [Wien] Regarding mBJ plus U
>>
>> Repeating myself, please run the command I sent. All anyone can do with
>> the information you have provided to date is guess, probably wrong.
>>
>> On Tue, Mar 8, 2016 at 10:37 AM, sikander Azam <
>> sikander.physi...@gmail.com> wrote:
>> Dear Laurence Marks<
>> https://plus.google.com/u/0/115978139881852385108?prsrc=4>
>> Thanks for your reply, Sir, actually we did mBJ+U calculations for parent
>> compound. We got the convergence. Then we produce the vacancies in the
>> parent compound, for that when we run the mBJ+U we get this problem i.e.
>> the energy is not converged.
>> So this is the only worry that why our calculations is not converging.
>> Firstly we give 60 cycles, then 80, but this also didn't solve our problem
>> i.e. we didnt got the convergence.
>>
>>
>> Note: By grep :DIS *.scf we get 0.21815 0.21815 0.21815 ..20 times
>> and by grep :ENE *.scf we get 0.5014 0.5014
>> .20 times
>>
>> with best regard
>> Azam
>>
>>
>>
>>
>> On Tue, Mar 8, 2016 at 6:31 AM, Laurence Marks > > wrote:
>> Please run the command below and post the result; it will provide some
>> information about what is going on (although it may not answer everything).
>> You can either run it in a linux shell (under bash) or paste it to a file
>> (e.g. ~/bin/Check, $WIENROOT/Check or $WIENROOT/Check_lapw), do a "chmod
>> a+x file" then just do "Check" (or whatever name you used).
>>
>> tail -n 10 *.scf $1 | grep -e :ADIST -e :DIR -e :MV -e GREED -e :FRMS
>> -e :ENE -e :CHARG -e PRATT \
>> -e :DIS -e "MIXING SC" -e ":RANK" -e PLANE | \
>> grep -v -e "with 1.0" -e scheme -e CONTRIBUTION | \
>> tail -n 50
>>
>>
>> On Tue, Mar 8, 2016 at 8:17 AM, sikander Azam <
>> sikander.physi...@gmail.com> wrote:
>>
>> Dear Gavin abin
>> Thanks Sir for the reply, but I ran it for 60 cycle two times with
>> commands
>> runsp-lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
>> Regards
>> Sikander
>>
>> On 8 Mar 2016 14:36, "Gavin Abo"  gs...@crimson.ua.edu>> wrote:
>> How many cycles did the calculation run for and what did you set for the
>> maximum number of iterations (i.e., the number that you set for the -i
>> option)?
>>
>> If you did not use the -i option, just
>>
>> run_lapw or runsp_lapw
>>
>> The program will run up to 40 cycles by default.
>>
>> It is common for a mBJ calculation to not be able to reach converge
>> within 40 cycles [1-3], which is why it suggests during the running of
>> init_mbj that you increase the maximum number of interactions.  The example
>> the init_mbj script gives is to set -i to 80:
>>
>> run_lapw -i 80 (or runsp_lapw -i 80)
>>
>> [1]
>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg06119.html
>> [2]
>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09879.html
>> [3]
>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg02833.html
>>
>> On 3/8/2016 3:51 AM, sikander Azam wrote:
>>
>> Dear all
>> I am doing calculations using mBJ plus U, but when the calculations
>> complete, I get that energy is not converged. But when I check the SCF file
>> I get a constant value of 0.52341000 for energy convergence and 0.34568
>> values for charge convergence.
>> So I don't understand on 

Re: [Wien] Regarding mBJ plus U

[Laurence Marks]

Short of logging in to your computer myself I cannot do anything. You
probably pasted it in wrong, you need to investigate what you did wrong.

On Wed, Mar 9, 2016 at 7:53 AM, sikander Azam 
wrote:

> Dear laurence Marks
> I am extremely sorry, this commands doesn't work with me. Please could you
> make it easy for me.
> Regards
> Sikander
> On 8 Mar 2016 15:36, "Laurence Marks"  wrote:
>
>> Please run the command below and post the result; it will provide some
>> information about what is going on (although it may not answer everything).
>> You can either run it in a linux shell (under bash) or paste it to a file
>> (e.g. ~/bin/Check, $WIENROOT/Check or $WIENROOT/Check_lapw), do a "chmod
>> a+x file" then just do "Check" (or whatever name you used).
>>
>> tail -n 10 *.scf $1 | grep -e :ADIST -e :DIR -e :MV -e GREED -e :FRMS
>> -e :ENE -e :CHARG -e PRATT \
>> -e :DIS -e "MIXING SC" -e ":RANK" -e PLANE | \
>> grep -v -e "with 1.0" -e scheme -e CONTRIBUTION | \
>> tail -n 50
>>
>>
>> On Tue, Mar 8, 2016 at 8:17 AM, sikander Azam <
>> sikander.physi...@gmail.com> wrote:
>>
>>> Dear Gavin abin
>>> Thanks Sir for the reply, but I ran it for 60 cycle two times with
>>> commands
>>> runsp-lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
>>> Regards
>>> Sikander
>>> On 8 Mar 2016 14:36, "Gavin Abo"  wrote:
>>>
 How many cycles did the calculation run for and what did you set for
 the maximum number of iterations (i.e., the number that you set for the -i
 option)?

 If you did not use the -i option, just

 run_lapw or runsp_lapw

 The program will run up to 40 cycles by default.

 It is common for a mBJ calculation to not be able to reach converge
 within 40 cycles [1-3], which is why it suggests during the running of
 init_mbj that you increase the maximum number of interactions.  The example
 the init_mbj script gives is to set -i to 80:

 run_lapw -i 80 (or runsp_lapw -i 80)

 [1]
 http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg06119.html
 [2]
 http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09879.html
 [3]
 http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg02833.html

 On 3/8/2016 3:51 AM, sikander Azam wrote:

>
> Dear all
> I am doing calculations using mBJ plus U, but when the calculations
> complete, I get that energy is not converged. But when I check the SCF 
> file
> I get a constant value of 0.52341000 for energy convergence and 
> 0.34568
> values for charge convergence.
> So I don't understand on the logic. please help me that what should I
> do. Should I continue with these calculations and find the properties or
> some one will give me some suggestions.
> Thanks in advance.
> Regards
> Azam
>
> ___
 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

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


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

Re: [Wien] Regarding mBJ plus U

[sikander Azam]

Dear P . Blaha
Sir, I don't have f state, I applied on Ti , in which I have d-state.
Regards
Sikander
On 9 Mar 2016 06:28, "Peter Blaha"  wrote:

> mBJ works very well for bandgaps of s,p and even 3d electrons. HOwever, it
> is too weak to handle the atomic-like 4f electrons properly.
>
> xxx+U can handle the 4f electrons, but still very often the gap is too
> small (because it is then determined by the "other electrons" in 4f
> compounds), or one would need an unphysically large value of U.
>
> A combination of mBJ+U with a rather moderate U value looks quite good in
> many cases 
>
> Am 08.03.2016 um 22:37 schrieb Fecher, Gerhard:
>
>> May be it is off-topic, but what is the physics behind mBJ+U ?
>> or is that just a question on why a feature of Wien2k does not work as
>> expected ?
>>
>> 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-boun...@zeus.theochem.tuwien.ac.at [
>> wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Laurence Marks [
>> l-ma...@northwestern.edu]
>> Gesendet: Dienstag, 8. März 2016 18:20
>> An: A Mailing list for WIEN2k users
>> Betreff: Re: [Wien] Regarding mBJ plus U
>>
>> Repeating myself, please run the command I sent. All anyone can do with
>> the information you have provided to date is guess, probably wrong.
>>
>> On Tue, Mar 8, 2016 at 10:37 AM, sikander Azam <
>> sikander.physi...@gmail.com> wrote:
>> Dear Laurence Marks<
>> https://plus.google.com/u/0/115978139881852385108?prsrc=4>
>> Thanks for your reply, Sir, actually we did mBJ+U calculations for parent
>> compound. We got the convergence. Then we produce the vacancies in the
>> parent compound, for that when we run the mBJ+U we get this problem i.e.
>> the energy is not converged.
>> So this is the only worry that why our calculations is not converging.
>> Firstly we give 60 cycles, then 80, but this also didn't solve our problem
>> i.e. we didnt got the convergence.
>>
>>
>> Note: By grep :DIS *.scf we get 0.21815 0.21815 0.21815 ..20 times
>> and by grep :ENE *.scf we get 0.5014 0.5014
>> .20 times
>>
>> with best regard
>> Azam
>>
>>
>>
>>
>> On Tue, Mar 8, 2016 at 6:31 AM, Laurence Marks > > wrote:
>> Please run the command below and post the result; it will provide some
>> information about what is going on (although it may not answer everything).
>> You can either run it in a linux shell (under bash) or paste it to a file
>> (e.g. ~/bin/Check, $WIENROOT/Check or $WIENROOT/Check_lapw), do a "chmod
>> a+x file" then just do "Check" (or whatever name you used).
>>
>> tail -n 10 *.scf $1 | grep -e :ADIST -e :DIR -e :MV -e GREED -e :FRMS
>> -e :ENE -e :CHARG -e PRATT \
>> -e :DIS -e "MIXING SC" -e ":RANK" -e PLANE | \
>> grep -v -e "with 1.0" -e scheme -e CONTRIBUTION | \
>> tail -n 50
>>
>>
>> On Tue, Mar 8, 2016 at 8:17 AM, sikander Azam <
>> sikander.physi...@gmail.com> wrote:
>>
>> Dear Gavin abin
>> Thanks Sir for the reply, but I ran it for 60 cycle two times with
>> commands
>> runsp-lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
>> Regards
>> Sikander
>>
>> On 8 Mar 2016 14:36, "Gavin Abo"  gs...@crimson.ua.edu>> wrote:
>> How many cycles did the calculation run for and what did you set for the
>> maximum number of iterations (i.e., the number that you set for the -i
>> option)?
>>
>> If you did not use the -i option, just
>>
>> run_lapw or runsp_lapw
>>
>> The program will run up to 40 cycles by default.
>>
>> It is common for a mBJ calculation to not be able to reach converge
>> within 40 cycles [1-3], which is why it suggests during the running of
>> init_mbj that you increase the maximum number of interactions.  The example
>> the init_mbj script gives is to set -i to 80:
>>
>> run_lapw -i 80 (or runsp_lapw -i 80)
>>
>> [1]
>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg06119.html
>> [2]
>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09879.html
>> [3]
>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg02833.html
>>
>> On 3/8/2016 3:51 AM, sikander Azam wrote:
>>
>> Dear all
>> I am doing calculations using mBJ plus U, but when the calculations
>> complete, I get that energy is not converged. But when I check the SCF file
>> I get a constant value of 0.52341000 for energy convergence and 0.34568
>> values for charge convergence.
>> So I don't understand on the logic. 

Re: [Wien] Regarding mBJ plus U

[sikander Azam]

Dear laurence Marks
I am extremely sorry, this commands doesn't work with me. Please could you
make it easy for me.
Regards
Sikander
On 8 Mar 2016 15:36, "Laurence Marks"  wrote:

> Please run the command below and post the result; it will provide some
> information about what is going on (although it may not answer everything).
> You can either run it in a linux shell (under bash) or paste it to a file
> (e.g. ~/bin/Check, $WIENROOT/Check or $WIENROOT/Check_lapw), do a "chmod
> a+x file" then just do "Check" (or whatever name you used).
>
> tail -n 10 *.scf $1 | grep -e :ADIST -e :DIR -e :MV -e GREED -e :FRMS
> -e :ENE -e :CHARG -e PRATT \
> -e :DIS -e "MIXING SC" -e ":RANK" -e PLANE | \
> grep -v -e "with 1.0" -e scheme -e CONTRIBUTION | \
> tail -n 50
>
>
> On Tue, Mar 8, 2016 at 8:17 AM, sikander Azam  > wrote:
>
>> Dear Gavin abin
>> Thanks Sir for the reply, but I ran it for 60 cycle two times with
>> commands
>> runsp-lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
>> Regards
>> Sikander
>> On 8 Mar 2016 14:36, "Gavin Abo"  wrote:
>>
>>> How many cycles did the calculation run for and what did you set for the
>>> maximum number of iterations (i.e., the number that you set for the -i
>>> option)?
>>>
>>> If you did not use the -i option, just
>>>
>>> run_lapw or runsp_lapw
>>>
>>> The program will run up to 40 cycles by default.
>>>
>>> It is common for a mBJ calculation to not be able to reach converge
>>> within 40 cycles [1-3], which is why it suggests during the running of
>>> init_mbj that you increase the maximum number of interactions.  The example
>>> the init_mbj script gives is to set -i to 80:
>>>
>>> run_lapw -i 80 (or runsp_lapw -i 80)
>>>
>>> [1]
>>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg06119.html
>>> [2]
>>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09879.html
>>> [3]
>>> http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg02833.html
>>>
>>> On 3/8/2016 3:51 AM, sikander Azam wrote:
>>>

 Dear all
 I am doing calculations using mBJ plus U, but when the calculations
 complete, I get that energy is not converged. But when I check the SCF file
 I get a constant value of 0.52341000 for energy convergence and 0.34568
 values for charge convergence.
 So I don't understand on the logic. please help me that what should I
 do. Should I continue with these calculations and find the properties or
 some one will give me some suggestions.
 Thanks in advance.
 Regards
 Azam

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

Re: [Wien] Regarding mBJ plus U

[Gavin Abo]

If you ran as you describe:

runsp_lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
runsp_lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60

The first runsp_lapw should have ran the calculation from cycle 1 up to 
cycle 60.  The second runsp_lapw should have then removed the broyd 
files and repeated the same calculation again from cycle 1 up to cycle 60.


Now, if you had did:

runsp_lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
runsp_lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60 -NI

The first runsp_lapw should have ran the calculation from cycle 1 up to 
cycle 60.  The second runsp_lapw should have then kept the broyd files 
(because of the -NI) and continued the calculation from cycle 61 up to 
cycle 120.


However, your new description that the energy and charge convergence are 
constant in every cycle is much clearer.  So, I now don't think that 
increasing the maximum number of iterations will solve your problem.


Of the few mBJ calculations that I have ran, I don't remember ever 
having any problem just doing:


run[sp]_lapw ... -i 80 (with the default MSR1 in case.inm)

If I were to encounter a convergence problem, then I would restore my 
pre-mBJ calculation and try starting with a few iterations of PRATT and 
switch back to MSR1 [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07403.html 
]:


restore_lapw
run[sp]_lapw ... -i 15 (with PRATT in case.inm)
run[sp]_lapw ... -i 80 -NI (with MSR1 in case.inm)

If the mBJ instructions were written today, maybe PRATT would not be 
mentioned in the UG mBJ procedure.


I believe the PRATT part of the UG mBJ procedure was written back in the 
day when MSEC1 was the default (before MSR1 existed) [ 
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg03783.html 
].  I suspect that mBJ calculations starting with MSEC1 failed 
frequently, such that PRATT for a few iterations was the workaround to 
the MSEC1 problem.


There was one user in the past that reported that they had the same 
problem with a mBJ calculation, where the energy and charge convergence 
became constant in every cycle:


https://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07150.html

It looks like it might have been because they used too large of a mixing 
greed for PRATT.  Since the thread of posts seem to stop, the user 
likely solved it by using a smaller (but not too small) PRATT mixing greed.


Unfortunately, you did not run the exact command that Prof. Marks sent 
and provide the output as it looks like it would have included 
information about the mixing parameters that were used during the 
calculation.


On 3/8/2016 9:37 AM, sikander Azam wrote:
Dear Laurence Marks 

Thanks for your reply, Sir, actually we did mBJ+U calculations for 
parent compound. We got the convergence. Then we produce the vacancies 
in the parent compound, for that when we run the mBJ+U we get this 
problem i.e. the energy is not converged.
So this is the only worry that why our calculations is not converging. 
Firstly we give 60 cycles, then 80, but this also didn't solve our 
problem i.e. we didnt got the convergence.



*Note:* By *grep :DIS *.scf* we get 0.21815 0.21815 0.21815 
..20 times
and by *grep :ENE *.scf* we get 0.5014 0.5014 
.20 times


with best regard
Azam




On Tue, Mar 8, 2016 at 6:31 AM, Laurence Marks 
> wrote:


Please run the command below and post the result; it will provide
some information about what is going on (although it may not
answer everything). You can either run it in a linux shell (under
bash) or paste it to a file (e.g. ~/bin/Check, $WIENROOT/Check or
$WIENROOT/Check_lapw), do a "chmod a+x file" then just do "Check"
(or whatever name you used).

tail -n 10 *.scf $1 | grep -e :ADIST -e :DIR -e :MV -e GREED
-e :FRMS -e :ENE -e :CHARG -e PRATT \
-e :DIS -e "MIXING SC" -e ":RANK" -e PLANE | \
grep -v -e "with 1.0" -e scheme -e CONTRIBUTION | \
tail -n 50


On Tue, Mar 8, 2016 at 8:17 AM, sikander Azam
>
wrote:

Dear Gavin abin
Thanks Sir for the reply, but I ran it for 60 cycle two times
with commands
runsp-lapw -p -orb -ec 0.0001 -cc 0.0001 -i 60
Regards
Sikander

On 8 Mar 2016 14:36, "Gavin Abo" > wrote:

How many cycles did the calculation run for and what did
you set for the maximum number of iterations (i.e., the
number that you set for the -i option)?

If you did not use the -i option, just

run_lapw or runsp_lapw

The program will run up to 40 cycles by default.

It is common for a mBJ calculation to not be able to reach
converge within 40 cycles [1-3], which is why it 

Re: [Wien] Problem with k-parallel

[Peter Blaha]

Hi,

Yes, we had have recently also such a problem. It comes from slow disk I/O.

A fie like/tmp/.tmp2.mpolak.50255

is a temporary file created by lapw2para and is used when we modify the 
lapw2_xx.def files by a couple of sed commands.


Because of this I've reduced the sed commands in my version of 
lapw2para. Unfortunately, I cannot post the script because it will not 
be compatible with your WIEN2k version, but I can tell you what we did 
and since then these errors did not show up anymore.


Please identify the following lines in your lapw2para and modify it like 
shown below:

...
#creating  def files
set i = 1
while ($i <= $maxproc)
#  if ($debug > 0) echo -n "$i "
  cp $def.def $tmp_dir/.tmp.$user.$$
  #subsituting in files:
  cat <$tmp_dir/.script.$user.$$
s/vectorso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/vectorso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/vectordum$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/vectordum$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/vector$dnup'/vector${dnup}_$i'/w $tmp_dir/.mist.$user.$$
s/vector$updn'/vector${updn}_$i'/w $tmp_dir/.mist.$user.$$
s/energyso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/energyso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/energydum/&_$i/w $tmp_dir/.mist.$user.$$
s/energy$dnup'/energy${dnup}_$i'/w $tmp_dir/.mist.$user.$$
s/energy$updn'/energy${updn}_$i'/w $tmp_dir/.mist.$user.$$
s/\(weigh$dnup\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
s/\(weigh$updn\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
s/\(weightaverso$updn\)'/\1_$i'/w $tmp_dir/.mist.$user.$$
s/normso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/normso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/output2${updn}$eece/&_$i/w $tmp_dir/.mist.$user.$$
s/clmval${updn}$eece/&_$i/w $tmp_dir/.mist.$user.$$
s/vrespval$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/dmat$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/scf2$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/help$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/almblm$updn/&_$i/w $tmp_dir/.mist.$user.$$

theend

  sed -f $tmp_dir/.script.$user.$$ $tmp_dir/.tmp.$user.$$ > 
$tmp_dir/.tmp1.$user.$$

  mv $tmp_dir/.tmp1.$user.$$ "$def"_$i.def

#  sed "s/vector_${i}dn_$i/vectordn_$i/" 
$tmp_dir/.tmp1.$user.$$>$tmp_dir/.tmp2.$user.$$
#  sed "s/vector_${i}up_$i/vectorup_$i/" 
$tmp_dir/.tmp2.$user.$$>$tmp_dir/.tmp1.$user.$$
#  sed "s/vector_${i}so_$i/vectorso_$i/" 
$tmp_dir/.tmp1.$user.$$>$tmp_dir/.tmp2.$user.$$
#  sed "s/energy_${i}up_$i/energyup_$i/" 
$tmp_dir/.tmp2.$user.$$>$tmp_dir/.tmp1.$user.$$
#  sed "s/energy_${i}dn_$i/energydn_$i/" 
$tmp_dir/.tmp1.$user.$$>$tmp_dir/.tmp2.$user.$$
#  sed "s/energy_${i}so_$i/energyso_$i/" 
$tmp_dir/.tmp2.$user.$$>$tmp_dir/.tmp1.$user.$$
#  sed "s/energyso_${i}dn_$i/energysodn_${i}/" 
$tmp_dir/.tmp1.$user.$$>$tmp_dir/.tmp2.$user.$$
#  sed "s/energy_${i}dum_$i/energydum_$i/" 
$tmp_dir/.tmp2.$user.$$>$tmp_dir/.tmp1.$user.$$
#  sed "s/vector_${i}so_${i}dn_$i/vectorsodn_$i/" 
$tmp_dir/.tmp1.$user.$$>$tmp_dir/.tmp2.$user.$$
#  sed "s/vector_${i}dum_${i}dn_$i/vectordumdn_$i/" 
$tmp_dir/.tmp2.$user.$$>"$def"_$i.def

  @ i ++
end

As you can see, all these additional sed commands are now commented, 
since after the modifications of the .script.xx file they are not needed 
anymore.



On 03/08/2016 03:44 PM, Maciej Polak wrote:

Dear WIEN2k users and developers,

I encountered a very strange problem. Sometimes (50/50 chance), the 
calculations using just k-parallel will not finish. This exact same case, when 
submitted again (it sometime takes more tries) finishes with no problem. 
Sometimes it crashes after a few iterations, sometimes after a hundred or more, 
and sometimes it just finishes successfully.

This is what I get in the output:

sed: can't read /tmp/.tmp2.mpolak.50255: No such file or directory
cp: cannot stat `.in.tmp': No such file or directory


There is also an error in stderr:

forrtl: No such file or directory
forrtl: severe (29): file not found, unit 20, file 
/lustre/scratch/tmp/pbs.1275300.achilles/MoS2_LDA/fort.20
Image PC Routine Line Source
lapw2 004B3E37 Unknown Unknown Unknown
lapw2 004D5BE0 Unknown Unknown Unknown
lapw2 0048140D MAIN__ 155 lapw2_tmp_.F
lapw2 00403F0E Unknown Unknown Unknown
libc.so.6 2B1F2CD53D5D Unknown Unknown Unknown
lapw2 00403E19 Unknown Unknown Unknown


Do you have any idea what may be the cause of this? Running on just one CPU is 
always fine. There is certainly no error in my input file, because after a few 
tries this exact same case will eventually finish correctly.

Thank you for your help

Maciej Polak
___
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



--

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

Re: [Wien] General question on NMR

[Peter Blaha]

The limitations are of course determined a lot by the available computer 
resources.


On a normal modern PC you are probalby limited to clusters of 50 atoms, 
while on a large supercomputer with 512 cores for your job you can 
probably go up to much larger clusters.


The problem will anyway be the structure of such nanocluster, since any 
structure optimization will lead only to the next local minimum, but the 
global minimum might be very difficult to find unless you have some idea 
about the inital structure.


The NMR art itself is also mpi parallel, so when you can do the scf 
calculation, you probably can also do the NMR.


Peter Blaha

On 03/08/2016 04:22 PM, Pascal Boulet wrote:

Dear all,

A colleague of mine who is doing experimental H-NMR measurements on
molecules grafted on gold nanoparticules asked me whether it is possible
or not to run NMR calculations. Since I have no experience at all on
this kind of calculation, I would like to know if someone could tell me
what is the limit in size of the models we can simulate and what
accuracy we can expect.

Thank you for your reply.
Best regards
Pascal
--
Pascal Boulet /- MCF HDR, Resp. L1 MPCI - DEPARTEMENT CHIMIE/
Aix-Marseille Université - ST JEROME - Avenue Escadrille Normandie
Niemen - 13013 Marseille
Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Site : http://allos.up.univ-mrs.fr/pascal - Email :
pascal.bou...@univ-amu.fr 
/Afin de respecter l'environnement, merci de n'imprimer cet email que si
nécessaire./



___
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



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Crystal structure that XCrySDen cannot visualize

[Lyudmila Dobysheva]

08.03.2016 22:19, delamora wrote:

that there is a problem, but what I see is that it is with XCrySDen and
not with WIEN2k.
Well, this structure cannot be visualized with XCrySDen
Structure that cannot be visualized
more GdO-H2-C.struct


Dear Pablo,

I have taken your struct file and it passed well through my Xcrysden 
(see in attachments), so cannot see your problem.


By the way, I'd say this is not
> Gd and H2O
but an oxide of Gd with H2 molecules.

Best wishes
  Lyudmila Dobysheva
--
Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
426001 Izhevsk, ul.Kirova 132
RUSSIA
--
Tel.:7(3412) 432045(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/
--
Title   
CXZ LATTICE,NONEQUIV.ATOMS:  3 8 Cm
MODE OF CALC=RELA unit=ang 
  7.558908 12.100156 13.092413 90.00 90.00128.659811
ATOM   1: X=0. Y=0. Z=0.
  MULT= 1  ISPLIT= 8
Gd1NPT=  781  R0=0.1000 RMT=1.9600   Z: 64.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM   2: X=0.6000 Y=0.6000 Z=0.
  MULT= 1  ISPLIT= 8
O 1NPT=  781  R0=0.0001 RMT=1.6100   Z:  8.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM   3: X=0.5470 Y=0.4000 Z=0.4470
  MULT= 2  ISPLIT= 8
   3: X=0.5470 Y=0.4000 Z=0.5530
H 1NPT=  781  R0=0.0001 RMT=0.6600   Z:  1.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
   2  NUMBER OF SYMMETRY OPERATIONS
 1 0 0 0.
 0 1 0 0.
 0 0 1 0.
   1
 1 0 0 0.
 0 1 0 0.
 0 0-1 0.
   2
___
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