hi again,
>>> i'll probably just continue experimenting on my own for the
>>> moment (tracking
>>> any updates to the main trunk LSF support) to see if i can figure
>>> it out. any
>>> advice the best way to get such back support into trunk, if and
>>> when if exists
>>> / is working?
>>
>> The *best* way would be for you to sign a third-party agreement -
>> see the
>> web site for details and a copy. Barring that, the only option
>> would be to
>> submit the code through either Jeff or I. We greatly prefer the
>> agreement
>> method as it is (a) less burdensome on us and (b) gives you greater
>> flexibility.
>
> i'll talk to 'the man' -- it should be okay ... eventually, at
> least ...
See http://www.open-mpi.org/community/contribute/ for details. As an
open project, we always welcome new developers, but we do need to
keep the IP tidy.
will do.
MPI-2 does support the MPI_COMM_JOIN and MPI_COMM_ACCEPT/
MPI_COMM_CONNECT models. We do support this in Open MPI, but the
restrictions (in terms of ORTE) may not be sufficient for you.
perhaps i'll experiment -- any clues as to what the orte restrictions might be?
Some other random notes in no particular order:
- As you noted, the LSF support is *very* new; it was just added last
week.
- It also likely doesn't work yet; we started the integration work
and ran into a technical issue that required further discussion with
Platform. They're currently looking into it; we stopped the LSF work
in ORTE until they get back to us.
i see -- i might be trying to work on the 6.x support today. can you
give me any hints on what the problem was in case i run into the same
issue?
- FWIW, one of the main reasons OMPI/ORTE didn't add extensive/
flexible support for dynamic addition of resources was the potential
for queue time. Many systems run "full" all the time, so if you try
to acquire more resources, you could just sit in a queue for minutes/
hours/days/weeks before getting nodes. While it is certainly
possible to program with this model, we didn't really want to get
into the rats nest of corner cases that this would entail, especially
since very few users are asking for it.
yeah, it does seem like the queuing issue is critical. i think as long
as the requests for more resources are non-blocking, and the
application itself can deal with that, it shouldn't create too many
corner cases. in fact, if the application wants to block (potentially
for a long time) that might be okay too (i.e. on the initial big
allocation, just after some startup routine determines the needed
initial resources).
- That being said, MPI_THREAD_MULTIPLE and MPI_COMM_SPAWN *might*
offer a way out here. But I think a) THREAD_MULTIPLE isn't working
yet (other OMPI members are working on this), and b) even when
THREAD_MULTIPLE works, there will be ORTE issues to deal with
(canceling pending resource allocations, etc.). Ralph mentioned that
someone else is working on such things on the TM/PBS/Torque side; I
haven't followed that effort closely.
it seems that MPI_THREAD_MULTIPLE is to be avoided for now, but there
are perhaps other workarounds (using threads in other ways, etc.).
also, i'd love to hear about the existing efforts -- i'm hoping
someone working on them might be reading this ... ;)
> well, certainly part of the issue is the need (or at least strong
> preference) to support 6.2 -- but read on.
>
[SNIP LSF API info/guesswork]
I am certainly not an expert on LSF (nor its API) -- I only started
using it last week! Do you have any contacts to ask at Platform?
They would likely be the best ones to discuss this with.
i'm in the same boat. i'll try to talk to the people here at cadence
that might have said contacts at Platform.
--
Jeff Squyres
Cisco Systems
Matt.
