[Pw_forum] WFC convergence in NEB calculation

Mon Oct 13 23:32:01 CEST 2008

On Mon, 13 Oct 2008, Janos Kiss wrote:

hi janos,

JK> I was also concerned about this aspect, but when i did a quick and 
JK> rough test calculation, the wfc convergence was not particularly better, and 
JK> one SCF step took a lot longer time. Therefore, i just killed it impatiently 
JK> iirc.

please don't discard nicola marzari's suggestion to use the cp.x code
with damped dynamics. with difficult to converge wavefunctions, this
is actually quite competitive (and the reason why i added it to CPMD 
not so long ago. mind you the CPMD implementation is less sophisticated 
than the one in cp.x).

[...]

JK> I tried to use the cg scheme for those images where the wfc convergence was 
JK> tricky, but it was not successfull. I am really afraid, that somehow i 
JK> managed to misscompile the code, because if i try to crank up the density 
JK> cutoff above 5 times the pwcutoff, the code crashes right after the wfc 
JK> initialization in the wfc diagonalization. I think this is a really bad sign.

... or a sign, that you have an overly paranoid sysadmin that does not
allow increasing the stack size sufficiently. 

JK> In fact, i completely forgot to mention, that i was able to produce a relative 
JK> stable binary with mkl 8.1 only. With newer mkl versions in a geometry 

i would not expect that you see bad behavior because of the MKL version.
miscopilation because of bad compiler version or overoptimization is
_much_ more likely.

JK> optimization after several successfull steps when the nuclei were close to 
JK> the minimum  geometry the code crashed very often in chdiag. This was 

JK> reproduceable for a TiO2 and a Cu slab as well. With mkl 10 it was a pain to 
JK> actually produce somehow a binary (i had to modify some flags to get it 

compiling Q-E properly with mkl-10 has been discussed on this list N+1 
times, please check the mailing list archives. it is actually not that
difficult if you understand how mkl is structured, and _that_ is 
explained in the mkl documentation. 

JK> working), but the binary crashed right after the wfc initialisation for all 
JK> my test calculations. 
JK> Than i have seen in the forum, that mkl 10 does not give any gain compared 
JK> to older mkl versions, so i gave up on it. Of course, to clarify this i should 

that is usually a sign of not using mkl correctly. particularly when
using the threaded version, but not enforcing OMP_NUM_THREADS=1 on _all_ 
parallel nodes. again, this has been discussed plenty of times here.

JK> attache all the config files, the machine architecture, the ifc compiler and 
JK> mkl versions and so on. 
JK> Apparently i am not alone having this issue on the new quad core Intel Xeon 
JK> machines. For example, on dual Opteron i produced a rock solid binary with 
JK> Atlas and with mkl 9.0 as well. Now someone could say, that i am not really 
JK> supposed to use mkl on an Opteron, but it worked. It was only around 4% 

mkl works well on opteron and is - as of recent versions - also 
validated from intel for opteron. the mapping PGI compiler-> AMD CPU
and Intel compiler -> Intel CPU is mostly due to marketing myths and 
incompetent or lazy sysadmins. 

JK> slower than the Atlas version, and the numbers were looking the same (within 
JK> the numerical noise). Of course, i would prefer to use the dual Quad Xeon 
JK> machines, because they are faster. I would suspect, that this is more like an 
JK> issue with the Quad Xeon architecture, or with our particular system 
JK> environment/installation.

i'm having no problems with Q-E on a cluster of dual quad-core xeon 
using intel mkl-10 and 10.1 compilers. once mostly has to make sure
to have recent patchlevels and compile/link with the proper flags.

cheers,
    axel.

p.s.: here are the flags that i'm using on our machine running a
clone of RHEL 5.1.

FFLAGS         = -O2 -assume byterecl -march=pentiumpro -mtune=core2 -pc64 -unroll 
FFLAGS_NOOPT   = -O0 -assume byterecl

the mkl linking is done in a somewhat atypical way, because i don't 
want to have to set up LD_LIBRARY_PATH globally, so i am encoding it 
into the binaries directly using -rpath (see the manpage for "ld"). 
i'm also explicitly linking the non-threaded version (for details 
see the mkl docs). please note that this only works with mkl 10.

BLAS_LIBS      = -Wl,-rpath,/cmm/pkg/intel/mkl/default/lib/em64t \
-L/cmm/pkg/intel/mkl/default/lib/em64t -lmkl_intel_lp64 -lmkl_sequential -lmkl_core

JK> 
JK> Yours Sincerely,
JK>    Janos.
JK> 
JK>  ==================================================================
JK>    Janos Kiss   e-mail: janos.kiss at theochem.ruhr-uni-bochum.de       
JK>  Lehrstuhl fuer Theoretische Chemie  Phone: +49 (0)234/32-26485 
JK>  NC 03/297                                  +49 (0)234 32 26754
JK>  Ruhr-Universitaet Bochum            Fax:   +49 (0)234/32-14045
JK>  D-44780 Bochum            http://www.theochem.ruhr-uni-bochum.de
JK>  ==================================================================
JK> 
JK> 
JK> _______________________________________________
JK> Pw_forum mailing list
JK> Pw_forum at pwscf.org
JK> http://www.democritos.it/mailman/listinfo/pw_forum
JK> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.