[Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol

Tue Apr 16 10:23:38 CDT 2013

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" <schulzm at llnl.gov>
> To: mpi3-tools at lists.mpi-forum.org
> Cc: "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>
> 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
> <m.a.hermanns at grs-sim.de>
> 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
> > Mpi3-tools at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
> 
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> 
> 
> 
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
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)