[petsc-dev] Removed functions in MPI 3

[Barry Smith]

On Jan 21, 2013, at 5:41 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Mon, Jan 21, 2013 at 5:31 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Mon, Jan 21, 2013 at 4:12 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> Dear PETScians,
> 
> MPI 3.0 *removes* a set of functions from MPI 1.x, of which the following are in use in PETSc:
> 
>  * MPI_Type_struct, used in
>    src/ts/characteristic/impls/da/slda.c
>    src/dm/impls/mesh/meshpcice.c
> 
>  * MPI_Errhandler_create/MPI_Errhandler_set, used in
>    src/sys/objects/pinit.c
>    src/sys/objects/init.c
> 
> In both cases function were renamed in MPI-2.0:
>   MPI_Type_struct       -> MPI_Type_create_struct
>   MPI_Errhandler_create -> MPI_Comm_create_errhandler
>   MPI_Errhandler_set    -> MPI_Comm_set_errhandler

  Damn assholes, changing their API all the time for no good reason.

> 
> It should be sufficient to update BuildSystem/config/packages/MPI.py and add the respective checks in configureMPI2(). Any objections on the following defines:
>   HAVE_MPI_TYPE_CREATE_STRUCT
>   HAVE_MPI_COMM_CREATE_ERRHANDLER
>   HAVE_MPI_COMM_SET_ERRHANDLER
> in the case of success?
> 
> Yes, this is the right way.
> 
> I'm also in favor of changing all the call sites to the new function names. I think that if configure does not find a new function name, we can
> 
> #define MPI_Type_create_struct(count,lens,displs,types,newtype) MPI_Type_struct((count),(lens),(displs),(types),(newtype))

 Yes switch to the new names and have configure generate the old when needed. I am actually in favor of having configure generate the string 
> #define MPI_Type_create_struct(count,lens,displs,types,newtype) MPI_Type_struct((count),(lens),(displs),(types),(newtype)) 
and sticking it in petscconf.h or petscfix.h when needed and not having in PETSc source/include file code ugly stuff like

#if !defined(PETSC_HAVE_MPI_TYPE_CREATE_STRUCT)
> #define MPI_Type_create_struct(count,lens,displs,types,newtype) MPI_Type_struct((count),(lens),(displs),(types),(newtype)) 
#endif

but I am sure Jed will find some objection to having configure generate the string directly.

> 
> similar to the defines in petsclog.h (though those are for logging) so that we don't need macros at every call site. FWIW, I'd prefer that the redefines in petsclog.h be moved to a header that is not mandatory for users to include (because the current approach cannot be used with another library that also does the same thing).

   Is this even possible without requiring some "extra" include in each PETSc source that has to be added?  Though I agree in principle with not having these macros visible in user code I don't like needing some convoluted "thing" that is different between PETSc source code and user code; one of the original goals of PETSc design was the user code and PETSc code were indistinguishable as much as possible both to the human eye and compilers. So I'd need to see a clean way of handling this that didn't involve ugly stuff like
#define THIS_BE_PETSC_SOURCE at the top of each PETSc source code file.

   Barry