My application (AVS/Express, a visualization tool) falls squarely into
this category. The main 'express' process (no relation to Parasoft,
btw) is started by the user and must be able to start MPI and/or
connect to a running MPI simulation (via client/server).
I currently do this by a terrible hack: I have express run a shell
script that runs mpirun which starts an MPI "master" process, which
does whatever spawning and/or connecting it needs to. That process,
and thus all the slaves, can only communicate with express by the
(non-MPI) "hack" protocol. This bogus architecture is necessary
because I can't make the express process into an MPI process.
I am basing a commercial product (the MPP version of AVS/Express) on
MPI, and I can tell you this is an important feature for me and my
I couldn't get to the meeting, but my understanding from talking with
Bill Saphir afterwards was that some folks thought the semantics would
be unclear if the implementation uses a daemon: what should the
behavior be if the singleton is started either before or after the
daemon (or should the singleton *start* the daemon)? I would be
satisfied with the restriction that MPI_Init() fails if the daemon is
not already running (or if MPI_Init() can't contact it for whatever
reason), same as the behavior in LAM now (I think, correct me if I'm
wrong LAM folks). I don't think this should be hard to implement, and
the idea seems pretty clear to me.
Please do reconsider it, as Andrew suggests!
-- Gary Oberbrunner firstname.lastname@example.org Advanced Visual Systems, Inc. http://www.avs.com/~garyo 300 Fifth Avenue (617)890-8192 x2133 TEL Waltham, MA 02154 (617)890-8287 FAX