Ralph, thank you the reply.
I just try what you said and it works! I didn't think to try the array of
info arguments because in the spawn_multiple documentation I read the
follow:
"... *array_of_info*, is an array of *info *arguments; however, *only the
first argument in that array is used. Any s
Guess I'm having trouble reading your diff...different notation than I'm used
to seeing. I'll have to parse thru it when I have more time.
On May 16, 2011, at 1:02 PM, Peter Thompson wrote:
> Hmmm? We're not removing the putenv() calls. Just adding a strdup()
> beforehand, and then calling p
Hmmm? We're not removing the putenv() calls. Just adding a strdup()
beforehand, and then calling putenv() with the string duplicated from
env[j]. Of course, if the strdup fails, then we bail out.
As for why it's suddenly a problem, I'm not quite as certain. The
problem we do show is a dou
On May 16, 2011, at 12:45 PM, Peter Thompson wrote:
> Hi Ralph,
>
> We've had a number of user complaints about this. Since it seems on the
> face of it that it is a debugger issue, it may have not made it's way back
> here. Is your objection that the patch basically aborts if it gets a bad
You need to use MPI_Comm_spawn_multiple. Despite the name, it results in a
single communicator being created by a single launch - it just allows you to
specify multiple applications to run.
In this case, we use the same app, but give each element a different "host"
info key to get the behavior
Hi Ralph,
We've had a number of user complaints about this. Since it seems on
the face of it that it is a debugger issue, it may have not made it's
way back here. Is your objection that the patch basically aborts if it
gets a bad value? I could understand that being a concern. Of
cours
Ralph,
I have the same issue and I've been searching how to do this, but I couldn't
find.
What exactly must be the string in the host info key to do what Rodrigo
described?
<<< Inside your master, you would create an MPI_Info key "host" that has a
value
<<< consisting of a string "host1,host2,ho
Hi all,
I hope to provide enough information to make my problem clear. I
have been debugging a lot after continually getting a segfault
in my program, but then I decided to try and run it on another
node, and it didn't segfault! The program which causes this
strange behaviour can be downloaded wit
Here is the output of the "ompi_info --param btl openib":
MCA btl: parameter "btl_openib_flags" (current value: <306>,
data
source: default value)
BTL bit flags (general flags: SEND=1, PUT=2, GET=4,
SEN
On May 16, 2011, at 8:53 AM, Brock Palen wrote:
>
>
>
> On May 16, 2011, at 10:23 AM, Samuel K. Gutierrez wrote:
>
>> Hi,
>>
>> Just out of curiosity - what happens when you add the following MCA option
>> to your openib runs?
>>
>> -mca btl_openib_flags 305
>
> You Sir found the magic co
On May 16, 2011, at 10:23 AM, Samuel K. Gutierrez wrote:
> Hi,
>
> Just out of curiosity - what happens when you add the following MCA option to
> your openib runs?
>
> -mca btl_openib_flags 305
You Sir found the magic combination.
I verified this lets IMB and CRASH progress pass their lock
Hi,
Just out of curiosity - what happens when you add the following MCA option to
your openib runs?
-mca btl_openib_flags 305
Thanks,
Samuel Gutierrez
Los Alamos National Laboratory
On May 13, 2011, at 2:38 PM, Brock Palen wrote:
> On May 13, 2011, at 4:09 PM, Dave Love wrote:
>
>> Jeff Squ
12 matches
Mail list logo
