Take a look at orte/mca/rmaps/seq - you can select it with -mca rmaps seq
I believe it is documented
On Thu, Feb 4, 2010 at 5:48 PM, Eugene Loh wrote:
> Ralph Castain wrote:
>
> That is correct and has always been the behavior. If you want OMPI to
>> respect host order, you have to use the seq
Ralph Castain wrote:
That is correct and has always been the behavior. If you want OMPI to
respect host order, you have to use the sequential mapper instead of
the default round-robin mapper.
Sorry, what's the sequential mapper?
That is correct and has always been the behavior. If you want OMPI to
respect host order, you have to use the sequential mapper instead of the
default round-robin mapper.
On Thu, Feb 4, 2010 at 4:37 PM, Eugene Loh wrote:
> I'd check the man page, but since I just rewrote it I don't think that's
I'd check the man page, but since I just rewrote it I don't think that's
going to help!
I have two nodes, A and B, and I run "mpirun -hostfile myhostfile
-tag-output hostname" with five different hostfiles. Here is what I get:
B slots=2
B slots=2
A slots=2
A slots=2
B B B B A A A A
B slots=
I started again from the beginning to sort out exactly what was going
on. Here's what I found.
If I use the CMake GUI, and set CMAKE_BUILD_TYPE to Release,
re-configure and then generate, and then do the following build command:
"devenv OpenMPI.sln /build"
I get the following:
1>-- Bui
I'm trying to compile openmpi-1.4.1 on MacOSX 10.5.8 using Absoft Fortran
90 11.0 and gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple
Inc. build 5493). I get the following error:
make
...
Making all in mca/io/romio
Making all in romio
Making all in include
make[4]: Nothing to be don
Dorian -
Your observation is correct - Open MPI will only make progress on a passive
target communication if the target enters the MPI library in some meaningful
way (tests on a request which hasn't completed, makes a one-sided call, starts
communication, etc.).
I'm the author of the onesided
I am out of the office until 02/13/2010.
I will respond to your message when I return.
Note: This is an automated response to your message "users Digest, Vol
1476, Issue 1" sent on 2/4/10 11:00:12 AM.
This is the only notification you will receive while this person is away.
Has anybody built 1.4.1 on Solaris 8 (Sparc), because it isn't going
very well here. If you succeeded at this please tell me how you did it.
Here is my tale of woe.
First attempt with gcc (3.4.6 from SunFreeware) and
./configure --with-sge --prefix=/opt/ompi141
gmake all install >build_log1
Hi Dave,
thanks for your answer.
The question to me is: Is an MPI process supposed to eventually exit or
can it be a server process running for eternity?
In the later case, no progress will be made ...
I think it might be helpful to users to give a clarification in the
standard (e.g. in an "
Hi Marcus,
I don't think it's correct to set CMAKE_CL_64 explicitly in CMake-GUI,
it's a variable describing the system.
And it's not a good idea to use "Configuration Manager" to adapt another
configuration, if you really want to do so, you have to also adjust each
project property to fit
On Feb 3, 2010, at 6:24 PM, Dorian Krause wrote:
Unless it is also specified that a process must eventually exit with
a call to MPI_Finalize (I couldn't find such a requirement),
progress for RMA access to a passive server which does not
participate actively in any MPI communication is not
I figure out my issue. We were building on Sles9 was causing the type
field debug information not being generated for the .o. So even though
the type symbols could be found the field descriptions for those types
could not because they were never generated. Using Sles10 as the OS to
compile a
Hi,
I have another problem with building x86_64 on 64 bit Windows 7. I set
CMAKE_CL_64 to true in cmake-gui, and and set the VS2008 config to x64
(`New' platform adapted from WIN32). However, I get this during the
build:
1>-- Build started: Project: libopen-pal, Configuration: Debug x64 --
I just ran everything again. I'm absolutely positive that when I used
CMake's GUI last night that setting Release still gave me pdbs. But
when I put SET (CMAKE_BUILD_TYPE Release) into the top-level
CMakeLists.txt, I have a Release build and the install is fine. It's
highly likely that I did
> Hmmm. I did try setting release and I think I still got pdbs. I'll try
> again from a totally clean source tree and post back.
Another datapoint:
I tried Cmake's Generate after setting CMAKE_BUILD_TYPE and building.
I have the same sort of build problems with setting x64 in the VS 2008
config
Hmmm. I did try setting release and I think I still got pdbs. I'll try
again from a totally clean source tree and post back.
Damien
On 10-02-04 4:41 AM, Shiqing Fan wrote:
Hi Damien,
I did a clean build on my 64 bit Windows 7, but I didn't see the same
problem. Could you please make sure
Hi Damien,
I did a clean build on my 64 bit Windows 7, but I didn't see the same
problem. Could you please make sure that the CMAKE_BUILD_TYPE variable
in the CMake-GUI is set to "release"? Setting "release" in Visual Studio
will not change the CMake install scripts.
Thanks,
Shiqing
Dam
r22549 should solve the mpirun crash problem, it's just few lines
change, you could try to modify the source file, or I can send you a
patch. But the mpirun might still hang due to a tcp connection failure,
I made a ticket for this problem:
https://svn.open-mpi.org/trac/ompi/ticket/2231 .
Nevermind... I figured this one out on my own. I was calling foo() from
inside an if (rank == 0) block. Since MPI_Comm_dup is a collective
operation, it was waiting for all the other nodes to also call
MPI_Comm_dup. Oops.
--
Prentice
Prentice Bisbal wrote:
> I have a problem with MPI_Comm_dup. Wh
20 matches
Mail list logo
