<div dir="ltr">PETSc could also just provide a VecReduce and VecReduceStride operation, which might simplify the programming effort a bit.<div><br></div><div>A<br><br><div class="gmail_quote">On Tue, Jun 21, 2011 at 7:53 PM, Jed Brown <span dir="ltr"><<a href="mailto:five9a2@gmail.com">five9a2@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><div class="gmail_quote">On Tue, Jun 21, 2011 at 18:25, David Ketcheson <span dir="ltr"><<a href="mailto:david.ketcheson@kaust.edu.sa" target="_blank">david.ketcheson@kaust.edu.sa</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Thanks, Jed.  We actually just want the sum, but since all values are positive, your suggestion will work.<div><br></div><div>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.</div>

</div></blockquote></div><br></div><div>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.</div>

<div><br></div><div>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).</div>

<div><br></div><div>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.</div>

<div><br></div><div><br></div><div>Someone should probably add VecStride{Norm,Max,Min,Scale}All() to petsc4py.</div>
</blockquote></div><br></div></div>