Dear all, only about the missing ierror in the Fortran MPI_PCONTROL(level): Of course, this interface is valid since MPI-1.1 and never had an additional ierror argument. Nobody never complained about the conflict to the wording MPI-3.0 page 19 lines 8-12. We may correct this with the following additional wording, i.e., without touching the interface specifications: MPI-3.0 page 19 lines 11-12 read A few MPI operations which are functions do not have the return code argument. but should read The subroutine MPI_PCONTROL and a few MPI operations which are functions do not have the return code argument. MPI-3.0 page 557 line 27-28 read MPI libraries themselves make no use of this routine, and simply return immediately to the user code. but should read MPI libraries themselves make no use of this routine, and simply return immediately to the user code. Note that the Fortran interface does not include an ierror argument. I expect that this is all what should be done as erratum about MPI_PCONTROL. My concret wording may/should be optimized (--> Jeff?). Additional remark: I would not say anything about the return-value of the C interface. The wording "and simply return immediately" should say enough, i.e., nobody can expect that a MPI_SUCCESS is returned, because returning MPI_SUCCESS may be more than "and simply return immediately". Although I expect that all high-quality MPI implementations return MPI_SUCCESS, which is also okay, because a function must return something. Best regards Rolf ----- Original Message -----

From: "Martin Schulz" <[email protected]> To: [email protected] Cc: "MPI-3 Fortran working group" <[email protected]> Sent: Tuesday, April 16, 2013 4:34:53 PM Subject: Re: [Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol On Apr 16, 2013, at 3:19 AM, Marc-Andre Hermanns <[email protected]> wrote:

...

Jeff,

...

I certainly don't mean deleting PMPI from MPI-4. I mean putting something better in MPI-4 that, over time, can replace PMPI (so that PMPI *can* be deleted in some future version).

I don't really understand why the issues with Pcontrol has an influence on whether the PMPI should be surpassed by anything else?

I agree - we are starting to mix topics and we should keep them separate. I think we have at least four threads going as one: - How can we fix the current issues in the Fortran bindings for the PMPI interface - How can we fix the ambiguity in the current definition of MPI_Pcontrol - Should we replace PMPI with something else - Should we add a new (additional) MPI_Pcontrol mechanism

I think all of these are independent.

...

Isn't it for use of the profiling tool only?

MPI_Pcontrol is used by the application writer to control/inform tools. The initial intent was to turn on/off profilers, but it kind has outgrown this. In any case, calls to MPI_Pcontrol go into the application code and have to be usable by developers (as any other MPI call). Therefore, we should support all language bindings for it. Otherwise we might as well remove all Fortran bindings with the argument that people can wrap their calls to MPI from Fortran themselves.

...

Scalasca does not use Pcontrol at the moment. Could anyone give me an example of a tool using it, and some context in how it is used to understand what kind of interface is needed?

mpiP and O|SS use it to enable phase profiling (in the sense it was originally designed for), the load balance analysis tool Libra uses it to allow codes to identify major time steps, our collection tools for Boxfish use it to annotate phases, we are working on load balancers that use Pcontrol to communicate application topology to the load balancer and in the future (as part of the exascale software stack design) we are thinking about creating families of APIs that use Pcontrol to pass general application information to runtime systems. The advantage is always that this is a call whose link symbol is always present and hence applications can easily pass hints and the tools/runtimes that can interpret it can use it, while on other systems we can still link and run.

Martin

...

Cheers, Marc-Andre

-- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52062 Aachen | Germany

Tel +49 241 80 99753 Fax +49 241 80 6 99753 Web www.grs-sim.de

Members: Forschungszentrum Jülich GmbH | RWTH Aachen University Registered in the commercial register of the local court of Düren (Amtsgericht Düren) under registration number HRB 5268 Registered office: Jülich Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt _______________________________________________ Mpi3-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

_______________________________________________ Mpi3-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)