The problem here is that you are attempting to start the application
processes without using our mpirun. We call this a "standalone" launch.
Unfortunately, OMPI doesn't currently understand how to do a standalone
launch - ORTE will get confused and abort, as you experienced. There are two
ways to
Could you try this version of the specfile (there's a download link at
the bottom):
https://svn.open-mpi.org/trac/ompi/browser/trunk/contrib/dist/linux/openmpi.spec
This is the specfile on the OMPI trunk, which hasn't made it over to
the v1.2 branch yet. Here's the diff between the two (
Yes, please let us know if this fixes it. We're working on a 1.2.6
release; we can definitely put this fix in there if it's correct.
Thanks!
On Mar 13, 2008, at 4:07 PM, George Bosilca wrote:
I dig into the sources and I think you correctly pinpoint the bug.
It seems we have a mismatch be
Two things:
- You might want to run "mpicc --showme" to get the list of compiler/
linker flags to put into KDevelop. Better yet, if you can get
KDevelop to use mpicc (etc.) instead of gcc, that would avoid you
needing to explicitly list anything in terms of libraries, header
locations, et
I don't know if anyone has tried to run Open MPI with globus before.
One requirement that Open MPI currently has is that all nodes must be
reachable to each other via TCP. Is that true in your globus
environment?
On Mar 10, 2008, at 11:01 AM, Christoph Spielmann wrote:
Hi everybody!
I
On Mar 9, 2008, at 5:39 PM, Justus Schwabedal wrote:
I got it. The answer I was looking for was: lam deamons are
not in use anymore. mpirun does everything byitself as soon
as all the path variables are set up correctly. However, what
are the openIB and uDAPL warnings good for? E.g:
Sorry for
On Mar 10, 2008, at 9:15 PM, Jim Hill wrote:
I'm trying to build a 64-bit 1.2.5 on an 8-core Xeon Mac Pro running
OS X 10.4.11, with the Portland Group's PGI Workstation 7.1-5
tools. The configure script works its magic with a couple of
modifications to account for PGI's tendency to freak
