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.