[MPICH] MIPICH2 and Windows MFC GUIs

[David Ashton]

Peter,

There are two ways to access GUIs using MPICH2.

1) Use the -localroot option to mpiexec.  This will cause processes on the
local host to be launched from a sub-process of mpiexec.  The result of this
option is that processes on the host where mpiexec is run will be able to
create GUIs that the user can interact with.  The limitation is that
processes on remote nodes cannot create GUIs.

2) In order to create GUIs on remote machines the process manager, smpd,
must be started by hand on each node.
	a) You can log on to each machine and execute the following: "smpd
-stop" followed by "smpd -d 0".  This stops the process manager service and
then starts a local user-space copy with debugging output turned off.
	b) Or you can log on to each machine and start the process manager
using a different port than the one the smpd service uses.  Execute
something like this: "smpd -d 0 -port 10000"

Then with user-space smpd process managers running on all the nodes you can
start your job using mpiexec and all processes on all nodes will be able to
create visible GUIs.

For additional security when using option 2 you can specify a passphrase
other than the default by adding the "-phrase <some_pass_phrase>" to both
the smpd command lines and mpiexec commands.

The above solutions are mentioned in the "Runtime environment" section of
the "Windows Developer's Guide" in the documentation section of the MPICH2
homepage:
http://www.mcs.anl.gov/mpi/mpich2


I'm not sure what mean by your dll question.  By definition all dlls loaded
by a process live in that process space.  If you load a dll that makes MPI
calls you should make sure that that code makes use of the MPI_Initialized
and MPI_Finalized functions to make sure that MPI_Init and MPI_Finalize are
only called once and that no MPI calls are made after MPI_Finalize and that
no chaining is done - MPI_Init ... MPI_Finalize ... MPI_Init ...
MPI_Finalize is illegal.  You also have to make sure that all code that is
run either from the main process or a dll is compiled with the same version
of MPICH2.  If your dlls do not make MPI calls then none of this is a
problem.

-David Ashton

-----Original Message-----
From: owner-mpich-discuss at mcs.anl.gov
[mailto:owner-mpich-discuss at mcs.anl.gov] On Behalf Of peter_raeth at juno.com
Sent: Friday, March 31, 2006 11:54 AM
To: mpich-discuss at mcs.anl.gov
Subject: [MPICH] MIPICH2 and Windows MFC GUIs

Have been through the forum archive and went through a google search but did
not find anything on this topic. I am hoping that someone can give me some
pointers.

We have access to 3rd-party code that was written in Visual C++, using MFC
for GUI dialogs. It also generates DLLs depending on menu selections. Some
of these DLLs run a long time and we would like to use a cluster so that
additional resources can be added to the processing. The DLLs already use
shared memory so that best use is made of single-machine resources.

Using the typical console method for starting an mpiexec job, we can verify
that the code is running. But, none of the dialogs appear. We get only
console messages generated via printf.

Two questions:

1) How is it possible to start a Windows cluster job under MPICH2 so that
MFC GUI dialogs appear and are functional?

2) Does a DLL generated by a program started with also run under that MPICH2
session so that messages can be passed? If not, is there a way to make
something like that work?

Would appreciate some pointers to literature on this topic. Modifying the
code to replace MFC GUIs is not an option due to the size of the code base.

Thank you for any insights you can offer.


Best,

Peter.