Folks -
Some of the library confusion arises due to differences between
mpif77 -link_info and mpif90 -link_info. While pmemd is all f90, it
really
does not use mpi modules except in rare cases (I know of one case - the
ibm
sp4/sp5, and linking a 32 bit pmemd against the system mpi libs - now
probably 64 bits, where I need to "use" the f90 mpi modules - this is
something obscure about the function call interfaces that I have not
tracked
down, but the crashes go away if you use the module defs). So while I
originally used mpif90 -link_info to get the libraries, I have been moving
to using mpif77 -link_info, which generally produces a simpler linkage
line.
I have not completely cleaned this stuff up yet, but intend to do more
before the release (hacking on amoeba currently). One could argue that
using the modules and f90 linkage would be more bombproof generally; I
have
opted for the simpler course of assuming f77 mpi libraries because that
may
be all that is installed at some sites (there is grief in various releases
of mpich/mpich2 with screwed up f90 defs that keep the mpi f90 interface
build from working, unless you go in and modify mpi f90 source - geez).
One
note on linkage stuff for sander - on my systems (mpich*) I see grief with
finding dynamic libraries for parallel sander unless I specifically
include
whatever dynamic libraries I need in ld.so.conf (and execute the ldconf,
or
whatever it is); this applies to intel libraries of various ilks. So the
rpath stuff that Ross originally introduced in sander a while back, and
which I also implemented in pmemd, probably needs reintroduction (I don't
have these problems with my pmemd parallel installs). Other mpi library
issues - I have tons of grief with nonstandard installs, and there is no
easy way around this unless the mpi distributor gives you a clean way to
get
a link line - I think OpenMPI does this now. I think we just have to warn
the users about this; system people rename libraries, put them in obscure
places, change the structure; you can't really automatically handle such
total randomness (one of the virtues of getting a canned system from sgi,
ibm, etc.). In some instances a pmemd mpi configuration may be not quite
portable to all systems because of these nonstandard issues. For the mpi
implementations that I can install/run on my own platforms, I get things
absolutely right (BUT "right" for one version of mpich, lam, etc may not
be
right for a later version). For things like infiniband/mpivach, I am
dependent on what I find at other installations, and if they did something
nonstandard when they installed the libaries (like changing library names,
which the system folks at unc did with the latest new system), my
configuration may not run exactly correctly, and will require a bit of
editing.
Regards - Bob
----- Original Message -----
From: "David A. Case" <case.scripps.edu>
To: "B. Lachele Foley" <lfoley.uga.edu>
Cc: <amber-developers.scripps.edu>
Sent: Thursday, March 02, 2006 12:51 PM
Subject: amber-developers: problems with parallel installation of Amber 9
> On Thu, Mar 02, 2006, B. Lachele Foley wrote:
>
>> Someone asked me to compile sander for parallel on another
>> machine. It got through a lot of the compile, but finally
>> didn't work.
>
> Please send these messages to amber-developers.scripps.edu (first
> subscribe
> by sending email to majordomo.scripps.edu with "subscribe
> amber-developers"
> in the body of the message). And/or post to the wiki:
>
> http://amber.scripps.edu/pmwiki/pmwiki.php/Main/Amber9pf
>
> I'll cc this to the developers list in case someone can help.
>
>>
>> The main complaint seems to be that certain variables are not
>> defined in the parallel libraries.
>>
>> I set MPICH_HOME to /usr/local/programs/mpich-1.2.6.
>
> (Just a note, to everyone: the latest configure scripts follow the pmemd
> model, and just use a single environment variable (MPI_HOME) for all
forms
> of MPI.)
>
>>
>> For example, here is a complaint:
>>
>>
/usr/local/programs/mpich-1.2.6/lib/libmpich.a(comm_split.o)(.text+0xf7):
>> In function `MPI_Comm_split':
>> : undefined reference to `PMPI_Allreduce'
>
> It looks like you need to add -lpmpich to the LOADLIB string in
config.h.
> I'm guessing that some versions of mpich need this (earlier ones?
> different
> architectures?, different communicators?) and others don't.
>
> I see that Bob Duke just includes "-lmpich -lpmpich" for mpich, whereas
> sander is asking for "-lfmpich -lmpich". Does anyone know if there is a
> universal correct answer to this, or a way (as with lam and openmpi) to
> tell from the installation itself what is required?
>
> [Aside: Bob's libraries for MPICH2 are also different than sander's.
Yet
> both seem to work for me on the same machine.... A significant number
of
> posts on the reflector have to do with parallel installation, so it
would
> be great to see if we can clean this up somehow.]
>
> ...thx...dac
>
>
Received on Wed Apr 05 2006 - 23:49:42 PDT
