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). > > > > 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/3e99e31c/attachment.html>
