Reuti wrote:
Am 14.10.2008 um 23:39 schrieb Craig Tierney:
Reuti wrote:
Am 14.10.2008 um 23:18 schrieb Craig Tierney:
Ralph Castain wrote:
I -think- there is...at least here, it does seem to behave that way
on our systems. Not sure if there is something done locally to make
it work.
Also, t
Am 14.10.2008 um 23:39 schrieb Craig Tierney:
Reuti wrote:
Am 14.10.2008 um 23:18 schrieb Craig Tierney:
Ralph Castain wrote:
I -think- there is...at least here, it does seem to behave that
way on our systems. Not sure if there is something done locally
to make it work.
Also, though, I hav
Reuti wrote:
Am 14.10.2008 um 23:18 schrieb Craig Tierney:
Ralph Castain wrote:
I -think- there is...at least here, it does seem to behave that way
on our systems. Not sure if there is something done locally to make
it work.
Also, though, I have noted that LD_LIBRARY_PATH does seem to be
ge
Am 14.10.2008 um 23:18 schrieb Craig Tierney:
Ralph Castain wrote:
I -think- there is...at least here, it does seem to behave that
way on our systems. Not sure if there is something done locally to
make it work.
Also, though, I have noted that LD_LIBRARY_PATH does seem to be
getting forwa
You might want to look at something like the mpi-selector project that
is part of OFED (but is easily separable; it's a small package); it
might be helpful to you...?
http://www.openfabrics.org/git/?p=~jsquyres/mpi-
selector.git;a=summary
On Oct 14, 2008, at 5:18 PM, Craig Tierney wrot
Ralph Castain wrote:
I -think- there is...at least here, it does seem to behave that way on
our systems. Not sure if there is something done locally to make it work.
Also, though, I have noted that LD_LIBRARY_PATH does seem to be getting
forwarded on the 1.3 branch in some environments. OMPI i
Ralph Castain wrote:
You might consider using something like "module" - we use that system
for exactly this reason. Works quite well and solves the multiple
compiler issue.
This is the problem. We use modules to switch compilers/MPI stacks.
When a job is launched, whatever LD_LIBRARY_PATH
In torque/pbs using the #PBS -V command pushes the environment
variables out to the nodes. I don't know if that is what was
happening with slurm.
Doug Reeder
On Oct 14, 2008, at 12:33 PM, Ralph Castain wrote:
I -think- there is...at least here, it does seem to behave that way
on our system
I -think- there is...at least here, it does seem to behave that way on
our systems. Not sure if there is something done locally to make it
work.
Also, though, I have noted that LD_LIBRARY_PATH does seem to be
getting forwarded on the 1.3 branch in some environments. OMPI isn't
doing it di
I use modules too, but they only work locally. Or is there a feature
in "module" to automatically load the list of currently loaded local
modules remotely ?
george.
On Oct 14, 2008, at 3:03 PM, Ralph Castain wrote:
You might consider using something like "module" - we use that
system f
You might consider using something like "module" - we use that system
for exactly this reason. Works quite well and solves the multiple
compiler issue.
Ralph
On Oct 14, 2008, at 12:56 PM, Craig Tierney wrote:
George Bosilca wrote:
The option to expand the remote LD_LIBRARY_PATH, in such a
George Bosilca wrote:
The option to expand the remote LD_LIBRARY_PATH, in such a way that Open
MPI related applications have their dependencies satisfied, is in the
trunk. The fact that the compiler requires some LD_LIBRARY_PATH is out
of the scope of an MPI implementation, and I don't think we
The option to expand the remote LD_LIBRARY_PATH, in such a way that
Open MPI related applications have their dependencies satisfied, is in
the trunk. The fact that the compiler requires some LD_LIBRARY_PATH is
out of the scope of an MPI implementation, and I don't think we should
take care
George Bosilca wrote:
Craig,
This is a problem with the Intel libraries and not the Open MPI ones.
You have to somehow make these libraries available on the compute nodes.
What I usually do (but it's not the best way to solve this problem) is
to copy these libraries somewhere on my home area
Gus Correa wrote:
Hi Craig, George, list
Here is a quick and dirty solution I used before for a similar problem.
Link the Intel libraries statically, using the "-static-intel" flag.
Other shared libraries continue to be dynamically linked.
For instance:
mipf90 -static-intel my_mpi_program.f90
Hi Craig, George, list
Here is a quick and dirty solution I used before for a similar problem.
Link the Intel libraries statically, using the "-static-intel" flag.
Other shared libraries continue to be dynamically linked.
For instance:
mipf90 -static-intel my_mpi_program.f90
What is not clear
Craig,
This is a problem with the Intel libraries and not the Open MPI ones.
You have to somehow make these libraries available on the compute nodes.
What I usually do (but it's not the best way to solve this problem) is
to copy these libraries somewhere on my home area and to add the
dir
17 matches
Mail list logo
