On Jan 21, 2013, at 6:30 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> Are there any places that call MPI directly, but do not include anything from > petsc-private? Probably not, but petscsys.h includes petsc-private/petscimpl.h petscvec.h includes petsc-private/vecimpl.h etc so I think all user code includes all the parts of petsc-private that PETSc code does. Could we bag the ugly MPI logging macros and somehow use the "perfectly designed" MPI profiling level to gather the information? Sadly I think not, but would that be workable? (And still work with other MPI logging systems?) Barry > > 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 > > > > >
