October 2017 - mpiwg-tools - mailman3.cels.anl.gov

The path to decode MPI_T event buffers?
by Marc-Andre Hermanns 06 Oct '17

06 Oct '17

Hi all, regarding decoding copied MPI_T event buffers, I was wondering whether we could kill two birds with one stone and combine this with the design for the 'handle introspection' interface we initially thought for debuggers. After all, characteristics are similar in the sense that I need an interface to query structure and potentially some crude form of semantics (arrays, groups, ranks, ...) from a 'blob' or a memory address, respectively. One difference is though that event buffers may exist before and after MPI_Init and MPI_Finalize, respectively, but the normal handles (comm, file, win, ...) a debugger may want to decode do not. What do you think? Should we explore/design in this direction? Personally, I think if we come up with a common solution, we'd reduce the number of function calls needed to enable both approaches as well as the number of 'concepts' a user needs to understand. Cheers, Marc-Andre PS: I would like to postpone the actual work on such an interface until we have more progress our active proposals. I don't want to get tangled up in juggling too many large proposals at the same time. -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Max Sagebaum 06 Oct '17

06 Oct '17

Hello Jean-Baptiste, thanks for the pointer to the general requests. I did not yet had a look at them. I can carry my additional data in this data structure. But I am not quite sure about the overhead. In order to implement this, I need to tell mpi with grequest_complete, that the request is completed. Since I want to wrap the usual asynchronous requests this would yield the following layout: 1. Start grequest 2. start thread that executes the grequest 3. In the thread: I. start the regular request II. Wait until the regular request is finished III. Signal mpi that the grequest is complete 4. User calls Wait/Test etc. on the grequest 5. the free call performs the postprocessing (Needs to be performed in the main thread, otherwise race conditions need to be handled)(this might also be possible in the extra thread, but I need to look my main data structure, which introduces overheads on the whole application) With this implementation I would create a thread for each asynchronous MPI call. The threads would be idle. Can this have an impact on overall performance? I could imagine, that it is also possible to have a busy thread, that tests for all wrapped asynchronous requests. But the busy thread could slow down the performance of a cluster node quite strongly. Whats you opinion on this matter? Cheers Max On Thu, 2017-10-05 at 15:46 +0200, Jean-Baptiste BESNARD wrote: Hi Max, Thank you very much for these details, I must admit that I need a bit more time to fully understand the scenario :) However, considering that you want to « wrap » requests could the Generalized Request interface 12.2 in the standard (or the extended one which are also widespread because of their use by ROMIO) be of any use to create requests objects which are then pointing to your own requests through the extra state parameter ? For extended generalized requests see : http://www.mcs.anl.gov/uploads/cels/papers/P1417.pdf Thanks, Jean-Baptiste. Le 5 oct. 2017 à 15:25, Max Sagebaum <max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]>> a écrit : Hi @ all, thanks for all the input. From what I gather from the discussion, a 'classic' wrapper - as mentioned by Marc (wrap functions only, leave types intact) - is no problem to generate. I agree on that. For a complete Wrapper (wrap functions and redefine types) a new ABI needs to be defined. If I aim for the new ABI I will have look at the wi4mpi project since they have already done this. I could link to there "interface" mode. I will post a message to Marc and Marc-Andre and the wi4mpi list if I have any problems here. But before I would like to tell you a little bit more about the why as Marc-Andre, has rightfully ask for. We are doing Algorithmic Differentiation which has three consequences for MPI communication: - We need to store data for each MPI communication such as MPI_Send, Recv , etc. - Buffers need to be pre- and postprocessed - For each MPI communication there is a reverse communication. The pre- and postprocessing part is the problematic bit. We need to do it, since we are using new structures to represent the floating point types. This can be for example: struct AReal { double value; int index; }; In this example the prostprocessing requires the index to be adapted to the new machine, since the index is kind of a pointer for AD. So after the buffer is received the index of all AReal types needs to be renewed. If I do this for a MPI_Recv, there are no problems since I can do everything inside of the routine. If a MPI_Irecv is called, I can only modify the buffer after the Request is finished (e.g. in the Wait call). My design is now to define a new request: struct AMPI_Request { void* data; Func func; MPI_Request request; } My implementation of wait would then be, int AMPI_Wait(AMPI_Request* request) { int r = PMPI_Wait(request->request); request->func(request->data); // perform the post processing } Because of the structre AMPI_Request I need to include mpi.h to have the original MPI_Request available and I need to modify all function where MPI_Request is used. The same techniques is used so far for MPI_Op and MPI_Datatype. I hope this explains, why I would like to have PMPI definitions for MPI_Request, MPI_Datatype, etc. I can still change the design of my implementation, so I am also open for pointers how to avoid the redefinition of MPI_Request. Cheers Max On Wed, 2017-10-04 at 16:22 +0000, Marc.PERACHE(a)CEA.FR<mailto:[email protected]> wrote: Hi Max, As Marc-André said wi4mpi was designed to avoid the recompilation phase of large applications required each time you need to change the underlying MPI implementation. Basically, wi4mpi allows to change the internal representation of all MPI type declared in the mpi.h without recompiling the application in "preload" mode. Wi4mpi provides also its own MPI interface and translate types to the underlying MPI implementation in "interface" mode. In "interface" mode, you'll have to recompile your application. Currently, wi4mpi supports bi-directional ABI conversion for OpenMPI, MPICH, IntelMPI, MPI Spectrum, wi4mpi ABI. By the end of the year we will add the MPC ABI. If I understand correctly what you want to do, wi4mpi can provide the glue between your API (i.e. enriched MPI types) used by the application and the underlying MPI implementation. In this case, you'll have to recompile your application but it doesn't require code modification in the application. If you want to avoid application recompilation you'll need to modify wi4mpi internals. If you have questions on wi4mpi, we should take this off the list and keep everyone else in CC. Regards, Marc -----Message d'origine----- De : Marc-Andre Hermanns [mailto:[email protected]] Envoyé : mercredi 4 octobre 2017 15:51 À : mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]>; Max Sagebaum Cc : PERACHE Marc 600952 Objet : Re: [mpiwg-tools] PMPI for a complete MPI wrapper Hi Max, thanks for the fast answer. With the pmpi.h I mean a file like mpi.h but only containing the PMPI_ Interface. As you suggested I might try to create a full wrapper myself. I took a look on the wi4mpi project and there approach seems to create there own interface aka. mpi.h and then wrap this to the intel MPI or OpenMPI implementation. Due to this approach, they know the data types and can generate the interface. For the wi4mpi project, Jean-Baptiste and people from CEA may be the right people to talk to. The wi4mpi is a bit of a special project, as it is provides a software 'glue' to make MPI implementations interchangeable. It is a way to overcome the missing ABI (i.e., a specification of types, etc.). Usually, the users will have to recompile their application every time they choose a different MPI (potentially also when using a different version of the same MPI), as values and types in the mpi.h may have changed. For large simulation codes, this can take a long time. When you have a translating 'glue' like wi4mpi in between, you can swap MPI implementations via LD_PRELOAD at the start time of the application. I don't know enough about wi4mpi to really know what their goal is: Have a mixed MPI run (e.g., couple two codes compiled against differnt MPIs)? Use a library compiled for one MPI together with an application compiled against another? Just make it easier for users to link against the right MPI? All of the above? @Marc? Any comments on what the design goal of wi4mpi is? Does it support other MPI implementations beside Intel-MPI and Open-MPI? (If this discussion drifts more towards 'wi4mpi' specifics, we should take this off the list and keep everyone else in CC) In my library I wanted to use a light wight wrapper. That is I wanted to use the original data types. With this approach I currently have structures like: struct AMPI_Comm { // my own data; MPI_Comm comm; // the original object }; I can then simply call the pmpi functions with the stored original object. If I have a wrapper such that there is a PMPI_Comm object available, I could do the following: struct MPI_Comm { // my own data; PMPI_Comm comm; // the original object }; If the wrapper should use the same types from a general mpi.h, then I do not know the types and would need to declare something like: hidden_mpi.c #include <mpi.h> decltype(MPI_COMM_WORLD) PMPI_COMM_WORLD = MPI_COMM_WORLD; and then I need to use PMPI_COMM_WORLD in my library and I can generate a hmpi.h wich contains lines like: #define MPI_COMM_WORLD PMPI_COMM_WORLD Which could be included by the user. But in order use PMPI_* in my library, I need to specify the symbol in a header file for which I need the type. In order to get the type I need to include mpi.h which will define MPI_COMM_WORLD and I have a name clash. mpi.h only _declares_ the prototype. It does not define anything (apart from CPP macros, etc.). If you provide your own types, then you will need to declare your own prototypes, which I would generate (see below). So unfortunately I see no way in providing a wrapper without writing a complete MPI Interface, which I would like to avoid. I might be able to use the wi4mpi Project and use there interface as a base for my implementation, which would add a dependency to my project. For just a 'classic' wrapper, you just need to provide the definition (implementation) of the function you want to replace, adhering to the declared (in mpi.h) function prototype. A third and very ugly option would be, that I define all my types as void* in the interface for the user. But this disables type checking and I still would need to wrap from void* to references of my types. So I might just stay in my AMPI namespace and provide a macro for the user to either call regular mpi functions or my wrapper functions. If you need 'classic' wrappers for your project, you might consider generating that code with a generator like 'wrap' [2]. As I mentioned in my other mail, writing a 'classic' wrapper is straight forward. Cheers, Marc-Andre [2] https://github.com/LLNL/wrap On Wed, 2017-10-04 at 11:00 +0200, Jean-Baptiste BESNARD wrote: Dear Max, I’m not sure I completely understand what you mean by a « pmpi.h » however I may have some initial elements below. The PMPI interface is currently targeting MPI functions only and indeed some of the values you’ll find in your executable will be compile time constants. In fact, most MPI types/Constants are implementation dependent, there is no unified ABI. Nonetheless, you might be able to interpret them in your wrapper library in order to have them « rerouted » to your target implementation. I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to be MPI_COMM_WORLD2. And for sure you wont’t find a PMPI_COMM_WORLD. I can help on writing a wrapper for the whole PMPI interface. See my repo here: https://github.com/besnardjb/mpi-snippets There is a simple python script generating VIM snippets for MPI from JSON specs, it can easily be converted to a script generating the whole MPI interface. Eventually, an approach close to what you want to do might be https://github.com/cea-hpc/wi4mpi which operates this systematic handler conversion between MPI flavors, but this clearly involves some rewriting. Hope this helps. Regards, Jean-Baptiste. Le 4 oct. 2017 à 10:35, Max Sagebaum <max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> <mailto:[email protected]>> a écrit : Hello @ all, my question is concerning the PMPI specification. I hope the list is the correct place to ask. I want to write a complete wrapper for MPI. That is every define, typedef and function will be wrapped and might be completely changed. Currently I prefixed everything with AMPI_ such that no name clashes exist. But the user would need to rename every occurrence of MPI_ with AMPI_ I would now like to use the PMPI definition of MPI to define my wrappers as the MPI version which then use the PMPI definitions. Unfortunately I could not find tutorials for a complete wrapper. As an example take MPI_COMM_WORLD. I made a grep on the openmpi installation on my linux machine for PMPI_COMM_WORLD but the result was empty. The definition of MPI_COMM_WORLD was #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world) without any chance to switch to PMPI_COMM_WORLD as a predefined macro. I also checked the newest source tarball of openmpi and I could not find anything for PMPI_COMM_WORLD there. In the mpi 3.0 standard on page 555 in section 14.2.1 the requirements are just listed for functions. Was the definition of the PMPI_ supplements for defines, types etc. never discussed? I would have expected, that I can just include a pmpi.h and then I would have all the PMPI_ symbols without the MPI symbols available. Do you know of any way I could make my idea work? Cheers Max -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> <mailto:[email protected]> URL: www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de/> <http://www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de/>> _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> URL: www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de/> _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de URL: www.scicomp.uni-kl.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Jean-Baptiste BESNARD 05 Oct '17

05 Oct '17

Hi Max, Thank you very much for these details, I must admit that I need a bit more time to fully understand the scenario :) However, considering that you want to « wrap » requests could the Generalized Request interface 12.2 in the standard (or the extended one which are also widespread because of their use by ROMIO) be of any use to create requests objects which are then pointing to your own requests through the extra state parameter ? For extended generalized requests see : http://www.mcs.anl.gov/uploads/cels/papers/P1417.pdf Thanks, Jean-Baptiste. > Le 5 oct. 2017 à 15:25, Max Sagebaum <max.sagebaum(a)scicomp.uni-kl.de> a écrit : > > Hi @ all, > > thanks for all the input. From what I gather from the discussion, a 'classic' wrapper - as mentioned by Marc (wrap functions only, leave types intact) - is no problem to generate. I agree on that. > For a complete Wrapper (wrap functions and redefine types) a new ABI needs to be defined. > > If I aim for the new ABI I will have look at the wi4mpi project since they have already done this. I could link to there "interface" mode. I will post a message to Marc and Marc-Andre and the wi4mpi list if I have any problems here. > > But before I would like to tell you a little bit more about the why as Marc-Andre, has rightfully ask for. > > We are doing Algorithmic Differentiation which has three consequences for MPI communication: > - We need to store data for each MPI communication such as MPI_Send, Recv , etc. > - Buffers need to be pre- and postprocessed > - For each MPI communication there is a reverse communication. > > The pre- and postprocessing part is the problematic bit. We need to do it, since we are using new structures to represent the floating point types. > This can be for example: > struct AReal { > double value; > int index; > }; > > In this example the prostprocessing requires the index to be adapted to the new machine, since the index is kind of a pointer for AD. So after the buffer is received the index of all AReal types needs to be renewed. > If I do this for a MPI_Recv, there are no problems since I can do everything inside of the routine. > If a MPI_Irecv is called, I can only modify the buffer after the Request is finished (e.g. in the Wait call). My design is now to define a new request: > struct AMPI_Request { > void* data; > Func func; > MPI_Request request; > } > > My implementation of wait would then be, > int AMPI_Wait(AMPI_Request* request) { > int r = PMPI_Wait(request->request); > > request->func(request->data); // perform the post processing > } > > Because of the structre AMPI_Request I need to include mpi.h to have the original MPI_Request available and I need to modify all function where MPI_Request is used. > The same techniques is used so far for MPI_Op and MPI_Datatype. > > I hope this explains, why I would like to have PMPI definitions for MPI_Request, MPI_Datatype, etc. > > I can still change the design of my implementation, so I am also open for pointers how to avoid the redefinition of MPI_Request. > > Cheers > > Max > > On Wed, 2017-10-04 at 16:22 +0000, Marc.PERACHE(a)CEA.FR wrote: >> Hi Max, >> >> As Marc-André said wi4mpi was designed to avoid the recompilation phase of large applications required each time you need to change the underlying MPI implementation. Basically, wi4mpi allows to change the internal representation of all MPI type declared in the mpi.h without recompiling the application in "preload" mode. Wi4mpi provides also its own MPI interface and translate types to the underlying MPI implementation in "interface" mode. In "interface" mode, you'll have to recompile your application. Currently, wi4mpi supports bi-directional ABI conversion for OpenMPI, MPICH, IntelMPI, MPI Spectrum, wi4mpi ABI. By the end of the year we will add the MPC ABI. >> >> If I understand correctly what you want to do, wi4mpi can provide the glue between your API (i.e. enriched MPI types) used by the application and the underlying MPI implementation. In this case, you'll have to recompile your application but it doesn't require code modification in the application. If you want to avoid application recompilation you'll need to modify wi4mpi internals. If you have questions on wi4mpi, we should take this off the list and keep everyone else in CC. >> >> Regards, >> Marc >> >> -----Message d'origine----- >> De : Marc-Andre Hermanns [mailto:[email protected] <mailto:[email protected]>] >> Envoyé : mercredi 4 octobre 2017 15:51 >> À : mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]>; Max Sagebaum >> Cc : PERACHE Marc 600952 >> Objet : Re: [mpiwg-tools] PMPI for a complete MPI wrapper >> >> Hi Max, >> >>> >>> thanks for the fast answer. With the pmpi.h I mean a file like mpi.h >>> but only containing the PMPI_ Interface. As you suggested I might try >>> to create a full wrapper myself. I took a look on the wi4mpi project >>> and there approach seems to create there own interface aka. mpi.h and >>> then wrap this to the intel MPI or OpenMPI implementation. Due to this >>> approach, they know the data types and can generate the interface. >> >> >> For the wi4mpi project, Jean-Baptiste and people from CEA may be the >> right people to talk to. >> >> The wi4mpi is a bit of a special project, as it is provides a software >> 'glue' to make MPI implementations interchangeable. It is a way to >> overcome the missing ABI (i.e., a specification of types, etc.). >> >> Usually, the users will have to recompile their application every time >> they choose a different MPI (potentially also when using a different >> version of the same MPI), as values and types in the mpi.h may have >> changed. For large simulation codes, this can take a long time. When >> you have a translating 'glue' like wi4mpi in between, you can swap MPI >> implementations via LD_PRELOAD at the start time of the application. >> >> I don't know enough about wi4mpi to really know what their goal is: >> Have a mixed MPI run (e.g., couple two codes compiled against differnt >> MPIs)? Use a library compiled for one MPI together with an application >> compiled against another? Just make it easier for users to link >> against the right MPI? All of the above? >> >> @Marc? Any comments on what the design goal of wi4mpi is? Does it >> support other MPI implementations beside Intel-MPI and Open-MPI? >> >> (If this discussion drifts more towards 'wi4mpi' specifics, we should >> take this off the list and keep everyone else in CC) >> >>> >>> In my library I wanted to use a light wight wrapper. That is I wanted >>> to use the original data types. With this approach I currently have >>> structures like: >>> >>> struct AMPI_Comm { >>> // my own data; >>> MPI_Comm comm; // the original object >>> }; >>> >>> I can then simply call the pmpi functions with the stored original >>> object. >>> If I have a wrapper such that there is a PMPI_Comm object available, I >>> could do the following: >>> struct MPI_Comm { >>> // my own data; >>> PMPI_Comm comm; // the original object >>> }; >>> >>> If the wrapper should use the same types from a general mpi.h, then I >>> do not know the types and would need to declare something like: >>> >>> hidden_mpi.c >>> #include <mpi.h> >>> decltype(MPI_COMM_WORLD) PMPI_COMM_WORLD = MPI_COMM_WORLD; >>> >>> and then I need to use PMPI_COMM_WORLD in my library and I can >>> generate a hmpi.h wich contains lines like: >>> #define MPI_COMM_WORLD PMPI_COMM_WORLD >>> >>> Which could be included by the user. But in order use PMPI_* in my >>> library, I need to specify the symbol in a header file for which I >>> need the type. In order to get the type I need to include mpi.h which >>> will define MPI_COMM_WORLD and I have a name clash. >> >> >> mpi.h only _declares_ the prototype. It does not define anything >> (apart from CPP macros, etc.). >> >> If you provide your own types, then you will need to declare your own >> prototypes, which I would generate (see below). >> >>> >>> So unfortunately I see no way in providing a wrapper without writing a >>> complete MPI Interface, which I would like to avoid. I might be able >>> to use the wi4mpi Project and use there interface as a base for my >>> implementation, which would add a dependency to my project. >> >> >> For just a 'classic' wrapper, you just need to provide the definition >> (implementation) of the function you want to replace, adhering to the >> declared (in mpi.h) function prototype. >> >>> >>> A third and very ugly option would be, that I define all my types as >>> void* in the interface for the user. But this disables type checking >>> and I still would need to wrap from void* to references of my types. >>> >>> So I might just stay in my AMPI namespace and provide a macro for the >>> user to either call regular mpi functions or my wrapper functions. >> >> >> If you need 'classic' wrappers for your project, you might consider >> generating that code with a generator like 'wrap' [2]. >> >> As I mentioned in my other mail, writing a 'classic' wrapper is >> straight forward. >> >> Cheers, >> Marc-Andre >> >> >> [2] https://github.com/LLNL/wrap <https://github.com/LLNL/wrap> >> >>> >>> On Wed, 2017-10-04 at 11:00 +0200, Jean-Baptiste BESNARD wrote: >>>> >>>> Dear Max, >>>> >>>> I’m not sure I completely understand what you mean by a « pmpi.h » >>>> however I may have some initial elements below. >>>> >>>> The PMPI interface is currently targeting MPI functions only and >>>> indeed some of the values you’ll find in your executable will be >>>> compile time constants. >>>> In fact, most MPI types/Constants are implementation dependent, >>>> there is no unified ABI. >>>> >>>> Nonetheless, you might be able to interpret them in your wrapper >>>> library in order to have them « rerouted » to your target >>>> implementation. >>>> I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to >>>> be MPI_COMM_WORLD2. >>>> And for sure you wont’t find a PMPI_COMM_WORLD. >>>> >>>> I can help on writing a wrapper for the whole PMPI interface. See my >>>> repo here: https://github.com/besnardjb/mpi-snippets <https://github.com/besnardjb/mpi-snippets> >>>> There is a simple python script generating VIM snippets for MPI from >>>> JSON specs, it can easily be converted to a script generating the >>>> whole MPI interface. >>>> >>>> Eventually, an approach close to what you want to do might >>>> be https://github.com/cea-hpc/wi4mpi <https://github.com/cea-hpc/wi4mpi> which operates this systematic >>>> handler conversion between MPI flavors, but this clearly involves >>>> some rewriting. >>>> >>>> Hope this helps. >>>> >>>> Regards, >>>> >>>> Jean-Baptiste. >>>> >>>>> >>>>> Le 4 oct. 2017 à 10:35, Max Sagebaum >>>>> <max.sagebaum(a)scicomp.uni-kl.de <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>>> a écrit : >>>>> Hello @ all, >>>>> >>>>> my question is concerning the PMPI specification. I hope the list >>>>> is the correct place to ask. >>>>> >>>>> I want to write a complete wrapper for MPI. That is every define, >>>>> typedef and function will be wrapped and might be completely >>>>> changed. Currently I prefixed everything with AMPI_ such that no >>>>> name clashes exist. But the user would need to rename every >>>>> occurrence of MPI_ with AMPI_ >>>>> >>>>> I would now like to use the PMPI definition of MPI to define my >>>>> wrappers as the MPI version which then use the PMPI definitions. >>>>> Unfortunately I could not find tutorials for a complete wrapper. >>>>> >>>>> As an example take MPI_COMM_WORLD. I made a grep on the openmpi >>>>> installation on my linux machine for PMPI_COMM_WORLD but the result >>>>> was empty. The definition of MPI_COMM_WORLD was >>>>> #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, >>>>> ompi_mpi_comm_world) >>>>> without any chance to switch to PMPI_COMM_WORLD as a predefined macro. >>>>> >>>>> I also checked the newest source tarball of openmpi and I could not >>>>> find anything for PMPI_COMM_WORLD there. >>>>> >>>>> In the mpi 3.0 standard on page 555 in section 14.2.1 the >>>>> requirements are just listed for functions. Was the definition of >>>>> the PMPI_ supplements for defines, types etc. never discussed? >>>>> >>>>> I would have expected, that I can just include a pmpi.h and then I >>>>> would have all the PMPI_ symbols without the MPI symbols available. >>>>> >>>>> Do you know of any way I could make my idea work? >>>>> >>>>> Cheers >>>>> >>>>> Max >>>>> >>>>> -- >>>>> Max Sagebaum >>>>> >>>>> Chair for Scientific Computing, >>>>> TU Kaiserslautern, >>>>> Bldg/Geb 34, Paul-Ehrlich-Strasse, >>>>> 67663 Kaiserslautern, Germany >>>>> >>>>> Phone: +49 (0)631 205 5638 >>>>> Fax: +49 (0)631 205 3056 >>>>> Email: max.sagebaum(a)scicomp.uni-kl.de <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >>>>> URL: www.scicomp.uni-kl.de <http://www.scicomp.uni-kl.de/> <http://www.scicomp.uni-kl.de <http://www.scicomp.uni-kl.de/>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools> >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools> >>> >>> >>> -- >>> >>> Max Sagebaum >>> >>> Chair for Scientific Computing, >>> TU Kaiserslautern, >>> Bldg/Geb 34, Paul-Ehrlich-Strasse, >>> 67663 Kaiserslautern, Germany >>> >>> Phone: +49 (0)631 205 5638 >>> Fax: +49 (0)631 205 3056 >>> Email: max.sagebaum(a)scicomp.uni-kl.de <mailto:[email protected]> >>> URL: www.scicomp.uni-kl.de <http://www.scicomp.uni-kl.de/> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools> >>> >> >> >> -- >> Marc-Andre Hermanns >> Jülich Aachen Research Alliance, >> High Performance Computing (JARA-HPC) >> Jülich Supercomputing Centre (JSC) >> >> Wilhelm-Johnen-Str. >> 52425 Jülich >> Germany >> >> Phone: +49 2461 61 2509 | +49 241 80 24381 >> Fax: +49 2461 80 6 99753 >> www.jara.org/jara-hpc <http://www.jara.org/jara-hpc> >> email: hermanns(a)jara.rwth-aachen.de <mailto:[email protected]> >> > -- > Max Sagebaum > > Chair for Scientific Computing, > TU Kaiserslautern, > Bldg/Geb 34, Paul-Ehrlich-Strasse, > 67663 Kaiserslautern, Germany > > Phone: +49 (0)631 205 5638 > Fax: +49 (0)631 205 3056 > Email: max.sagebaum(a)scicomp.uni-kl.de > URL: www.scicomp.uni-kl.de > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Max Sagebaum 05 Oct '17

05 Oct '17

Hi @ all, thanks for all the input. From what I gather from the discussion, a 'classic' wrapper - as mentioned by Marc (wrap functions only, leave types intact) - is no problem to generate. I agree on that. For a complete Wrapper (wrap functions and redefine types) a new ABI needs to be defined. If I aim for the new ABI I will have look at the wi4mpi project since they have already done this. I could link to there "interface" mode. I will post a message to Marc and Marc-Andre and the wi4mpi list if I have any problems here. But before I would like to tell you a little bit more about the why as Marc-Andre, has rightfully ask for. We are doing Algorithmic Differentiation which has three consequences for MPI communication: - We need to store data for each MPI communication such as MPI_Send, Recv , etc. - Buffers need to be pre- and postprocessed - For each MPI communication there is a reverse communication. The pre- and postprocessing part is the problematic bit. We need to do it, since we are using new structures to represent the floating point types. This can be for example: struct AReal { double value; int index; }; In this example the prostprocessing requires the index to be adapted to the new machine, since the index is kind of a pointer for AD. So after the buffer is received the index of all AReal types needs to be renewed. If I do this for a MPI_Recv, there are no problems since I can do everything inside of the routine. If a MPI_Irecv is called, I can only modify the buffer after the Request is finished (e.g. in the Wait call). My design is now to define a new request: struct AMPI_Request { void* data; Func func; MPI_Request request; } My implementation of wait would then be, int AMPI_Wait(AMPI_Request* request) { int r = PMPI_Wait(request->request); request->func(request->data); // perform the post processing } Because of the structre AMPI_Request I need to include mpi.h to have the original MPI_Request available and I need to modify all function where MPI_Request is used. The same techniques is used so far for MPI_Op and MPI_Datatype. I hope this explains, why I would like to have PMPI definitions for MPI_Request, MPI_Datatype, etc. I can still change the design of my implementation, so I am also open for pointers how to avoid the redefinition of MPI_Request. Cheers Max On Wed, 2017-10-04 at 16:22 +0000, Marc.PERACHE(a)CEA.FR wrote: Hi Max, As Marc-André said wi4mpi was designed to avoid the recompilation phase of large applications required each time you need to change the underlying MPI implementation. Basically, wi4mpi allows to change the internal representation of all MPI type declared in the mpi.h without recompiling the application in "preload" mode. Wi4mpi provides also its own MPI interface and translate types to the underlying MPI implementation in "interface" mode. In "interface" mode, you'll have to recompile your application. Currently, wi4mpi supports bi-directional ABI conversion for OpenMPI, MPICH, IntelMPI, MPI Spectrum, wi4mpi ABI. By the end of the year we will add the MPC ABI. If I understand correctly what you want to do, wi4mpi can provide the glue between your API (i.e. enriched MPI types) used by the application and the underlying MPI implementation. In this case, you'll have to recompile your application but it doesn't require code modification in the application. If you want to avoid application recompilation you'll need to modify wi4mpi internals. If you have questions on wi4mpi, we should take this off the list and keep everyone else in CC. Regards, Marc -----Message d'origine----- De : Marc-Andre Hermanns [mailto:[email protected]] Envoyé : mercredi 4 octobre 2017 15:51 À : mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]>; Max Sagebaum Cc : PERACHE Marc 600952 Objet : Re: [mpiwg-tools] PMPI for a complete MPI wrapper Hi Max, thanks for the fast answer. With the pmpi.h I mean a file like mpi.h but only containing the PMPI_ Interface. As you suggested I might try to create a full wrapper myself. I took a look on the wi4mpi project and there approach seems to create there own interface aka. mpi.h and then wrap this to the intel MPI or OpenMPI implementation. Due to this approach, they know the data types and can generate the interface. For the wi4mpi project, Jean-Baptiste and people from CEA may be the right people to talk to. The wi4mpi is a bit of a special project, as it is provides a software 'glue' to make MPI implementations interchangeable. It is a way to overcome the missing ABI (i.e., a specification of types, etc.). Usually, the users will have to recompile their application every time they choose a different MPI (potentially also when using a different version of the same MPI), as values and types in the mpi.h may have changed. For large simulation codes, this can take a long time. When you have a translating 'glue' like wi4mpi in between, you can swap MPI implementations via LD_PRELOAD at the start time of the application. I don't know enough about wi4mpi to really know what their goal is: Have a mixed MPI run (e.g., couple two codes compiled against differnt MPIs)? Use a library compiled for one MPI together with an application compiled against another? Just make it easier for users to link against the right MPI? All of the above? @Marc? Any comments on what the design goal of wi4mpi is? Does it support other MPI implementations beside Intel-MPI and Open-MPI? (If this discussion drifts more towards 'wi4mpi' specifics, we should take this off the list and keep everyone else in CC) In my library I wanted to use a light wight wrapper. That is I wanted to use the original data types. With this approach I currently have structures like: struct AMPI_Comm { // my own data; MPI_Comm comm; // the original object }; I can then simply call the pmpi functions with the stored original object. If I have a wrapper such that there is a PMPI_Comm object available, I could do the following: struct MPI_Comm { // my own data; PMPI_Comm comm; // the original object }; If the wrapper should use the same types from a general mpi.h, then I do not know the types and would need to declare something like: hidden_mpi.c #include <mpi.h> decltype(MPI_COMM_WORLD) PMPI_COMM_WORLD = MPI_COMM_WORLD; and then I need to use PMPI_COMM_WORLD in my library and I can generate a hmpi.h wich contains lines like: #define MPI_COMM_WORLD PMPI_COMM_WORLD Which could be included by the user. But in order use PMPI_* in my library, I need to specify the symbol in a header file for which I need the type. In order to get the type I need to include mpi.h which will define MPI_COMM_WORLD and I have a name clash. mpi.h only _declares_ the prototype. It does not define anything (apart from CPP macros, etc.). If you provide your own types, then you will need to declare your own prototypes, which I would generate (see below). So unfortunately I see no way in providing a wrapper without writing a complete MPI Interface, which I would like to avoid. I might be able to use the wi4mpi Project and use there interface as a base for my implementation, which would add a dependency to my project. For just a 'classic' wrapper, you just need to provide the definition (implementation) of the function you want to replace, adhering to the declared (in mpi.h) function prototype. A third and very ugly option would be, that I define all my types as void* in the interface for the user. But this disables type checking and I still would need to wrap from void* to references of my types. So I might just stay in my AMPI namespace and provide a macro for the user to either call regular mpi functions or my wrapper functions. If you need 'classic' wrappers for your project, you might consider generating that code with a generator like 'wrap' [2]. As I mentioned in my other mail, writing a 'classic' wrapper is straight forward. Cheers, Marc-Andre [2] https://github.com/LLNL/wrap On Wed, 2017-10-04 at 11:00 +0200, Jean-Baptiste BESNARD wrote: Dear Max, I’m not sure I completely understand what you mean by a « pmpi.h » however I may have some initial elements below. The PMPI interface is currently targeting MPI functions only and indeed some of the values you’ll find in your executable will be compile time constants. In fact, most MPI types/Constants are implementation dependent, there is no unified ABI. Nonetheless, you might be able to interpret them in your wrapper library in order to have them « rerouted » to your target implementation. I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to be MPI_COMM_WORLD2. And for sure you wont’t find a PMPI_COMM_WORLD. I can help on writing a wrapper for the whole PMPI interface. See my repo here: https://github.com/besnardjb/mpi-snippets There is a simple python script generating VIM snippets for MPI from JSON specs, it can easily be converted to a script generating the whole MPI interface. Eventually, an approach close to what you want to do might be https://github.com/cea-hpc/wi4mpi which operates this systematic handler conversion between MPI flavors, but this clearly involves some rewriting. Hope this helps. Regards, Jean-Baptiste. Le 4 oct. 2017 à 10:35, Max Sagebaum <max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> <mailto:[email protected]>> a écrit : Hello @ all, my question is concerning the PMPI specification. I hope the list is the correct place to ask. I want to write a complete wrapper for MPI. That is every define, typedef and function will be wrapped and might be completely changed. Currently I prefixed everything with AMPI_ such that no name clashes exist. But the user would need to rename every occurrence of MPI_ with AMPI_ I would now like to use the PMPI definition of MPI to define my wrappers as the MPI version which then use the PMPI definitions. Unfortunately I could not find tutorials for a complete wrapper. As an example take MPI_COMM_WORLD. I made a grep on the openmpi installation on my linux machine for PMPI_COMM_WORLD but the result was empty. The definition of MPI_COMM_WORLD was #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world) without any chance to switch to PMPI_COMM_WORLD as a predefined macro. I also checked the newest source tarball of openmpi and I could not find anything for PMPI_COMM_WORLD there. In the mpi 3.0 standard on page 555 in section 14.2.1 the requirements are just listed for functions. Was the definition of the PMPI_ supplements for defines, types etc. never discussed? I would have expected, that I can just include a pmpi.h and then I would have all the PMPI_ symbols without the MPI symbols available. Do you know of any way I could make my idea work? Cheers Max -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> <mailto:[email protected]> URL: www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de> <http://www.scicomp.uni-kl.de> _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> URL: www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de> _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc<http://www.jara.org/jara-hpc> email: hermanns(a)jara.rwth-aachen.de<mailto:[email protected]> -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de URL: www.scicomp.uni-kl.de

1 0

Meeting reminder: Oct 5, 2017
by Marc-Andre Hermanns 04 Oct '17

04 Oct '17

Dear all, this is you meeting reminder for our conference call tomorrow October 5, 2017 at 11 am EST. As usual, you find the meeting details here: https://apps.fz-juelich.de/scalasca/mpiwg-tools-webex/ To be honest, I am not quite sure, whether is is PMPI2 or MPI_T events week, so I put both on the agenda. I started to write down some text for MPI_T events, but didn't push anything to Github yet. Will do before the call. Agenda: - Update from the face-to-face meeting (tickets, discussion, etc.) - PMPI2 discussion (if Martin is there, and ready to continue) - MPI_T events (if there is time) Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Marc.PERACHE＠CEA.FR 04 Oct '17

04 Oct '17

Hi Max, As Marc-André said wi4mpi was designed to avoid the recompilation phase of large applications required each time you need to change the underlying MPI implementation. Basically, wi4mpi allows to change the internal representation of all MPI type declared in the mpi.h without recompiling the application in "preload" mode. Wi4mpi provides also its own MPI interface and translate types to the underlying MPI implementation in "interface" mode. In "interface" mode, you'll have to recompile your application. Currently, wi4mpi supports bi-directional ABI conversion for OpenMPI, MPICH, IntelMPI, MPI Spectrum, wi4mpi ABI. By the end of the year we will add the MPC ABI. If I understand correctly what you want to do, wi4mpi can provide the glue between your API (i.e. enriched MPI types) used by the application and the underlying MPI implementation. In this case, you'll have to recompile your application but it doesn't require code modification in the application. If you want to avoid application recompilation you'll need to modify wi4mpi internals. If you have questions on wi4mpi, we should take this off the list and keep everyone else in CC. Regards, Marc -----Message d'origine----- De : Marc-Andre Hermanns [mailto:[email protected]] Envoyé : mercredi 4 octobre 2017 15:51 À : mpiwg-tools(a)lists.mpi-forum.org; Max Sagebaum Cc : PERACHE Marc 600952 Objet : Re: [mpiwg-tools] PMPI for a complete MPI wrapper Hi Max, > thanks for the fast answer. With the pmpi.h I mean a file like mpi.h > but only containing the PMPI_ Interface. As you suggested I might try > to create a full wrapper myself. I took a look on the wi4mpi project > and there approach seems to create there own interface aka. mpi.h and > then wrap this to the intel MPI or OpenMPI implementation. Due to this > approach, they know the data types and can generate the interface. For the wi4mpi project, Jean-Baptiste and people from CEA may be the right people to talk to. The wi4mpi is a bit of a special project, as it is provides a software 'glue' to make MPI implementations interchangeable. It is a way to overcome the missing ABI (i.e., a specification of types, etc.). Usually, the users will have to recompile their application every time they choose a different MPI (potentially also when using a different version of the same MPI), as values and types in the mpi.h may have changed. For large simulation codes, this can take a long time. When you have a translating 'glue' like wi4mpi in between, you can swap MPI implementations via LD_PRELOAD at the start time of the application. I don't know enough about wi4mpi to really know what their goal is: Have a mixed MPI run (e.g., couple two codes compiled against differnt MPIs)? Use a library compiled for one MPI together with an application compiled against another? Just make it easier for users to link against the right MPI? All of the above? @Marc? Any comments on what the design goal of wi4mpi is? Does it support other MPI implementations beside Intel-MPI and Open-MPI? (If this discussion drifts more towards 'wi4mpi' specifics, we should take this off the list and keep everyone else in CC) > In my library I wanted to use a light wight wrapper. That is I wanted > to use the original data types. With this approach I currently have > structures like: > > struct AMPI_Comm { > // my own data; > MPI_Comm comm; // the original object > }; > > I can then simply call the pmpi functions with the stored original > object. > If I have a wrapper such that there is a PMPI_Comm object available, I > could do the following: > struct MPI_Comm { > // my own data; > PMPI_Comm comm; // the original object > }; > > If the wrapper should use the same types from a general mpi.h, then I > do not know the types and would need to declare something like: > > hidden_mpi.c > #include <mpi.h> > decltype(MPI_COMM_WORLD) PMPI_COMM_WORLD = MPI_COMM_WORLD; > > and then I need to use PMPI_COMM_WORLD in my library and I can > generate a hmpi.h wich contains lines like: > #define MPI_COMM_WORLD PMPI_COMM_WORLD > > Which could be included by the user. But in order use PMPI_* in my > library, I need to specify the symbol in a header file for which I > need the type. In order to get the type I need to include mpi.h which > will define MPI_COMM_WORLD and I have a name clash. mpi.h only _declares_ the prototype. It does not define anything (apart from CPP macros, etc.). If you provide your own types, then you will need to declare your own prototypes, which I would generate (see below). > So unfortunately I see no way in providing a wrapper without writing a > complete MPI Interface, which I would like to avoid. I might be able > to use the wi4mpi Project and use there interface as a base for my > implementation, which would add a dependency to my project. For just a 'classic' wrapper, you just need to provide the definition (implementation) of the function you want to replace, adhering to the declared (in mpi.h) function prototype. > A third and very ugly option would be, that I define all my types as > void* in the interface for the user. But this disables type checking > and I still would need to wrap from void* to references of my types. > > So I might just stay in my AMPI namespace and provide a macro for the > user to either call regular mpi functions or my wrapper functions. If you need 'classic' wrappers for your project, you might consider generating that code with a generator like 'wrap' [2]. As I mentioned in my other mail, writing a 'classic' wrapper is straight forward. Cheers, Marc-Andre [2] https://github.com/LLNL/wrap > On Wed, 2017-10-04 at 11:00 +0200, Jean-Baptiste BESNARD wrote: >> Dear Max, >> >> I’m not sure I completely understand what you mean by a « pmpi.h » >> however I may have some initial elements below. >> >> The PMPI interface is currently targeting MPI functions only and >> indeed some of the values you’ll find in your executable will be >> compile time constants. >> In fact, most MPI types/Constants are implementation dependent, >> there is no unified ABI. >> >> Nonetheless, you might be able to interpret them in your wrapper >> library in order to have them « rerouted » to your target >> implementation. >> I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to >> be MPI_COMM_WORLD2. >> And for sure you wont’t find a PMPI_COMM_WORLD. >> >> I can help on writing a wrapper for the whole PMPI interface. See my >> repo here: https://github.com/besnardjb/mpi-snippets >> There is a simple python script generating VIM snippets for MPI from >> JSON specs, it can easily be converted to a script generating the >> whole MPI interface. >> >> Eventually, an approach close to what you want to do might >> be https://github.com/cea-hpc/wi4mpi which operates this systematic >> handler conversion between MPI flavors, but this clearly involves >> some rewriting. >> >> Hope this helps. >> >> Regards, >> >> Jean-Baptiste. >> >>> Le 4 oct. 2017 à 10:35, Max Sagebaum >>> <max.sagebaum(a)scicomp.uni-kl.de >>> <mailto:[email protected]>> a écrit : >>> Hello @ all, >>> >>> my question is concerning the PMPI specification. I hope the list >>> is the correct place to ask. >>> >>> I want to write a complete wrapper for MPI. That is every define, >>> typedef and function will be wrapped and might be completely >>> changed. Currently I prefixed everything with AMPI_ such that no >>> name clashes exist. But the user would need to rename every >>> occurrence of MPI_ with AMPI_ >>> >>> I would now like to use the PMPI definition of MPI to define my >>> wrappers as the MPI version which then use the PMPI definitions. >>> Unfortunately I could not find tutorials for a complete wrapper. >>> >>> As an example take MPI_COMM_WORLD. I made a grep on the openmpi >>> installation on my linux machine for PMPI_COMM_WORLD but the result >>> was empty. The definition of MPI_COMM_WORLD was >>> #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, >>> ompi_mpi_comm_world) >>> without any chance to switch to PMPI_COMM_WORLD as a predefined macro. >>> >>> I also checked the newest source tarball of openmpi and I could not >>> find anything for PMPI_COMM_WORLD there. >>> >>> In the mpi 3.0 standard on page 555 in section 14.2.1 the >>> requirements are just listed for functions. Was the definition of >>> the PMPI_ supplements for defines, types etc. never discussed? >>> >>> I would have expected, that I can just include a pmpi.h and then I >>> would have all the PMPI_ symbols without the MPI symbols available. >>> >>> Do you know of any way I could make my idea work? >>> >>> Cheers >>> >>> Max >>> >>> -- >>> Max Sagebaum >>> >>> Chair for Scientific Computing, >>> TU Kaiserslautern, >>> Bldg/Geb 34, Paul-Ehrlich-Strasse, >>> 67663 Kaiserslautern, Germany >>> >>> Phone: +49 (0)631 205 5638 >>> Fax: +49 (0)631 205 3056 >>> Email: max.sagebaum(a)scicomp.uni-kl.de <mailto:[email protected]> >>> URL: www.scicomp.uni-kl.de <http://www.scicomp.uni-kl.de> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > > -- > > Max Sagebaum > > Chair for Scientific Computing, > TU Kaiserslautern, > Bldg/Geb 34, Paul-Ehrlich-Strasse, > 67663 Kaiserslautern, Germany > > Phone: +49 (0)631 205 5638 > Fax: +49 (0)631 205 3056 > Email: max.sagebaum(a)scicomp.uni-kl.de > URL: www.scicomp.uni-kl.de > > > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Marc-Andre Hermanns 04 Oct '17

04 Oct '17

Hi Max, > thanks for the fast answer. With the pmpi.h I mean a file like mpi.h > but only containing the PMPI_ Interface. As you suggested I might try > to create a full wrapper myself. I took a look on the wi4mpi project > and there approach seems to create there own interface aka. mpi.h and > then wrap this to the intel MPI or OpenMPI implementation. Due to this > approach, they know the data types and can generate the interface. For the wi4mpi project, Jean-Baptiste and people from CEA may be the right people to talk to. The wi4mpi is a bit of a special project, as it is provides a software 'glue' to make MPI implementations interchangeable. It is a way to overcome the missing ABI (i.e., a specification of types, etc.). Usually, the users will have to recompile their application every time they choose a different MPI (potentially also when using a different version of the same MPI), as values and types in the mpi.h may have changed. For large simulation codes, this can take a long time. When you have a translating 'glue' like wi4mpi in between, you can swap MPI implementations via LD_PRELOAD at the start time of the application. I don't know enough about wi4mpi to really know what their goal is: Have a mixed MPI run (e.g., couple two codes compiled against differnt MPIs)? Use a library compiled for one MPI together with an application compiled against another? Just make it easier for users to link against the right MPI? All of the above? @Marc? Any comments on what the design goal of wi4mpi is? Does it support other MPI implementations beside Intel-MPI and Open-MPI? (If this discussion drifts more towards 'wi4mpi' specifics, we should take this off the list and keep everyone else in CC) > In my library I wanted to use a light wight wrapper. That is I wanted > to use the original data types. With this approach I currently have > structures like: > > struct AMPI_Comm { > // my own data; > MPI_Comm comm; // the original object > }; > > I can then simply call the pmpi functions with the stored original > object. > If I have a wrapper such that there is a PMPI_Comm object available, I > could do the following: > struct MPI_Comm { > // my own data; > PMPI_Comm comm; // the original object > }; > > If the wrapper should use the same types from a general mpi.h, then I > do not know the types and would need to declare something like: > > hidden_mpi.c > #include <mpi.h> > decltype(MPI_COMM_WORLD) PMPI_COMM_WORLD = MPI_COMM_WORLD; > > and then I need to use PMPI_COMM_WORLD in my library and I can > generate a hmpi.h wich contains lines like: > #define MPI_COMM_WORLD PMPI_COMM_WORLD > > Which could be included by the user. But in order use PMPI_* in my > library, I need to specify the symbol in a header file for which I > need the type. In order to get the type I need to include mpi.h which > will define MPI_COMM_WORLD and I have a name clash. mpi.h only _declares_ the prototype. It does not define anything (apart from CPP macros, etc.). If you provide your own types, then you will need to declare your own prototypes, which I would generate (see below). > So unfortunately I see no way in providing a wrapper without writing a > complete MPI Interface, which I would like to avoid. I might be able > to use the wi4mpi Project and use there interface as a base for my > implementation, which would add a dependency to my project. For just a 'classic' wrapper, you just need to provide the definition (implementation) of the function you want to replace, adhering to the declared (in mpi.h) function prototype. > A third and very ugly option would be, that I define all my types as > void* in the interface for the user. But this disables type checking > and I still would need to wrap from void* to references of my types. > > So I might just stay in my AMPI namespace and provide a macro for the > user to either call regular mpi functions or my wrapper functions. If you need 'classic' wrappers for your project, you might consider generating that code with a generator like 'wrap' [2]. As I mentioned in my other mail, writing a 'classic' wrapper is straight forward. Cheers, Marc-Andre [2] https://github.com/LLNL/wrap > On Wed, 2017-10-04 at 11:00 +0200, Jean-Baptiste BESNARD wrote: >> Dear Max, >> >> I’m not sure I completely understand what you mean by a « pmpi.h » >> however I may have some initial elements below. >> >> The PMPI interface is currently targeting MPI functions only and >> indeed some of the values you’ll find in your executable will be >> compile time constants. >> In fact, most MPI types/Constants are implementation dependent, >> there is no unified ABI. >> >> Nonetheless, you might be able to interpret them in your wrapper >> library in order to have them « rerouted » to your target >> implementation. >> I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to >> be MPI_COMM_WORLD2. >> And for sure you wont’t find a PMPI_COMM_WORLD. >> >> I can help on writing a wrapper for the whole PMPI interface. See my >> repo here: https://github.com/besnardjb/mpi-snippets >> There is a simple python script generating VIM snippets for MPI from >> JSON specs, it can easily be converted to a script generating the >> whole MPI interface. >> >> Eventually, an approach close to what you want to do might >> be https://github.com/cea-hpc/wi4mpi which operates this systematic >> handler conversion between MPI flavors, but this clearly involves >> some rewriting. >> >> Hope this helps. >> >> Regards, >> >> Jean-Baptiste. >> >>> Le 4 oct. 2017 à 10:35, Max Sagebaum >>> <max.sagebaum(a)scicomp.uni-kl.de >>> <mailto:[email protected]>> a écrit : >>> Hello @ all, >>> >>> my question is concerning the PMPI specification. I hope the list >>> is the correct place to ask. >>> >>> I want to write a complete wrapper for MPI. That is every define, >>> typedef and function will be wrapped and might be completely >>> changed. Currently I prefixed everything with AMPI_ such that no >>> name clashes exist. But the user would need to rename every >>> occurrence of MPI_ with AMPI_ >>> >>> I would now like to use the PMPI definition of MPI to define my >>> wrappers as the MPI version which then use the PMPI definitions. >>> Unfortunately I could not find tutorials for a complete wrapper. >>> >>> As an example take MPI_COMM_WORLD. I made a grep on the openmpi >>> installation on my linux machine for PMPI_COMM_WORLD but the result >>> was empty. The definition of MPI_COMM_WORLD was >>> #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, >>> ompi_mpi_comm_world) >>> without any chance to switch to PMPI_COMM_WORLD as a predefined macro. >>> >>> I also checked the newest source tarball of openmpi and I could not >>> find anything for PMPI_COMM_WORLD there. >>> >>> In the mpi 3.0 standard on page 555 in section 14.2.1 the >>> requirements are just listed for functions. Was the definition of >>> the PMPI_ supplements for defines, types etc. never discussed? >>> >>> I would have expected, that I can just include a pmpi.h and then I >>> would have all the PMPI_ symbols without the MPI symbols available. >>> >>> Do you know of any way I could make my idea work? >>> >>> Cheers >>> >>> Max >>> >>> -- >>> Max Sagebaum >>> >>> Chair for Scientific Computing, >>> TU Kaiserslautern, >>> Bldg/Geb 34, Paul-Ehrlich-Strasse, >>> 67663 Kaiserslautern, Germany >>> >>> Phone: +49 (0)631 205 5638 >>> Fax: +49 (0)631 205 3056 >>> Email: max.sagebaum(a)scicomp.uni-kl.de <mailto:[email protected]> >>> URL: www.scicomp.uni-kl.de <http://www.scicomp.uni-kl.de> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > > -- > > Max Sagebaum > > Chair for Scientific Computing, > TU Kaiserslautern, > Bldg/Geb 34, Paul-Ehrlich-Strasse, > 67663 Kaiserslautern, Germany > > Phone: +49 (0)631 205 5638 > Fax: +49 (0)631 205 3056 > Email: max.sagebaum(a)scicomp.uni-kl.de > URL: www.scicomp.uni-kl.de > > > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Marc-Andre Hermanns 04 Oct '17

04 Oct '17

Dear Max, > my question is concerning the PMPI specification. I hope the list is > the correct place to ask. In this specific case regarding the general API, it is. ;-) If you want internal information about implementation detail, the respective mailing lists of that specific implementation are the right point of contact. > I want to write a complete wrapper for MPI. That is every define, > typedef and function will be wrapped and might be completely changed. The question here is, _why_ do you want to write a complete wrapper including all constants, types, etc.? As Jean-Baptiste already mentioned, the MPI standard only defines PMPI symbols for its functions only. However, with (almost) every function being wrapped, you are in full control of the interaction with the MPI implementation. For example: In MPI_Init, you could create a new communicator 'my_new_world' and keep a reference to it internally. Then when wrapping any function with a communicator argument, you can silently swap MPI_COMM_WORLD against this new communicator. int MPI_Barrier(MPI_Comm comm) { if (comm == MPI_COMM_WORLD) { PMPI_Barrier(new_world_comm); } } Agreed, this is a runtime change, as opposed to a compile-time change that would apply if you changed a constant directly and this may imply more overhead. > Currently I prefixed everything with AMPI_ such that no name > clashes exist. But the user would need to rename every occurrence > of MPI_ with AMPI_ Requiring users to change their code is usually critical, as beyond simple benchmarks, it can become cumbersome and error prone quite quickly. Furthermore, the definition of the PMPI interface is actually designed such that a user does not have to modify any code. > I would now like to use the PMPI definition of MPI to define my > wrappers as the MPI version which then use the PMPI definitions. > Unfortunately I could not find tutorials for a complete wrapper. I also do not have a tutorial at hand, but you should be able to learn by example from any tool package that uses PMPI wrappers (e.g., Score-P [1]; check code in src/adapters/mpi/SCOREP_Mpi_*.c) The recipe is pretty simple: 1) #include <mpi.h> 2) define (not declare) the function you want to wrap (see barrier above) 3) compile 4) link to MPI application > As an example take MPI_COMM_WORLD. I made a grep on the openmpi > installation on my linux machine for PMPI_COMM_WORLD but the result > was empty. The definition of MPI_COMM_WORLD was > #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, > ompi_mpi_comm_world) > without any chance to switch to PMPI_COMM_WORLD as a predefined macro. An MPI implementation is free to define any constants and handles as they see fit. Some implementations use pointers to structs, others use integers to identify handles. IMHO, trying to redefine handles or types portably across different implementations is a moot project. > I also checked the newest source tarball of openmpi and I could not > find anything for PMPI_COMM_WORLD there. As said before, the PMPI interface _only_ covers functions, and even allows some exceptions. For example, MPI_Wtime is not required to be a function and poses a PMPI symbol, but instead be defined completely as a macro. As a consequence, one might not be able to intercept MPI_Wtime in this way. > In the mpi 3.0 standard on page 555 in section 14.2.1 the requirements > are just listed for functions. Was the definition of the PMPI_ > supplements for defines, types etc. never discussed? The question is again: What is it that you are trying to accomplish that is not possible with PMPI today? The PMPI interface was (afaik) introduced to enable easy profiling of applications, i.e., creating wrappers to easily insert measurement code before and after the actual MPI function invocation. For constants, I do not see any similar application. Any handles are opaque objects in that you do not know how they may be defined. Redefining them and handing them to the implementation seems problematic to me. > I would have expected, that I can just include a pmpi.h and then I > would have all the PMPI_ symbols without the MPI symbols available. > Do you know of any way I could make my idea work? IMHO, the 'what' and 'how' you proposed is not possible. But maybe, if you elaborate more on the 'why', there is a way to leverage the PMPI interface for your needs. Cheers, Marc-Andre [1] http://www.vi-hps.org/upload/packages/scorep/scorep-3.1.tar.gz -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Max Sagebaum 04 Oct '17

04 Oct '17

Hello Jean-Baptiste, thanks for the fast answer. With the pmpi.h I mean a file like mpi.h but only containing the PMPI_ Interface. As you suggested I might try to create a full wrapper myself. I took a look on the wi4mpi project and there approach seems to create there own interface aka. mpi.h and then wrap this to the intel MPI or OpenMPI implementation. Due to this approach, they know the data types and can generate the interface. In my library I wanted to use a light wight wrapper. That is I wanted to use the original data types. With this approach I currently have structures like: struct AMPI_Comm { // my own data; MPI_Comm comm; // the original object }; I can then simply call the pmpi functions with the stored original object. If I have a wrapper such that there is a PMPI_Comm object available, I could do the following: struct MPI_Comm { // my own data; PMPI_Comm comm; // the original object }; If the wrapper should use the same types from a general mpi.h, then I do not know the types and would need to declare something like: hidden_mpi.c #include <mpi.h> decltype(MPI_COMM_WORLD) PMPI_COMM_WORLD = MPI_COMM_WORLD; and then I need to use PMPI_COMM_WORLD in my library and I can generate a hmpi.h wich contains lines like: #define MPI_COMM_WORLD PMPI_COMM_WORLD Which could be included by the user. But in order use PMPI_* in my library, I need to specify the symbol in a header file for which I need the type. In order to get the type I need to include mpi.h which will define MPI_COMM_WORLD and I have a name clash. So unfortunately I see no way in providing a wrapper without writing a complete MPI Interface, which I would like to avoid. I might be able to use the wi4mpi Project and use there interface as a base for my implementation, which would add a dependency to my project. A third and very ugly option would be, that I define all my types as void* in the interface for the user. But this disables type checking and I still would need to wrap from void* to references of my types. So I might just stay in my AMPI namespace and provide a macro for the user to either call regular mpi functions or my wrapper functions. Cheers Max On Wed, 2017-10-04 at 11:00 +0200, Jean-Baptiste BESNARD wrote: Dear Max, I’m not sure I completely understand what you mean by a « pmpi.h » however I may have some initial elements below. The PMPI interface is currently targeting MPI functions only and indeed some of the values you’ll find in your executable will be compile time constants. In fact, most MPI types/Constants are implementation dependent, there is no unified ABI. Nonetheless, you might be able to interpret them in your wrapper library in order to have them « rerouted » to your target implementation. I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to be MPI_COMM_WORLD2. And for sure you wont’t find a PMPI_COMM_WORLD. I can help on writing a wrapper for the whole PMPI interface. See my repo here: https://github.com/besnardjb/mpi-snippets There is a simple python script generating VIM snippets for MPI from JSON specs, it can easily be converted to a script generating the whole MPI interface. Eventually, an approach close to what you want to do might be https://github.com/cea-hpc/wi4mpi which operates this systematic handler conversion between MPI flavors, but this clearly involves some rewriting. Hope this helps. Regards, Jean-Baptiste. Le 4 oct. 2017 à 10:35, Max Sagebaum <max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]>> a écrit : Hello @ all, my question is concerning the PMPI specification. I hope the list is the correct place to ask. I want to write a complete wrapper for MPI. That is every define, typedef and function will be wrapped and might be completely changed. Currently I prefixed everything with AMPI_ such that no name clashes exist. But the user would need to rename every occurrence of MPI_ with AMPI_ I would now like to use the PMPI definition of MPI to define my wrappers as the MPI version which then use the PMPI definitions. Unfortunately I could not find tutorials for a complete wrapper. As an example take MPI_COMM_WORLD. I made a grep on the openmpi installation on my linux machine for PMPI_COMM_WORLD but the result was empty. The definition of MPI_COMM_WORLD was #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world) without any chance to switch to PMPI_COMM_WORLD as a predefined macro. I also checked the newest source tarball of openmpi and I could not find anything for PMPI_COMM_WORLD there. In the mpi 3.0 standard on page 555 in section 14.2.1 the requirements are just listed for functions. Was the definition of the PMPI_ supplements for defines, types etc. never discussed? I would have expected, that I can just include a pmpi.h and then I would have all the PMPI_ symbols without the MPI symbols available. Do you know of any way I could make my idea work? Cheers Max -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de<mailto:[email protected]> URL: www.scicomp.uni-kl.de<http://www.scicomp.uni-kl.de> _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Max Sagebaum Chair for Scientific Computing, TU Kaiserslautern, Bldg/Geb 34, Paul-Ehrlich-Strasse, 67663 Kaiserslautern, Germany Phone: +49 (0)631 205 5638 Fax: +49 (0)631 205 3056 Email: max.sagebaum(a)scicomp.uni-kl.de URL: www.scicomp.uni-kl.de

1 0

Re: [mpiwg-tools] PMPI for a complete MPI wrapper
by Jean-Baptiste BESNARD 04 Oct '17

04 Oct '17

Dear Max, I’m not sure I completely understand what you mean by a « pmpi.h » however I may have some initial elements below. The PMPI interface is currently targeting MPI functions only and indeed some of the values you’ll find in your executable will be compile time constants. In fact, most MPI types/Constants are implementation dependent, there is no unified ABI. Nonetheless, you might be able to interpret them in your wrapper library in order to have them « rerouted » to your target implementation. I mean, knowing the value of MPI_COMM_WORLD you could rewrite it to be MPI_COMM_WORLD2. And for sure you wont’t find a PMPI_COMM_WORLD. I can help on writing a wrapper for the whole PMPI interface. See my repo here: https://github.com/besnardjb/mpi-snippets <https://github.com/besnardjb/mpi-snippets> There is a simple python script generating VIM snippets for MPI from JSON specs, it can easily be converted to a script generating the whole MPI interface. Eventually, an approach close to what you want to do might be https://github.com/cea-hpc/wi4mpi <https://github.com/cea-hpc/wi4mpi> which operates this systematic handler conversion between MPI flavors, but this clearly involves some rewriting. Hope this helps. Regards, Jean-Baptiste. > Le 4 oct. 2017 à 10:35, Max Sagebaum <max.sagebaum(a)scicomp.uni-kl.de> a écrit : > > Hello @ all, > > my question is concerning the PMPI specification. I hope the list is the correct place to ask. > > I want to write a complete wrapper for MPI. That is every define, typedef and function will be wrapped and might be completely changed. Currently I prefixed everything with AMPI_ such that no name clashes exist. But the user would need to rename every occurrence of MPI_ with AMPI_ > > I would now like to use the PMPI definition of MPI to define my wrappers as the MPI version which then use the PMPI definitions. Unfortunately I could not find tutorials for a complete wrapper. > > As an example take MPI_COMM_WORLD. I made a grep on the openmpi installation on my linux machine for PMPI_COMM_WORLD but the result was empty. The definition of MPI_COMM_WORLD was > #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world) > without any chance to switch to PMPI_COMM_WORLD as a predefined macro. > > I also checked the newest source tarball of openmpi and I could not find anything for PMPI_COMM_WORLD there. > > In the mpi 3.0 standard on page 555 in section 14.2.1 the requirements are just listed for functions. Was the definition of the PMPI_ supplements for defines, types etc. never discussed? > > I would have expected, that I can just include a pmpi.h and then I would have all the PMPI_ symbols without the MPI symbols available. > > Do you know of any way I could make my idea work? > > Cheers > > Max > > -- > Max Sagebaum > > Chair for Scientific Computing, > TU Kaiserslautern, > Bldg/Geb 34, Paul-Ehrlich-Strasse, > 67663 Kaiserslautern, Germany > > Phone: +49 (0)631 205 5638 > Fax: +49 (0)631 205 3056 > Email: max.sagebaum(a)scicomp.uni-kl.de > URL: www.scicomp.uni-kl.de > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

1 0