[Wien] Calculation of flourescence spectra
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
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
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
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
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
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/libopenblas.so
[Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran
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
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, <lot.a...@yahoo.com> 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
[Wien] Spin-polarization in ELNES calculations
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
Re: [Wien] Spin-polarization in ELNES calculations
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 pbl...@theochem.tuwien.ac.at 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] troubles with mixer in scf
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 L-marks at northwestern.edu 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 david.holec at unileoben.ac.at 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
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 pblaha at theochem.tuwien.ac.at 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 L-marks at northwestern.edu 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 david.holec at unileoben.ac.at 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
[Wien] troubles with mixer in scf
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
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)
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
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] Modeling of Ag5Pb2O6
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
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¾«Æ··¿Ô´ÈÈÏúÖÐ http://popme.163.com/link/003982_0509_4206.html ___ 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
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
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
