[Wien] Comparing Total Energies

[David Tompsett]

Dear Fabien,

Thanks for the response. It is probably my k-mesh that is making it
inaccurate to compare.

David.

On Tue, Jul 10, 2012 at 3:48 PM,  wrote:

> Hi,
>
> When comparing two total energies obtained from different unit cells, one
> has to be always very careful.
>
> First, if you did the calculation on the
> small unit cell with a k-mesh (n1,n2,n3), then the calculation on the
> large unit cell should be done with the corresponding k-mesh
> (n1/m1,n2/m2,n3/m3), where m1, m2, and m3 indicate by how many times
> (along the lattice vectors a, b and c) is the large unit cell larger than
> the small one. You can have problems if If n1/m1, n2/m2 or n3/m3 is not
> an integer. But this not a problem if you
> are using very good k-meshes such that the energies are well converged.
>
> It can also happen that the orientation of the lattice vectors are
> completely different in the small and large unit cells. In this case
> some numerical noise (e.g., from the FFTs) can introduce some errors.
>
> But actually, what do you mean by "I can't compare"?
>
> My recommendation: use the same unit cell.
>
> F. Tran
>
> On Tue, 10 Jul 2012, David Tompsett wrote:
>
> > Dear All,
> >
> > I have what is probably a very basic question about comparing total
> > energies. I have been considering a system that undergoes a charge
> density
> > wave transition from a high to low symmetry structure. I have been
> > comparing the total energy of the high and low symmetry structures. The
> > unit cell of the high symmetry structure has half as many atoms as does
> the
> > low symmetry one.
> >
> > In my calculations it seems I can't compare 2x(total energy of high
> > symmetry cell) with 1x(total energy of low symmetry cell). Instead I have
> > to perform the high symmetry calculation in the same size unit cell and
> > symmetry as for the low symmetry. Why is this the case? What is the
> effect
> > of having different sized unit cells?
> >
> > Thank you,
> > David Tompsett.
> >
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/e6ca7ddc/attachment-0001.htm>

[Wien] negative grr values in mBJ calculation causing lapw0 to fail

[Neil Johnson]

Hello Dr. Tran,

I believe I have located the problem. The SCF cycle did not fully converge 
before the density gradient was calculated. Running SCF to full convergence 
should ameliorate this issue.

Thank you,
-Neil Johnson, B.Sc.



On 12-07-11 1:22 AM, tran at theochem.tuwien.ac.at wrote:
> In principle, GRR should not be negative because it is the average of
> |??|/? (note that it's the norm) in the unit cell volume.
> In output0_grr, there is
> TOTAL=  *
> for the PLANE WAVE CONTRIBUTION, which means that the problem comes from
> the interstitial region. I would guess that this comes from some numerical
> instabilities.
>
> Such problems car arise close to the nucleus of very atoms or in regions
> of space with low electron density. Is it the case in your system?
> For the moment, I can not say much more.
>
> F. Tran
>
> On Tue, 10 Jul 2012, Neil Johnson wrote:
>
>> Hello all,
>> I am attempting to perform an mBJ calculation using the steps listed in sec
>> 4.5.8 of the user's manual. However, lapw0 keeps failing in the final scf
>> cycles after switching to IXC=28. We tracked the problem down to a negative
>> GRR (??/? = -36.0544), the square root of which is taken to calculate "c for
>> IXC=28" in lapw0. Taking the square root of a negative number is generally
>> frowned upon, and the program spits out a lot of "NaN"s before failing.
>>
>> Has anyone experienced this problem before, or know what would cause lapw0
>> -grr to produce a negative GRR value?
>>
>> I've posted the output0 and output0_grr files to
>> http://homepage.usask.ca/~nwj781/lapw0/
>> <http://homepage.usask.ca/%7Enwj781/lapw0/> for reference. Thanks!
>>
>> Cheers,
>>
>> Neil Johnson
>> University of Saskatchewan
>> Saskatoon, Canada
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>
>>
>>
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/3549a0bf/attachment.htm>

[Wien] Carrier Density of ZrO2

[Avijit Ghosh]

On Fri, Jul 6, 2012 at 4:01 AM, Gavin Abo  wrote:

>  Check into whether BoltzTraP (a separate code from Wien2k) can do what
> you want, there is a link to the code on the unsupported page:
>
> http://www.wien2k.at/reg_user/unsupported/
>
> Also, refer to:
>
> http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-February/016178.html
>
>
> On 7/5/2012 10:19 AM, Alex Animalu wrote:
>
>   Dear Wien2k Users,
> Pls, I am new to wien2k. I have successfully done a converged
> self-consistent calculation for ZrO2. Now, I need the carrier density
> (concentration) of the system. I know that lapw5 calculates charge densityand 
> other information are in *.scf. Please, help me by guiding me to where
> I can find the carrier density (in unit of say 10^18 per cm cube) in my
> output or how to obtain it.
>
> Thank you very much for your help.
>
> ___
> Wien mailing listWien at 
> zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>


-- 
***
Dr. Avijit Ghosh
Assistant Professor
Centre for Applied Physics
Central University of Jharkhand,
Ratu- Lohardaga Road,
Brambe, Ranchi
Jharkhand-835205
INDIA.
Mob: +919474403587
E-mail: avijit at phy.iitkgp.ernet.in
avi_phy at rediffmail.com
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/6c531dd0/attachment.htm>

[Wien] compilation error in lapw1_mpi

[alpa dashora]

Dear Wien2k users,

I have also tried -lmpi in RP_LIBS, but it still gives the same error.
rgds,

On Wed, Jul 11, 2012 at 7:26 AM, Gavin Abo  wrote:

>  Add "-lmpi" to your RP_LIBS.  This should resolve the undefined ompi_mpi
> references.
>
>
> On 7/10/2012 5:26 AM, Laurence Marks wrote:
>
> Go directly to the link advisor page that Gavin gave and copy what it
> tells you to use.
>
> N.B.  Wienk currently does not need the real fftw libraries (rfftw)
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu 1-847-491-3996
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought"
> Albert Szent-Gyorgi
>  On Jul 10, 2012 3:47 AM, "alpa dashora"  wrote:
>
>>  Dear Wien2k user,
>>
>> Thank you very much for your reply. I have changed the OPTIONS as
>> suggested by bu, but it still gives the same error message as earlier.
>>
>> Please suggest me.
>>
>> With kind regards,
>>
>> On Tue, Jul 10, 2012 at 1:32 PM, Gavin Abo  wrote:
>>
>>>  The link advisor (
>>> http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/)
>>> settings with MKL 10.0, Linux, Intel 64, Fortran, Static, LP64, Sequential,
>>> Scalapack, and Open MPI:
>>>
>>> $(MKLROOT)/lib/em64t/libmkl_scalapack_lp64.a
>>> $(MKLROOT)/lib/em64t/libmkl_solver_lp64_sequential.a *-Wl,--start-group*
>>> $(MKLROOT)/lib/em64t/libmkl_intel_lp64.a
>>> $(MKLROOT)/lib/em64t/libmkl_sequential.a $(MKLROOT)/lib/em64t/libmkl_core.a
>>> $(MKLROOT)/lib/em64t/libmkl_blacs_openmpi_lp64.a *-Wl,--end-group
>>> -lpthread -lm*
>>>
>>> suggest that your RP_LIBS settings may need to be:
>>>
>>> current:RP_LIBS:-L/opt/intel/cmkl/10.0.1.014/lib/em64t-lmkl_scalapack_lp64 
>>> -lmkl_solver_lp64_sequential
>>> *-Wl,--start-group* -lmkl_intel_lp64 -lmkl_sequential -lmkl_core
>>> -lmkl_blacs_openmpi_lp64 *-Wl,--end-group* *-lpthread 
>>> -lm*-L/opt/fftw-2.1.5/lib/lib/ -lfftw_mpi -lrfftw_mpi -lfftw -lrfftw
>>>
>>>
>>> On 7/9/2012 11:02 PM, alpa dashora wrote:
>>>
>>>Dear Prof. Blaha and Wien2k users,
>>>
>>> I am trying to install Wien2k_11.5 in parallel mode on a 8 processors
>>> server. On compilation, it gives the error in lapw1_mpi as follows:
>>>
>>> /opt/intel/cmkl/
>>> 10.0.1.014/lib/em64t/libmkl_blacs_openmpi_lp64.a(igesd2d_.o)<http://10.0.1.014/lib/em64t/libmkl_blacs_openmpi_lp64.a%28igesd2d_.o%29>:
>>> In function `igesd2d_':
>>>
>>> _igesd2d_.c:(.text+0x43): undefined reference to `ompi_mpi_int'
>>>
>>> _igesd2d_.c:(.text+0x95): undefined reference to `ompi_mpi_byte'
>>> with so many lines.
>>>
>>> The OPTIONS file is as follows:
>>>
>>> current:FOPT:-FR -O3 -mp1 -w -prec_div -pc80 -pad -ip -traceback
>>> -l/opt/openmpi/include
>>> current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -traceback
>>> current:LDFLAGS:-L/root/WIEN2k_11/SRC_lib -L/opt/intel/cmkl/
>>> 10.0.1.014/lib/em64t -lmkl_em64t -lmkl_blacs_openmpi_lp64 -lmkl_solver
>>> -lguide -lpthread
>>> current:DPARALLEL:'-DParallel'
>>> current:R_LIBS:-L/opt/intel/cmkl/10.0.1.014/lib/em64t-lmkl_scalapack_lp64 
>>> -lmkl_solver_lp64_sequential -lmkl_intel_lp64
>>> -lmkl_sequential -lmkl_core -lmkl_blacs_openmpi_lp64
>>> -L/opt/fftw-2.1.5/lib/lib/ -lfftw_mpi -lrfftw_mpi -lfftw -lrfftw
>>> current:RP_LIBS:-L/opt/intel/cmkl/10.0.1.014/lib/em64t-lmkl_scalapack_lp64 
>>> -lmkl_solver_lp64_sequential -lmkl_intel_lp64
>>> -lmkl_sequential -lmkl_core -lmkl_blacs_openmpi_lp64
>>> -L/opt/fftw-2.1.5/lib/lib/ -lfftw_mpi -lrfftw_mpi -lfftw -lrfftw
>>> current:MPIRUN:/opt/openmpi/1.3/bin/mpirun -v -n_NP_ _EXEC_
>>>  Please tell me how to reduce this error.
>>>
>>> *Note:* I am able to run the program with single processor.
>>>
>>> Thanks in advance.
>>>
>>> With kind regards,
>>>
>>> --
>>>  Dr. Alpa Dashora
>>>
>>>
>>>
>>> --
>>> Alpa Dashora
>>>
>>>
>>>  ___
>>> Wien mailing listWien at 
>>> zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>
>>>
>>>
>>>
>>> ___
>>> Wien mailing list
>>> Wien at zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>
>>>
>>
>>
>> --
>> Alpa Dashora
>>
>
>
> ___
> Wien mailing listWien at 
> zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>


-- 
Alpa Dashora
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/e93fb355/attachment.htm>

[Wien] hello

[halima zaari]

I am a Phd student who use the code Wien2k-11.  we installed this  code
under open suse  with intel ifort 12 +mkl
I run the calculation with a simple system GaAs without  supercell. it works
fine but when I run the supercell calculation it does not work and it gives
me the following message
 /home/WIEN2K/lapw1c . uplapw1.def   failed
I check the folder wehere he  gives it the edge. you find the attached file
think su much for help me

with the best regards
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/c01677c5/attachment.htm>
-- next part --
A non-text attachment was scrubbed...
Name: uplapw1.def
Type: application/octet-stream
Size: 627 bytes
Desc: not available
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/c01677c5/attachment.dll>
-- next part --
A non-text attachment was scrubbed...
Name: uplapw1.error
Type: application/octet-stream
Size: 14 bytes
Desc: not available
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/c01677c5/attachment-0001.dll>

[Wien] negative grr values in mBJ calculation causing lapw0 to fail

[t...@theochem.tuwien.ac.at]

In principle, GRR should not be negative because it is the average of
|??|/? (note that it's the norm) in the unit cell volume.
In output0_grr, there is
TOTAL=  *
for the PLANE WAVE CONTRIBUTION, which means that the problem comes from
the interstitial region. I would guess that this comes from some numerical
instabilities.

Such problems car arise close to the nucleus of very atoms or in regions
of space with low electron density. Is it the case in your system?
For the moment, I can not say much more.

F. Tran

On Tue, 10 Jul 2012, Neil Johnson wrote:

> Hello all,
> I am attempting to perform an mBJ calculation using the steps listed in sec
> 4.5.8 of the user's manual. However, lapw0 keeps failing in the final scf
> cycles after switching to IXC=28. We tracked the problem down to a negative
> GRR (??/? = -36.0544), the square root of which is taken to calculate "c for
> IXC=28" in lapw0. Taking the square root of a negative number is generally
> frowned upon, and the program spits out a lot of "NaN"s before failing.
> 
> Has anyone experienced this problem before, or know what would cause lapw0
> -grr to produce a negative GRR value?
> 
> I've posted the output0 and output0_grr files to
> http://homepage.usask.ca/~nwj781/lapw0/
>  for reference. Thanks!
> 
> Cheers,
> 
> Neil Johnson
> University of Saskatchewan
> Saskatoon, Canada
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> 
> 

[Wien] compilation error in lapw1_mpi

[Gavin Abo]

gt; with so many lines.
>>>
>>> The OPTIONS file is as follows:
>>>
>>> current:FOPT:-FR -O3 -mp1 -w -prec_div -pc80 -pad -ip
>>> -traceback -l/opt/openmpi/include
>>> current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip
>>> -traceback
>>> current:LDFLAGS:-L/root/WIEN2k_11/SRC_lib
>>> -L/opt/intel/cmkl/10.0.1.014/lib/em64t
>>> <http://10.0.1.014/lib/em64t> -lmkl_em64t
>>> -lmkl_blacs_openmpi_lp64 -lmkl_solver -lguide -lpthread
>>> current:DPARALLEL:'-DParallel'
>>> current:R_LIBS:-L/opt/intel/cmkl/10.0.1.014/lib/em64t
>>> <http://10.0.1.014/lib/em64t> -lmkl_scalapack_lp64
>>> -lmkl_solver_lp64_sequential -lmkl_intel_lp64
>>> -lmkl_sequential -lmkl_core -lmkl_blacs_openmpi_lp64
>>> -L/opt/fftw-2.1.5/lib/lib/ -lfftw_mpi -lrfftw_mpi -lfftw
>>> -lrfftw
>>> current:RP_LIBS:-L/opt/intel/cmkl/10.0.1.014/lib/em64t
>>> <http://10.0.1.014/lib/em64t> -lmkl_scalapack_lp64
>>> -lmkl_solver_lp64_sequential -lmkl_intel_lp64
>>> -lmkl_sequential -lmkl_core -lmkl_blacs_openmpi_lp64
>>> -L/opt/fftw-2.1.5/lib/lib/ -lfftw_mpi -lrfftw_mpi -lfftw
>>> -lrfftw
>>> current:MPIRUN:/opt/openmpi/1.3/bin/mpirun -v -n_NP_ _EXEC_
>>>
>>> Please tell me how to reduce this error.
>>>
>>> *Note:* I am able to run the program with single processor.
>>>
>>> Thanks in advance.
>>>
>>> With kind regards,
>>>
>>> -- 
>>> Dr. Alpa Dashora
>>>
>>>
>>>
>>> -- 
>>> Alpa Dashora
>>>
>>>
>>> ___
>>> Wien mailing list
>>> Wien at zeus.theochem.tuwien.ac.at  <mailto:Wien at 
>>> zeus.theochem.tuwien.ac.at>
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>
>>
>>
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> <mailto:Wien at zeus.theochem.tuwien.ac.at>
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>
>>
>>
>>
>> -- 
>> Alpa Dashora
>>
>>
>>
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at  <mailto:Wien at 
>> zeus.theochem.tuwien.ac.at>
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> <mailto:Wien at zeus.theochem.tuwien.ac.at>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
>
> -- 
> Alpa Dashora
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/db2df883/attachment.htm>

[Wien] "case.insp" to define band character for plotting

[guohuaihong]

#x27;//achar(92)//'! N'//achar(92)//'N'
460  endif
461  if(xmlabel1(ii1:ii1+2).eq.'DXZ') then
462 index_shift = index_shift+4
463 xmlabel1(ii1+7:12+index_shift) = 
xmlabel1(ii1+3:12+index_shift-4)
464 xmlabel1(ii1:ii1+6) 
='d'//achar(92)//'sxz'//achar(92)//'N'//achar(92)//'N'
465  ! end if
466  if(xmlabel1(ii1:ii1+2).eq.'DYZ') then
467 index_shift = index_shift+4
468 xmlabel1(ii1+7:12+index_shift) = 
xmlabel1(ii1+3:12+index_shift-4)
469 xmlabel1(ii1:ii1+6) 
='d'//achar(92)//'syz'//achar(92)//'N'//achar(92)//'N'
470  endif
471 ! ;   enddo !ii1
472do ii1=1,39
473 if(xmlabel1(ii1:ii1+4).eq.'DX2Y2') then
474 index_shift = index_shift+13
475 xmlabel1(ii1+18:12+index_shift) = 
xmlabel1(ii1+5:12+index_shift-13)
476   
xmlabel1(ii1:ii1+17)='d'//achar(92)//'sx'//achar(92)//'S2'//achar(92)//'N'//achar(92)//'s-y'//achar(92)//'S2'//achar(92)//'N'
477  endif
==! ===


Can you please give me some tips about it, thanks in advance.
 
Yours,

H.H. GUO

Magnetism and Magnetic Materials Division
Shenyang Materials Science National Laboratory
Institute of Metal Research
Chinese Academy of Sciences
72 Wenhua Road,Shenyang 110016, China


+86-15140243901 (mobile)
work: hhguo at imr.ac.cn






___
Wien mailing list
Wien at 
zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien






-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120711/11eee1ae/attachment.htm>