hi francesco,<div><br></div><div>[...]</div><div><br></div><div>my your words find entrance into the ears of the cp2k gods.</div><div><br></div><div>it is funny to see how cp2k divides the world. i am feeling a bit bad, though,</div><div>because some of your OpenMP troubles could have been avoided if</div><div>i had posted a summary based on the thread that i started recently.</div><div>at some point the discussion went off-list and thus there was no resolution</div><div>posted here. perhaps, i should make up for it now.</div><div><br></div><div>for the most part, it wasn't possible to reach an agreement what the </div><div>(main) problem is, since it apparently cannot be reproduced on other</div><div>machines but the ones that i am using. ...and i refuse to use as ugly</div><div>a software as MPICH, if the much more elegant and maintainable </div><div>OpenMPI provides the same API and only a faction of the headaches</div><div>for maintaining and using it. so i ended up with the following conclusions</div><div>as to how to compile for MPI+OpenMP (MPI-only had no problems</div><div>with either compiler provided a serial MKL was loaded)</div><div><br></div><div>- gfortran 4.4.x is OpenMP 3.0 capable according to cp2k, intel 11.1 is not.</div><div>  one can make the ssmp  version work with a define.</div><div><br></div><div>- OpenMPI needs to be compiled with MPI threads support (or another workaround</div><div>  define needs to be used), but then seems to work, even with the MKL provided</div><div>  BLACS/SCALAPACK (i have more trust in that being compiled correctly than myself).</div><div><br></div><div>- when compiling with OpenMP enabled, don't compile fftw3 with OpenMP support.</div><div>  also, don't link with a multi-threaded MKL for psmp. this is actually less of a problem<br></div><div>  than what might initially think, since most of the cases where you would _want_ to</div><div>  use OpenMP+MPI (i.e. when its performance is better than MPI alone), there is</div><div>  not so much data to parallelize FFTs or BLAS over to justify the overhead. one can </div><div>  test this using FFTSG where the impact of parallel/non-parallel compile of the FFT</div><div>  alone can be tested. this is not really that much of a surprise, since on modern hardware</div><div>  memory bandwidth is the most valuable property and with multi-threaded FFTs in</div><div>  shared memory, you often are head back by the available bandwidth more than what</div><div>  you would gain from the additional CPU power.</div><div><br></div><div>with these settings, i can run the testjobs that people in our group need fairly reliable</div><div>and efficiently. Intel still seems to be off a bit with OpenMP+MPI, since occasionally</div><div>calculations get stuck. i cannot help, but suspect that there are some race conditions</div><div>hidden that just don't show if you have the right hardware/software on your local machine.</div><div><br></div><div><div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Anyway, these are my two pennies for improving the architecture file
<br>archive, and, maybe, stimulate some discussion about the issue of
<br>working versions and debug of the code.
<br></blockquote><div><br></div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>unfortunately, the cp2k code has developed into such an hard to read and</div><div>difficult to understand monster, that it is unlikely that problems will be resolved</div><div>unless they show up on somebody's machine that is used to digging into</div><div>the code deep enough to sort this out. for me this was the end of the road.</div><div><br></div><div>in some sense, i can understand the status of the arch files. you have</div><div>to change them for almost any machine all the time, and people _can_</div><div>look up in the corresponding documentation how to do this. if you don't</div><div>know how to do this, you probably shouldn't dare to compile cp2k in the</div><div>first place. turning this into some autoconf (or worse, cmake) style setup</div><div>will most likely make things even worse, by giving people a false sense</div><div>of know having to know exactly what to place on the compiler and linker</div><div>flag variable statements.</div><div><br></div><div>with that in mind, i am attaching the set of arch files that i am currently</div><div>using and that seemed to have worked at some point in time around </div><div>mid may in 2011. </div><div><br></div><div>ciao,</div><div>    axel.</div><div><br></div><div>p.s.: building/tuning libsmm on a 4-way opteron 6174 machine is fun. ;-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
<br>Cheers,
<br>F.
<br>
<br>
<br>
<br>
<br></blockquote></div></div>