[petsc-dev] Removed functions in MPI 3

[Jed Brown]

Are there any places that call MPI directly, but do not include anything
from petsc-private?
On Jan 21, 2013 6:27 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:

>
> 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
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130121/77b88ddf/attachment.html>