FWIW, I suggested the OMPI_<function>() method for two reasons:
1. It's stable and would divorce itself from any underlying env
variables that may change over time (although starting with v1.3, some
of the ones Ralph mentioned shouldn't be changing)
2. Providing OMPI_* functions is a pre-standardization mechanism to
see if users really want/can use them. If we get feedback that they
are useful, that's a good data point to the Forum to actually have an
official MPI_* version of the function that will be standardized.
And I wasn't clear before -- I was assuming that this particular
OMPI_<function> would allow itself to be called before MPI_INIT().
Otherwise, that would somewhat defeat the point of Brian's request. :-)
On Oct 22, 2008, at 10:02 AM, Ralph Castain wrote:
We could - though it isn't clear that it really accomplishes anything.
I believe some of the suggestions on this thread have forgotten about
singletons. If the code calls MPI_Init, we treat that as a singleton
and immediately set all the MPI environmental params - which means the
proc's environment now looks exactly as if it had been launched by
mpirun. That is by design for proper singleton operation. So doing
anything that starts with MPI_Init isn't going to work.
What I think Brian is trying to do is detect that his code was not
launched by mpirun -prior- to calling MPI_Init so he can decide if he
wants to do that at all. Checking for the enviro params I suggested is
a good way to do it - I'm not sure that adding another one really
helps. The key issue is having something he can rely on, and I think
the ones I suggested are probably his best bet for OMPI.
What would be nice is if you MPI Forum types could agree on an MPI-
standard way of doing this so Brian wouldn't have to check a dozen
different variations... :-)
Ralph
On Oct 22, 2008, at 7:21 AM, Jeff Squyres wrote:
> I wonder if it would be useful to have an OMPI-specific extension
> for this kind of functionality, perhaps
> OMPI_Was_launched_by_mpirun() (or something with a better name,
> etc.)...?
>
> This would be a pretty easy function for us to provide (right
> Ralph?). My question is -- would this (and perhaps other similar
> extensions) be useful to the community at large?
>
>
>
> On Oct 21, 2008, at 5:46 PM, Adams, Brian M wrote:
>
>>> I'm not sure I understand the problem. The ale3d program from
>>> LLNL operates exactly as you describe and it can be built
>>> with mpich, lam, or openmpi.
>>
>> Hi Doug,
>>
>> I'm not sure what reply would be most helpful, so here's an
attempt.
>>
>> It sounds like we're on the same page with regard to the desired
>> behavior. Historically, we've been able to detect serial vs.
>> parallel launch of the binary foo, with a whole host of
>> implementations, including those you mention, as well as some
>> vendor-specific implementations (possibly including DEC/OSF, SGI,
>> Sun, and AIX/poe, though I don't know all the details). We
>> typically distinguish serial from parallel executions on the basis
>> of environment variables set only in the MPI runtime environment.
>> I was just trying to ascertain what variable would be best to test
>> for in an OpenMPI environment, and I think Ralph helped with that.
>>
>> If the ale3d code takes a different approach, I'd love to hear
>> about it, off-list if necessary.
>>
>> Brian
>>
>>
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
Cisco Systems
