Ralph H Castain wrote:
>I. Support for non-MPI jobs
>Considerable complexity currently exists in ORTE because of the stipulation
>in our first requirements document that users be able to mpirun non-MPI jobs
>- i.e., that we support such calls as "mpirun -n 100 hostname". This creates
>a situation, however, where the RTE cannot know if the application will call
>MPI_Init (or at least orte_init), which has significant implications to the
>RTE's architecture. For example, during the launch of the application's
>processes, the RTE cannot go into any form of blocking receive while waiting
>for the procs to report a successful startup as this won't occur for
>execution of something like "hostname".
>Jeff has noted that support for non-MPI jobs is not something most (all?)
>MPIs currently provide, nor something that users are likely to exploit as
>they can more easily just "qsub hostname" (or the equivalent for that
>environment). While nice for debugging purposes, therefore, it isn't clear
>that supporting non-MPI jobs is worth the increased code complexity and
>In addition, the fact that we do not know if a job will call Init limits our
>ability to do collective communications within the RTE, and hence our
>scalability - see the note on that specific subject for further discussion
>on this area.
>This would be a "regression" in behavior, though, so the questions for the
>(a) do we want to retain the feature to run non-MPI jobs with mpirun as-is
>(and accept the tradeoffs, including the one described below in II)?
From a user standpoint, a) would be preferable. However, as you point
out, there are issues. Are you saying that we cannot do collectives
(Item III) if we preserve a? Or is it that things will just be more
complex. I guess I am looking for more details about what the tradeoffs
are for preserving a.
Having said that, we would probably be OK with b) if that makes things
>(b) do we provide a flag to mpirun (perhaps adding the distinction that
>"orterun" must be used for non-MPI jobs?) to indicate "this is NOT an MPI
>job" so we can act accordingly?
>(c) simply eliminate support for non-MPI jobs?
>(d) other suggestions?
>devel mailing list