There is a clear requirement for the user code to be able to control the profiler dynamically at run time. This is normally used for (at least) the purposes of
o Enabling and disabling profiling depending on the state of the calculation o Flushing trace buffers at non-critical points in the calculation o Adding user events to a trace file.These requirements are met by use of the MPI_PCONTROL.
MPI_PCONTROL(level, ...) IN level Profiling levelMPI_Pcontrol(const int level, ...) MPI_PCONTROL(level)INTEGER LEVEL
MPI libraries themselves make no use of this routine, and simply return immediately to the user code. However the presence of calls to this routine allows a profiling package to be explicitly called by the user.
Since MPI has no control of the implementation of the profiling code, The MPI Forum was unable to specify precisely the semantics which will be provided by calls to MPI_PCONTROL. This vagueness extends to the number of arguments to the function, and their datatypes.
However to provide some level of portability of user codes to different profiling libraries, the MPI Forum requested the following meanings for certain values of level.
The MPI Forum also requested that the default state after MPI_INIT has been called is for profiling to be enabled at the normal default level. (i.e. as if MPI_PCONTROL had just been called with the argument 1). This allows users to link with a profiling library and obtain profile output without having to modify their source code at all.
The provision of MPI_PCONTROL as a no-op in the standard MPI library allows users to modify their source code to obtain more detailed profiling information, but still be able to link exactly the same code against the standard MPI library.