On Tue, Feb 24, 2009 at 3:47 PM, Yixun Liu <span dir="ltr"><<a href="mailto:enjoywm@cs.wm.edu">enjoywm@cs.wm.edu</a>></span> wrote<br><div class="gmail_quote">You mean I have no need to call<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
VecSet(v, 0.0); and<br>
MatZeroEntries(mat);<br>
<br>
after I set the size for the vector or matrix?<br><div><div class="Wj3C7c"></div></div></blockquote><div><br>Yes, do not call them.<br><br> Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="Wj3C7c">
Barry Smith wrote:<br>
><br>
> Jed is right. Our intention is to have the vector initialized to zero<br>
> at creation time IF we allocate the array space.<br>
> Tracking down a not properly initialized vector is the type of bug<br>
> that takes forever to find; plus I wanted consistency<br>
> between vectors and matrix. Users SHOULD NOT call a MatZeroEntries()<br>
> initially on matrices (since it screws up<br>
> preallocation) so we should not have them do it on vectors either for<br>
> consistency.<br>
><br>
> Barry<br>
><br>
> On Feb 24, 2009, at 10:57 AM, Jed Brown wrote:<br>
><br>
>> On Tue 2009-02-24 06:53, Matthew Knepley wrote:<br>
>>> On Mon, Feb 23, 2009 at 8:26 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>><br>
>>> wrote:<br>
>>><br>
>>><br>
>>> Vectors have all entries equal to zero. Dense matrices have all entries<br>
>>> equal to zero. Sparse matrices have no entries (logically this is<br>
>>> the same<br>
>>> as entries equal to zero).<br>
>>><br>
>>><br>
>>> We do not automatically zero the entires upon allocation. You have<br>
>>> to call<br>
>>> VecZeroEntries() or VecSet()<br>
>>> to initialize the vector.<br>
>><br>
>> That's what I would have expected, but Barry is correct, at least for<br>
>> the usual types. See, for instance<br>
>><br>
>> PetscErrorCode PETSCVEC_DLLEXPORT VecCreate_Seq(Vec V)<br>
>> {<br>
>> Vec_Seq *s;<br>
>> PetscScalar *array;<br>
>> PetscErrorCode ierr;<br>
>> PetscInt n = PetscMax(V->map->n,V->map->N);<br>
>> PetscMPIInt size;<br>
>><br>
>> PetscFunctionBegin;<br>
>> ierr = MPI_Comm_size(((PetscObject)V)->comm,&size);CHKERRQ(ierr);<br>
>> if (size > 1) {<br>
>> SETERRQ(PETSC_ERR_ARG_WRONG,"Cannot create VECSEQ on more than one<br>
>> process");<br>
>> }<br>
>> ierr = PetscMalloc(n*sizeof(PetscScalar),&array);CHKERRQ(ierr);<br>
>> ierr = PetscLogObjectMemory(V, n*sizeof(PetscScalar));CHKERRQ(ierr);<br>
>> ierr = PetscMemzero(array,n*sizeof(PetscScalar));CHKERRQ(ierr);<br>
>> ierr = VecCreate_Seq_Private(V,array);CHKERRQ(ierr);<br>
>> s = (Vec_Seq*)V->data;<br>
>> s->array_allocated = array;<br>
>> PetscFunctionReturn(0);<br>
>> }<br>
>><br>
>><br>
>><br>
>> In well-structured code, the cost of zeroing the vector is tiny and the<br>
>> effort to track down uninitialized bugs is significant enough that this<br>
>> seems like a sane default.<br>
>><br>
>> Jed<br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>