Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: [OMPI devel] RTE issue I. Support for non-MPI jobs
From: Ralph H Castain (rhc_at_[hidden])
Date: 2007-12-04 10:11:54

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
community are:

(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)?

(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?