Re: [Wien] Some error messages during Installation of WIEN2k_14.2 on CentOS6.5

2015-11-02 Thread Laurence Marks
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, tongwei  wrote:

> 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

2015-11-02 Thread tongwei
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

2015-11-02 Thread Tone Kokalj
--
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?

2015-11-02 Thread Laurence Marks
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 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
>
>
> --
> 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?

2015-11-02 Thread Elias Assmann
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?

2015-11-02 Thread Peter Blaha

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