AMBER Archive (2005)

Subject: Re: AMBER: problems with running sander in parallel on linux

From: Robert Duke (rduke_at_email.unc.edu)
Date: Tue Feb 15 2005 - 13:43:37 CST

Okay, guys, I am a little fuzzy on this stuff, but as I recollect:
1) LD_LIBRARY_PATH is first critical during linking, and only used in
loading (by ld.so) when the information needed to find a shared object is
not present in the executable.
2) I actually don't set LD_LIBRARY_PATH at all on the machines other than
the compile machine; I just make sure that all the machines have a version
of the intel compiler libraries visible in the same place (via the same
path).
3) It may be necessary to get the path to the ifort libs into
/etc/ld.so.cache by using ldconfig. Please read the man pages for ldconfig
(the dynamic linking config tool), ld.so (the dynamic loader), and ld (the
linker) for clarifications on all this wonderful stuff.
4) I WOULD be 100% behind making everything static, but there were huge
problems with statically linked executables on RH 3 a while back, associated
with the fact that the static threads libraries were essentially broke
(whereas the dynamic loaded ones are okay). One could dink around with
loader options and perhaps manage to dynamically load only certain things,
but I never got to the bottom of the problem, and the OS and compiler were
both moving targets.

Bottom line -
1) I continue to load everything dynamically because I have not sorted out
this grief.
2) I use LD_LIBRARY_PATH in compiling, but also use ldconfig to insure the
correct library paths are in /etc/ld.so.conf. Please read the ldconfig man
page.
3) I insure the intel libraries are visible by the same path. I have no
idea whether 2 + 3 are both necessary; I would not think so, but it works.

4) Another common environment gotcha, especially for pmemd, but potentially
for sander, is the need to put "limit stacksize unlimited" in your .login
and .cshrc files (it should only be needed in the first, but it IS needed in
the second; I would regard this as a linux bug).

I think I wrote up some stuff that is out there on the amber web page about
all this stuff; David Konerding dug deeper than I did and there was some
mail on the reflector; I used to be fascinated by all this stuff when I was
a systems guy, but got over it and just want to get the job done.

Regards - Bob

----- Original Message -----
From: "Ross Walker" <ross_at_rosswalker.co.uk>
To: <amber_at_scripps.edu>
Sent: Tuesday, February 15, 2005 1:50 PM
Subject: RE: AMBER: problems with running sander in parallel on linux

> Hi Piotr,
>
>> I compiled mpi sander on my linux box using ifort intel compiler
>> (under most recent mpi/mpd).
>> When I tried to run it (in this case on 2 processors) I got
>> the following error message:
>>
>> sander: error while loading shared libraries: libimf.so:
>> cannot open shared object file: No such file or directory
>> sander: error while loading shared libraries: libimf.so:
>> cannot open shared object file: No such file or directory
>
> What mpi wrapper are you using? It is possible that the mpirun command is
> running rsh to your machine and this is not sourcing your login scripts
> correctly. Hence it doesn't pick up the LD_LIBRARY_PATH and so can't find
> the libraries. See if you can find out how your mpirun is spawning
> processes
> and in particular find out what shell it is running. The default shell may
> be different to "your" shell.
>
> The best solution to this is to compile everything static. You can compile
> a
> static version of lam by adding the flag -all-static to the configure
> script. Then recompile lam and also compile amber statically. You can also
> compile mpich statically but I can't remember the options for this.
>
> All the best
> Ross
>
> /\
> \/
> |\oss Walker
>
> | Department of Molecular Biology TPC15 |
> | The Scripps Research Institute |
> | Tel:- +1 858 784 8889 | EMail:- ross_at_rosswalker.co.uk |
> | http://www.rosswalker.co.uk/ | PGP Key available on request |
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not
> be read every day, and should not be used for urgent or sensitive issues.
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber_at_scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu
>

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu