[Wien] Calculation of flourescence spectra

[David Holec]

Dear Wien2k users,

Does anyone have experience calculating the fluorescence spectra of
molecules using DFT/Wien2k? I would greatly appreciate any hint on
tutorial/experience/publication. Thank you very much in advance.

With best regards,
David


---
*Dr. David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE
___
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] QTL error TELNES

[David Holec]

Dear Phillipe,

I had recently very similar issues and following hint from Pavel Ondračka
helped me:

“Looks like a bug. I see something similar on the mailing list. Please
apply all patches from github.com/gsabo/WIEN2k-Patches from the 21.1
directory and let me know if that helps.”

Maybe it will help you, too.
David

On Wed 15. Dec 2021 at 16:14, Peter Blaha 
wrote:

> Please look intoqtl.def   in your folder
>
> What does it say for unit 10 ? In particular is there an "OLD" or
> "UNKNOWN" tag ? (It should be unknown).
>
> Regards
>
> Am 15.12.2021 um 16:05 schrieb Philippe JONNARD:
> > Hello,
> >
> > I am running WIEN version 21.1 on a machine of type server Intel
> > x86_64 with operating system SUSE Linux Enterprise Server 12 SP3,
> > fortran compiler Intel 18.2 and math libraries Intel MKL 18.2. I am
> > using w2web to perform my calculations.
> >
> > I am trying to calculte EELS spectra. I start with INNES but each time
> > I obtain the following error once I have clicked on the button "x -qtl
> > telnes":
> >
> >  'QTL' - can't open unit: 10
> >  'QTL' -filename: case.vectordn
> >  'QTL' -  status: unknown  form: unformatted
> >
> > I have verified that the case.vectordn file is not present in my case
> > folder. I have found a discussion on the mailing list where the same
> > error message is discussed but the problem seemed to come from some
> > parallel vectors, which I do not know what they are.
> >
> > Thnak you for your help,
> >
> > P. Jonnard
> >
> > ___
> > 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. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -----
>
> ___
> 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
>
-- 


---
*Dr David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE
___
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] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

[David Holec]

Hi Pavel,

I have added now -DHAVE_LIBMVEC to the compiler options as you have
suggested (and removed it from the preprocessor flags).

 O   Compiler options:-ffree-form -O2 -ftree-vectorize
-march=native -ffree-line-length-none -ffpe-summary=none -DHAVE_LIBMVEC
 P   Preprocessor flags   -DParallel


Here are the results of the test case:

$ x lapw1
STOP  LAPW1 END
109.094u 1.126s 0:29.41 374.7%  0+0k 0+37864io 0pf+0w
$ grep HORB *output1*
test_case.output1:   TIME HAMILT (CPU)  =11.9, HNS =15.2, HORB
= 0.0, DIAG =82.4, SYNC = 0.0
test_case.output1:   TIME HAMILT (WALL) = 3.1, HNS = 4.4, HORB
= 0.0, DIAG =21.2, SYNC = 0.0

David

---
*Dr David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE
___
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] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

[David Holec]

I see... I have added it to preprocessor flags (hopefully that is correct):

  P   Preprocessor flags   -DParallel -DHAVE_LIBM

recompiled and ran the test again - not a significant speed-up though:

$ x lapw1
STOP  LAPW1 END
115.970u 2.083s 0:31.90 370.0%  0+0k 22400+37864io 43pf+0w

David


---
*Dr David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE

>
>
___
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] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

[David Holec]

Dear Pavel,

Many thanks again for your patience and guidance. With the
libopenblas-openmp-dev package it seems to work well!

$ ldd lapw1
   linux-vdso.so.1 (0x7ffca83d8000)
   *libopenblas.so.0 => /lib/x86_64-linux-gnu/libopenblas.so.0
(0x14563f924000) *
   libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
(0x14563f65c000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x14563f50d000)
   libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1
(0x14563f4e1000)
   libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1
(0x14563f49f000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x14563f47c000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x14563f288000)
   /lib64/ld-linux-x86-64.so.2 (0x145641b2d000)
   libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
(0x14563f23e000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x14563f223000)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x14563f21d000)

and these options in siteconfig:
 L   Linker Flags:$(FOPT)
-L/usr/lib/x86_64-linux-gnu/openblas-openmp
 R   R_LIBS (LAPACK+BLAS):-lopenblas

I also get better timings now (though the TIME HAMILT are slightly longer,
but overall improvement):
$ ../x lapw1
STOP  LAPW1 END
119.400u 1.937s 0:32.53 372.9%  0+0k 0+37864io 0pf+0w
$ grep HORB *output1*
test_case.output1:   TIME HAMILT (CPU)  =17.3, HNS =18.4, HORB
= 0.0, DIAG =85.0, SYNC = 0.0
test_case.output1:   TIME HAMILT (WALL) = 4.6, HNS = 5.2, HORB
= 0.0, DIAG =22.0, SYNC = 0.0

Thanks for your help,
David
---
*Dr David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE


On Wed, 24 Nov 2021 at 12:39, Pavel Ondračka 
wrote:

> Hi David,
>
> well, it is hard to say without the debug info why the OpenBLAS crahes.
> My guess is that you link with the 64bit interface, try to install the
> standard one (openblas-openmp-devel) and replace openblas64-openmp with
> openblas-openmp everywhere in you config. Also remove the -lpthread
> (just to be safe, but in theory should not matter), it is not needed
> with OpenMP. If it still crashes, please recompile with debug info
> enabled (add -g to compiler options) and send me the x lapw1 output via
> PM.
>
> BTW my response was mostly motivated by me suspecting you actually link
> against slow netlib BLAS (which turned out to be the case) and I wanted
> to warn others in case someone in the future would be using your
> settings as a reference :-)
>
> Best regards
> Pavel
>
> On Wed, 2021-11-24 at 11:09 +0100, David Holec wrote:
> > Hi Pavel,
> >
> > Many thanks for your insights. As you know, I am not an expert on how
> > to compile codes, for me, this is sadly a trial and error adventure.
> >
> > I tried to compile it against the openblas library, but although the
> > compilation ends without any errors, I get a segmentation fault when
> > running lapw1 (on the test case
> > from http://www.wien2k.at/reg_user/benchmark/). The current setting
> > are:
> >
> >  L   Linker Flags:$(FOPT) -L/usr/lib/x86_64-linux-
> > gnu/openblas64-openmp
> >  R   R_LIBS (LAPACK+BLAS):/usr/lib/x86_64-linux-gnu/openblas64-
> > openmp/libopenblas64.so.0 -lpthread
> >
> >
> > (The rest is as I wrote in my first email.) Here is the list of
> > linked libraries:
> > $ ldd lapw1
> > linux-vdso.so.1 (0x7ffea57d6000)
> > libopenblas64.so.0 => /lib/x86_64-linux-
> > gnu/libopenblas64.so.0 (0x14fe2b2e5000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x14fe2b2c2000)
> > libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
> > (0x14fe2affa000)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> > (0x14fe2aeab000)
> > libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1
> > (0x14fe2ae7f000)
> > libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1
> > (0x14fe2ae3d000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> > (0x14fe2ac49000)
> > /lib64/ld-linux-x86-64.so.2 (0x14fe2d4d3000)
> > libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
> > (0x14fe2abff000)
> > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> > (0x14fe2abe4000)
> > libdl.so.2 => /lib/x86_64-l

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

[David Holec]

Hi Pavel,

Many thanks for your insights. As you know, I am not an expert on how to
compile codes, for me, this is sadly a trial and error adventure.

I tried to compile it against the openblas library, but although the
compilation ends without any errors, I get a segmentation fault when
running lapw1 (on the test case from
http://www.wien2k.at/reg_user/benchmark/). The current setting are:

 L   Linker Flags:$(FOPT)
-L/usr/lib/x86_64-linux-gnu/openblas64-openmp
 R   R_LIBS (LAPACK+BLAS):
   /usr/lib/x86_64-linux-gnu/openblas64-openmp/libopenblas64.so.0 -lpthread

(The rest is as I wrote in my first email.) Here is the list of linked
libraries:
$ ldd lapw1
   linux-vdso.so.1 (0x7ffea57d6000)
   *libopenblas64.so.0 => /lib/x86_64-linux-gnu/libopenblas64.so.0
(0x14fe2b2e5000) *
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x14fe2b2c2000)
   libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
(0x14fe2affa000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x14fe2aeab000)
   libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1
(0x14fe2ae7f000)
   libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1
(0x14fe2ae3d000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x14fe2ac49000)
   /lib64/ld-linux-x86-64.so.2 (0x14fe2d4d3000)
   libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
(0x14fe2abff000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x14fe2abe4000)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x14fe2abde000)

And here is the stacking fault (it doesn't tell me anything):
$x lapw1

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:
#0  0x148fb48b8d21 in ???
#1  0x148fb48b7ef5 in ???
#2  0x148fb452d20f in ???
#3  0x148fb54495fb in ???
Segmentation fault
0.949u 0.472s 0:00.84 167.8%0+0k 14400+10992io 31pf+0w

Any idea?

With the settings I reported yesterday, everything works just fine (though
probably not very efficiently - but this is not a problem for me as this
binary is not a "production" binary on any HPC):

$ ldd lapw1
   linux-vdso.so.1 (0x7ffc60765000)

*libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x150cec90f000)
   liblapack.so.3 => /lib/x86_64-linux-gnu/liblapack.so.3
(0x150cec26b000) *
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x150cec248000)
   libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
(0x150cebf8)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x150cebe31000)
   libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1
(0x150cebe05000)
   libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1
(0x150cebdc1000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x150cebbcf000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x150cebbb4000)
   /lib64/ld-linux-x86-64.so.2 (0x150cec9fc000)
   libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
(0x150cebb6a000)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x150cebb64000)

and:

$ x lapw1
STOP  LAPW1 END
162.045u 0.918s 2:31.25 107.7%  0+0k 8976+37856io 35pf+0w
$ grep HORB *output1*
test_case.output1:   TIME HAMILT (CPU)  =16.3, HNS =20.0, HORB
= 0.0, DIAG =   125.9, SYNC = 0.0
test_case.output1:   TIME HAMILT (WALL) = 4.4, HNS =20.0, HORB
= 0.0, DIAG =   126.0, SYNC = 0.0

(I am using it on my 10-year old "type writer":
$lscpu
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Vendor ID:   GenuineIntel
CPU family:  6
Model:   26
Model name:  Intel(R) Xeon(R) CPU   W3550  @
3.07GHz
)


---
*Dr David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE


On Wed, 24 Nov 2021 at 08:27, Pavel Ondračka 
wrote:

> Hi David,
>
> as you said it works for you, so feel free to ignore, but I have some
> further tips if you are interested. Ubuntu switches between the
> different blas and lapack using the "alternatives", so its difficult to
> say if you actually link with the correct one.
>
> "ldd lapw1" in WIENROOT should show which one is actually linked, what
> you want to have is the openmp openblas
> /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so
> /usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.so
> or alternatively
> /usr/lib/x86_64-linux-gnu/openblas-openmp/libopenbl

[Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

[David Holec]

Dear all,

I have just spent some time making Wien2k run on my single machine running
Ubuntu 20.04 with gfortran/gcc. Since I am not an expert, it was a trial
and error, but it seems that I found a working combination (sadly, the
default parameters didn't work for me). Maybe this will help someone. Here
are the settings that did the job for me:

  M   OpenMP switch:   -fopenmp
 O   Compiler options:-ffree-form -O2 -ftree-vectorize
-march=native -ffree-line-length-none -ffpe-summary=none
 L   Linker Flags:$(FOPT) -L/usr/lib/x86_64-linux-gnu
 P   Preprocessor flags   '-DParallel'
 R   R_LIBS (LAPACK+BLAS):-lblas -llapack -lpthread
 F   FFTW options:-DFFTW3 -DFFTW_OMP -I/usr/include
 FFTW-LIBS:   -L/usr/lib/x86_64-linux-gnu -lfftw3
-lfftw3_omp

where the FFTW options were:

  R  FFTWROOT:  /usr/
  V  FFTW_VERSION:  FFTW3
  L  FFTW_LIB:  lib/x86_64-linux-gnu
  N  FFTW_LIBNAME:  fftw3

Compiler versions:
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
gfortran --version
GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

And I used the generic lapack and openblas packages provides by Ubuntu
repos:
liblapack-dev/focal,now 3.9.0-1build1 amd64 [installed]
liblapack3/focal,now 3.9.0-1build1 amd64 [installed,automatic]
liblapack64-3/focal,now 3.9.0-1build1 amd64 [installed,automatic]
liblapack64-dev/focal,now 3.9.0-1build1 amd64 [installed]

libblas-dev/focal,now 3.9.0-1build1 amd64 [installed]
libblas3/focal,now 3.9.0-1build1 amd64 [installed,automatic]
libblas64-3/focal,now 3.9.0-1build1 amd64 [installed,automatic]
libblas64-dev/focal,now 3.9.0-1build1 amd64 [installed,automatic]

libopenblas64-0/focal-updates,now 0.3.8+ds-1ubuntu0.20.04.1 amd64
[installed]
libopenblas64-0-openmp/focal-updates,now 0.3.8+ds-1ubuntu0.20.04.1 amd64
[installed]
libopenblas64-0-pthread/focal-updates,now 0.3.8+ds-1ubuntu0.20.04.1 amd64
[installed,automatic]

(I am not totally sure if I need all the libraries above, but certainly,
with these, the compilation seems to work and I am able to run SCF cycles &
Telnes calculations without errors :-)

All the best,
David
---
*Dr David Holec*
*Computational Materials Science group*
Department of Materials Science
Montanuniversität Leoben



Franz-Josef-Strasse 18, A-8700 Leoben, Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
materials.unileoben.ac.at
cms.unileoben.ac.at

WHERE RESEARCH MEETS FUTURE
___
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] third-order-of-elastic-constants

[David Holec]

Dear Amir Lot,

You can follow, e.g., the recipes published in our paper:

http://journals.aps.org/prb/abstract/10.1103/PhysRevB.85.064101

With best wishes,
David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
Montanuniversität Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202


On 18 April 2016 at 09:21,   wrote:
> Dear WIEN2k user,
> Can you guide me how i can find "third order of elastic constants" using
> energy approach?
> with best,
> A. lot
>
> ___
> 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] Spin-polarization in ELNES calculations

[David Holec]

Thanks Peter for your prompt response, this is very helpful and
clarifies my confusion ;-)

David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
Montanuniversität Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202


On 4 June 2013 14:16, Peter Blaha  wrote:
> You just have to run it for spin-up AND dn and sum up the results.
>
> It has nothing to do whether you set "N" as non-magnetic or not, only the
> final scf-results are important and also the N-p DOS could be (slightly)
> different for spin-up and dn.
>
> PS: ELNES does not know about spin-orbit coupling and L2 vs. L3.
>
>
> On 06/04/2013 12:30 PM, David Holec wrote:
>>
>> Dear Wien2k users,
>>
>> Could anyone please explain to me the role of spin in ELNES
>> calculations? In particular, suppose I am trying to get ELNES of
>> ferromagnetic or antiferromagnetic compounds consisting of two
>> sublattices, one out of which is non-magnetic (CrN, in the
>> initialisation phase I set up/dn spins on Cr, and no magnetic moment
>> on N atoms). I am interested in both Cr L2,3 edge and N K edge.
>>
>> Many thanks in advance for your help,
>> David
>> --
>> Dr. David Holec
>> Dept. of Physical Metallurgy and Materials Testing
>> Montanuniversität Leoben
>> Franz-Josef-Strasse 18
>> A-8700 Leoben
>> Austria
>> tel. +43-(0)3842-4024211
>> fax. +43-(0)3842-4024202
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>>
>
> --
>
>   P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWWW:
> http://info.tuwien.ac.at/theochem/
> --
> ___
> 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] Spin-polarization in ELNES calculations

[David Holec]

Dear Wien2k users,

Could anyone please explain to me the role of spin in ELNES
calculations? In particular, suppose I am trying to get ELNES of
ferromagnetic or antiferromagnetic compounds consisting of two
sublattices, one out of which is non-magnetic (CrN, in the
initialisation phase I set up/dn spins on Cr, and no magnetic moment
on N atoms). I am interested in both Cr L2,3 edge and N K edge.

Many thanks in advance for your help,
David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
Montanuniversität Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202
___
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] troubles with mixer in scf

[David Holec]

Dear Peter,

diff case.inc old_case.inc gives empty output, so this is probably not
the problem. In any case, it seems to work now, and I am sure that the
problem was most likely a human mistake introduced by my.

David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
Montanuniversit?t Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202


On 13 March 2013 09:12, Peter Blaha  wrote:
> It looks like an error in some input file and most likely it is the source
> of the segmentation fault occuring later.
> Best would be if you find the line number, where the READ-problem occurs.
> (compiled with -traceback and ifort, not aix !)
>
> Since you mentioned core-holes: maybe case.inc got wrong when you introduced
> the hole ???
>
> Anyway, it seems to work now.
>
> PS: The knowledge of spin-polarization in w2web does not depend on the
> directory, but the "Session" of w2web. So deleting all files in a directory,
> but "reusing" the old project in w2web does not change the settings of w2web
> (but you can modify this manually in the "Session management" section. But
> in any case, -up is ignored for nn, sgroup,...
>
>
>
> On 03/13/2013 08:56 AM, David Holec wrote:
>>
>> Dear Laurence,
>>
>> Many thanks for your prompt response. To your seggestions:
>>
>> --> cat *.error:
>> Error in MIXER
>> Error in MIXER
>>
>> --> mixer mixer.def:
>> 1525-097 A READ statement using decimal base input found the invalid
>> digit '.' in the input file.  The program will recover by assuming a
>> zero in its place.
>> Segmentation fault (core dumped)
>>
>> --> deleting *broyd* files didn't help.
>>
>> But, I have started the calculation from fresh (used only the struct
>> file, deleted everything else in the directory), and after
>> initialisation everything seems to be running fine now. I have no idea
>> where and when I did something wrong, but apparently it was again the
>> human factor.
>>
>> Hmm, just checking the difference between the \:log file from
>> yesterday and today, I realise that yesterday all initialisation
>> routines (nn, sgroup, etc.) were invoked with -up switch. I have no
>> idea why (I used w2web in a fresh directory both yesterday and today).
>> Could thins be the trouble maker?
>>
>> Thanks for your help!
>> David
>> --
>> Dr. David Holec
>> Dept. of Physical Metallurgy and Materials Testing
>> Montanuniversit?t Leoben
>> Franz-Josef-Strasse 18
>> A-8700 Leoben
>> Austria
>> tel. +43-(0)3842-4024211
>> fax. +43-(0)3842-4024202
>>
>>
>> On 12 March 2013 18:37, Laurence Marks  wrote:
>>>
>>> Hard to know exactly. Normally this is because something went wrong
>>> earlier (e.g. NaN in files) and did not crash the scf cycle.
>>>
>>> Is there anything in any of the other error files (cat *.error) ?
>>>
>>> Did you have a previous unpolarized calculation in the same directory
>>> and did not delete the *.broyd* files?
>>>
>>> Did you use -traceback in the compilation? If you did what does the
>>> command "mixer mixer.def" give you? (Sometimes this is more
>>> informative.)
>>>
>>> A segmentation fault like this is normally due to some incorrect
>>> arguments being passed to the Intel mkl routines which are hard to get
>>> useful information from.
>>>
>>> Let me know please.
>>>
>>> On Tue, Mar 12, 2013 at 12:23 PM, David Holec
>>>  wrote:
>>>>
>>>> Dear Wien2k users,
>>>>
>>>> I am facing an error in the first scf cycle. Unfortunately, I am
>>>> unable to find the information that would guide me down to the core of
>>>> the problem. I would appreciate any guidance from you!
>>>>
>>>> It is a spin-polarized calculation of CrN. The error appear at the end
>>>> of the first cycle:
>>>>
>>>> ...
>>>> w03   user=271.571wallclock=17287.2
>>>> 3.0u 0.6s 0:53 6% 2+129k 0+0io 30pf+0w
>>>>>
>>>>>lcore -up   (17:59:52) 0.2u 0.0s 0:00 51% 1+9k 0+0io 3pf+0w
>>>>>lcore -dn   (17:59:52) 0.2u 0.0s 0:00 75% 1+8k 0+0io 1pf+0w
>>>>>mixer   (17:59:53) Segmentation fault (core dumped)
>>>>
>>>> 0.1u 0.3s 0:01 35% 1+43k 0+0io 1pf+0w
>>>> error: command   /home/d.holec/codes/WIEN2k_11.1/mixer mixer.def
>>>> failed
>>>>

[Wien] troubles with mixer in scf

[David Holec]

Dear Laurence,

Many thanks for your prompt response. To your seggestions:

--> cat *.error:
Error in MIXER
Error in MIXER

--> mixer mixer.def:
1525-097 A READ statement using decimal base input found the invalid
digit '.' in the input file.  The program will recover by assuming a
zero in its place.
Segmentation fault (core dumped)

--> deleting *broyd* files didn't help.

But, I have started the calculation from fresh (used only the struct
file, deleted everything else in the directory), and after
initialisation everything seems to be running fine now. I have no idea
where and when I did something wrong, but apparently it was again the
human factor.

Hmm, just checking the difference between the \:log file from
yesterday and today, I realise that yesterday all initialisation
routines (nn, sgroup, etc.) were invoked with -up switch. I have no
idea why (I used w2web in a fresh directory both yesterday and today).
Could thins be the trouble maker?

Thanks for your help!
David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
Montanuniversit?t Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202


On 12 March 2013 18:37, Laurence Marks  wrote:
> Hard to know exactly. Normally this is because something went wrong
> earlier (e.g. NaN in files) and did not crash the scf cycle.
>
> Is there anything in any of the other error files (cat *.error) ?
>
> Did you have a previous unpolarized calculation in the same directory
> and did not delete the *.broyd* files?
>
> Did you use -traceback in the compilation? If you did what does the
> command "mixer mixer.def" give you? (Sometimes this is more
> informative.)
>
> A segmentation fault like this is normally due to some incorrect
> arguments being passed to the Intel mkl routines which are hard to get
> useful information from.
>
> Let me know please.
>
> On Tue, Mar 12, 2013 at 12:23 PM, David Holec
>  wrote:
>> Dear Wien2k users,
>>
>> I am facing an error in the first scf cycle. Unfortunately, I am
>> unable to find the information that would guide me down to the core of
>> the problem. I would appreciate any guidance from you!
>>
>> It is a spin-polarized calculation of CrN. The error appear at the end
>> of the first cycle:
>>
>> ...
>>w03   user=271.571wallclock=17287.2
>> 3.0u 0.6s 0:53 6% 2+129k 0+0io 30pf+0w
>>>   lcore -up   (17:59:52) 0.2u 0.0s 0:00 51% 1+9k 0+0io 3pf+0w
>>>   lcore -dn   (17:59:52) 0.2u 0.0s 0:00 75% 1+8k 0+0io 1pf+0w
>>>   mixer   (17:59:53) Segmentation fault (core dumped)
>> 0.1u 0.3s 0:01 35% 1+43k 0+0io 1pf+0w
>> error: command   /home/d.holec/codes/WIEN2k_11.1/mixer mixer.def   failed
>>
>>>   stop error
>>
>> mixer.error is not really helpful: "Error in MIXER"
>>
>> Perhaps some hint is in the case.outputm file:
>> ...
>>  JATOM =  11   J =  2
>>   ESX  =  -5.7200202706E+02 OCC =   2.00E+00  2.00E+00
>>ESUM,EKIN =  -94314.3061676110083 0.00E+00
>>  JATOM =  11   J =  3
>>   ESX  =  -4.8320954414E+02 OCC =   2.00E+00  2.00E+00
>>ESUM,EKIN =  -94886.3081946670136 0.00E+00
>>  JATOM =  11   J =  4
>>   ESX  =  -9.5116518730E+02 OCC =   4.00E+00  4.00E+00
>>ESUM,EKIN =  -95369.5177388110169 0.00E+00
>>  JATOM =  12   J =  1
>>   ESX  =  -5.
>>
>> The struct file contains 12 in-equivalent atoms (6 N, 6 Cr), atom 12
>> is the last Cr.
>>
>> I am not sure whether you need more information to track the problem -
>> if so, I am happy to share it, of course.
>>
>> Perhaps last comment is: I am trying to calculate the N-K energy edge
>> onset for various magnetic configurations as a difference between the
>> ground state and excited state with core hole (extra electron in
>> case.in2 file). Exactly the same settings in non-magnetic case (only
>> different initial spin given in instgen_lapw for Cr atom (up vs. nm)
>> and scf invoked by run_lapw instead of runsp_lapw) runs without any
>> trouble.
>>
>> Thanks in advance for you help!
>> David
>> --
>> Dr. David Holec
>> Dept. of Physical Metallurgy and Materials Testing
>> Montanuniversit?t Leoben
>> Franz-Josef-Strasse 18
>> A-8700 Leoben
>> Austria
>> tel. +43-(0)3842-4024211
>> fax. +43-(0)3842-4024202
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
> --
> 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
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] troubles with mixer in scf

[David Holec]

Dear Wien2k users,

I am facing an error in the first scf cycle. Unfortunately, I am
unable to find the information that would guide me down to the core of
the problem. I would appreciate any guidance from you!

It is a spin-polarized calculation of CrN. The error appear at the end
of the first cycle:

...
   w03   user=271.571wallclock=17287.2
3.0u 0.6s 0:53 6% 2+129k 0+0io 30pf+0w
>   lcore -up   (17:59:52) 0.2u 0.0s 0:00 51% 1+9k 0+0io 3pf+0w
>   lcore -dn   (17:59:52) 0.2u 0.0s 0:00 75% 1+8k 0+0io 1pf+0w
>   mixer   (17:59:53) Segmentation fault (core dumped)
0.1u 0.3s 0:01 35% 1+43k 0+0io 1pf+0w
error: command   /home/d.holec/codes/WIEN2k_11.1/mixer mixer.def   failed

>   stop error

mixer.error is not really helpful: "Error in MIXER"

Perhaps some hint is in the case.outputm file:
...
 JATOM =  11   J =  2
  ESX  =  -5.7200202706E+02 OCC =   2.00E+00  2.00E+00
   ESUM,EKIN =  -94314.3061676110083 0.00E+00
 JATOM =  11   J =  3
  ESX  =  -4.8320954414E+02 OCC =   2.00E+00  2.00E+00
   ESUM,EKIN =  -94886.3081946670136 0.00E+00
 JATOM =  11   J =  4
  ESX  =  -9.5116518730E+02 OCC =   4.00E+00  4.00E+00
   ESUM,EKIN =  -95369.5177388110169 0.00E+00
 JATOM =  12   J =  1
  ESX  =  -5.

The struct file contains 12 in-equivalent atoms (6 N, 6 Cr), atom 12
is the last Cr.

I am not sure whether you need more information to track the problem -
if so, I am happy to share it, of course.

Perhaps last comment is: I am trying to calculate the N-K energy edge
onset for various magnetic configurations as a difference between the
ground state and excited state with core hole (extra electron in
case.in2 file). Exactly the same settings in non-magnetic case (only
different initial spin given in instgen_lapw for Cr atom (up vs. nm)
and scf invoked by run_lapw instead of runsp_lapw) runs without any
trouble.

Thanks in advance for you help!
David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
Montanuniversit?t Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202

[Wien] ifort + mkl on xeon cpu

[David Holec]

Dear all,

What is the currently recommended version of ifort+mkl for compiling Wien2k?

Also, could anyone advice me on optimal compiler options for x64 Linux
(openSuSE 12.1/12.2), Intel Xeon W3550 4core processor, 8GB RAM,
single machine configuration (no MPI, only k-point parallelization).

Thanks in advance!
David
--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
University of Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024211
fax. +43-(0)3842-4024202

[Wien] LAPW1 error (munmap_chunk)

[David Holec]

2b97adfd-2b97ae1cf000 ---p 000cc000 08:02 426171
  /opt/intel/composer_xe_2011_sp1.7.256/compiler/lib/intel64/libiomp5.so
2b97ae1cf000-2b97ae1d9000 rw-p 000cb000 08:02 426171
  /opt/intel/composer_xe_2011_sp1.7.256/compiler/lib/intel64/libiomp5.so
2b97ae1d9000-2b97ae1f rw-p  00:00 0
2b97ae1f-2b97ae1f2000 r-xp  08:02 803154
  /lib64/libdl-2.14.1.so
2b97ae1f2000-2b97ae3f2000 ---p 2000 08:02 803154
  /lib64/libdl-2.14.1.so
2b97ae3f2000-2b97ae3f3000 r--p 2000 08:02 803154
  /lib64/libdl-2.14.1.so
2b97ae3f3000-2b97ae3f4000 rw-p 3000 08:02 803154
  /lib64/libdl-2.14.1.so
2b97ae3f4000-2b97ae3f5000 rw-p  00:00 0
2b97ae3f5000-2b97ae57c000 r-xp  08:02 788017
  /lib64/libc-2.14.1.so
2b97ae57c000-2b97ae77b000 ---p 00187000 08:02 788017
  /lib64/libc-2.14.1.so
2b97ae77b000-2b97ae77f000 r--p 00186000 08:02 788017
  /lib64/libc-2.14.1.so
2b97ae77f000-2b97ae78 rw-p 0018a000 08:02 788017
  /lib64/libc-2.14.1.so
2b97ae78-2b97ae785000 rw-p  00:00 0
2b97ae785000-2b97ae79a000 r-xp  08:02 789289
  /lib64/libgcc_s.so.1
2b97ae79a000-2b97ae999000 ---p 00015000 08:02 789289
  /lib64/libgcc_s.so.1
2b97ae999000-2b97ae99a000 r--p 00014000 08:02 789289
  /lib64/libgcc_s.so.1
2b97ae99a000-2b97ae99b000 rw-p 00015000 08:02 789289
  /lib64/libgcc_s.so.1
2b97ae99b000-2b97ae99d000 rw-p  00:00 0
2b97ae99d000-2b97aeea4000 r-xp  08:02 1086342
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_vml_mc3.so
2b97aeea4000-2b97af0a3000 ---p 00507000 08:02 1086342
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_vml_mc3.so
2b97af0a3000-2b97af0e7000 rw-p 00506000 08:02 1086342
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_vml_mc3.so
2b97af0e7000-2b97af0e8000 rw-p  00:00 0
2b97af1b7000-2b97af215000 rw-p  00:00 0
2b97afbee000-2b97b1766000 r-xp  08:02 1086331
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_mc3.so
2b97b1766000-2b97b1965000 ---p 01b78000 08:02 1086331
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_mc3.so
2b97b1965000-2b97b19ba000 rw-p 01b77000 08:02 1086331
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/lib/intel64/libmkl_mc3.so
2b97b19ba000-2b97b1bdc000 rw-p  00:00 0
7fffb3eb6000-7fffb3edc000 rw-p  00:00 0  [stack]
7fffb3f69000-7fffb3f6a000 r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0
  [vsyscall]
forrtl: error (76): Abort trap signal
Image  PCRoutineLine
Source
libc.so.6  2B97AE429D95  Unknown   Unknown  Unknown
libc.so.6  2B97AE42B2AB  Unknown   Unknown  Unknown
libc.so.6  2B97AE46599E  Unknown   Unknown  Unknown
libc.so.6  2B97AE46B6D6  Unknown   Unknown  Unknown
libmkl_core.so 2B97ACAD8DED  Unknown   Unknown  Unknown
libmkl_mc3.so  2B97B019316C  Unknown   Unknown  Unknown
libmkl_core.so 2B97ACADF792  Unknown   Unknown  Unknown
libmkl_mc3.so  2B97B01EFF18  Unknown   Unknown  Unknown
libmkl_core.so 2B97ACAE13A1  Unknown   Unknown  Unknown
libmkl_mc3.so  2B97B01BE214  Unknown   Unknown  Unknown
libmkl_mc3.so  2B97B01F5D19  Unknown   Unknown  Unknown
libmkl_core.so 2B97ACAE1889  Unknown   Unknown  Unknown
libmkl_intel_thre  2B97ABB16699  Unknown   Unknown  Unknown
libmkl_intel_lp64  2B97AB337217  Unknown   Unknown  Unknown
lapw1  004665A8  seclr4_   423
seclr4_tmp_.F
lapw1  0040EAA8  calkpt_   200
calkpt_tmp_.F
lapw1  00443723  MAIN__ 61  lapw1_tmp_.F
lapw1  00404F4C  Unknown   Unknown  Unknown
libc.so.6  2B97AE41623D  Unknown   Unknown  Unknown
lapw1  00404E49  Unknown   Unknown  Unknown


Any help, or direction where to look for the source of my problems,
would be hugely appreciated. Many thanks!

David


--
Dr. David Holec
Dept. of Physical Metallurgy and Materials Testing
University of Leoben
Franz-Josef-Strasse 18
A-8700 Leoben
Austria
tel. +43-(0)3842-4024241
fax. +43-(0)3842-4024202
-- next part --
A non-text attachment was scrubbed...
Name: Zr2Ni7.struct
Type: application/octet-stream
Size: 2132 bytes
Desc: not available
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120629/b68c6b8f/attachment.dll>

[Wien] Small bug in userconfig

[David Holec]

Dear Peter and all Wien2k users,

I think there is a small big in the userconfig script. When you do a
fresh installation and $OCTAVE_PATH is not set yet, then the script
fails. I've tracked the problem down to the lines 196, 231, 272 and
314 where it should be '\$OCTAVE_PATH' instead of just '$OCTAVE_PATH'.
At least I needed this change in bash.

I am using the lastes version of Wien2k.

With best regards,
David

[Wien] About super cell calculations

[David Holec]

Dear Mokkath,

please have a look in UG, section 10.4 (examples, supercell calc).

In principle, once you have created a supercell using the supercell
program, you need to copy the newly generated struct file
(case_super.struct) into your case.struct file (I recommend you make a
backup copy of the original struct file first!). After that you either
edit the structure manually or you can use e.g. StructGen from w2web.

Good luck!
David

2008/6/17 J.H. Mokkath, FB18 :
>
>
> Hello Wien2k users,
>
> I have a simple doubt regarding the supercell calculations. I did creat a 
> simple
> Fe molecule. After that I would like to create a supercell with one Fe atom is
> replaced with Rh atom. My qeustion is at what step I could change one Fe atom
> into Rh atom.
>
> Any help would be appreciated.
>
> Regards,
> Mokkath...
>
> 
> This mail sent through http://www.uni-kassel.de/www-mail
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>

[Wien] Broadening in XAFS / ELNES

[David Holec]

Dear Che,

as far as I understand it, the broadened ELNES intensity is obtained by 
convolution of the unbroadened intensity with the Lorentzian profile. 
Analytically this is expressed as:

I_br(E)=\int I(E') \Gamma(E) / ( \pi ((E-E')^2+\Gamma(E) ) dE'

\Gamma(E) is for example the function given for in Moreau's paper, I(E') 
is the unbroadened ELNES.

Hope this is helpful.
David

Che Seabourne wrote:
> I am using the latest version of Wien - with the pre-compiled 
> executables from the website. This question specifically relates to the 
> TELNES and related broadening modules. Having searched through the 
> previous mailing lists, I have been able to find Kevin Jorissen's 
> previous descriptions of the various broadenings that can be applied to 
> the results. Of particular interest to myself is the energy dependent 
> final-state lifetime broadening capability.
> 
> With a background in chemistry I have been able to successfully 
> understand Moreau et al's description of finding a Lorentzian broadening 
> factor. I would however be interested to know in basic terms (being a 
> non-expert) how this is applied to the raw .elnes data.
> 
> Any advice would be greatly appreciated
> 
> Che Seabourne
> 
> -- 
> --
> Che Seabourne
> Institute for Materials Research
> SPEME
> University of Leeds
> chmcrs at leeds.ac.uk 
> http://www.engineering.leeds.ac.uk/imr/people/ResearchStudentProfiles.shtml
> 
> 
> 
> 
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] Modeling of Ag5Pb2O6

[David Holec]

Hi Toni,

you need non-zero RMTs (probably somewhere around 2). Please consult the 
userguide for explanation.

David

Ivas Toni wrote:
> Dear All,
>  
> I am trying to model band structure of Ag5Pb2O6 with space group P31m(Nr
> 162). 
> But after converting cif file to struct and reading in the w2web
> interface and setting a RMT with setrmt,
> Pb atoms have RMT=0.0 after which lstart returns an error. By setting
> the RMT to small value 0.005 for Pb atoms
> lstart succeeded but the created file Ag5Pb2O6.rsp crushes after dstart
> due the end-file error. 
>  
> Is this problem of cif2struct converter or I am doing something wrong?
>  
> I would appreciate any advice or suggestion.
>  
> Thank you,
> Toni Ivas
> Department of Materials
> ETH Zurich
>  
>  
>  
> 
> 
> 
> 
> 
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] 3D charge density

[David Holec]

Hi Chang-Wen,

Lapw5 will give you the electron density plots. Look in UG for more
help. Also, the tutorial part in UG is useful for this topic.

All the best,
David


zhchwsd at 163.com wrote:
> Dear,
> 
>Can I calculated 3D charge density in the crystal compound. If 
> possible, what the procedure I'll go ahead?
> 
>  Thanks you in advance.
> 
>  
> 
>   chang-wen zhang
> 
> 
> 
> 
> º¼Öݸ´µØÁ¬³Ç¹ú¼ÊµØÌúÉú»î·½Ê½£¬76-134©O¾«Æ··¿Ô´ÈÈÏúÖÐ 
> 
> 
> 
> 
> 
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] Sum of PDOSes doesn't give total DOS

[David Holec]

Good morning all,

this is just to finish this thread. I have found answers to my questions 
here:

http://zeus.theochem.tuwien.ac.at/pipermail/wien/2007-January/008616.html

David

David Holec wrote:
> Thanks for the reply. Am I able to dig this out somehow? Or is the 
> interstitial basically everything else?
> 
>   DOS_interstitial = DOS_total - sum_{all atoms} PDOS_{atom}_total
> 
> Is this the case? Then, would it make any sense to interprete whatever I 
> get from tetra as that portion of density of states that can be 
> unambiguously identified with a particular atom & orbit?
> 
> David
> 
> Cormac McGuinness wrote:
>> There is also the interstitial DOS
>>
>> Cormac
>>
>> - Sorry - I should reply to the list - will send anyway
>>
>>
>> On Fri, 2008-05-02 at 15:25 +0100, David Holec wrote:
>>> Dear Wien2k users & developers,
>>>
>>> I'm getting a bit puzzled by following problem: when I calculate 
>>> total DOS of a system using tetra, and at the same time calculate 
>>> PDOS of that system, the sum of DOSes does not add up to total DOS.
>>>
>>> Let me be a bit more specific: I have a 4 atomic unit cell of AlN, 2 
>>> atoms being Al and two N. My assumption would be that when I use 
>>> following int-file
>>>
>>> Title
>>>   -1.50 0.002 2.500 0.003   EMIN, DE, EMAX, Gauss-broadening(>de)
>>>  11 NUMBER OF DOS-CASES specified below
>>>  01   total atom, case=column in qtl-header, label
>>>  11   Atom1 tot
>>>  12   Atom1 s
>>>  13   Atom1 p
>>>  14   Atom1 pz
>>>  15   Atom1 px+py
>>>  21   Atom1 tot
>>>  22   Atom1 s
>>>  23   Atom1 p
>>>  24   Atom1 pz
>>>  25   Atom1 px+py
>>>
>>> then it would hold e.g.:
>>>
>>>Atom1 tot + Atom2 tot = total
>>>
>>> or:
>>>
>>>Atom1 s + Atom1 p = Atom1 tot
>>>
>>> When I integrate the total DOS (column 2 of the output corresponding 
>>> to the above tetra input) over -20eV to 0eV, I got 16.004e which is 
>>> very close to 16e I am expecting in the in this region (I am 
>>> basically missing 4*2 1s electrons which are deeper than my energy 
>>> window). But the same integral for Atom1 tot (column 3 in the output) 
>>> gives 1.4285e whereas for Atom2 tot (column 8 in the output) it gives 
>>> 8.5117e. Their sum is 9.9404e...
>>>
>>> I assume it is tricky to try to distinguish which electron belongs to 
>>> which atom in solid state but still I would expect that the sum of 
>>> these two would be give the total DOS.
>>>
>>> Could any help me either how to get out of this (can I simply 
>>> renormalise the PDOSes in order to get correct number of electrons?) 
>>> or tell me where my thinking goes wrong?
>>>
>>> Many thanks in advance,
>>> David
>>> ___
>>> Wien mailing list
>>> Wien at zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>
> 

[Wien] Sum of PDOSes doesn't give total DOS

[David Holec]

Thanks for the reply. Am I able to dig this out somehow? Or is the 
interstitial basically everything else?

   DOS_interstitial = DOS_total - sum_{all atoms} PDOS_{atom}_total

Is this the case? Then, would it make any sense to interprete whatever I 
get from tetra as that portion of density of states that can be 
unambiguously identified with a particular atom & orbit?

David

Cormac McGuinness wrote:
> There is also the interstitial DOS
> 
> Cormac
> 
> - Sorry - I should reply to the list - will send anyway
> 
> 
> On Fri, 2008-05-02 at 15:25 +0100, David Holec wrote:
>> Dear Wien2k users & developers,
>>
>> I'm getting a bit puzzled by following problem: when I calculate total 
>> DOS of a system using tetra, and at the same time calculate PDOS of that 
>> system, the sum of DOSes does not add up to total DOS.
>>
>> Let me be a bit more specific: I have a 4 atomic unit cell of AlN, 2 
>> atoms being Al and two N. My assumption would be that when I use 
>> following int-file
>>
>> Title
>>   -1.50 0.002 2.500 0.003   EMIN, DE, EMAX, Gauss-broadening(>de)
>>  11 NUMBER OF DOS-CASES specified below
>>  01   total atom, case=column in qtl-header, label
>>  11   Atom1 tot
>>  12   Atom1 s
>>  13   Atom1 p
>>  14   Atom1 pz
>>  15   Atom1 px+py
>>  21   Atom1 tot
>>  22   Atom1 s
>>  23   Atom1 p
>>  24   Atom1 pz
>>  25   Atom1 px+py
>>
>> then it would hold e.g.:
>>
>>Atom1 tot + Atom2 tot = total
>>
>> or:
>>
>>Atom1 s + Atom1 p = Atom1 tot
>>
>> When I integrate the total DOS (column 2 of the output corresponding to 
>> the above tetra input) over -20eV to 0eV, I got 16.004e which is very 
>> close to 16e I am expecting in the in this region (I am basically 
>> missing 4*2 1s electrons which are deeper than my energy window). But 
>> the same integral for Atom1 tot (column 3 in the output) gives 1.4285e 
>> whereas for Atom2 tot (column 8 in the output) it gives 8.5117e. Their 
>> sum is 9.9404e...
>>
>> I assume it is tricky to try to distinguish which electron belongs to 
>> which atom in solid state but still I would expect that the sum of these 
>> two would be give the total DOS.
>>
>> Could any help me either how to get out of this (can I simply 
>> renormalise the PDOSes in order to get correct number of electrons?) or 
>> tell me where my thinking goes wrong?
>>
>> Many thanks in advance,
>> David
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>

[Wien] Sum of PDOSes doesn't give total DOS

[David Holec]

Dear Wien2k users & developers,

I'm getting a bit puzzled by following problem: when I calculate total 
DOS of a system using tetra, and at the same time calculate PDOS of that 
system, the sum of DOSes does not add up to total DOS.

Let me be a bit more specific: I have a 4 atomic unit cell of AlN, 2 
atoms being Al and two N. My assumption would be that when I use 
following int-file

Title
  -1.50 0.002 2.500 0.003   EMIN, DE, EMAX, Gauss-broadening(>de)
 11 NUMBER OF DOS-CASES specified below
 01   total atom, case=column in qtl-header, label
 11   Atom1 tot
 12   Atom1 s
 13   Atom1 p
 14   Atom1 pz
 15   Atom1 px+py
 21   Atom1 tot
 22   Atom1 s
 23   Atom1 p
 24   Atom1 pz
 25   Atom1 px+py

then it would hold e.g.:

   Atom1 tot + Atom2 tot = total

or:

   Atom1 s + Atom1 p = Atom1 tot

When I integrate the total DOS (column 2 of the output corresponding to 
the above tetra input) over -20eV to 0eV, I got 16.004e which is very 
close to 16e I am expecting in the in this region (I am basically 
missing 4*2 1s electrons which are deeper than my energy window). But 
the same integral for Atom1 tot (column 3 in the output) gives 1.4285e 
whereas for Atom2 tot (column 8 in the output) it gives 8.5117e. Their 
sum is 9.9404e...

I assume it is tricky to try to distinguish which electron belongs to 
which atom in solid state but still I would expect that the sum of these 
two would be give the total DOS.

Could any help me either how to get out of this (can I simply 
renormalise the PDOSes in order to get correct number of electrons?) or 
tell me where my thinking goes wrong?

Many thanks in advance,
David

[Wien] How to set Orientation sensitive in InnesGen

[David Holec]

Dear Bo Zhu,

the three angles are the Euler angles. I think that implicitly the
electron beam goes along the z-axis. You can use the Euler angles to
"rotate" your structure so that the beam goes along a different
crystallographic orientation.

More about the Euler angles and the way how to rotate your crystal can
be found here: http://en.wikipedia.org/wiki/Euler_angles.

With regards to LXDOS, go to your wien2k directory, to SRC_lapw2
subdirectory and edit file modules.F. Then recompile lapw2 module (using
siteconfig - see the UG) and you can go ahead.

With best regards,
David



bozhu wrote:
> Dear Users and Developlers,
> 
> I want to calculate the energy loss near edge structure using telnes.2 
> program. I want to take into account
>  the relative orientation between sample and beam. When I edited the 
> case.innes, I didn't know the means of 
> Alpha. Beta. Gamma. I didn't find the topic in mail list and the manual. I 
> found the name of "K. Jorissen. ELNES
>  Code Developer's Guide", but did not find it. Can you give me a copy if you 
> have or tell me what the means of 
> "Alpha. Beta. Gamma"?
> 
> PS://LXDOS set to 3
> 
> //Could you please help me with this? Thanks!
> 
> best wishes,
> Bo Zhu
> 

[Wien] SP-SSM 2008 - Abstract submission deadline

[David Holec]

Please ignore my previous mail - I used a wrong email address.

David

On 04/02/2008, David Holec  wrote:
>
> Dear Xavier,
>
> I've just registered for the conference in Nantes. I am attaching an
> abstract of my proposed contribution as I haven't found a way how to submit
> it on-line. Please let me know if the format of the abstract is acceptable.
>
> I am looking forward to hearing from you. With best wishes,
>
> David Holec
> Department of Materials Science and Metallurgy
> University of Cambridge
>
>
> On 29/01/2008, Rocquefelte  wrote:
> >
> > Dear colleagues,
> >
> > We cordially invite you to participate to the Second International
> > Symposium on Structure-Property Relationships in Solid State Materials
> > (SP-SSM 2008) to be held in Nantes from June 29th to July 3rd, 2008. All
> > the information regarding this interdisciplinary conference can be found
> > at the conference website: http://www.cnrs-imn.fr/SP-SSM_2008/. Abstract
> > submission deadline has been postponed until February, 4.
> >
> > The goal of the symposium is to highlight the relationships between
> > specific physical properties of the materials and their structure and/or
> > chemical composition as well as how these properties may be modified by
> > varying the nature of the chemical bonds, the strength of the
> > electron-electron interaction, the concentration of dopants, etc. The
> > meeting will be devoted mainly to structure-property relationships in
> > magnetic, optical, electronic, thermoelectric and functional materials.
> > Within the scope of this symposium, further topics in fuel cell and
> > photovoltaic solar cells will be encouraged. This symposium will provide
> > opportunities for experimental and theoretical solid state chemists,
> > physicists and materials scientists to share their knowledge and
> > expertise.
> >
> > Important dates:
> >
> > *February 4th, Abstract submission deadline*
> > February 15th: Final program
> > March 1st: end of early registration
> > June 29th: paper submission deadline
> >
> > Invited speakers
> >
> > M. Asensio, Madrid / Paris, Spain / France
> > A. Belik, Ibaraki, Japan
> > X. Blase, Villeurbanne, France
> > M. Drillon, Strasbourg, France
> > C. Elsasser, Freiburg, Germany
> > C. Ewels, Nantes, France
> > L. Forro, Lausanne, Switzerland
> > D. Gourier, Paris, France
> > L. Hammarstr?m, Uppsala, Sweden
> > H. Hosono, Tokyo, Japan
> > J. Irvin, St Andrews, Scotland
> > M. G. Kanatzidis, Evanston, IL, USA
> > J. Lucas, Rennes, France
> > A. Maignan, Caen, France
> > A. Meijerink, Utrecht, The Netherlands
> > M. Pouchard, Bordeaux, France
> > L. Reining, Palaiseau, France
> > A. Rockett, Urbana, IL, USA
> > M. Sato, Nagoya, Japan
> > W. Schnick, M?nchen, Germany
> > A. Simon, Stuttgart, Germany
> > A. Villesuzanne, Bordeaux, France
> >
> > For any question or suggestions, please do not hesitate to contact us at
> > SP-SSM_2008 at cnrs-imn.fr. We would also appreciate if you could
> > disseminate this Announcement through your Department or Institution.
> >
> > We hope to see you in Nantes in June !
> >
> > On behalf of the organizers
> >
> > Dr. St?phane Jobic
> >
> > ___
> > 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/20080204/2bb8dae5/attachment.html