> >>> 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.
> 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
> - 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
> - 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
> - 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