<p>Barry, </p>
<p>>> Do not call MatZeroEntries on a freshly created matrix (that destroys the preallocation pattern) so skip the MatZeroEntries the first time.<br>
I found an earlier thread (<a href="http://lists.mcs.anl.gov/pipermail/petsc-users/2011-April/008566.html">http://lists.mcs.anl.gov/pipermail/petsc-users/2011-April/008566.html</a>) where you said that it would not destroy the preallocation too. </p>
<p>So is the behavior different in the dev version ?</p>
<p>Vijay</p>
<div class="gmail_quote">On Jul 5, 2011 8:03 PM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br type="attribution">> <br>> On Jul 5, 2011, at 5:42 PM, Lisandro Dalcin wrote:<br>
> <br>>> On 5 July 2011 17:35, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>>>> <br>>>>> Beginning of a time step (1st implicit stage of RK scheme):<br>
>>>> 1. Use MatZeroEntries on the preconditioner<br>>>> <br>>>> Do not call MatZeroEntries on a freshly created matrix (that destroys the preallocation pattern) so skip the MatZeroEntries the first time.<br>
>>> <br>>> <br>>> What do you mean? The OP said that the nonzero structure was set at<br>>> problem set up.<br>> <br>> Perhaps I miss understood. I interpreted that to mean the matrix was provided with the correct preallocation information (and not the nonzero structure) but yes if the nonzero structure is already set then one can call MatZeroEntries() at that point.<br>
> <br>> Perhaps we should "fix" MatZeroEntries()" to not screw up preallocation information!<br>> <br>> Barry<br>> <br>> <br>>> <br>>> -- <br>>> Lisandro Dalcin<br>
>> ---------------<br>>> CIMEC (INTEC/CONICET-UNL)<br>>> Predio CONICET-Santa Fe<br>>> Colectora RN 168 Km 472, Paraje El Pozo<br>>> 3000 Santa Fe, Argentina<br>>> Tel: +54-342-4511594 (ext 1011)<br>
>> Tel/Fax: +54-342-4511169<br>> <br></div>