[petsc-dev] Generality of VecScatter

[Jed Brown]

On Thu, Nov 24, 2011 at 01:49, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

> I mean that for a scatter (a,x) (a,y) with MAX_VALUES the result at a
> would be the MAX of values at x and y.
> With the new API that would be disallowed.
>

Yes, but you could flip the spaces as in (x,a) (y,a).


>  Also, if you allow (a,x) (b,x) then you are effectively allowing (x,a)
> (x,b),
> since you can emulate it with the reverse mode, unless you ban that too.
>

My point is that the ability to reduce (and gather/scatter) resides on only
one side. When you create the scatter, you can choose which side has
reductions. It makes the specification asymmetric. This reduces storage and
makes certain operations more performant. It also (I think) eliminates some
bugs and makes reduction and (more importantly) gather/scatter semantics
easier to understand.

It's entirely possible to allow reduction on both sides (still with
lightweight/scalable storage), but I think it would be more confusing to
work with. I'm skeptical that it's important.

BTW, remote fetch-and-add is a fantastic tool for inverting communication
graphs without O(size) redundant storage. So if the space with multiple
edges per vertex knows who should own a point (e.g. in graph partitioning),
we can flip the graph without global synchronization (like Allreduce) or
O(size) storage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111124/42a2fbc4/attachment.html>