This sounds like the fuel problem we're facing right now. Potentially,
there are enough resources (for now). Simultaneously, there is enough
demand (for ever). But they are connected by this artificially
maintained tiny pipe ...
The tuned collective are not supposed to adapt to all cases.
That is strange. If your procs are trapping the signal, then it should be
okay - at least, my signal traps are operating cleanly in Mac, TM, and SLURM
environments.
Let me know if you see anything further and maybe we can figure out why it
is behaving that way.
Ralph
On 4/17/08 2:03 PM,
Ralph,
Thanks for looking into this. I do not think that the behaviour needs to
change - it is correct. However, for some reason this is not how things
were running for me - I wander what the difference is. I worked around
this by getting the pid's of the mpi processes, and delivered the
The question was raised on this list a short while ago about potentially
incorrect behavior by ORTE/OMPI in response to SIGUSR2 being sent to
application procs. I have spent some time chasing this down, and it does
-not- appear to be an issue within our systems.
What I have found is that if you
Brief summary:
In r18190, I have restored the --do-not-launch capability, and added a
--do-not-resolve flag. This note describes how you can use those to build
and test application mappings without first getting an allocation and/or
launching it.
Longer description:
Users and developers have
Sweet!
On Apr 17, 2008, at 10:06 AM, Ralph H Castain wrote:
I have implemented and committed (r18190) a new RMAPS module that
sequentially maps ranks to the hosts listed in a hostfile. You must
set -mca
rmaps seq in order to access this module - it will -not- be selected
any
other way.
I have implemented and committed (r18190) a new RMAPS module that
sequentially maps ranks to the hosts listed in a hostfile. You must set -mca
rmaps seq in order to access this module - it will -not- be selected any
other way.
The basic method of operation respects the hostfile descriptions on
