Re: [Wien] Some error messages during Installation of WIEN2k_14.2 on CentOS6.5
I am 99.9% certain that none of these is an error. The compile script will tell you if there are any at the end, these are flagged with "Error". N.B., the values set value for NMATMAX=32 set value for NUME=32000 are large, you could run into problems with these if you are running k-point parallel for larger jobs. Since you only have a 2 node cluster with 1G ethernet (?) you may be only intending to run smaller jobs in which case it will be fine. You could get an OOM (Out Of Memory) OS crash with larger jobs. On Mon, Nov 2, 2015 at 8:51 AM, tongweiwrote: > Dear Everyone, > > During installing WIEN2k_14.2, I watched the screen and saw a few errors > in the following. I am not sure it is OK or not. > ---after save compiler options--- > No Makefile.orig in SRC_structeditor/SRC_lib, leaving directory. > No Makefile.orig in SRC_BerryPI, leaving directory. > No Makefile.orig in SRC_lib, leaving directory. > No Makefile.orig in SRC_structeditor, leaving directory. > No Makefile.orig in SRC_templates, leaving directory. > No Makefile.orig in SRC_usersguide_html, leaving directory. > No Makefile.orig in SRC_w2web, leaving directory. > -During compiling- > RC_BerryPI ... > make: *** No rule to make target `clean'. Stop. > make: *** No targets specified and no makefile found. Stop. > > SRC_clmcopy ... > make: Circular modules.o <- modules.o dependency dropped. > make: Circular reallocate.o <- modules.o dependency dropped. > make: Circular reallocate.o <- reallocate.o dependency dropped. > > make[1]: Leaving directory `/usr/local/WIEN2k_14.2/SRC_dstart' > make: *** No rule to make target `complex'. Stop. > --- > > Waiting for solution. > Thanks! > > WT > > +++Here is my situation and installation process > > 1. Hardware: A simple cluster with TWO DELL T760/T7600 workstations > communicating through 1000M switch: > Master (node1)--- 2*Xeon E5-2690 (2*8core), 128G memory > Slave (node2) 2*Xeon E5-2690 v2 (2*10core), 64G memory > ---Installation is on Master. > 2. OS: CentOS 6.5 64bit final > 3. Required package installed > F90 compiler Intel parallel_studio_xe_2013_update4 inluding ifort > version 13.1.3, icc version 13.1.3, MKL, installed at /opt/intel > perl 5 v5.10.1 installed at /usr/bin/perl) > emacs --- GNU Emacs 23.1.1 installed at /usr/bin/emacs) > ghostscript v8.70 installed at /usr/bin/ghostscript) > gnuplot - gnuplot 4.2 patchlevel 6 installed at /usr/bin/gnuplot ) > www-browser - firefox 38.2.1 installed > Tcl/Tk-Toolkit - tcl.x86_64/tk.x86_64 v8.5.7 installed > FFTW v.2 or 3 -Both installed with yum (fftw2-2.1.5, fftw-3.2.1), > and also installed fftw3.3.4 from source through > "./configure --prefix=/usr/local/fftw3.3.4 CC="icc" > --enable-mpi --enable-threads" > and "make", "make install" at /usr/local/fftw3.3.4 with > parallel available. > MPI+SCALAPACK -Yum installed mpich-3.1-4, openmpi-1.8.1, > scalapack-common-2.0.2, > scalapack-openmpi-2.0.2,scalapack-mpich-2.0.2,blacs-common-2.0.2,blacs-mpich-2.0.2, > blacs-openmpi-2.0.2 >Also mpich-3.1 was installed from source at > /usr/local/mpich3_intel13 (compiled with ifort13 and icc13 > compiler)This mpich path is indicated in the bashrc and profile* > Python Python 2.6.6 (with numpy1.4) came with OS, > Python 2.7.3 installed at /usr/local/lib/python2.7, > /usr/local/bin > New Numpy 1.8.0 was uninstalled, and Numpy 1.6.2 was installed > with Python 2.7.3. > Intel MKL-fft Intel MKL-fft was compiled through "make libintel64 > F=intel precision=MKL_DOUBLE" at /opt/intel/mkl/interfaces/x > (=fftw2xc fftw2xf fftw3xc fftw3xf) > 4. Install WIEN2k_14.2 > mkdir "WIEN2k_14.2" at /usr/local/ > copy Fccni.tar.gz TiC.tar.gz TiO2.tar.gz WIEN2k_14.2.tar to > /usr/local/WIEN2k_14.2, then: > # tar -xvf WIEN2k_14.2.tar > # gunzip *.gz > # chmod +x ./expand_lapw > # ./expand_lapw > ***Everything is unpacked except Fccni.tar*, then > # tar -xf Fccni.tar > # ./siteconfig_lapw >** >* Specify a system * >** > Selection: I > >*** >* Specify compilers * >*** > Your Fortran compiler will be ifort. > Your C compiler will be cc. >** >* Specify compiler options * >** > searching > You have the following mkl libraries in > /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64 : > > /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_blacs_intelmpi_ilp64.so > .. > /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_lapack95_ilp64.a > MKL_TARGET_ARCH was set to intel64 > The default options shown on the next screen should be ok > Hit Enter to continue > Current settings: > O Compiler
[Wien] Some error messages during Installation of WIEN2k_14.2 on CentOS6.5
Dear Everyone, During installing WIEN2k_14.2, I watched the screen and saw a few errors in the following. I am not sure it is OK or not. ---after save compiler options--- No Makefile.orig in SRC_structeditor/SRC_lib, leaving directory. No Makefile.orig in SRC_BerryPI, leaving directory. No Makefile.orig in SRC_lib, leaving directory. No Makefile.orig in SRC_structeditor, leaving directory. No Makefile.orig in SRC_templates, leaving directory. No Makefile.orig in SRC_usersguide_html, leaving directory. No Makefile.orig in SRC_w2web, leaving directory. -During compiling- RC_BerryPI ... make: *** No rule to make target `clean'. Stop. make: *** No targets specified and no makefile found. Stop. SRC_clmcopy ... make: Circular modules.o <- modules.o dependency dropped. make: Circular reallocate.o <- modules.o dependency dropped. make: Circular reallocate.o <- reallocate.o dependency dropped. make[1]: Leaving directory `/usr/local/WIEN2k_14.2/SRC_dstart' make: *** No rule to make target `complex'. Stop. --- Waiting for solution. Thanks! WT +++Here is my situation and installation process 1. Hardware: A simple cluster with TWO DELL T760/T7600 workstations communicating through 1000M switch: Master (node1)--- 2*Xeon E5-2690 (2*8core), 128G memory Slave (node2) 2*Xeon E5-2690 v2 (2*10core), 64G memory ---Installation is on Master. 2. OS: CentOS 6.5 64bit final3. Required package installed F90 compiler Intel parallel_studio_xe_2013_update4 inluding ifort version 13.1.3, icc version 13.1.3, MKL, installed at /opt/intel perl 5 v5.10.1 installed at /usr/bin/perl) emacs --- GNU Emacs 23.1.1 installed at /usr/bin/emacs) ghostscript v8.70 installed at /usr/bin/ghostscript) gnuplot - gnuplot 4.2 patchlevel 6 installed at /usr/bin/gnuplot ) www-browser - firefox 38.2.1 installed Tcl/Tk-Toolkit - tcl.x86_64/tk.x86_64 v8.5.7 installed FFTW v.2 or 3 -Both installed with yum (fftw2-2.1.5, fftw-3.2.1), and also installed fftw3.3.4 from source through "./configure --prefix=/usr/local/fftw3.3.4 CC="icc" --enable-mpi --enable-threads" and "make", "make install" at /usr/local/fftw3.3.4 with parallel available. MPI+SCALAPACK -Yum installed mpich-3.1-4, openmpi-1.8.1, scalapack-common-2.0.2, scalapack-openmpi-2.0.2,scalapack-mpich-2.0.2,blacs-common-2.0.2,blacs-mpich-2.0.2, blacs-openmpi-2.0.2 Also mpich-3.1 was installed from source at /usr/local/mpich3_intel13 (compiled with ifort13 and icc13 compiler)This mpich path is indicated in the bashrc and profile*Python Python 2.6.6 (with numpy1.4) came with OS, Python 2.7.3 installed at /usr/local/lib/python2.7, /usr/local/bin New Numpy 1.8.0 was uninstalled, and Numpy 1.6.2 was installed with Python 2.7.3.Intel MKL-fft Intel MKL-fft was compiled through "make libintel64 F=intel precision=MKL_DOUBLE" at /opt/intel/mkl/interfaces/x (=fftw2xc fftw2xf fftw3xc fftw3xf)4. Install WIEN2k_14.2 mkdir "WIEN2k_14.2" at /usr/local/ copy Fccni.tar.gz TiC.tar.gz TiO2.tar.gz WIEN2k_14.2.tar to /usr/local/WIEN2k_14.2, then:# tar -xvf WIEN2k_14.2.tar # gunzip *.gz # chmod +x ./expand_lapw # ./expand_lapw ***Everything is unpacked except Fccni.tar*, then # tar -xf Fccni.tar# ./siteconfig_lapw ** * Specify a system * ** Selection: I *** * Specify compilers * *** Your Fortran compiler will be ifort. Your C compiler will be cc. ** * Specify compiler options * ** searching You have the following mkl libraries in /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64 : /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_blacs_intelmpi_ilp64.so .. /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_lapack95_ilp64.a MKL_TARGET_ARCH was set to intel64 The default options shown on the next screen should be ok Hit Enter to continue Current settings: O Compiler options:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -O3 -xW F FFTW options: L Linker Flags:$(FOPT) -L/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/ -pthread -i-static P Preprocessor flags '-DParallel' R R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread FL FFTW_LIBS: -lfftw3_mpi -lfftw3 -L/usr/local/fftw3_intel12_mpich3/lib S Save and Quit *** * Changing compiler options * ***changing Makefile in SRC_lib/blas_lapw changing Makefile in SRC_lib/lapack_lapw No Makefile.orig in SRC_structeditor/SRC_lib, leaving directory. (*There are several this
[Wien] EWinS 2016 - EUSpec Winter School on core level spectroscopies
-- EWinS 2016 - EUSpec Winter School on core level spectroscopies -- Date: 1 – 11 February 2016. Venue: Ajdovščina, Slovenia The COST action EUSpec (http://www.euspec.eu/) is proud to announce its first two-week winter school on core level spectroscopies to be held at the Applied Physics Faculty of the University of Nova Gorica. SCHOOL MOTIVATION The aim of the school is to introduce theoreticians as well as experimentalists to foundations of modern approaches for studying core level spectroscopies from first-principles modeling to the most advanced experimental spectroscopy techniques. The school will bring together experts and early career investigators working on advanced materials science, with a common interest in high level and up-to-date sophisticated spectroscopy experiments and modeling tools. The school will be an extraordinary opportunity for students and young researchers to be introduced to core level spectroscopies and to discuss with worldwide recognized scientists in a friendly environment. Regular lectures and talks will be followed by hands-on courses on the following three codes: ORCA (quantum chemistry), WIEN2k (full-potential all-electron), and Quantum ESPRESSO (pseudo-potential). * * * * Registration & Info: http://ewins2016.ijs.si/ School contact email: ewins2...@ijs.si Regular registration deadline: 15 December, 2015 Regular registration fee: 50 EUR PARTICIPATION AND FINANCIAL SUPPORT There is no restrictions for participants with respect to age and/or title, but the school is limited to a maximum of 40 participants. Limited COST fundings are available to support travel and accommodation for participants from the COST countries or the Near Neighbour Country approved institution. PhD students, postdocs, and researchers are eligible for refunding. INVITED PLENARY SPEAKERS Maria N. Piancastelli (Uppsala University) Lucia Reining (Ecole Polytechnique) Frank de Groot (Utrecht University) Stefano Baroni (SISSA) Claudio Masciovecchio (Elettra Sincrotrone) Cécile Hébert (EPFL) Dimitrios Manganas (MPI für Chemische Energiekonversion) Local Organizers Layla Martin-Samos (University of Nova Gorica), Anton Kokalj (Jožef Stefan Institute), Barbara Ressel (University of Nova Gorica) International Committee Hubert Ebert (University of Munich), Didier Sébilleau (University of Rennes 1), Amélie Juhin (University P. et M. Curie-CNRS), Frank de Groot (Utrecht University), Maddalena Pedio (CNR-IOM), Jarmila Savkova (University of West Bohemia), Sara Lafuerza (ESRF), Nicholas Hine (University of Warwick), Yaroslav Kvashnin (Uppsala University) ___ 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] RMTs changing on their own?
For the :WARN, please do "grep -ie Warn case.scf", sometimes there is more information. If that does not help send the case.scf to my private email. Not sure about the other. Peter added something to automatically change RMTs in the latest version, not sure if that played a role (I have never used it). Is there a clminter.log or similar in the directory? Do "grep clminter" on :log? On Mon, Nov 2, 2015 at 9:22 AM, Elias Assmannwrote: > Hi List, > > My MSR1a (‘-min’) calculation was running along happily until I reduced > the RMTs (using ‘clminter’). After that it continued to run for several > iterations, but now has crashed (“SELECT” error in lapw1). > > I noticed that the RMTs in the current struct file are back to their > original values, before the reduction. Is it possible that this change > happened automatically? > > I happened to check on the calculation in the last iteration before it > crashed, and saw that the ‘case.struct’ had the original, larger, RMTs > while ‘case.struct_old’ still had the reduced ones. Now, after the > crash, both files have the original radii. > > This is corroborated (I think) by the :RKM tag in ‘case.scf’, which > changes in the last iteration, apparently back to the value it had > before the RMT reduction: > > ... > :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > ... > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > > By the way, I had a separate calculation running in a subdirectory of > this one, in case there could be any interference from that. Also, this > is still the same calculation I asked about earlier, and I still get the > *WARNING*s from ‘mixer’ without a more explicit message. > > > Elias > > > -- > Elias Assmann > Institute of Theoretical and Computational Physics > TU Graz ⟨https://itp.tugraz.at/⟩ > > -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Gyorgi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] RMTs changing on their own?
Hi List, My MSR1a (‘-min’) calculation was running along happily until I reduced the RMTs (using ‘clminter’). After that it continued to run for several iterations, but now has crashed (“SELECT” error in lapw1). I noticed that the RMTs in the current struct file are back to their original values, before the reduction. Is it possible that this change happened automatically? I happened to check on the calculation in the last iteration before it crashed, and saw that the ‘case.struct’ had the original, larger, RMTs while ‘case.struct_old’ still had the reduced ones. Now, after the crash, both files have the original radii. This is corroborated (I think) by the :RKM tag in ‘case.scf’, which changes in the last iteration, apparently back to the value it had before the RMT reduction: ... :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: ... :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: By the way, I had a separate calculation running in a subdirectory of this one, in case there could be any interference from that. Also, this is still the same calculation I asked about earlier, and I still get the *WARNING*s from ‘mixer’ without a more explicit message. Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ 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] RMTs changing on their own?
Yes, it could really happen ! (Not happy about it, need to be changed) I recently introduced in the run(sp)_lapw scripts a hack that mixer should run a second time with a larger mixing (echo 0.2 >.pratt), in case it is the first iteration and the charge distance is very small. However, I also added a line in such a case that struct_old should be copied to struct (probably on Lauries request, because otherwise the positions could be inconsistent). if ($icycle == 1 && $itestdis < 10 && "$itestmem" == "0" && $?firstcheck) then echo 0.2 >.pratt unset firstcheck rm *.broy* if ($testmsr == 'MSR') cp $file.struct_old $file.struct <---comment goto mixer endif This hack is because in WIEN2k_14 the mixer started always with a very small PRATT-step, which could lead to stagnation. It would be best if mixer would do this internally. At the moment comment the copy-line to prevent this again. PS: When overlapping spheres happen, do: cp case.struct case.struct_new edit case.struct_new and set smaller sphere radii x clminter (-up(dn) cp case.struct_new case.struct cp case.clmsum_new case.clmsum ... clmup/dn On 11/02/2015 04:22 PM, Elias Assmann wrote: Hi List, My MSR1a (‘-min’) calculation was running along happily until I reduced the RMTs (using ‘clminter’). After that it continued to run for several iterations, but now has crashed (“SELECT” error in lapw1). I noticed that the RMTs in the current struct file are back to their original values, before the reduction. Is it possible that this change happened automatically? I happened to check on the calculation in the last iteration before it crashed, and saw that the ‘case.struct’ had the original, larger, RMTs while ‘case.struct_old’ still had the reduced ones. Now, after the crash, both files have the original radii. This is corroborated (I think) by the :RKM tag in ‘case.scf’, which changes in the last iteration, apparently back to the value it had before the RMT reduction: ... :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: ... :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: By the way, I had a separate calculation running in a subdirectory of this one, in case there could be any interference from that. Also, this is still the same calculation I asked about earlier, and I still get the *WARNING*s from ‘mixer’ without a more explicit message. Elias ___ 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.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/staff/tc_group_e.php -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html