These days you can start by looking at pmemd's mvapich configure, but most
mvapich versions I am running into require you to use mpif77 or mpif90 (the
latter may be more important for sander - I am not sure, the former works
fine for pmemd) to find out what libraries to use for the particular mvapich
release you are dealing with. So what you need to do is be sure that the
mpif77 is the one that is being used by the mpi stack you want to use (do a
"which mpif77", looking for a directory path), then do a "mpif77 -link_info"
and see what it tells you about which libraries to use. For mvapich
installations, the libraries will be in two places, one for the "user level"
mpi calls, and another for the system-level library used by the mpi library
itself (so you see the pmemd configure will ask for two directories where
the library files are). Doing all this, you have a chance. All this joyous
stuff is explained in the README that is in the pmemd directory; it is
really required reading for intelligently installing pmemd, and can be
helpful when the rest of the amber install does not work as planned. A word
on the different philosophies for the amber general install vs. the pmemd
install. The amber general install assumes you are on some sort of standard
installation, and that through autoconf stuff and the answers to a few
questions, it will be able to get things right. This works pretty well most
of the time, if you have some standard system that was tested. Where it
works really poorly is if you are on a big supercomputer system somewhere
where the software is configured differently on the frontend node compared
to all the work nodes, or where the frontend node may actually be different
hardware than the work nodes, or where the system setup is just completely
different than anything else amber knows how to deal with. These sorts of
environments will probably continue to exist because the operating system
requirements on a front end node as opposed to a work node are often
different (so you want full functionality on the frontend node, but there
are advantages to running a stripped down OS on the worknodes in that it
makes system responsiveness more predictable). So you end up essentially
with a cross compilation scenario, multiple mpi stacks, etc. etc. Also,
there are all sorts of installations out there where the system software
setup has been "tweaked", "improved" - pick your favorite explanation, such
that it does not look like anything anywhere else. And there is no
guarantee that the vanilla mpi methods for handling this will work
correctly, and first of all, you have to find the right mpi stack. Then
there is the issue of mpi software evolution, compiler evolution, etc.
Freaking everything changes, generally out of sync and with little regard
for what else is changing, and before you know it, you really have to know
something to do an install. So ultimately reading the mpi user guide (if
there is one; when OpenMPI first came out I did not include it as a pmemd
target because they had no documentation; since then I have not included it
as a target because in general the performance is not that great;
unfortunately it seem to be coming included on lots of small systems, and is
an install option with examples for the rest of amber) and reading at least
the pmemd README and reading the user guide for the major supercomputer
installations, if that is what you are dealing with, is required.
Regards - Bob Duke
----- Original Message -----
From: "David A. Case" <case.biomaps.rutgers.edu>
To: <amber.scripps.edu>
Sent: Monday, December 22, 2008 8:35 AM
Subject: Re: AMBER: amber 9 compilation error with mvapich and
intelcompilers
> On Mon, Dec 22, 2008, Amit Bajaj wrote: (using html...please use plain
> text):
>
>> we used mvapich 1.x so we provided option "mpich" while generating
>> config.h
>
> Well, it looks like mvapich is not the same as mpich. Maybe someone
> on the list will have some experience to report. Take a look a what
> pmemd does in its configure script, since there is an option there for
> mvapich.
>
> ...dac
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
to majordomo.scripps.edu
Received on Wed Dec 24 2008 - 01:10:17 PST
