Re: [Wien] Confusion in Selecting proper value of Hubbard potential.

2013-07-19 Thread Zaid 
Dear Sir H. Jiang

I implemented GGA+U to my considered compound, keeping in mind that GGA+U
is valuable for compounds having strongly correlated system (like in d and
f orbitals). But My problem is regarding the selection of U value.

Experimental band gap for my compound is 2.0eV. The maximum band gap on
increasing U value for my calculation is 1.117eV at 10 eV. So, should I
increase U value beyond 10eV ? Untill now from my literature review, the
value of U is less than 10 eV.
Secondly, if suppose a compound has not been studied experimentally then
how we choose calue of U ?

Kindly guide.

Best regards
Zaid


On Sat, Jul 20, 2013 at 2:31 PM, Hong Jiang  wrote:

>  Hi,
> The Hubbard U correction in LDA/GGA+U is to correct the failure of LDA/GGA
> to describe localized d- or f-states.  Therefore LDA/GGA+U is able to give
> an accurate band gap only if the band gap of your system happens to be of
> d-d or f-f character, which, however, not the case for most systems (see,
> e.g. H. Jiang, et al. *Phys. Rev. B* *82*, 045108 
> (2010)).
>
> To obtain accurate band gaps, you can try
> * modified Becke-Johnson, ( F. Tran and P. Blaha, Phys. Rev. Lett. *102*,
> 226401 
> (2009);
> H. Jiang (J. Chem. Phys. *134*, 
> 134115(2013))
> * hybrid functionals, (F. Tran and P. Blaha, Phys. Rev. B 83, 235118
> (2011) )
> * GW (if your system is not very big).  (H. Jiang et al. Computer Phys.
> Commun.,*184*, 348(2013) ).
>
> Hong
>
>
> 于 2013/7/20 14:03, Zaid 写道:
>
>Dear Sir,
>
>  you are right. Experimental band gap for my compound is 2.0eV. The
> maximum band gap on increasing U value for my calculation is 1.117eV at 10
> eV. So, should I increase U value beyond 10eV ? Untill now from my
> literature review, the value of U is less than 10 eV.
>  Secondly, if suppose a compound has not been studied experimentally then
> how we choose calue of U ?
>
>  Thank you
>  Zaid
>
>
> On Sat, Jul 20, 2013 at 1:48 PM,  wrote:
>
>> Hi,
>>
>> I have never heard that the proper value of U is the one when the band gap
>> starts to decrease. Usually the value of U is chosen such that the
>> calculated properties (e.g., band gap or magnetic moment) agree with
>> experiment.
>>
>> F. Tran
>>
>> On Sat, 20 Jul 2013, Zaid wrote:
>>
>> > Respected Users
>> >
>> >
>> > I am applying GGA+U technique to considered compounds. In order to
>> select
>> > proper value of U for specific material, I am changing the value of U
>> from
>> > 2eV to 10eV with a step of 1eV. I was expecting that on increasing U
>> value
>> > in the range 2-10eV, a value of U will appear where the corresponding
>> band
>> > gap will start to decrease instead of increase. That value of U where
>> the
>> > band gap start to decrease instead of rising will be the proper U value
>> in
>> > the range 2-10eV.
>> >
>> > I my case the, every time I am getting increasing band gap values on
>> > increasing U value from 2-10eV with a step of 1eV. Band gap does not
>> > decrease in the range 2-10eV. Should I increase the range ? May anyone
>> > suggest that whether my practice of finding U value is right ? If not
>> how
>> > can I find proper value of U for specific compound ?
>> >
>> > Thank you very much
>> >
>> > Best Regards
>> > Zaid
>> >
>> ___
>> 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 
> listw...@zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Confusion in Selecting proper value of Hubbard potential.

2013-07-19 Thread Hong Jiang 

Hi,
The Hubbard U correction in LDA/GGA+U is to correct the failure of 
LDA/GGA to describe localized d- or f-states.  Therefore LDA/GGA+U is 
able to give an accurate band gap only if the band gap of your system 
happens to be of d-d or f-f character, which, however, not the case for 
most systems (see, e.g. H. Jiang, et al. /Phys. Rev. B/ *82*, 045108 
(2010)). 


To obtain accurate band gaps, you can try
* modified Becke-Johnson, ( F. Tran and P. Blaha, Phys. Rev. Lett. 
*102*, 226401 (2009) 
; 
H. Jiang (J. Chem. Phys. *134*, 134115(2013) 
 )
* hybrid functionals, (F. Tran and P. Blaha, Phys. Rev. B 83, 235118 
(2011) )
* GW (if your system is not very big).  (H. Jiang et al. Computer Phys. 
Commun.,*184*, 348(2013) ).


Hong


? 2013/7/20 14:03, Zaid ??:

Dear Sir,

you are right. Experimental band gap for my compound is 2.0eV. The 
maximum band gap on increasing U value for my calculation is 1.117eV 
at 10 eV. So, should I increase U value beyond 10eV ? Untill now from 
my literature review, the value of U is less than 10 eV.
Secondly, if suppose a compound has not been studied experimentally 
then how we choose calue of U ?


Thank you
Zaid


On Sat, Jul 20, 2013 at 1:48 PM, > wrote:


Hi,

I have never heard that the proper value of U is the one when the
band gap
starts to decrease. Usually the value of U is chosen such that the
calculated properties (e.g., band gap or magnetic moment) agree with
experiment.

F. Tran

On Sat, 20 Jul 2013, Zaid wrote:

> Respected Users
>
>
> I am applying GGA+U technique to considered compounds. In order
to select
> proper value of U for specific material, I am changing the value
of U from
> 2eV to 10eV with a step of 1eV. I was expecting that on
increasing U value
> in the range 2-10eV, a value of U will appear where the
corresponding band
> gap will start to decrease instead of increase. That value of U
where the
> band gap start to decrease instead of rising will be the proper
U value in
> the range 2-10eV.
>
> I my case the, every time I am getting increasing band gap values on
> increasing U value from 2-10eV with a step of 1eV. Band gap does not
> decrease in the range 2-10eV. Should I increase the range ? May
anyone
> suggest that whether my practice of finding U value is right ?
If not how
> can I find proper value of U for specific compound ?
>
> Thank you very much
>
> Best Regards
> Zaid
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html




___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Confusion in Selecting proper value of Hubbard potential.

2013-07-19 Thread Zaid 
Dear Sir,

you are right. Experimental band gap for my compound is 2.0eV. The maximum
band gap on increasing U value for my calculation is 1.117eV at 10 eV. So,
should I increase U value beyond 10eV ? Untill now from my literature
review, the value of U is less than 10 eV.
Secondly, if suppose a compound has not been studied experimentally then
how we choose calue of U ?

Thank you
Zaid


On Sat, Jul 20, 2013 at 1:48 PM,  wrote:

> Hi,
>
> I have never heard that the proper value of U is the one when the band gap
> starts to decrease. Usually the value of U is chosen such that the
> calculated properties (e.g., band gap or magnetic moment) agree with
> experiment.
>
> F. Tran
>
> On Sat, 20 Jul 2013, Zaid wrote:
>
> > Respected Users
> >
> >
> > I am applying GGA+U technique to considered compounds. In order to select
> > proper value of U for specific material, I am changing the value of U
> from
> > 2eV to 10eV with a step of 1eV. I was expecting that on increasing U
> value
> > in the range 2-10eV, a value of U will appear where the corresponding
> band
> > gap will start to decrease instead of increase. That value of U where the
> > band gap start to decrease instead of rising will be the proper U value
> in
> > the range 2-10eV.
> >
> > I my case the, every time I am getting increasing band gap values on
> > increasing U value from 2-10eV with a step of 1eV. Band gap does not
> > decrease in the range 2-10eV. Should I increase the range ? May anyone
> > suggest that whether my practice of finding U value is right ? If not how
> > can I find proper value of U for specific compound ?
> >
> > Thank you very much
> >
> > Best Regards
> > Zaid
> >
> ___
> 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] Confusion in Selecting proper value of Hubbard potential.

2013-07-19 Thread tran 
Hi,

I have never heard that the proper value of U is the one when the band gap
starts to decrease. Usually the value of U is chosen such that the
calculated properties (e.g., band gap or magnetic moment) agree with
experiment.

F. Tran

On Sat, 20 Jul 2013, Zaid wrote:

> Respected Users
> 
> 
> I am applying GGA+U technique to considered compounds. In order to select
> proper value of U for specific material, I am changing the value of U from
> 2eV to 10eV with a step of 1eV. I was expecting that on increasing U value
> in the range 2-10eV, a value of U will appear where the corresponding band
> gap will start to decrease instead of increase. That value of U where the
> band gap start to decrease instead of rising will be the proper U value in
> the range 2-10eV.
> 
> I my case the, every time I am getting increasing band gap values on
> increasing U value from 2-10eV with a step of 1eV. Band gap does not
> decrease in the range 2-10eV. Should I increase the range ? May anyone
> suggest that whether my practice of finding U value is right ? If not how
> can I find proper value of U for specific compound ?
> 
> Thank you very much
> 
> Best Regards
> Zaid
> 
___
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] Confusion in Selecting proper value of Hubbard potential.

2013-07-19 Thread Zaid 
Respected Users


I am applying GGA+U technique to considered compounds. In order to select
proper value of U for specific material, I am changing the value of U from
2eV to 10eV with a step of 1eV. I was expecting that on increasing U value
in the range 2-10eV, a value of U will appear where the corresponding band
gap will start to decrease instead of increase. That value of U where the
band gap start to decrease instead of rising will be the proper U value in
the range 2-10eV.

I my case the, every time I am getting increasing band gap values on
increasing U value from 2-10eV with a step of 1eV. Band gap does not
decrease in the range 2-10eV. Should I increase the range ? May anyone
suggest that whether my practice of finding U value is right ? If not how
can I find proper value of U for specific compound ?

Thank you very much

Best Regards
Zaid
___
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 bug in qtl f projection

2013-07-19 Thread Kim Kyoo 
Dear All,
I found a bug in the "qtl" package.
SRC_qtl/transf.f should be debugged as following



==
In the very beginning, the definitions of s3, s5 are missing

  s2=sqrt(2.)
*
!!KK--
*
*  s3=sqrt(3.)*
*  s5=sqrt(5.)*
*
!!---
*
  do m1=-l,l
   do m2=-l,l
T(m1,m2)=0.
   enddo
  enddo

  if(nm.eq.1)then! identity matrix, basis Ylm
   write(6,100)L
100format(' L=',i3,'. Unitary transformation to Ylm basis')
   do m1=-L,L
 T(m1,m1)=1.
   enddo
  else if(nm.ge.2)then! Real basis   (*)
! ordering: real y_L,M^+, y_L,M^-, yL,M-1^+, y_L,M-1^-, y_L0
   write(6,101)L
101format(' L=',i3,'. Unitary transformation to real basis')
   k=-L
   do M=-L,-1
T(k, M)=1./s2
T(k,-M)=1./s2
k=k+1
T(k, M)= img/s2
T(k,-M)=-img/s2
k=k+1
   enddo
T(L, 0)=1.
  endif


  if(L.eq.3)then
   if(nm.eq.5)then ! f states in cubic symmetry treated here
*
!!KK--
*
*T=0*
*
!!---
*

L=3,nm=5 should be treated separately but this condition holds for (*) too
spoiling T matrix. so we need to initialize again
or one can modify the condition (*) to exclude L=3,nm=5 condition
==
tested result was reasonable.

Best,
Kyoo

Kyoo Kim
dept of Physics
POSTECH, Pohang, Korea
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Define the direction of magnetization in case.inso for fcc or bcc cubic lattice

2013-07-19 Thread Peter Blaha 

It is with respect to the conventional cubic cell.

Am 19.07.2013 15:17, schrieb Zhu, Jianxin:

Dear Peter,

When we prepare for case.inso, there is one line for the direction of 
magnetization denoted by h, k, l, which have values like
  0 0 1.

For fcc or bcc cubic lattice, are these values defined with respect to the 
vectors of primitive cell or the vectors of the conventional unit cell?
Which file can I look into to verify their true meaning?

I have this question in the observation that lattice constants for the 
conventional cell are used for fcc or bcc cubic lattices.

Thanks,

Jianxin



- Original Message -
From: Peter Blaha [mailto:pbl...@theochem.tuwien.ac.at]
Sent: Friday, July 19, 2013 07:00 AM
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Multicore on i7 iMac

I suppose you used   -orb  ???

initso told you, that you have to deal with indmc/inorb yourself.

I suppose you have a case.indm  ??
SO needs a case.indmc.

cp case.indm case.indmc

However, when so has splitted your atoms, it could be that you need to
edit the indmc (and inorb) file and add the corresponding lines for
your eventually splitted positions

Am 19.07.2013 11:31, schrieb pl...@physics.ucdavis.edu:

Dear WIEN2k experts,

My GdTiO3 bulk calculation (space group 62) works well on the iMac with
GGA+U. However, when I try to add SOC there is an error after the first
iteration:

lplucin@iff1276:GTO_GGAU_SOC % more STDOUT
   LAPW0 END
   LAPW1 END
   LAPW1 END
   LAPW1 END
   LAPW1 END
LAPWSO END
LAPWSO END
LAPW2 - FERMI; weighs written
   LAPW2 END
   LAPW2 END
   SUMPARA END
LAPW2 - FERMI; weighs written
   LAPW2 END
   LAPW2 END
   SUMPARA END


stop error: the required input file GTO_GGAU_SOC.indmc for the next

step could not be found

Could you advise?

Regards,
Lukasz



Dear Prof. Blaha,

Thank you for your comment, it helps.

My slab was indeed wrong not having the inversion symmetry. I have now
constructed the slab with the inversions symmetry (was found automatic by
nn and sgroup), and the calculation is running. Actually you have
explained that to me already in 2008 (see below)... so I'm a bit
embarrassed :-)

The calculation is for Fe slab. UG says, that it is sufficient to do SCF
without spin-orbit, and then initialize spin-orbit and do one single SCF
iteration with spin-orbit. Or should I converge SCF again after including
spin-orbit? In any case, once I get the slab running properly, I am
planning to test and compare the results.

Regards,
Lukasz




 Original Message 
Subject:Re: [Wien] Fe slab
Date:   Fri, 04 Jul 2008 14:56:26 +0200
From:   Peter Blaha 
Reply-To:   A Mailing list for WIEN2k users

To: A Mailing list for WIEN2k users 


Why would you use such a struct file ?

a) With limited experience, start with small models, 5 or 7 layers only.
b) I don't know how this struct file was created, but for sure a 15
layer Fe(001) slab can have inversion symmetry and I'm pretty sure that
WIEN should be able to find the proper symmetry (sgroup) when you allow
for it.Remove ALL numbering for atomes (Fe1,2,3,...) and run the
initialization. sgroup (or nn in most cases) should always group 2 atoms
together (make them equivalent, except the center). sgroup should also
shift the atoms along z.
Your calculations will be 4 times faster when you have inversion symmetry!
c) When going for thicker slabs, you should also improve your vacuum. It
does not make sense to go to a thick slab, but have surface-surface
interactions through the vacuum.
d) k-mesh: why would one use a "2" fold k-mesh in z-direction. With
recent WIEN2k versions you can also specify a 21x21x1 mesh for kgen.
e) Some cases may need more than 40 iterations. As long as it does not
diverge, just continue.
f) Eventually TEMP with some broadening (0.005) may help convergence.
However, in particular with magnetic systems, make sure that the
broadening does not influence your magnetism and recheck with smaller
broadening.











  From this message alone, we one cannot say anything, maybe except that the
calculations seem to have diverged (large CTEST).

But when starting from a converged calculation, this is very unusual.

PS: In a "slab" calculation it is almost always possible to setup the slab
such that it has inversion symmetry and thus you would have case.in1
instead of case.in1c.
Inversion for slabs is a) much faster, b) avoids spurious dipoles from two
different surfaces.

On 04/17/2013 11:03 PM, pl...@physics.ucdavis.edu wrote:

Dear Prof. Blaha and WIEN2k experts,

I have 4 physical cores (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz). It
seems that on my compilation using HT and filling up all 8 threads makes
some particular calculation just a bit faster compared to the settings
you
have suggested, but with HT CPU gets more hot (fan is on more often), so
it makes no sense. I will use the settings you have recommended.

I have now an error for the slab with spin-polarized but without spin
orbit

[Wien] Define the direction of magnetization in case.inso for fcc or bcc cubic lattice

2013-07-19 Thread Zhu, Jianxin 
Dear Peter,

When we prepare for case.inso, there is one line for the direction of 
magnetization denoted by h, k, l, which have values like 
 0 0 1.

For fcc or bcc cubic lattice, are these values defined with respect to the 
vectors of primitive cell or the vectors of the conventional unit cell? 
Which file can I look into to verify their true meaning?

I have this question in the observation that lattice constants for the 
conventional cell are used for fcc or bcc cubic lattices.

Thanks,

Jianxin
 


- Original Message -
From: Peter Blaha [mailto:pbl...@theochem.tuwien.ac.at]
Sent: Friday, July 19, 2013 07:00 AM
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Multicore on i7 iMac

I suppose you used   -orb  ???

initso told you, that you have to deal with indmc/inorb yourself.

I suppose you have a case.indm  ??
SO needs a case.indmc.

cp case.indm case.indmc

However, when so has splitted your atoms, it could be that you need to 
edit the indmc (and inorb) file and add the corresponding lines for
your eventually splitted positions

Am 19.07.2013 11:31, schrieb pl...@physics.ucdavis.edu:
> Dear WIEN2k experts,
>
> My GdTiO3 bulk calculation (space group 62) works well on the iMac with
> GGA+U. However, when I try to add SOC there is an error after the first
> iteration:
>
> lplucin@iff1276:GTO_GGAU_SOC % more STDOUT
>   LAPW0 END
>   LAPW1 END
>   LAPW1 END
>   LAPW1 END
>   LAPW1 END
> LAPWSO END
> LAPWSO END
> LAPW2 - FERMI; weighs written
>   LAPW2 END
>   LAPW2 END
>   SUMPARA END
> LAPW2 - FERMI; weighs written
>   LAPW2 END
>   LAPW2 END
>   SUMPARA END
>
>>stop error: the required input file GTO_GGAU_SOC.indmc for the next
> step could not be found
>
> Could you advise?
>
> Regards,
> Lukasz
>
>
>> Dear Prof. Blaha,
>>
>> Thank you for your comment, it helps.
>>
>> My slab was indeed wrong not having the inversion symmetry. I have now
>> constructed the slab with the inversions symmetry (was found automatic by
>> nn and sgroup), and the calculation is running. Actually you have
>> explained that to me already in 2008 (see below)... so I'm a bit
>> embarrassed :-)
>>
>> The calculation is for Fe slab. UG says, that it is sufficient to do SCF
>> without spin-orbit, and then initialize spin-orbit and do one single SCF
>> iteration with spin-orbit. Or should I converge SCF again after including
>> spin-orbit? In any case, once I get the slab running properly, I am
>> planning to test and compare the results.
>>
>> Regards,
>> Lukasz
>>
>>
>>
>>
>>  Original Message 
>> Subject: Re: [Wien] Fe slab
>> Date:Fri, 04 Jul 2008 14:56:26 +0200
>> From:Peter Blaha 
>> Reply-To:A Mailing list for WIEN2k users
>> 
>> To:  A Mailing list for WIEN2k users 
>>
>>
>> Why would you use such a struct file ?
>>
>> a) With limited experience, start with small models, 5 or 7 layers only.
>> b) I don't know how this struct file was created, but for sure a 15
>> layer Fe(001) slab can have inversion symmetry and I'm pretty sure that
>> WIEN should be able to find the proper symmetry (sgroup) when you allow
>> for it.Remove ALL numbering for atomes (Fe1,2,3,...) and run the
>> initialization. sgroup (or nn in most cases) should always group 2 atoms
>> together (make them equivalent, except the center). sgroup should also
>> shift the atoms along z.
>> Your calculations will be 4 times faster when you have inversion symmetry!
>> c) When going for thicker slabs, you should also improve your vacuum. It
>> does not make sense to go to a thick slab, but have surface-surface
>> interactions through the vacuum.
>> d) k-mesh: why would one use a "2" fold k-mesh in z-direction. With
>> recent WIEN2k versions you can also specify a 21x21x1 mesh for kgen.
>> e) Some cases may need more than 40 iterations. As long as it does not
>> diverge, just continue.
>> f) Eventually TEMP with some broadening (0.005) may help convergence.
>> However, in particular with magnetic systems, make sure that the
>> broadening does not influence your magnetism and recheck with smaller
>> broadening.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  From this message alone, we one cannot say anything, maybe except that the
>> calculations seem to have diverged (large CTEST).
>>
>> But when starting from a converged calculation, this is very unusual.
>>
>> PS: In a "slab" calculation it is almost always possible to setup the slab
>> such that it has inversion symmetry and thus you would have case.in1
>> instead of case.in1c.
>> Inversion for slabs is a) much faster, b) avoids spurious dipoles from two
>> different surfaces.
>>
>> On 04/17/2013 11:03 PM, pl...@physics.ucdavis.edu wrote:
>>> Dear Prof. Blaha and WIEN2k experts,
>>>
>>> I have 4 physical cores (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz). It
>>> seems that on my compilation using HT and filling up all 8 threads makes
>>> some particular calculation just a bit faster compared to the settings
>>> you
>>> have suggested, but with HT CPU gets

Re: [Wien] Multicore on i7 iMac

2013-07-19 Thread Peter Blaha 

I suppose you used   -orb  ???

initso told you, that you have to deal with indmc/inorb yourself.

I suppose you have a case.indm  ??
SO needs a case.indmc.

cp case.indm case.indmc

However, when so has splitted your atoms, it could be that you need to 
edit the indmc (and inorb) file and add the corresponding lines for

your eventually splitted positions

Am 19.07.2013 11:31, schrieb pl...@physics.ucdavis.edu:

Dear WIEN2k experts,

My GdTiO3 bulk calculation (space group 62) works well on the iMac with
GGA+U. However, when I try to add SOC there is an error after the first
iteration:

lplucin@iff1276:GTO_GGAU_SOC % more STDOUT
  LAPW0 END
  LAPW1 END
  LAPW1 END
  LAPW1 END
  LAPW1 END
LAPWSO END
LAPWSO END
LAPW2 - FERMI; weighs written
  LAPW2 END
  LAPW2 END
  SUMPARA END
LAPW2 - FERMI; weighs written
  LAPW2 END
  LAPW2 END
  SUMPARA END


   stop error: the required input file GTO_GGAU_SOC.indmc for the next

step could not be found

Could you advise?

Regards,
Lukasz



Dear Prof. Blaha,

Thank you for your comment, it helps.

My slab was indeed wrong not having the inversion symmetry. I have now
constructed the slab with the inversions symmetry (was found automatic by
nn and sgroup), and the calculation is running. Actually you have
explained that to me already in 2008 (see below)... so I'm a bit
embarrassed :-)

The calculation is for Fe slab. UG says, that it is sufficient to do SCF
without spin-orbit, and then initialize spin-orbit and do one single SCF
iteration with spin-orbit. Or should I converge SCF again after including
spin-orbit? In any case, once I get the slab running properly, I am
planning to test and compare the results.

Regards,
Lukasz




 Original Message 
Subject:Re: [Wien] Fe slab
Date:   Fri, 04 Jul 2008 14:56:26 +0200
From:   Peter Blaha 
Reply-To:   A Mailing list for WIEN2k users

To: A Mailing list for WIEN2k users 


Why would you use such a struct file ?

a) With limited experience, start with small models, 5 or 7 layers only.
b) I don't know how this struct file was created, but for sure a 15
layer Fe(001) slab can have inversion symmetry and I'm pretty sure that
WIEN should be able to find the proper symmetry (sgroup) when you allow
for it.Remove ALL numbering for atomes (Fe1,2,3,...) and run the
initialization. sgroup (or nn in most cases) should always group 2 atoms
together (make them equivalent, except the center). sgroup should also
shift the atoms along z.
Your calculations will be 4 times faster when you have inversion symmetry!
c) When going for thicker slabs, you should also improve your vacuum. It
does not make sense to go to a thick slab, but have surface-surface
interactions through the vacuum.
d) k-mesh: why would one use a "2" fold k-mesh in z-direction. With
recent WIEN2k versions you can also specify a 21x21x1 mesh for kgen.
e) Some cases may need more than 40 iterations. As long as it does not
diverge, just continue.
f) Eventually TEMP with some broadening (0.005) may help convergence.
However, in particular with magnetic systems, make sure that the
broadening does not influence your magnetism and recheck with smaller
broadening.











 From this message alone, we one cannot say anything, maybe except that the
calculations seem to have diverged (large CTEST).

But when starting from a converged calculation, this is very unusual.

PS: In a "slab" calculation it is almost always possible to setup the slab
such that it has inversion symmetry and thus you would have case.in1
instead of case.in1c.
Inversion for slabs is a) much faster, b) avoids spurious dipoles from two
different surfaces.

On 04/17/2013 11:03 PM, pl...@physics.ucdavis.edu wrote:

Dear Prof. Blaha and WIEN2k experts,

I have 4 physical cores (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz). It
seems that on my compilation using HT and filling up all 8 threads makes
some particular calculation just a bit faster compared to the settings
you
have suggested, but with HT CPU gets more hot (fan is on more often), so
it makes no sense. I will use the settings you have recommended.

I have now an error for the slab with spin-polarized but without spin
orbit (see below part of STDOUT file). I tried to look at old emails
from
this group, but could not quickly find a solution. Same slab has
converged
before in a non-parallel mode with spin-polarized and with spin-orbit. I
use cutoff 8 Ry and:

K-VECTORS FROM UNIT:4  -11.0   5.5   933   emin/emax/nband

in case.in1c.

Regards,
Lukasz


...
   CORE  END
   CORE  END
   MIXER END
in cycle 22ETEST: .381681805000   CTEST: 1.9705727
   LAPW0 END
   LAPW1 END
   LAPW1 END
   LAPW1 END
   LAPW1 END
LAPW2 - FERMI; weighs written
   LAPW2 END
   LAPW2 END
   SUMPARA END
LAPW2 - FERMI; weighs written
   LAPW2 END
   LAPW2 END
   SUMPARA END
   CORE  END
   CORE  END
   MIXER END
in cycle 23ETEST: .294226365000   CTEST: 2.3441252
   LAPW0 END
   LAPW1 END
   LAPW1 END
   LAPW1 END
   LAPW1 END
FERMI -

Re: [Wien] Error in CORE in external field example

2013-07-19 Thread Peter Blaha 

What do you think if you apply a field of 100 Ry ???

Am 18.07.2013 08:40, schrieb Yasir Ali:



Hi dear wien2k  users and dear P. Blaha
I am just struck with error. i am using an external electric field and
during run_lapw it gives CORE error. when i opend the error file, it
gives a message like
_
  'CORE' - NSTOP= 362 positive eigenvalue for  3S  Atom:   0 Zn1
  'CORE' - Try to apply a potential shift in case.inc
__

my case.in0 is this.

___
TOT   13(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA)
NR2V  IFFT  (R2V)
   40  40 402.00  1min IFFT-parameters, enhancement factor, iprint
30 100.0   (#of FK in E-field expansion, EFELD (Ry)
___
Please help in removing thiss error.

Regards:
Yasir Ali





Regards:
Yasir Ali



___
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



--
Peter Blaha
Inst.Materials Chemistry
TU Vienna
Getreidemarkt 9
A-1060 Vienna
Austria
+43-1-5880115671
___
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] Multicore on i7 iMac

2013-07-19 Thread pluto 
Dear WIEN2k experts,

My GdTiO3 bulk calculation (space group 62) works well on the iMac with
GGA+U. However, when I try to add SOC there is an error after the first
iteration:

lplucin@iff1276:GTO_GGAU_SOC % more STDOUT
 LAPW0 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
 LAPW1 END
LAPWSO END
LAPWSO END
LAPW2 - FERMI; weighs written
 LAPW2 END
 LAPW2 END
 SUMPARA END
LAPW2 - FERMI; weighs written
 LAPW2 END
 LAPW2 END
 SUMPARA END

>   stop error: the required input file GTO_GGAU_SOC.indmc for the next
step could not be found

Could you advise?

Regards,
Lukasz


> Dear Prof. Blaha,
>
> Thank you for your comment, it helps.
>
> My slab was indeed wrong not having the inversion symmetry. I have now
> constructed the slab with the inversions symmetry (was found automatic by
> nn and sgroup), and the calculation is running. Actually you have
> explained that to me already in 2008 (see below)... so I'm a bit
> embarrassed :-)
>
> The calculation is for Fe slab. UG says, that it is sufficient to do SCF
> without spin-orbit, and then initialize spin-orbit and do one single SCF
> iteration with spin-orbit. Or should I converge SCF again after including
> spin-orbit? In any case, once I get the slab running properly, I am
> planning to test and compare the results.
>
> Regards,
> Lukasz
>
>
>
>
>  Original Message 
> Subject:  Re: [Wien] Fe slab
> Date: Fri, 04 Jul 2008 14:56:26 +0200
> From: Peter Blaha 
> Reply-To: A Mailing list for WIEN2k users
> 
> To:   A Mailing list for WIEN2k users 
>
>
> Why would you use such a struct file ?
>
> a) With limited experience, start with small models, 5 or 7 layers only.
> b) I don't know how this struct file was created, but for sure a 15
> layer Fe(001) slab can have inversion symmetry and I'm pretty sure that
> WIEN should be able to find the proper symmetry (sgroup) when you allow
> for it.Remove ALL numbering for atomes (Fe1,2,3,...) and run the
> initialization. sgroup (or nn in most cases) should always group 2 atoms
> together (make them equivalent, except the center). sgroup should also
> shift the atoms along z.
> Your calculations will be 4 times faster when you have inversion symmetry!
> c) When going for thicker slabs, you should also improve your vacuum. It
> does not make sense to go to a thick slab, but have surface-surface
> interactions through the vacuum.
> d) k-mesh: why would one use a "2" fold k-mesh in z-direction. With
> recent WIEN2k versions you can also specify a 21x21x1 mesh for kgen.
> e) Some cases may need more than 40 iterations. As long as it does not
> diverge, just continue.
> f) Eventually TEMP with some broadening (0.005) may help convergence.
> However, in particular with magnetic systems, make sure that the
> broadening does not influence your magnetism and recheck with smaller
> broadening.
>
>
>
>
>
>
>
>
>
>
>
> From this message alone, we one cannot say anything, maybe except that the
> calculations seem to have diverged (large CTEST).
>
> But when starting from a converged calculation, this is very unusual.
>
> PS: In a "slab" calculation it is almost always possible to setup the slab
> such that it has inversion symmetry and thus you would have case.in1
> instead of case.in1c.
> Inversion for slabs is a) much faster, b) avoids spurious dipoles from two
> different surfaces.
>
> On 04/17/2013 11:03 PM, pl...@physics.ucdavis.edu wrote:
>> Dear Prof. Blaha and WIEN2k experts,
>>
>> I have 4 physical cores (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz). It
>> seems that on my compilation using HT and filling up all 8 threads makes
>> some particular calculation just a bit faster compared to the settings
>> you
>> have suggested, but with HT CPU gets more hot (fan is on more often), so
>> it makes no sense. I will use the settings you have recommended.
>>
>> I have now an error for the slab with spin-polarized but without spin
>> orbit (see below part of STDOUT file). I tried to look at old emails
>> from
>> this group, but could not quickly find a solution. Same slab has
>> converged
>> before in a non-parallel mode with spin-polarized and with spin-orbit. I
>> use cutoff 8 Ry and:
>>
>> K-VECTORS FROM UNIT:4  -11.0   5.5   933   emin/emax/nband
>>
>> in case.in1c.
>>
>> Regards,
>> Lukasz
>>
>>
>> ...
>>   CORE  END
>>   CORE  END
>>   MIXER END
>> in cycle 22ETEST: .381681805000   CTEST: 1.9705727
>>   LAPW0 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>> LAPW2 - FERMI; weighs written
>>   LAPW2 END
>>   LAPW2 END
>>   SUMPARA END
>> LAPW2 - FERMI; weighs written
>>   LAPW2 END
>>   LAPW2 END
>>   SUMPARA END
>>   CORE  END
>>   CORE  END
>>   MIXER END
>> in cycle 23ETEST: .294226365000   CTEST: 2.3441252
>>   LAPW0 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>>   LAPW1 END
>> FERMI - Error
>> cp: .in.tmp: No such file or directory
>>
>>>stop error
>>
>>
>>
>>
>> How many "real" cores do you have ? Most likely only 4 (the 8 comes from
>> hyperthreading

Re: [Wien] wien2venus.py problem

2013-07-19 Thread Dr. Sharat Chandra 


Dear Yasir Ali

Please use XCrysden for calculating the 3D electron density distribution 
in WIEN2k. It can handle spin polarized cases as well.


Regards
Sharat Chandra

On Thu, 18 Jul 2013, Yasir Ali wrote:


Date: Thu, 18 Jul 2013 22:16:35 -0700 (PDT)
From: Yasir Ali 
Reply-To: A Mailing list for WIEN2k users 
To: wien 
Subject: [Wien] wien2venus.py problem

I am facing problem in wien2venus.py. i used "wien2venus.py 50 50 50 "to 
generate case.rho3d file of electron density. When i used to plot this 
generated file, i.e., case.rho3d in VESTA, it does not give plot but 
only give an empty cube.


So any one can tell me what is the problem?

Regards:

Yasir Ali


___
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