Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] custom modules per job (PBS/OpenMPI/environment-modules)
From: Michael Sternberg (sternberg_at_[hidden])
Date: 2009-11-17 07:23:16

Hi David,

Hmm, your demo is well-chosen and crystal-clear, yet the output is unexpected. I do not see environment vars passed by default here:

login3$ qsub -l nodes=2:ppn=1 -I
qsub: waiting for job 34683.mds01 to start
qsub: job 34683.mds01 ready

n102$ mpirun -n 2 -machinefile $PBS_NODEFILE hostname
n102$ mpirun -n 2 -machinefile $PBS_NODEFILE env | grep FOO
n102$ export FOO=BAR
n102$ mpirun -n 2 -machinefile $PBS_NODEFILE env | grep FOO
n102$ type mpirun
mpirun is hashed (/opt/soft/openmpi-1.3.2-intel10-1/bin/mpirun)

Curious, what do you get upon:

        where mpirun

I built OpenMPI-1.3.2 here from source with:

    CC=icc CXX=icpc FC=ifort F77=ifort \
    LDFLAGS='-Wl,-z,noexecstack' \
    CFLAGS='-O2 -g -fPIC' \
    CXXFLAGS='-O2 -g -fPIC' \
    FFLAGS='-O2 -g -fPIC' \
    ./configure --prefix=$prefix \
        --with-libnuma=/usr \
        --with-openib=/usr \
        --with-udapl \
        --enable-mpirun-prefix-by-default \

I did't find the behavior I saw strange, given that orterun(1) talks only about $OPMI_* and inheritance from the remote shell. It also mentions a "boot MCA module", about which I couldn't find much on - hmm.

In the meantime, I did find a possible solution, namely, to tell ssh to pass a variable using SendEnv/AcceptEnv. That variable is then seen by and can be interpreted (cautiously) in /etc/profile.d/ scripts. A user could set it in the job file (or even qalter it post submission):

        #PBS -v VARNAME=foo:bar:baz

For VARNAME, I think simply "MODULES" or "EXTRAMODULES" could do.

With best regards,

On Nov 17, 2009, at 4:29 , David Singleton wrote:
> I'm not sure why you dont see Open MPI behaving like other MPI's w.r.t.
> modules/environment on remote MPI tasks - we do.
> xe:~ > qsub -q express -lnodes=2:ppn=8,walltime=10:00,vmem=2gb -I
> qsub: waiting for job 376366.xepbs to start
> qsub: job 376366.xepbs ready
> [dbs900_at_x27 ~]$ module load openmpi
> [dbs900_at_x27 ~]$ mpirun -n 2 --bynode hostname
> x27
> x28
> [dbs900_at_x27 ~]$ mpirun -n 2 --bynode env | grep FOO
> [dbs900_at_x27 ~]$ setenv FOO BAR
> [dbs900_at_x27 ~]$ mpirun -n 2 --bynode env | grep FOO
> [dbs900_at_x27 ~]$ mpirun -n 2 --bynode env | grep amber
> [dbs900_at_x27 ~]$ module load amber
> [dbs900_at_x27 ~]$ mpirun -n 2 --bynode env | grep amber
> LOADEDMODULES=openmpi/1.3.3:amber/9
> PATH=/apps/openmpi/1.3.3/bin:/home/900/dbs900/bin:/bin:/usr/bin::/opt/bin:/usr/X11R6/bin:/opt/pbs/bin:/sbin:/usr/sbin:/apps/amber/9/exe
> _LMFILES_=/apps/Modules/modulefiles/openmpi/1.3.3:/apps/Modules/modulefiles/amber/9
> AMBERHOME=/apps/amber/9
> LOADEDMODULES=openmpi/1.3.3:amber/9
> PATH=/apps/openmpi/1.3.3/bin:/home/900/dbs900/bin:/bin:/usr/bin:/opt/bin:/usr/X11R6/bin:/opt/pbs/bin:/sbin:/usr/sbin:/apps/amber/9/exe
> _LMFILES_=/apps/Modules/modulefiles/openmpi/1.3.3:/apps/Modules/modulefiles/amber/9
> AMBERHOME=/apps/amber/9
> David
> Michael Sternberg wrote:
>> Dear readers,
>> With OpenMPI, how would one go about requesting to load environment modules (of the kind) on remote nodes, augmenting those normally loaded there by shell dotfiles?
>> Background:
>> I run a RHEL-5/CentOS-5 cluster. I load a bunch of default modules through /etc/profile.d/ and recommend to users to customize modules in ~/.bashrc. A problem arises for PBS jobs which might need job-specific modules, e.g., to pick a specific flavor of an application. With other MPI implementations (ahem) which export all (or judiciously nearly all) environment variables by default, you can say:
>> #PBS ...
>> module load foo # not for OpenMPI
>> mpirun -np 42 ... \
>> bar-app
>> Not so with OpenMPI - any such customization is only effective for processes on the master (=local) node of the job, and any variables changed by a given module would have to be specifically passed via mpirun -x VARNAME. On the remote nodes, those variables are not available in the dotfiles because they are passed only once orted is live (after dotfile processing by the shell), which then immediately spawns the application binaries (right?)
>> I thought along the following lines:
>> (1) I happen to run Lustre, which would allow writing a file coherently across nodes prior to mpirun, and thus hook into the shell dotfile processing, but that seems rather crude.
>> (2) "mpirun -x PATH -x LD_LIBRARY_PATH …" would take care of a lot, but is not really general.
>> Is there a recommended way?
>> regards,
>> Michael
> _______________________________________________
> users mailing list
> users_at_[hidden]