True. Easy, but tedious. But so are #ifdefs. How do we find out who needs pre-MPI-2.0? On Nov 10, 2011 7:38 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > On Nov 10, 2011, at 4:10 PM, Jed Brown wrote: > > > On Thu, Nov 10, 2011 at 16:05, Barry Smith <bsmith at mcs.anl.gov> wrote: > > You could have ./configure check for MPI_IN_PLACE and generate an > error if it doesn't exist. But do we want to say PETSc requires MPI 2.0 > (or at least parts of it)???? Since we already have support for not having > MPI_IN_PLACE I'd only like to remove that extra support if we knew that all > (sane) users had access to MPI_IN_PLACE. Do we know this? > > > > If we found an implementation that doesn't have it, we could define the > MPI_IN_PLACE value and have our own wrapper that did the right thing > (allocated the work array). > > I don't see this being simple. We would need to implement many MPI > functions that take MPI_IN_PLACE. > > > > > > > > > > In general, can we rely on any MPI-2.0 features that have been > implemented in mpiuni and remove the macro checking? > > > > I don't have a clue what parts of MPI-2.0 that MPIUni does or does > not support :-(. I'm afraid we'll need to find out one operation at a > time. It definitely doesn't have the one-sided stuff, can/should that be > added? I don't see a big upside in putting the one-sided stuff into MPI uni. > > > > MPI one-sided is normally used to talk to remote processes, much like > MPI_Send, which we currently define to produce an error if called. I think > it would make sense to do the same thing with the one-sided stuff. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111110/35a6770b/attachment.html>
