[petsc-dev] VECCUSP needs to be zeroed?

[Matthew Knepley]

On Wed, Nov 9, 2011 at 4:06 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Wed, Nov 9, 2011 at 09:57, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>
>> Are you 100% sure about this? What's the point of wasting cycles by
>> explicitly calling Memzero in VecCreate_Seq? I bet may codes out there
>> (and even PETSc's testsuite) will break if you do not initialize all
>> entries to zero! For example, if you create a Vec or Mat and
>> immediately enter a loop using {Vec|Mat}SetValues(..., ADD_VALUES), I
>> think most people would expect this to work.
>>
>
> In practice, they are initialized to prevent constant support requests. If
> we intend for it to "mean" uninitialized, then Memzero in VecCreate_Seq()
> should be turned off when run under Valgrind, so that we can find places
> where the assumption is made.
>
> This is not nearly as simple as it may seem on NUMA. You want to fault the
> memory in the same pattern as it will be used later. It would be hard for
> Memzero to know how you wanted the memory faulted, so it would be expected
> to fault the memory incorrectly. Either we need a way to specify a locality
> (maybe as a coloring) so that Memzero can be correctly threaded, or we
> should NOT initialize the memory and rely on the user to do that. As much
> of a hassle as the latter is, it's still not a complete solution because
> all the Vec operations should use threads with the same memory distribution
> as mesh traversal.
>
> For the hardware, it is probably sufficient to make the NUMA partition
> either full blocks or interleaved at page-size granularity.
>

The simpler answer is yes, I always initialize the Mat or Vec to zero when
I use it. Even if its initialized when created,
I almost always get something from DMGetGlobalVector() etc. which could
have been used before.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111109/8073763a/attachment.html>