Folks -
I probably blew about a day fighting with this little problem created by
Intel, and thought I would mention it to the group since I have heard
rumblings about config problems. In my case, this got more complicated
because I changed compilers (ifort 8-->9) and was simultaneously trying to
get Intel mpi up and running so I could include a valid config in the
release. Always a bad idea to change two things at once. Anyway, here's
the deal. Ifort ships with a libguide.<so,a> in it's libraries. So does
MKL. If you look at the MKL examples, Intel recommends linking against
libguide.<a,so> when you build something that uses MKL, so pmemd does this
and so does sander. Now, this will come in as a .so unless you specify a
full path (since both .a and .so are available), and the version you get
will depend on your rpath setting. We set rpath based on LD_LIBRARY_PATH.
LD_LIBRARY_PATH is set by the various *vars.<csh,sh> scripts for the intel
products that you include in your .login or .profile. So now the copy of
libguide you get depends on the order of intel script invocations in your
.login or .profile. Well, if you have ifort 8 and mkl 8, the libguide's
are
equivalent and it does not matter. If you upgrade to ifort 9 (and the
last
mkl release is 8, so you can't upgrade), then the libguide's are
different,
and if you pick up the libguide.so from the new ifort 9, it apparently is
missing some things (special versions of memset, memcpy that they have
renamed in going from 8-->9) that mkl will attempt to call if libguide is
being included (must be conditional initialization code of some sort, I
would guess). So you either have to get the LD_LIBRARY_PATH "right" (done
such that MKL takes precedence over ifort), or you can specify the full
path
(including .a or .so to the libguide under MKL). I ultimately solved the
problem by just leaving out libguide completely, since it apparently is
only
needed if you are using OpenMP (something I did not glean from the current
release notes, but somehow stumbled upon googling the net to help figure
out
where the heck the problem was coming from). So you guys may want to look
into this for sander; trust me, it can wreck a day. The reason I
mentioned
conditional init code above is that you can run this stuff without
libguide
entirely, so the stuff that does not resolve is not actually needed, but
if
you pick up the "wrong" libguide, some other code attempts to get stuff
from
the other libguide. And to think that we pay for this stuff... Also
note,
at least for p4 and pmemd built with current options, ifort 9.0.032
produces
slower code than ifort 8.1.025
On netcdf, I have noticed that if you make clean (globally), you need to
run
configure again (at amber/src, not pmemd) to build netcdf. I have not
bothered to look at what gets blown away, and I presume this is being done
so the next "configure" will take; it may be a better idea to blow away
old
netcdf configure info as part of the configure process itself, as having
to
rerun configure is an unexpected side effect of doing a make clean.
Best Regards - Bob
Received on Wed Apr 05 2006 - 23:49:43 PDT
