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.
