<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>The mail from Rolf that didn't make it to the tools list.</div><div><br></div><div><br></div><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Rolf Rabenseifner <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">October 3, 2011 4:18:09 AM MDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">MPI3 Tools <<a href="mailto:mpi3-tools@lists.mpi-forum.org">mpi3-tools@lists.mpi-forum.org</a>>, MPI-3 Fortran working group <<a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: [MPI3 Fortran] [Mpi3-tools] Questions on the F2008 profiling interface issues</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Reply-To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">MPI-3 Fortran working group <<a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a>><br></span></div><br><div>Dear all,<br><br>according to pages:lines in<br><a href="https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf">https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf</a><br>and the decision of the Santorini 2011 meeting,<br>we should add the following text to accommodate the tools implementors.<br><br>P559:20-21 reads<br> equals .FALSE.. If<br>but should read<br> equals .FALSE., and<br><br>After p559 the following text should be added:<br><br>----------------------------<br>To simplify the development of profiling libraries, the MPI routines<br>are grouped together and it is required that<br>if the peer routine of a group is available within an MPI library<br>with one of its possible linker names then all of the routines<br>in this group must be also provided according to the same linker<br>name scheme, and if the peer routine is not available through<br>a linker name scheme then all other routines have also not to be<br>available through this scheme.<br><br>Peer routines and their groups:<br> - MPI_ALLOC_MEM<br> MPI_ALLOC_MEM and MPI_WIN_ALLOCATE.<br> - MPI_FREE_MEM<br> Only this routine is in this group.<br> - MPI_GET_ADDRESS<br> MPI_GET_ADDRESS and MPI_ADDRESS.<br> - MPI_SEND<br> All routines with choice buffer arguments that<br> are not declared as ASYNCHRONOUS within the mpi_f08 module<br> and exist already in MPI-2.2.<br> - MPI_NEIGHBOR_ALLTOALL<br> All routines with choice buffer arguments that<br> are not declared as ASYNCHRONOUS within the mpi_f08 module<br> and are new in MPI-3.0.<br> - MPI_ISEND<br> All routines with choice buffer arguments that<br> are declared as ASYNCHRONOUS within the mpi_f08 module<br> and exist already in MPI-2.2.<br> - MPI_IBCAST<br> All routines with choice buffer arguments that<br> are declared as ASYNCHRONOUS within the mpi_f08 module<br> and are new in MPI-3.0.<br> - MPI_OP_CREATE<br> Only this routine is in this group.<br> - MPI_REGISTER_DATAREP<br> Only this routine is in this group.<br> - MPI_COMM_KEYVAL_CREATE<br> All other routines with callback function arguments.<br> - MPI_COMM_DUP_FN<br> All predefined callback routines.<br> - MPI_COMM_RANK<br> All other MPI routines that exist already in MPI-2.2.<br> - MPI_IBARRIER<br> All other MPI routines that are new in MPI-3.0.<br><br>Advice to implementors.<br>If all the following conditions are fulfilled<br>(which is the case for most compilers)<br> - the handles in the mpi_f08 module occupy one Fortran<br> numerical storage unit (same as an INTEGER handle), and<br> - the internal argument passing used to pass an actual ierror<br> argument to a non optional ierror dummy argument is binary<br> compatible to passing an actual ierror argument to an ierror<br> dummy argument that is declared as OPTIONAL, and<br> - the internal argument passing for ASYNCHRONOUS and<br> non-ASYNCHRONOUS arguments is the same, and<br> - the internal routine call mechanism is the same for<br> the Fortran and the C compiler, and<br> - the compiler does not provide TR 29113,<br>then for most groups, the implementor may use the same<br>internal routine implementations for all Fortran support<br>methods with only different linker names.<br>For TR 29113 quality, new routines are needed only for<br>the routine groups of MPI_ISEND and MPI_IBCAST.<br>End of advice to implementors.<br>----------------------------<br><br>Not directly relevant for the tools people, but giving the reason<br>for differentiating several Choice-buffer routine groups,<br>the following changes are also done:<br><br>P552:14-18 read<br> - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to<br> .TRUE. and declare choice buffers using the Fortran 2008 TR 29113<br> feature assumed-type and assumed-rank, i.e., TYPE(*), DIMENSION(..),<br> if the underlying Fortran compiler supports it. With this,<br> non-contiguous sub-arrays can be used as buffers in nonblocking routines.<br>but should read<br> - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to<br> .TRUE. and declare choice buffers using the Fortran 2008 TR 29113<br> feature assumed-type and assumed-rank, i.e., TYPE(*), DIMENSION(..)<br> in all nonblocking, split collective and persistent communication<br> routines,<br> if the underlying Fortran compiler supports it. With this,<br> non-contiguous sub-arrays can be used as buffers in nonblocking routines.<br><br> Rationale. In all blocking routines, i.e., if the choice-buffer<br> is not declared as ASYNCHRONOUS, the TR 29113 feature is not needed<br> for the support of non-contiguous buffers because the compiler<br> can pass the buffer by in-and-out-copy through a contiguous scratch<br> array. End of rationale.<br><br>P555:7-10 read<br> - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to<br> .TRUE. if all choice buffer arguments<br> are declared with TYPE(*), DIMENSION(..), otherwise set it to<br> .FALSE.. With MPI_SUBARRAYS_SUPPORTED==.TRUE., non-contiguous<br> subarrays can be used as buers in nonblocking routines.<br>but should read<br> - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to<br> .TRUE. if all choice buffer arguments<br> in all nonblocking, split collective and persistent communication<br> routines<br> are declared with TYPE(*), DIMENSION(..), otherwise set it to<br> .FALSE.. With MPI_SUBARRAYS_SUPPORTED==.TRUE., non-contiguous<br> subarrays can be used as buers in nonblocking routines.<br><br>I'll try to be at the tel-con today.<br><br>Best regards<br>Rolf<br><br><br>----- Original Message -----<br><blockquote type="cite">From: "Martin Schulz" <<a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>><br></blockquote><blockquote type="cite">To: "Marc-Andre Hermanns" <<a href="mailto:m.a.hermanns@grs-sim.de">m.a.hermanns@grs-sim.de</a>><br></blockquote><blockquote type="cite">Cc: "MPI3 Tools" <<a href="mailto:mpi3-tools@lists.mpi-forum.org">mpi3-tools@lists.mpi-forum.org</a>>, "Martin Schulz" <<a href="mailto:schulz6@llnl.gov">schulz6@llnl.gov</a>>, "Craig E Rasmussen"<br></blockquote><blockquote type="cite"><<a href="mailto:rasmussn@lanl.gov">rasmussn@lanl.gov</a>>, "Rolf Rabenseifner" <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>>, "Jeff Squyres" <<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>>, "Andreas<br></blockquote><blockquote type="cite">Knüpfer" <<a href="mailto:andreas.knuepfer@tu-dresden.de">andreas.knuepfer@tu-dresden.de</a>>, "Todd Gamblin" <<a href="mailto:tgamblin@llnl.gov">tgamblin@llnl.gov</a>>, "Tobias Hilbrich"<br></blockquote><blockquote type="cite"><<a href="mailto:tobias.hilbrich@tu-dresden.de">tobias.hilbrich@tu-dresden.de</a>>, "MPI-3 Fortran working group" <<a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a>><br></blockquote><blockquote type="cite">Sent: Sunday, October 2, 2011 6:13:46 AM<br></blockquote><blockquote type="cite">Subject: Re: [Mpi3-tools] Questions on the F2008 profiling interface issues<br></blockquote><blockquote type="cite">Hi Marc-Andre,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Sep 30, 2011, at 6:27 AM, Marc-Andre Hermanns wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Martin,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I was in Dresden the last few days (visiting the Vampir group, in<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">particular Andreas Knuepfer and Tobias Hilbrich who are responsible<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">for<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">their MPI wrappers) and we sat down to talk about the issues around<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">profiling interface in ticket #229.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Here is a quick summary with a few questions that came up:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">* With the new Fortran symbol naming variants, there are 6 or 8 or<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">10<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">versions for every MPI subroutine. Tools could intercept all<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">versions by<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">providing own symbols for all versions.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If it is clear which name the symbols have, additional symbol names<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">should be easy to generate, so at this stage I think it doesn't<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">matter<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">much, whether we have 6, 8, or 10 different schemes to cover. Right?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I agree - as long as we can generate a full list of names, we can<br></blockquote><blockquote type="cite">intercept them all. Adding wrappers shouldn't be a problem.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Now the problem: Within the wrapper function a tool needs to call<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">correct PMPI call which usually is the same prefix (either '_f08',<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">'_f', '__' etc.) as the MPI call it is in. A mapping to matching C<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">functions (as most tools do it now) is not possible due to problems<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">with calling conventions for callback routines.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">As far as I know our wrappers call the C routines, because we jump<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">through all sorts of hoops to get a proper Fortran to C conversion<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">back. So in this regard, we need to fix this. Interestingly this has<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">popped up yet.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I agree - this is remarkable.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If we write Fortran wrappers in Fortran, how would a Fortran wrapper<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">compiled with Fortran 77 have to call the C measurement code inside<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wrapper? If the Fortran compiler implicitly adds underscores to the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">calls, do I have to provide a special Fortran interface to my<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">measurement system then?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That is a question for the Fortran experts.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">* Would the following solution work? All wrappers for Fortran are<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">written<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in Fortran instead of C.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">[...]<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">For every MPI function, there are 6 or 8 variants and all of them<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">need to be provided by a tool. This would probably mean that we<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">have<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">to compile wrappers with all three calling conventions (mpif.h, use<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">mpi_f and use mpi_f08) and then link them together?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Don't we need to compile with all three calling conventions on all<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">possible compilers on a given system?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Also, here, I think the Fortran experts need to weigh in.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">We currently provide all 4 name-mangling schemes with every install<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Scalasca, because we had some issues with applications using two<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">different Fortran compilers for different sub-modules. (This came up<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a project some years back, and ever since then we provide all<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">schemes in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the same library and it seems to work.)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">* As discussed at the forum, if we want to keep our tools in C<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(which is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">probably still the easier and better option), we need to know the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">symbols<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">on the "p" side and we need a portable way to figure this out. We<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">talked<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">about the solution of two groups of routines - one for which we<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">have _f08<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">symbols for one for which we don't. Rolf, how will you add this to<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">standard, in particular how will you form those groups.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I started to get some doubts about this approach. One of the issues<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">was<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that some choice-buffer routines had names longer than the proposed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">limit. So they need to be mangled differently, especially, their<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">symbol<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needs to be shortened. And as I understood it, the current idea is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">leave it to the MPI implementation to define the shortened name.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I thought that was just for the argument checking in mpif.h and that<br></blockquote><blockquote type="cite">we decided to not support this. Are there more locations were the<br></blockquote><blockquote type="cite">names are too long?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It is one thing, finding out which suffix is used. Finding how<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">function<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">names are mangled without any form of restricting to possible<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">schemes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">seems to be another ball game?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Am I missing something?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes, if we do have to shorten names, I agree - I think, though, we got<br></blockquote><blockquote type="cite">around the issue, or did we not?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think, as it was pointed out in Santorini with the Fortran<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Bindings in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">general, we (or at least I) don't have enough Fortran expertise to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">think<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this through all to the end and consider all implications. I think<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would be a great benefit to have people of the Fortran WG to join on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">call on Monday. I hope this is possible.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes, that would be great - all are cc-ed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Martin<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Marc-Andre<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Marc-Andre Hermanns<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">German Research School for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Simulation Sciences GmbH<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">c/o Laboratory for Parallel Programming<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">52056 Aachen | Germany<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tel +49 241 80 99753<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fax +49 241 80 6 99753<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Web <a href="http://www.grs-sim.de">www.grs-sim.de</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Members: Forschungszentrum Jülich GmbH | RWTH Aachen University<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Registered in the commercial register of the local court of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Düren (Amtsgericht Düren) under registration number HRB 5268<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Registered office: Jülich<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">________________________________________________________________________<br></blockquote><blockquote type="cite">Martin Schulz, <a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>, <a href="http://people.llnl.gov/schulzm">http://people.llnl.gov/schulzm</a><br></blockquote><blockquote type="cite">CASC @ Lawrence Livermore National Laboratory, Livermore, USA<br></blockquote><br>--<br>Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner">www.hlrs.de/people/rabenseifner</a><br>Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<br><br>_______________________________________________<br>mpi3-fortran mailing list<br><a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran<br></div></blockquote></div><br></div></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><br class="Apple-interchange-newline">-- </div><div>Jeff Squyres</div><div><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a></div><div>For corporate legal information go to:</div><div><a href="http://www.cisco.com/web/about/doing_business/legal/cri/">http://www.cisco.com/web/about/doing_business/legal/cri/</a></div></span></div></span></div></span></div></span></span>
</div>
<br></body></html>