[petsc-dev] ugly shit

[Jed Brown]

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>