Connecting MUI applications with different starting commands

[j8asic]

How can two MUI-enabled applications connect with each other if they are not started at the same time (with same mpirun command)?

Second question would be: if one has a MUI-enabled application, is it possible to connect with some other application that is extended by a dynamically loaded plug-in (containing MUI communication code)?

[SLongshaw]

Hello, the fundamentals of MUI are needed here to answer both questions:

MUI is effectively a neat wrapper around complex scenarios involving multiple MPI comm worlds. Therefore when we create an MUI interface (or interfaces), the assumption is that this will happen via the default MPI comm world, MUI therefore provides a helper function to give you a new, local comm world to use in your application for all other MPI communications. This is the key requirement of the library, we have to be able to tell our application to use a new comm world to free up the default comm world for MUI.

The fact that MUI relies on the default comm world also tells us that, in order for applications to talk to each other, they need to be launched using the same MPMD mpirun command (i.e. mpirun -np 2 [app1] : -np 4 [app2] : -np 2 [app3] : ...) if they aren't then they won't share the same default comm world and so won't be able to see each other.

In terms of your second question, all of the above applies, so there is no reason you can't connect using an application extended by a library, as long as you are able to tell the original application to use a different MPI comm world and you are able to include the external library above the MPI_Init command within the application. Another option is if you can modify the data in the application by way of input/output routines (either by file or shared memory or if the application provides a user routine method) then you could write an external "proxy" application that embeds MUI and simply sends/receives the data on behalf of the application in question.

[j8asic]

Understood, thank you for the explanation!

• Could you please comment on "ease" of the alternative: is there a file-based communicator ready out-of-the-box to avoid MPI in any case? (Assume performance is not crucial...)
• I'm not familiar with sockets, but can TCP be used instead of MPI for the problem above, and what is the status of it? Also, the same question for shared memory (e.g. with Boost, Qt or some other implementation)?
• And finally, if I would like to implement some missing communicator (e.g. via shared memory), would it be a one/two classes to modify/add or changes are needed throughout the whole code?

[SLongshaw]

Hi,

At the moment MUI is entirely MPI based, that isn't to say there isn't scope for extending this.

The general concept of adding a new communication layer is already present in the library (i.e. when you create an interface you do so using a string in the format "protocol://domain_name/interface_name", at the moment protocol can only be "mpi" but you may have noticed there is an incomplete TCP implementation already, following the same pattern a file-based communication layer could be added or one that uses shared memory. The "comm_factory" creates instances of the correct type of communication class depending on this string, so absolutely extending the functionality of the code is possible. I'm not going to say that you can simply write a new communication layer class and it will just work, certainly the basic design is already there to support this but undoubtedly there will be changes needed to other parts of the code for unforeseen reasons.

One comment I would make though is to remember that MPI was primarily chosen as the communication layer in the first place as it is portable in nature and system agnostic. Underneath it automatically uses the best transport layer depending on the fabric you are using (i.e. infiniband, TCP/IP for ethernet, shared memory for local operations etc.) so if you can find a way to make it work for what you are doing then you are guaranteeing your coupled solution can be used in nearly any environment.

One final point, MUI (other than using the current RBF spatial interpolation in the dev branch which introduces a dependency on Eigen at the moment) is a stand-alone library, I would try and make any additional functionality you add stand-alone as well, one of the key features of the library is that it is stand-alone and header-only. If you add a dependency on Boost or Qt etc. then this will be removing this neat feature.

[j8asic]

Thank you for all the explanations!