Hi Jason and All,
I am even more confused now since if the program is linked statically
it should not matter what its name or the libraries' it has been
linked against is.
But perhaps I did not explain well what I was proposing:
I am installing AmberTools systemwide and different users may want
either serial or parallel versions of nab. In fact the manual says
that "Once you have some level of comfort and experience with the
single-CPU version, you can enable parallel execution..." so it is
prudent to have both versions on the system.
So I am wondering whether I can:
1) Configure the parallel version (./configure -mpi), make, and install
2) In the bin directory rename *binaries* nab and nab2c to nab.MPI and
nab2c.MPI
3) Configure the serial version (./configure), make, and install -
this will ad serial nab and nab2c to the bin directory resulting in
having both serial and parallel versions of nab and nab2c.
What is "suspicious" is that the developers have not already provided
this mechanism like they have for ptraj?
-
Thanks,
-Martin.
Quoting Jason Swails <jason.swails.gmail.com>:
> Hello,
>
> On Mon, Feb 7, 2011 at 4:44 PM, Martin M. Ossowski <Martin.Ossowski.rice.edu
>> wrote:
>
>> Hello,
>>
>> I noticed that parallel AmberTools 1.4 programs do not have an *.MPI
>> suffixes while parallel Amber 11 programs have. Is there a reason for
>> this -- in other words, is it safe to rename parallel nab and nab2c to
>> nab.MPI and nab2c.MPI while also keeping the serial versions of these
>> programs in the same directory?
>>
>
> I may be mistaken here, but I believe the answer is *no*. Note that I
> believe nab is the *only* AmberTools package that makes use of MPI but
> overwrites the serial build with executables that are the same name. The
> other parallel tool, ptraj, should create a ptraj.MPI executable.
>
> The problem with just *renaming* nab and nab2c with a .MPI suffix is that it
> links to other libraries (like libsff.a). A quick "grep" in that directory
> shows me that there are MPI calls in the sff source files, so libsff.a will
> also be dependent on MPI as well. As far as I can tell, this approach will
> require you to rename *all* of the libraries nab links to (I'm not sure what
> all of them are) with the .MPI suffix and link to those explicitly.
>
> The safest way I can think of doing this is to have a separate directory
> where you compile just AmberTools in parallel if you have some need for
> having both versions, so that you can keep them sufficiently separated.
>
> Hope this helps,
> Jason
>
>
>> -Thank you,
>> -Martin.
>>
>>
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
>
--
Martin M. Ossowski, PhD
Research Computing Support Group,IT - MS119
Rice University
P.O.Box 1892
Houston, TX 77251-1892
Phone: 713-348-2533
Fax: 713-348-6099
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Feb 08 2011 - 08:30:03 PST
