Mike: exactly. That's about where our conversation ended circa 2 years ago. IIRC I was told along the lines that it was not supported, and i pointed out that MPI standard  recommends (if not requires) this way of doing things. I figured 3.3 is now getting closer to release now that i try to see if something has changed for it, but I guess I have to assume the developing parties are not interested in that user experience themselves, so I just have to conclude that nothing unfortunately for me has  changed in that regard since 3.2 in terms of UI experience.

Which is a shame really, because this is one of the easiest ways for integrating 3rd party process management including 3rd party clouds, containers, resource managers etc. etc. 

On Sat, Mar 3, 2018 at 2:30 PM, <Michael.Stokes@uah.edu> wrote:
Dmitriy,

I've written a server and client code example and compiled it using MPICH 3.2 using MPI_Comm_{accept,connect}() to see if MPICH 3.2 will form a intercommunicator between the two processes without using a launcher {mpiexec,mpirun}.  Before I started, I read the instructions ( MPI Specs 3.1 section 10.5.2). It states

"A high-quality implementation will allow any process (including those not started with a
“parallel application” mechanism) to become an MPI process by calling MPI_INIT. Such
a process can then connect to other MPI processes using the MPI_COMM_ACCEPT and
MPI_COMM_CONNECT routines, or spawn other MPI processes. MPI does not mandate
this behavior, but strongly encourages it where technically feasible."

Case 1) With the server and client run directly from the command-line the server executes down to the MPI_Comm_accept() call as anticipated, but when the port name is entered into the client process, it dies on MPI_Comm_connect() with the error ...

match_arg (utils/args/args.c:159): unrecognized argument pmi_args
[mpiexec@Que] HYDU_parse_array (utils/args/args.c:174): argument matching returned error
[mpiexec@Que] parse_args (ui/mpich/utils.c:1596): error parsing input array
[mpiexec@Que] HYD_uii_mpx_get_parameters (ui/mpich/utils.c:1648): unable to parse user arguments
[mpiexec@Que] main (ui/mpich/mpiexec.c:153): error parsing parameters

Case 2) When I run the server directly from the command-line and launch the client using mpirun, the same sort of error messages emerge but this time from the server.  Since the server blocks on the accept() call, the client must be successful in sending something to the server.  But apparently not what it is expecting.

So my conclusion is that MPICH is attempting to support the Singleton process, but either has a bug or there might be an installation issue on my end.

Hopefully someone can help sort this.

--Mike


_______________________________________________
discuss mailing list     discuss@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss