[petsc-dev] question about PETSc.Vec.sum()

[Aron Ahmadia]

PETSc could also just provide a VecReduce and VecReduceStride operation,
which might simplify the programming effort a bit.

A

On Tue, Jun 21, 2011 at 7:53 PM, Jed Brown <five9a2 at gmail.com> wrote:

> On Tue, Jun 21, 2011 at 18:25, David Ketcheson <
> david.ketcheson at kaust.edu.sa> wrote:
>
>> Thanks, Jed.  We actually just want the sum, but since all values are
>> positive, your suggestion will work.
>>
>> On a philosophical note, why is the default behavior of Vec.Sum to sum
>> over all dofs into a scalar?  This seems like a bad idea to me, since the
>> different DOFs typically don't even have the same physical units.  But maybe
>> the PETSc Vec abstraction is not what I believe it to be.
>>
>
> Historically, Vec has had little to no knowledge of separate meaning to
> components. The VecStrideXX() functions offer some convenience when dealing
> with components separately. We have been discussing putting more "field"
> information into Vec, mostly to make it less work to use solvers that
> distinguish fields.
>
> I agree that since the components have different units, there is no sense
> to summing them all up together. I think the only place in PETSc where
> VecSum is used algorithmically is in the removal of a constant null space,
> which only makes sense for single-component problems (otherwise the user
> would have provided a vector representing the null space).
>
> I think it would be reasonable for VecSum(), possibly named VecStrideSum(),
> to sum each "field" separately. The problem here is managing the
> variable-length return array in C. And it snowballs because VecMin(), etc.
> also don't make sense when comparing quantities with different units. The
> places where these functions are most commonly called often have to do
> user-defined nonlinear things (e.g. to compute observables like temperature
> or pressure). So I'm not sure the occasional convenience of making
> everything stride-aware justifies the interface complexity. I would have no
> arguments with adding a VecStrideSumAll() function which would provide
> exactly what you asked for.
>
>
> Someone should probably add VecStride{Norm,Max,Min,Scale}All() to petsc4py.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110621/2bd51380/attachment.html>