Re: [Wien] Question on convergence of charged state

[Hu, Wenhao]

Hi, Professor Marks:

The following is the results from the label of :NEC:

:NEC03: NUCLEAR AND ELECTRONIC CHARGE814.0   813.99598 Valence
:NEC01: NUCLEAR AND ELECTRONIC CHARGE814.0   813.96208
:NEC02: NUCLEAR AND ELECTRONIC CHARGE814.0   814.0
:NEC03: NUCLEAR AND ELECTRONIC CHARGE814.0   814.00092 Valence
:NEC01: NUCLEAR AND ELECTRONIC CHARGE814.0   813.96207
:NEC02: NUCLEAR AND ELECTRONIC CHARGE814.0   814.0
:NEC03: NUCLEAR AND ELECTRONIC CHARGE814.0   814.00091 Valence
:NEC01: NUCLEAR AND ELECTRONIC CHARGE814.0   813.96207
:NEC02: NUCLEAR AND ELECTRONIC CHARGE814.0   814.0
:NEC03: NUCLEAR AND ELECTRONIC CHARGE814.0   814.00063 Valence

About the charged state of defects in diamond, transitions among different 
charged states are possible to show up depending on the location of the Fermi 
energy. You can think about the nitrogen vacancy center, which has two stable 
states, i.e. neutral and -1 charged. The latter is proved to exhibit a spin one 
ground state.  Even though the supercell calculations have some flaws, my 
calculations so far qualitatively show a similar result in some charged 
isolated vacancy depending on various factors. The charged electron should be 
delocalized, but I can’t confirm the extent without a converged results. The 
thing I can confirm is that the magnetic moment are all from the defect level. 
Or maybe I didn’t get your question very well. If any other information about 
my calculation is needed, please let me know.

Thank you very much for your help. I really appreciate it.

Wenhao
___
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] Question on convergence of charged state

[Hu, Wenhao]

Hi, Professor Marks:

The information from the command you provided is as follows:

---
:DIS  :  CHARGE DISTANCE   ( 0.0491517 for atom   49 spin 1)  0.0083933
:PLANE:  INTERSTITIAL TOTAL 11.73512 DISTAN  5.593E-01 % 
:CHARG:  CLM CHARGE   /ATOM  2.21276 DISTAN  1.814E-01 % 
:DIRM :  MEMORY 10/10 RESCALES   8.34  9.08 RED 0.614 PRED 0.322 NEXT 0.515
:DIRA :  |MSR1a|= 2.797E-02 |PRATT|= 2.230E-01 ANGLE= 113.5 DEGREES
:DIRP :  |MSR1a|= 2.688E-02 |PRATT|= 2.738E-01 ANGLE=  85.5 DEGREES
:DIRQ :  |MSR1a|= 2.316E-02 |PRATT|= 2.850E-01 ANGLE=  77.3 DEGREES
:DIR  :  |MSR1a|= 3.548E-02 |PRATT|= 3.952E-01 ANGLE=  81.6 DEGREES
:FRMSA:  (mRyd/au)2.8243.209 RMS (au) 3.49E-04 MAX 1.15E-03 
:F-condition (mRyd/au)0.500 F
:MIX  :   MSE1a  REGULARIZATION: 7.03E-06  GREED: 0.048  Newton 1.00  0.10  
  
:ENE  : *WARNING** TOTAL ENERGY IN Ry =   -10214.29929714
:DIS  :  CHARGE DISTANCE   ( 0.0462410 for atom   49 spin 1)  0.0083777
:PLANE:  INTERSTITIAL TOTAL 11.73533 DISTAN  5.458E-01 % 
:CHARG:  CLM CHARGE   /ATOM  2.21276 DISTAN  1.759E-01 % 
:DIRM :  MEMORY 10/10 RESCALES   8.75  8.82 RED 1.049 PRED 0.515 NEXT 0.489
:DIRA :  |MSR1a|= 4.091E-02 |PRATT|= 2.759E-01 ANGLE=  49.9 DEGREES
:DIRP :  |MSR1a|= 5.346E-02 |PRATT|= 2.801E-01 ANGLE= 111.3 DEGREES
:DIRQ :  |MSR1a|= 4.654E-02 |PRATT|= 2.764E-01 ANGLE= 133.3 DEGREES
:DIR  :  |MSR1a|= 7.088E-02 |PRATT|= 3.935E-01 ANGLE= 120.8 DEGREES
:FRMSA:  (mRyd/au)3.6533.950 RMS (au) 5.23E-04 MAX 1.45E-03 
:F-condition (mRyd/au)0.500 F
:MIX  :   MSE1a  REGULARIZATION: 6.51E-06  GREED: 0.050  Newton 1.00  0.17  
  
:ENE  : *WARNING** TOTAL ENERGY IN Ry =   -10214.30126681
:DIS  :  CHARGE DISTANCE   ( 0.0546224 for atom   49 spin 1)  0.0111830
:PLANE:  INTERSTITIAL TOTAL 11.73531 DISTAN  7.019E-01 % 
:CHARG:  CLM CHARGE   /ATOM  2.21276 DISTAN  2.360E-01 % 
:DIRM :  MEMORY 10/10 RESCALES   8.75  8.90 RED 1.359 PRED 0.489 NEXT 0.467
:DIRA :  |MSR1a|= 3.835E-01 |PRATT|= 4.024E-01 ANGLE= 105.1 DEGREES
:DIRP :  |MSR1a|= 2.117E-01 |PRATT|= 3.604E-01 ANGLE=  58.2 DEGREES
:DIRQ :  |MSR1a|= 1.660E-01 |PRATT|= 3.708E-01 ANGLE=  40.5 DEGREES
:DIR  :  |MSR1a|= 2.690E-01 |PRATT|= 5.170E-01 ANGLE=  51.3 DEGREES
:FRMSA:  (mRyd/au)5.3255.625 RMS (au) 4.63E-03 MAX 1.67E-02 
:F-condition (mRyd/au)0.500 F
:MIX  :   MSE1a  REGULARIZATION: 4.87E-06  GREED: 0.046  Newton 1.00  0.72  
  
:ENE  : *WARNING** TOTAL ENERGY IN Ry =   -10214.30353561
:DIS  :  CHARGE DISTANCE   ( 0.0797259 for atom   49 spin 1)  0.0199414
:PLANE:  INTERSTITIAL TOTAL 11.73474 DISTAN  9.959E-01 % 
:CHARG:  CLM CHARGE   /ATOM  2.21273 DISTAN  3.275E-01 % 
:DIRM :  MEMORY 10/10 RESCALES   8.70  9.08 RED 1.145 PRED 0.467 NEXT 0.334
:DIRA :  |MSR1a|= 4.493E-01 |PRATT|= 2.194E-01 ANGLE=  81.6 DEGREES
:DIRP :  |MSR1a|= 3.142E-01 |PRATT|= 5.084E-01 ANGLE=  66.6 DEGREES
:DIRQ :  |MSR1a|= 2.695E-01 |PRATT|= 5.145E-01 ANGLE=  68.6 DEGREES
:DIR  :  |MSR1a|= 4.140E-01 |PRATT|= 7.233E-01 ANGLE=  67.6 DEGREES
:FRMSA:  (mRyd/au)2.7263.911 RMS (au) 5.37E-03 MAX 1.85E-02 
:F-condition (mRyd/au)0.500 F
:MIX  :   MSE1a  REGULARIZATION: 9.67E-06  GREED: 0.042  Newton 1.00  0.81  
  
:ENE  : *WARNING** TOTAL ENERGY IN Ry =   -10214.33684451
---

The reason why I’m looking at charged state is that I want to compare their 
stabilities and associated magnetic states. Thank you very much for your help. 
If any more information is needed, please let me know.

Regards,
Wenhao

On Mon, Feb 22, 2016 at 6:36 PM, Laurence Marks 
wrote:

> I assume that you have correctly changed the number of electrons in both
> case.in2(c) and case.inm.
>
> Beyond that, please execute and send me the output (or the list)
>
> tail -n 5 *.scf | 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 -44
>
> Without some more information about what is going on it is impossible to
> say anything beyond vague and probably incorrect general statements.
___
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 basic question about full hybrid functional calculation

[Hu, Wenhao]

Hi, All:


According to the link:


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



It seems that it's impossible to realize atomic position relaxation with full 
relaxation functional. Then, does it mean that the forces obtained with MSR1a 
are all wrong? I'm also wondering whether the calculation without atomic 
relaxation is accurate enough to describe the system.


Best,

Wenhao

[http://www.mail-archive.com/logo.png]

Re: [Wien] relaxation of atomic positions with the full 
...
www.mail-archive.com
Re: [Wien] relaxation of atomic positions with the full hybrid functionals. 
tran Fri, 25 Dec 2015 11:11:41 -0800

___
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 basic question about full hybrid functional calculation

[Hu, Wenhao]

Thank you all for the suggestions. I was considering doing a full hybrid 
functional calculation. Since the corresponding structure optimization is not 
implemented so far, I may postpone it until I have extra node to try it. 

BTW, as Pablo mentioned in his post, a unrelaxed structure can give a really 
wrong results. I’m wondering whether the full hybrid function calculation in 
WIEN2K is valuable or not. Or maybe they can still be used in some certain 
systems? 

Best,
Wenhao
___
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] Basic question about DOS of onsite-hybrid functional calculation

[Hu, Wenhao]

Hi, all:

I have a basic question on the DOS calculation of onsite-hybrid functional 
(ONF) calculation. When I check the UG, I can’t find  any notes about the DOS 
plotting of ONF, so I assume the program flow is the same in ONF as normal (x 
lapw2 -p -c -up/dn -qtl, then x tetra -p -up/dn). But when I compare the DOS 
from ONF and pure PBE-GGA calculations, I find that there’s no any change in 
the selected orbitals with ONF. This stays even when I change the mixing factor 
alpha from 0.25 to 1.0, which confuses me. Can anyone tell me whether the way I 
use lapw2 is wrong?

Some details about my calculations:
I’m calculating a Cr dopant in 4H-SiC (Si31 C32 Cr). Only the d orbitals of Cr 
is treated with ONF. HYBR mode is used.

If any further information is needed, please let me know.

Thanks,
Wenhao
___
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] Basic question about DOS of onsite-hybrid functional calculation

[Hu, Wenhao]

Hi, Prof. Laurence:

This result is converged to large extent with respect to force, charge and 
energy. The forces on individual atoms are all below 0.5 and the total force in 
z is 3.5, which is the direction without symmetry. The :MV flag gives the 
following information:

:MVORD  NDM  100 L1   1.324705E-06 %   1.9515E+00
:MVORD  NDM  100 L1   5.048483E-07 %   7.4904E-01
:MVORD  NDM  100 L1   5.945770E-07 %   8.E-01
:MVORD  NDM  100 L1   1.812394E-06 %   2.7020E+00
:MVORD  NDM  100 L1   4.148287E-07 %   6.2033E-01
:MVORD  NDM  100 L1   7.931515E-07 %   1.1769E+00
:MVORD  NDM  100 L1   5.749884E-07 %   8.5153E-01
:MVORD  NDM  100 L1   2.831283E-07 %   4.1772E-01
:MVORD  NDM  100 L1   2.054397E-07 %   3.0163E-01
:MVORD  NDM  100 L1   1.773378E-07 %   2.6035E-01

Best,
Wenhao


> Did you fully converge the calculation or just do one iteration? You have
> to fully converge. Also, what does "grep :MV case.scf | tail" give?
> 
> On Tue, Jan 26, 2016 at 11:08 AM, Hu, Wenhao <wenhao...@uiowa.edu> wrote:
> 
> > Hi, all:
> >
> > I have a basic question on the DOS calculation of onsite-hybrid functional
> > (ONF) calculation. When I check the UG, I can’t find  any notes about the
> > DOS plotting of ONF, so I assume the program flow is the same in ONF as
> > normal (x lapw2 -p -c -up/dn -qtl, then x tetra -p -up/dn). But when I
> > compare the DOS from ONF and pure PBE-GGA calculations, I find that there’s
> > no any change in the selected orbitals with ONF. This stays even when I
> > change the mixing factor alpha from 0.25 to 1.0, which confuses me. Can
> > anyone tell me whether the way I use lapw2 is wrong?
> >
> > Some details about my calculations:
> > I’m calculating a Cr dopant in 4H-SiC (Si31 C32 Cr). Only the d orbitals
> > of Cr is treated with ONF. HYBR mode is used.
> >
> > If any further information is needed, please let me know.
> >
> > Thanks,
> > Wenhao
> > ___
> > 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
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> Corrosion in 4D: MURI4D.numis.northwestern.edu
> Co-Editor, Acta Cryst A
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought"
> Albert Szent-Gyorgi
___
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] Basic question about DOS of onsite-hybrid functional calculation

[Hu, Wenhao]

Hi, Prof. Laurence:

No, I don’t include the SO effect. The orbital potential is applied in lapw1. 
Basically, I’m using the -eece flag of runs_lapw.  The program flow is as 
follows:

>   (runeece_lapw) options: -p
Sun Jan 24 14:24:18 CST 2016> (x) lapwdm -up -p -c
Sun Jan 24 14:24:40 CST 2016> (x) sumpara -up -d
Sun Jan 24 14:24:41 CST 2016> (x) lapwdm -dn -p -c
Sun Jan 24 14:25:03 CST 2016> (x) sumpara -dn -d
Sun Jan 24 14:25:03 CST 2016> (x) lapw2 -c -up -p -eece
Sun Jan 24 14:25:29 CST 2016> (x) sumpara -up -eece -d
Sun Jan 24 14:25:31 CST 2016> (x) lapw2 -c -dn -p -eece
Sun Jan 24 14:25:51 CST 2016> (x) sumpara -dn -eece -d
Sun Jan 24 14:25:51 CST 2016> (x) lapw0 -p -eece
Sun Jan 24 14:25:55 CST 2016> (x) orb -up -p
Sun Jan 24 14:25:55 CST 2016> (x) orb -dn -p
Sun Jan 24 14:26:02 CST 2016> (x) mixer -eece -orb
Sun Jan 24 14:26:44 CST 2016> (x) lapw0 -p
Sun Jan 24 14:27:49 CST 2016> (x) lapw1 -up -p -orb -c
Sun Jan 24 14:41:43 CST 2016> (x) lapw1 -dn -p -orb -c
Sun Jan 24 14:58:24 CST 2016> (x) lapw2 -up -p -c
Sun Jan 24 15:00:47 CST 2016> (x) sumpara -up -d
Sun Jan 24 15:00:55 CST 2016> (x) lapw2 -dn -p -c
Sun Jan 24 15:03:20 CST 2016> (x) sumpara -dn -d
Sun Jan 24 15:03:29 CST 2016> (x) lcore -up
Sun Jan 24 15:03:31 CST 2016> (x) lcore -dn

My case.ineece setup is as follows:
-12.0  1   emin natom
32 1 2 iatom nlorb lorb
HYBR  HYBR / EECE mode
1.00  amount of exact exchange
 
where 32 is the index of chromium.

Best,
Wenhao


___
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] Basic question about DOS of onsite-hybrid functional calculation

[Hu, Wenhao]

Hi, Prof. Laurence:

By following your suggestion, It seems that everything is normal except for the 
case.in2eece file. My case.in2eece is as follows:

TOT  EECE (TOT,FOR,QTL,EFG,FERMI)
-12.0 52.00 0.50 0.05 1 EMIN, NE, ESEPERMIN, ESEPER0, iqtlsave
TETRA0.000  (GAUSS,ROOT,TEMP,TETRA,ALL  eval)

It seems that NE is truncated, which should be 452 here. I’ll modify it and see 
what happens.

Thank you very much for your help,
Wenhao

> Hard to say. Thoughts:
> 
> Check case.scf2up/dn and look at the Cr d-occupancy
> 
>  grep :EORB *scforb*
> If everything is zero then no orbital terms were being applied.
> 
> Check case.vorbup/dn -- non zero terms?
> 
> Check case.scforbup/dn
> Last line should be
>PRATT mixing scheme with 1.000
> 
> head case.in2eece
> 
> Check that the number of electrons is right. There is a bug with how this
> file is created which can lead to problems. In one case I have it is
> TOT  EECE (TOT,FOR,QTL,EFG,FERMI)
> -9.0 592.0 0.50 0.05 EMIN, NE, ESEPERMIN, ESEPER0
> 
> and the corresponding first two lines in case.in2 are
> TOT (FOR,FOR,QTL,EFG,FERMI)
>  -12.0 592.0 0.50 0.05EMIN, NE, ESEPERMIN, ESEPER0
> 
> Here the 592 is what matters. If it has got truncated add some spaces
> before it in case.in2.
> 
> 
> 
> 
> 
> On Tue, Jan 26, 2016 at 1:36 PM, Hu, Wenhao <wenhao...@uiowa.edu> wrote:
> 
> > Hi, Prof. Laurence:
> >
> > No, I don’t include the SO effect. The orbital potential is applied in
> > lapw1. Basically, I’m using the -eece flag of runs_lapw.  The program flow
> > is as follows:
> >
> > >   (runeece_lapw) options: -p
> > Sun Jan 24 14:24:18 CST 2016> (x) lapwdm -up -p -c
> > Sun Jan 24 14:24:40 CST 2016> (x) sumpara -up -d
> > Sun Jan 24 14:24:41 CST 2016> (x) lapwdm -dn -p -c
> > Sun Jan 24 14:25:03 CST 2016> (x) sumpara -dn -d
> > Sun Jan 24 14:25:03 CST 2016> (x) lapw2 -c -up -p -eece
> > Sun Jan 24 14:25:29 CST 2016> (x) sumpara -up -eece -d
> > Sun Jan 24 14:25:31 CST 2016> (x) lapw2 -c -dn -p -eece
> > Sun Jan 24 14:25:51 CST 2016> (x) sumpara -dn -eece -d
> > Sun Jan 24 14:25:51 CST 2016> (x) lapw0 -p -eece
> > Sun Jan 24 14:25:55 CST 2016> (x) orb -up -p
> > Sun Jan 24 14:25:55 CST 2016> (x) orb -dn -p
> > Sun Jan 24 14:26:02 CST 2016> (x) mixer -eece -orb
> > Sun Jan 24 14:26:44 CST 2016> (x) lapw0 -p
> > Sun Jan 24 14:27:49 CST 2016> (x) lapw1 -up -p -orb -c
> > Sun Jan 24 14:41:43 CST 2016> (x) lapw1 -dn -p -orb -c
> > Sun Jan 24 14:58:24 CST 2016> (x) lapw2 -up -p -c
> > Sun Jan 24 15:00:47 CST 2016> (x) sumpara -up -d
> > Sun Jan 24 15:00:55 CST 2016> (x) lapw2 -dn -p -c
> > Sun Jan 24 15:03:20 CST 2016> (x) sumpara -dn -d
> > Sun Jan 24 15:03:29 CST 2016> (x) lcore -up
> > Sun Jan 24 15:03:31 CST 2016> (x) lcore -dn
> >
> > My case.ineece setup is as follows:
> > -12.0  1   emin natom
> > 32 1 2 iatom nlorb lorb
> > HYBR  HYBR / EECE mode
> > 1.00  amount of exact exchange
> >
> > where 32 is the index of chromium.
> >
> > Best,
> > Wenhao
> >
> >
> > ___
> > 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
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> Corrosion in 4D: MURI4D.numis.northwestern.edu
> Co-Editor, Acta Cryst A
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought"
> Albert Szent-Gyorgi
___
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] MPI vs multi-thread?

[Hu, Wenhao]

Hi, all:

I met some confusions when I try to compare the efficiency of MPI and 
multi-thread calculations. In the lapw1 stage of the same case, I found that 
MPI will take double time of that with multi-thread. Other than, it even takes 
longer time than k-point parallelization without multi-thread setup. Can anyone 
tell me under what case MPI has a better performance? Another question is about 
the number of thread per job. When I increase the OMP_NUM_THREADS from 2 to 4, 
my process usually crashes after two cycles although it does have a boost 
effect on the finished cycle. Is this a normal thing? Do we have an optimal 
threads number?

Best,
Wenhao
___
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 question about the Rkm

[Hu, Wenhao]

(I accidentally replied with a wrong title. To ensure consistency, I send this 
post again. Maybe the mail list manager can delete the wrong post for me^)

Hi, Peter:

Thank you very much for your reply. By following your suggestion, I unified the 
version of all the library to be compiled or consistent with intel composer xe 
2015 (MKL, fftw, openmpi etc.) and recompiled wien2k. The version of my openmpi 
is 1.6.5. However, I still get the same problem. Except for the message I 
posted earlier, I also have the following backtrace information of the process:

lapw1c_mpi:14596 terminated with signal 11 at PC=2ab4dac4df79 SP=7fff78b8e310.  
Backtrace:

lapw1c_mpi:14597 terminated with signal 11 at PC=2b847d2a1f79 SP=7fff8ef89690.  
Backtrace:
/opt/openmpi-intel-composer_xe_2015.3.187/1.6.5/lib/libmpi.so.1(MPI_Comm_size+0x59)[0x2ab4dac4df79]
/opt/openmpi-intel-composer_xe_2015.3.187/1.6.5/lib/libmpi.so.1(MPI_Comm_size+0x59)[0x2b847d2a1f79]
/Users/wenhhu/wien2k14/lapw1c_mpi(blacs_pinfo_+0x92)[0x49cf02]
/Users/wenhhu/wien2k14/lapw1c_mpi(blacs_pinfo_+0x92)[0x49cf02]
/opt/intel/composer_xe_2015.3.187/mkl/lib/intel64/libmkl_scalapack_lp64.so(sl_init_+0x21)[0x2b8478d2e171]
/opt/intel/composer_xe_2015.3.187/mkl/lib/intel64/libmkl_scalapack_lp64.so(sl_init_+0x21)[0x2ab4d66da171]
/Users/wenhhu/wien2k14/lapw1c_mpi(parallel_mp_init_parallel_+0x63)[0x463cd3]
/Users/wenhhu/wien2k14/lapw1c_mpi(parallel_mp_init_parallel_+0x63)[0x463cd3]
/Users/wenhhu/wien2k14/lapw1c_mpi(gtfnam_+0x22)[0x426372]
/Users/wenhhu/wien2k14/lapw1c_mpi(MAIN__+0x6c)[0x4493dc]
/Users/wenhhu/wien2k14/lapw1c_mpi(main+0x2e)[0x40d19e]
/Users/wenhhu/wien2k14/lapw1c_mpi(gtfnam_+0x22)[0x426372]
/Users/wenhhu/wien2k14/lapw1c_mpi(MAIN__+0x6c)[0x4493dc]
/Users/wenhhu/wien2k14/lapw1c_mpi(main+0x2e)[0x40d19e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x339101ed5d]
/Users/wenhhu/wien2k14/lapw1c_mpi[0x40d0a9]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x339101ed5d]
/Users/wenhhu/wien2k14/lapw1c_mpi[0x40d0a9]

Do you think it’s still the problem of my MKL or there’re some other issues I 
miss?

Best,
Wenhao



a) Clearly, for a nanowire simulation the mpi-parallelization is best. 
Unfortunately, on some clusters mpi is not set-up properly, or users do not use 
the proper mkl-libraries for hthe particular mpi. Please use the Intel 
link-library advisor, as was mentioned in previous posts. The mkl-scalapack 
will NOT work unless you use proper version of the blacs_lp64 library.
b) As a short term solution you should:

i) Use a parallelization with OMP_NUM_THREAD=2. This speeds up the calculation 
by nearly a factor of 2 and uses 2 cores in a single lapw1 without memory 
increase. ii) Reduce the number of k-points. I'm pretty sure you can reduce it 
to 2-4 for scf and structure optimization. This will save memory due to fewer 
k-parallel jobs. iii) During structure optimization you will end up with very 
small Si-H and C-H distances. So I'd reduce the H sphere right now to about 
0.6, but keep Si and C large (for C use around 1.2). With such a setup, a 
preliminary structure optimization can be done with RKMAX=2.0, which should 
later be checked with 2.5 and 3.0 iv) Use iterative diagonalization ! After the 
first cycle, this will speed-up the scf by a factor of 5 !! v) And of course, 
reconsider the size of your "vacuum", i.e. the seperation of your wires. 
"Vacuum" is VERY expensive in terms of memory and one should not set it too 
large without test. Optimize your wire with small a,b; then increase the vacuum 
later on (x supercell) and check if forces appear again and distances, ban 
structure, ... change.

Am 09.01.2016 um 22:07 schrieb Hu, Wenhao:

Hi, Marks and Peter:

Thank you for your suggestions. About your reply, I have several
follow-up questions. Actually, I’m using a intermediate cluster in my
university, which has 16 cores and 64 GB memory on standard nodes. The
calculation I’m doing is k-point but not MPI parallelized. From the :RKM
flag I posted in my first email, I estimate that the matrix size I need
for a Rkmax=5+ will be at least 4. In my current calculation, the
lapw1 program will occupy as large as 3GB on each slot (1 k point/slot).
So I estimate the memory for each slot will be at least 12 GB. I have 8
k points so that 96 GB memory will be required at least (if my
estimation is correct). Considering the current computation resources I
have, this is way too memory demanding. On our clusters, there’s a 4 GB
memory limit for each slot on standard node. Although I can submit
request for high memory node, but their usages are very competitive
among cluster users. Do you have any suggestions on accomplishing this
calculation within the limitation of my cluster?

About the details of my calculation, the material I'm looking at is a
hydrogen terminated silicon carbide with 56 atoms. A 1x1x14 k-mesh is
picked for k-point sampling. The radius of 1.2 is achieved from
setrmt_lapw actually. Indeed, the radius of hydrogen is too lar

Re: [Wien] Wien Digest, Vol 122, Issue 2

[Hu, Wenhao]

Hi, Peter:

Thank you very much for your reply. By following your suggestion, I unified the 
version of all the library to be compiled or consistent with intel composer xe 
2015 (MKL, fftw, openmpi etc.) and recompiled wien2k. The version of my openmpi 
is 1.6.5. However, I still get the same problem. Except for the message I 
posted earlier, I also have the following backtrace information of the process:

lapw1c_mpi:14596 terminated with signal 11 at PC=2ab4dac4df79 SP=7fff78b8e310.  
Backtrace:

lapw1c_mpi:14597 terminated with signal 11 at PC=2b847d2a1f79 SP=7fff8ef89690.  
Backtrace:
/opt/openmpi-intel-composer_xe_2015.3.187/1.6.5/lib/libmpi.so.1(MPI_Comm_size+0x59)[0x2ab4dac4df79]
/opt/openmpi-intel-composer_xe_2015.3.187/1.6.5/lib/libmpi.so.1(MPI_Comm_size+0x59)[0x2b847d2a1f79]
/Users/wenhhu/wien2k14/lapw1c_mpi(blacs_pinfo_+0x92)[0x49cf02]
/Users/wenhhu/wien2k14/lapw1c_mpi(blacs_pinfo_+0x92)[0x49cf02]
/opt/intel/composer_xe_2015.3.187/mkl/lib/intel64/libmkl_scalapack_lp64.so(sl_init_+0x21)[0x2b8478d2e171]
/opt/intel/composer_xe_2015.3.187/mkl/lib/intel64/libmkl_scalapack_lp64.so(sl_init_+0x21)[0x2ab4d66da171]
/Users/wenhhu/wien2k14/lapw1c_mpi(parallel_mp_init_parallel_+0x63)[0x463cd3]
/Users/wenhhu/wien2k14/lapw1c_mpi(parallel_mp_init_parallel_+0x63)[0x463cd3]
/Users/wenhhu/wien2k14/lapw1c_mpi(gtfnam_+0x22)[0x426372]
/Users/wenhhu/wien2k14/lapw1c_mpi(MAIN__+0x6c)[0x4493dc]
/Users/wenhhu/wien2k14/lapw1c_mpi(main+0x2e)[0x40d19e]
/Users/wenhhu/wien2k14/lapw1c_mpi(gtfnam_+0x22)[0x426372]
/Users/wenhhu/wien2k14/lapw1c_mpi(MAIN__+0x6c)[0x4493dc]
/Users/wenhhu/wien2k14/lapw1c_mpi(main+0x2e)[0x40d19e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x339101ed5d]
/Users/wenhhu/wien2k14/lapw1c_mpi[0x40d0a9]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x339101ed5d]
/Users/wenhhu/wien2k14/lapw1c_mpi[0x40d0a9]

Do you think it’s still the problem of my MKL or there’re some other issues I 
miss?

Best,
Wenhao



> a) Clearly, for a nanowire simulation the mpi-parallelization is best. 
> Unfortunately, on some clusters mpi is not set-up properly, or users do not 
> use the proper mkl-libraries for hthe particular mpi. Please use the Intel 
> link-library advisor, as was mentioned in previous posts. The mkl-scalapack 
> will NOT work unless you use proper version of the blacs_lp64 library.
> b) As a short term solution you should:
> 
> i) Use a parallelization with OMP_NUM_THREAD=2. This speeds up the 
> calculation by nearly a factor of 2 and uses 2 cores in a single lapw1 
> without memory increase. ii) Reduce the number of k-points. I'm pretty sure 
> you can reduce it to 2-4 for scf and structure optimization. This will save 
> memory due to fewer k-parallel jobs. iii) During structure optimization you 
> will end up with very small Si-H and C-H distances. So I'd reduce the H 
> sphere right now to about 0.6, but keep Si and C large (for C use around 
> 1.2). With such a setup, a preliminary structure optimization can be done 
> with RKMAX=2.0, which should later be checked with 2.5 and 3.0 iv) Use 
> iterative diagonalization ! After the first cycle, this will speed-up the scf 
> by a factor of 5 !! v) And of course, reconsider the size of your "vacuum", 
> i.e. the seperation of your wires. "Vacuum" is VERY expensive in terms of 
> memory and one should not set it too large without test. Optimize your wire 
> with small a,b; then increase the vacuum later on (x supercell) and check if 
> forces appear again and distances, ban structure, ... change.
> 
>> Am 09.01.2016 um 22:07 schrieb Hu, Wenhao:
>> 
>> Hi, Marks and Peter:
>> 
>> Thank you for your suggestions. About your reply, I have several
>> follow-up questions. Actually, I’m using a intermediate cluster in my
>> university, which has 16 cores and 64 GB memory on standard nodes. The
>> calculation I’m doing is k-point but not MPI parallelized. From the :RKM
>> flag I posted in my first email, I estimate that the matrix size I need
>> for a Rkmax=5+ will be at least 4. In my current calculation, the
>> lapw1 program will occupy as large as 3GB on each slot (1 k point/slot).
>> So I estimate the memory for each slot will be at least 12 GB. I have 8
>> k points so that 96 GB memory will be required at least (if my
>> estimation is correct). Considering the current computation resources I
>> have, this is way too memory demanding. On our clusters, there’s a 4 GB
>> memory limit for each slot on standard node. Although I can submit
>> request for high memory node, but their usages are very competitive
>> among cluster users. Do you have any suggestions on accomplishing this
>> calculation within the limitation of my cluster?
>> 
>> About the details of my calculation, the material I'm looking at is a
>> hydrogen terminated silicon carbide 

Re: [Wien] A question about the Rkm

[Hu, Wenhao]

Hi, Marks and Peter:

Thank you for your suggestions. About your reply, I have several follow-up 
questions. Actually, I’m using a intermediate cluster in my university, which 
has 16 cores and 64 GB memory on standard nodes. The calculation I’m doing is 
k-point but not MPI parallelized. From the :RKM flag I posted in my first 
email, I estimate that the matrix size I need for a Rkmax=5+ will be at least 
4. In my current calculation, the lapw1 program will occupy as large as 3GB 
on each slot (1 k point/slot). So I estimate the memory for each slot will be 
at least 12 GB. I have 8 k points so that 96 GB memory will be required at 
least (if my estimation is correct). Considering the current computation 
resources I have, this is way too memory demanding. On our clusters, there’s a 
4 GB memory limit for each slot on standard node. Although I can submit request 
for high memory node, but their usages are very competitive among cluster 
users. Do you have any suggestions on accomplishing this calculation within the 
limitation of my cluster?

About the details of my calculation, the material I'm looking at is a hydrogen 
terminated silicon carbide with 56 atoms. A 1x1x14 k-mesh is picked for k-point 
sampling. The radius of 1.2 is achieved from setrmt_lapw actually. Indeed, the 
radius of hydrogen is too large and I’m adjusting its radius during the 
progress of optimization all the time. The reason why I have such a huge matrix 
is mainly due to size of my unit cell. I’m using large unit cell to isolate the 
coupling between neighboring nanowire.

Except for the above questions, I also met some problems in mpi calculation. By 
following Marks’ suggestion on parallel calculation, I want to test the 
efficiency of mpi calculation since I only used k-point parallelized 
calculation before. The MPI installed on my cluster is openmpi. In the output 
file, I get the following error:

---
 LAPW0 END

lapw1c_mpi:19058 terminated with signal 11 at PC=2b56d9118f79 SP=7fffc23d6890.  
Backtrace:
...
mpirun has exited due to process rank 14 with PID 19061 on
node neon-compute-2-25.local exiting improperly. There are two reasons this 
could occur:

1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.

2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"

This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--
Uni_+6%.scf1up_1: No such file or directory.
grep: *scf1up*: No such file or directory

---

The job script I’m using is:

---
!/bin/csh -f
# -S /bin/sh
#
#$ -N uni_6
#$ -q MF
#$ -m be
#$ -M wenhao...@uiowa.edu<mailto:wenhao...@uiowa.edu>
#$ -pe smp 16
#$ -cwd
#$ -j y

cp $PE_HOSTFILE hostfile
echo "PE_HOSTFILE:"
echo $PE_HOSTFILE
rm .machines
echo granularity:1 >>.machines
while read hostname slot useless; do
i=0
l0=$hostname
while [ $i -lt $slot ]; do
echo 1:$hostname:2 >>.machines
let i=i+2
done
done>.machines

runsp_lapw -p -min -ec 0.0001 -cc 0.001 -fc 0.5
---

Is there any mistake I made or something missing in my script?

Thank your very much for your help.

Wenhao

I do not know many compounds, for which an RMT=1.2 bohr for H makes any sense 
(maybe LiH). Use setrmt and follow the suggestion. Usually, H spheres of CH or 
OH bonds should be less than 0.6 bohr. Experimental H-position are often very 
unreliable.
How many k-points ? Often 1 k-point is enough for 50+ atoms (at least at the 
beginning), in particular when you ahve an insulator.
Otherwise, follow the suggestions of L.Marks about parallelization.

Am 08.01.2016 um 07:28 schrieb Hu, Wenhao:

Hi, all:

I have some confusions on the Rkm in calculations with 50+ atoms. In my wien2k,

Re: [Wien] A basic question on QTL-B

[Hu, Wenhao]

Hi, Peter:

Thank you for your answer. This is very clear.

Best,
Wenhao

QTL stands for charge (Q) of each atom (t) and decomposed according to angular 
momentum (l). This is done for each eigenvalue.

In LAPW the wavefunction inside spheres is written as:

sum(lm) ( A_lm u_l + B_lm u-dot_l ) Y_lmwith u-dot = du / dE



The QTL are obviously = psi * psi, and thus comse from an A_lm^2 and B_lm^2 
term. Since the B_lm u-dot term comes from a truncated tailor-series of the 
E-dependent radial wavefunction u_l(E,r) it is important that this term is 
"small", otherwise your psi is either not very accurate (QTL-B warnings) or 
even wrong (QTL-B stop with "ghostbands”).

Am 28.12.2015 um 05:44 schrieb Hu, Wenhao:


Hi, all:

I have a quick question about the QTL-B. In the past, I met this error for many
times and usually it indicates the existence of ghost band. According to the 
message
that "QTL-B VALUE .EQ. XXX !!”, it should be some parameter derived from
QTL. But what is the concrete definition of QTL-B? I can’t find the answer 
anywhere
(maybe I’m just careless). Can anyone tell me about that?

Best,
Wenhao


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at<mailto: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



--
--
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<http://theochem.tuwien.ac.at>WIEN2k: 
http://www.wien2k.at<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

[Wien] A basic question on QTL-B

[Hu, Wenhao]

Hi, all:

I have a quick question about the QTL-B. In the past, I met this error for many 
times and usually it indicates the existence of ghost band. According to the 
message that "QTL-B VALUE .EQ. XXX !!”, it should be some parameter derived 
from QTL. But what is the concrete definition of QTL-B? I can’t find the answer 
anywhere (maybe I’m just careless). Can anyone tell me about that?

Best,
Wenhao


___
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] Error in initialization stage

[Hu, Wenhao]

Hi, All:

I met a problem in the initialization stage. I’m currently testing the effect 
of distance between clusters in nano wire calculation. When the distance is 
small (size of unit cell is small), everything is initialized properly. When I 
increase the distance until the size of unit cell is as large as 70x70x30 in 
bohr, I met the following problem:

dstart -c -p(14:31:23) running dstart in single mode
Segmentation fault
13.207u 0.136s 0:13.62 97.8%0+0k 0+18312io 0pf+0w
error: command   /Users/wenhhu/wien2k14/dstartpara -c start.def   failed

Can anyone tell what is this error? And How can we solve it?

Best,
Wenhao
___
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 question about the DOS of semi core state

[Hu, Wenhao]

Dear Peter:

Thanks for your clarification. My confusion get resolved by your answer. But I 
got another question. Actually, the reason why I want to calculated the semi 
core dos is to get the total occupation number of a specific atom. In my 
calculation, as you can see in the output I pasted, the valence electron in the 
sphere is 6.9038. When I checked the .outputtup file, I found the corresponding 
atom's dos integral is also around this value. As I expected, the electron 
density in the interstitial space should also be taken into account. This 
obviously can't solve my problem. Could you please give me any suggestions to 
figure out the occupation number of a specific atom in the supercell?

Wenhao
___
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 question about the DOS of semi core state

[Hu, Wenhao]

Dear WIEN2K users:

I have a questions about the DOS schema in WIEN2K. In my calculation, I have a 
Nickel atom in my supercell, which is a transition metal. From what I see in 
case.scf file for the Nickel atom part:

:CHA004: TOTAL VALENCE CHARGE INSIDE SPHERE   4 =   6.9038(RMT=  1.9900 )
:PCS004: PARTIAL CHARGES SPHERE =  4 S,P,D,F,  D-EG,D-T2G
:QTL004: 0.1864 3.0918 3.6103 0.0120 0. 0. 0. 1.7839 1.8262 0. 
0. 0.
Q-s-low E-s-low   Q-p-low E-p-low   Q-d-low E-d-low   Q-f-low E-f-low
:EPL004:  0. 10.2.9861 -3.97350. 10.0. 10.
Q-s-hi  E-s-hiQ-p-hi  E-p-hiQ-d-hi  E-d-hiQ-f-hi  E-f-hi
:EPH004:  0.1864  0.29880.1057  0.19853.6102  0.51790.0120  0.2378
(This is spin-up part)

 I believe that there should be semi core states in the window of -3.9735 Ry. 
But after I calculated the DOS, I found that there aren't any states from my 
core-state cut-off energy to -0.8 Ry. So I wonder will the semi core state will 
be counted in the regular DOS calculation. Or this is just my misunderstanding 
on the output file. If no, how can I get the dos of the semi core electrons?

Thanks for any suggestions and comments in advance. If any further information 
about my calculation you think is needed for locating the error, please lemme 
know.

Wenhao
___
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] Another question about the stop criteria of MSR1a mode

[Hu, Wenhao]

Hey, guys:

I have a question about the MSR1a calculation. Earlier, I did a fix spin 
momentum calculation. As Peter mentioned, runfsm_lapw doesn't have a support 
for -min flag so that it won't stop according to the force convergence we gave 
it. But just due to this issue, I achieved a extremely small force 
convergence(less than 0.0001 mRy/a.u.) after hundreds of cycles(it will run 
forever as long as I don't stop them).

And in the same case but using runsp_lapw, I used MSR1a mode and set the force 
convergence to 0.01 mRy/a.u. It will stop at around 1 mRy/a.u. after only 30 
cycles. I'm confused about the stop criteria of runsp_lapw. I believe it should 
be able to reach such a extremely small force convergence as well. However it 
just stops before reaching the target convergence...

Can anyone give me some ideas? I appreciate any comments and suggestions. If 
this is a case-by-case problem and more information is needed, I'll post my 
data later.

thanks in advance.
Wenhao
___
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] Another question about the stop criteria of MSR1a mode

[Hu, Wenhao]

Hi, Prof. Laurence:

Actually I did have set the first line of inM file to 0.01 mRy/a.u.. And this 
problem still shows up, is there any other possible mistakes I made? Or is 
there a method to ignore the stopping criterion in runsp_lapw? Then, I can 
decide when to stop by myself maybe.

Best,
Wenhao
___
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] Another question about the stop criteria of MSR1a mode

[Hu, Wenhao]

Hi, Prof. Laurence:


The version I'm using is wien14. So it should not be this issue. Do you think 
which file may give your more information to locate the problem? BTW, the case 
I'm looking at is a 2x2x2 3c Silicon Carbide supercell with a substitutional 
nickel in the center. The replaced atom is carbon.


I really appreciate your help,

Wenhao


--

Which version are you using? In earlier versions is was possible that MSR1a
stopped prematurely if the energy appeared converged, but I believe that
was cured. Otherwise I do not have enough information to comment.

On Thu, Nov 20, 2014 at 2:44 PM, Hu, Wenhao wenhao...@uiowa.edu wrote:

  Hi, Prof. Laurence:

  Actually I did have set the first line of inM file to 0.01 mRy/a.u.. And
 this problem still shows up, is there any other possible mistakes I made?
 Or is there a method to ignore the stopping criterion in runsp_lapw? Then,
 I can decide when to stop by myself maybe.

  Best,
 Wenhao




--
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
Co-Editor, Acta Cryst A
Research is to see what everybody else has seen, and to think what nobody
else has thought
Albert Szent-Gyorgi


___
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 awk version WIEN2K script use

[Hu, Wenhao]

Thanks guys. This error has been fixed after I manually modified TOT to FOR in 
*.in2c file.

Best regards,
Wenhao
___
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] About the awk version WIEN2K script use

[Hu, Wenhao]

Dear all,

I'm trying to do a fixed spin momentum calculation with WIEN2K. But after 
finishing the lapw1 stage, I got a message saying

awk: invalid -v option

 stop error: the required input file case.in2up for the next step could not be 
found.

My cluster is OSX based. And a 20070501 version of awk is preinstalled, which 
is not a gnu awk. So I doubt the problem is the incompatibility of my awk.

Thanks in advance!
Wenhao
___
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 awk version WIEN2K script use

[Hu, Wenhao]

Thanks Peter. This problem is resolved by installing gawk. And also thanks 
Martin, it's good to know about the difference between gawk and BSD gawk.

But I met another problem at the moment. After two scf cycles, I got a message 
saying that:

'Mixer' - Valence corrected forces are needed

in the mixer.error file. As I said, I'm doing a fixed spin momentum 
calculation with structure optimization(MSR1a mode). The crystal structure I'm 
looking at is a Nickel doped 2x2x2 SiC supercell. I appreciate any comments.

I don't know what file is related with this problem. So let me know what file 
you think will help to locate the error. I'll post them later.

Best,
Wenhao
___
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] Unable to achieve required force convergence in structure optimization

[Hu, Wenhao]

Dear all:

I met a problem when I use MSR1a method to determine equilibrium structure of 
my lattice. The convergence I want is 0.5mRy/au. But when I check the scfm 
file, the force on some specific atoms can be as large as 2 mRy/au. This 
problem remained even after I repeatedly ran my calculation for several times 
and lower the convergence from 0.5 to 0.2. Can anyone give me any suggestions?

Thanks in advance.
Wenhao
___
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 quick question about the force convergence (Laurence Marks)

[Hu, Wenhao]

Dear professor Laurence:

Thank you for your reply. I used MSR1a mode in my calculation. BTW, I didn't 
know that there's a difference in the force convergence between  PORT and 
MSR1a. If possible, could you tell me about it as well?

Best regards,

Wenhao
___
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 quick question about the force convergence

[Hu, Wenhao]

Dear all:

I have a quick question about the force convergence which I can't find an 
answer anywhere in the user guide. I wonder whether the force we're talking 
about here is the largest force on a particular atom in the unit cell or some 
other force. The reason why I propose this question is that I found the forces 
on some atoms are way larger than 0.5 mRy/a.u. even after the calculation 
reached the convergence.

Thank you in advance for any helpful advises.
Wenhao



___
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 question on the lapw2

[Hu, Wenhao]

Hi, all:

I met a problem in the calculation of Ni doped diamond supercell. Explicitly, 
what I'm trying to calculate is a 2x2x2 diamond supercell doped with a Nickel 
atom in the center of the supercell. Part of the structure files is pasted as 
follows:

Ni_Diamond
P   10
 RELA
 13.492650 13.492650 13.492650 90.00 90.00 90.00
ATOM   1: X=0. Y=0. Z=0.
  MULT= 1  ISPLIT= 2
C 1NPT=  781  R0=0.0001 RMT=1.3600   Z:  6.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.5000 Y=0. Z=0.
  MULT= 3  ISPLIT=-2
  -2: X=0. Y=0.5000 Z=0.
  -2: X=0. Y=0. Z=0.5000
C 2NPT=  781  R0=0.0001 RMT=1.3600   Z:  6.0
LOCAL ROT MATRIX:0.000 0.000 1.000
 1.000 0.000 0.000
 0.000 1.000 0.000
ATOM  -3: X=0.5000 Y=0.5000 Z=0.
  MULT= 3  ISPLIT=-2
  -3: X=0.5000 Y=0. Z=0.5000
  -3: X=0. Y=0.5000 Z=0.5000
C 3NPT=  781  R0=0.0001 RMT=1.3600   Z:  6.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM   4: X=0.5000 Y=0.5000 Z=0.5000
  MULT= 1  ISPLIT= 2
Ni4NPT=  781  R0=0.5000 RMT=1.7500   Z: 28.0
LOCAL ROT MATRIX:1.000 0.000 0.000
 0.000 1.000 0.000
 0.000 0.000 1.000
ATOM  -5: X=0.2500 Y=0.2500 Z=0.
  MULT=12  ISPLIT= 8
  -5: X=0.7500 Y=0.2500 Z=0.
  -5: X=0.2500 Y=0.7500 Z=0.
  -5: X=0.7500 Y=0.7500 Z=0.
  -5: X=0.2500 Y=0. Z=0.2500

I used the parallel calculation mode and the whole program just crashed in the 
lapw2 step. In the output file, I have the following messages:

 LAPW1 END
 LAPW1 END
LAPW2 - FERMI; weighs written
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
lapw2c 0001000652A1  _l2main_  893  
l2main_tmp_.F
lapw2c 0001000652A1  _l2main_  893  
l2main_tmp_.F
lapw2c 0001000798E3  _MAIN__   564  lapw2_tmp_.F
lapw2c 0001141C  Unknown   Unknown  Unknown
lapw2c 0001000798E3  _MAIN__   564  lapw2_tmp_.F
lapw2c 000113D4  Unknown   Unknown  Unknown
lapw2c 0001141C  Unknown   Unknown  Unknown
lapw2c 000113D4  Unknown   Unknown  Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
lapw2c 0001000652A1  _l2main_  893  
l2main_tmp_.F
lapw2c 0001000798E3  _MAIN__   564  lapw2_tmp_.F
lapw2c 0001141C  Unknown   Unknown  Unknown
lapw2c 000113D4  Unknown   Unknown  Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
lapw2c 0001000652A1  _l2main_  893  
l2main_tmp_.F
forrtl: severe (174): SIGSEGV, segmentation fault occurred
lapw2c 0001000798E3  _MAIN__   564  lapw2_tmp_.F
Image  PCRoutineLineSource
lapw2c 0001141C  Unknown   Unknown  Unknown
lapw2c 0001000652A1  _l2main_  893  
l2main_tmp_.F
lapw2c 000113D4  Unknown   Unknown  Unknown
lapw2c 0001000798E3  _MAIN__   564  lapw2_tmp_.F
lapw2c 0001141C  Unknown   Unknown  Unknown
lapw2c 000113D4  Unknown   Unknown  Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred


I checked the mailist and tried many possible solutions like decreasing the 
value of RMT*KMax. But they just doesn't work. I can paste the other 
configuration files if necessary. I really appreciate any suggestions or 
comments. Thank you in advance.

Best,
Wenhao
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

[Wien] Ghost band problem

[Hu, Wenhao]

Dear all:

I met some confusions in judging whether I got a ghost band in my wien2k 
calculation. What I'm trying to simulate is a 2X2X2 diamond supercell with a 
substituted europium atom in the center and a vacancy in the NN Carbon 
position. I got some warnings in the output file that:

...
WARN : QTL-B value eq.   2.49 in Band of energy   0.79126  ATOM=4  L=  3
WARN : QTL-B value eq.   2.51707   in Band of energy0.79114   ATOM=4   
L=  3
...

where the atom 4 is europium atom. The wien2k Userguide mentions that this 
warning may indicate the existence of ghost band. I know it's challenging for 
lots of DFT methods to deal with europium atom. So I'm afraid that my result is 
not reasonable. Can anyone give me some suggestions on this issue? The band 
structure has been attached. BTW,  I have applied the LSDA+U method and the U 
term is added to the europium's 4s orbital. U and J values are 0.52 Ry and 
0.055 Ry respectively which I got from another literature. 

I really appreciate any advices. If further information is required to make 
judgement, please let me know. I can paste it in the future email. Thank you 
guys in advance.

Best,
Wenhao
-- next part --
A non-text attachment was scrubbed...
Name: Screenshot from 2013-02-27 14:36:18.png
Type: image/png
Size: 31907 bytes
Desc: Screenshot from 2013-02-27 14:36:18.png
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130227/91c58836/attachment-0001.png