LAM: RHEL4 and lam 7.0.6 problem

Hi Brian !

Thank you again for your quick and helpful answers !

Sorry, I just realized that I had the Digest mode ON.......

Back on the topic...
I can see a problem here with the liblam version/lam runtime
having to 
match.
The problem is that I have a few different applications all
beeing 
linked to different lam versions.
The fact of having to match liblam version/lam runtime makes
it 
impossible to run those applications on the same machine.
That is a great obstacle.
Of course I can change the lam version on the fly,
accordingly to 
whatever application I have to run in that precise moment,
but that 
would be quite uncomfortable.... :-(

I remember reading in the FAQ that normally different lam
versions 
cannot co-exist on the same machine and different machines
have to run 
the same lam version.
Is there a workaround  on that issue ?

Cheers
Valter DAL BO
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/

On May 18, 2006, at 11:38 AM, Valter Dal Bo wrote:

> Back on the topic...
> I can see a problem here with the liblam version/lam
runtime having to
> match.
> The problem is that I have a few different applications
all beeing
> linked to different lam versions.
> The fact of having to match liblam version/lam runtime
makes it
> impossible to run those applications on the same
machine.
> That is a great obstacle.
> Of course I can change the lam version on the fly,
accordingly to
> whatever application I have to run in that precise
moment, but that
> would be quite uncomfortable.... :-(
>
> I remember reading in the FAQ that normally different
lam versions
> cannot co-exist on the same machine and different
machines have to run
> the same lam version.
> Is there a workaround  on that issue ?

There is not a workaround for the requirement that an entire
job run  
the same version of LAM/MPI and that the runtime /
application use  
the same version of LAM.

If you have requirements that make multiple versions of LAM 

necessary, I'd recommend looking into the modules package
(http:// 
modules.sourceforge.net/).  It was meant to deal with pretty
much  
exactly this situation.

Brian


-- 
   Brian Barrett
   LAM/MPI developer and all around nice guy
   Have a LAM/MPI day: http://www.lam-mpi.org/


_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/

Valter Dal Bo wrote:
> I remember reading in the FAQ that normally different
lam versions 
> cannot co-exist on the same machine and different
machines have to run 
> the same lam version.
> Is there a workaround  on that issue ?

Valter,

We have a bunch of different MPI packages (including
multiple versions 
of LAM) installed into different subdirectories on our
system, and they 
all co-exist peacefully.  To switch between them, you need
to be sure 
that your environment is configured properly for whichever
application 
you happen to be running.  That's where Brian's suggestion
of using the 
"modules" package could come in handy.

-Tom

-- 
Tom Crockett

College of William and Mary               email:  tomcompsci.wm.edu
Computational Science Cluster             phone:  (757)
221-2762
Savage House                              fax:    (757)
221-2023
P.O. Box 8795
Williamsburg, VA  23187-8795


_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/

Valter Dal Bo ha scritto:
> Dear Brian,
> 
> Thank you 4 your kind help.
> Very interesting that modules application that you
pointed out !
> I will definately take into consideration.
> 
> Cheers
> Valter
> 
> <snip>
> 

As a simpler and more limited alternative to using modules,
supposing 
that all mpi versions reside in /usr/local/* and that bash
is used as 
default shell, I propose the following script (let's call
it defmpi and 
put it somewhere in PATH) which I use on our cluster:

----
#!/bin/bash

mpi=${1:-lam}

if [ ! -d /usr/local/$1 ]; then
   echo "Errore: non esiste la directory
/usr/local/$mpi"
else
   if [ -n "$MPI" ]; then
     PATH=${PATH//:\/usr\/local\/$MPI\/bin}
   fi
   PATH=$PATH:/usr/local/$mpi/bin
   MPI=$mpi
   export MPI PATH
fi

unset mpi
----

It should be launched as
. defmpi
to use the default implementation or
. defmpi lam-xx.xx
to use another one.

This adds or replaces the desired mpi directory in the PATH
variable. 
The big limitation of this approach is that, in a networked
environment, 
it should not be started by hand but you have to put the .
defmpi 
command in the .bashrc of each user in order for the script
to work 
through rsh/ssh when you lamboot; this means that, unless
you change by 
hand the .bashrc, every user is by default limited to use a
single lam 
version. I used it to switch between lam and mpich (and of
course lam is 
the default ), but it
may work also for different lam versions; if 
you use dynamic libraries you may have to add a line to
change 
LD_LIBRARY_PATH along with PATH.
	Hope this helps, ciao, Davide

-- 
__________________________________________________________
Davide Cesari	ARPA-Servizio Idro Meteorologico      __
  tel       (39) 051/525926                            ||\
  fax       (39) 051/6497501                           |||\
  e-mail    dcesariarpa.emr.it                        |||/
  www       http://www.arpa.emr.it/sim
                 ---
  Address:  ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy
__________________________________________________________
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/