<div dir="ltr">Hi Barry,<div><br></div><div>Just added a PR for this. <a href="https://bitbucket.org/petsc/petsc/pull-requests/760/matresetpreallocation/diff">https://bitbucket.org/petsc/petsc/pull-requests/760/matresetpreallocation/diff</a></div><div><br></div><div><br></div><div>Fande,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 25, 2017 at 12:35 PM, Kong, Fande <span dir="ltr"><<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Sep 25, 2017 at 12:26 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Sep 25, 2017, at 1:17 PM, Kong, Fande <<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Sep 25, 2017 at 11:41 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Sep 25, 2017, at 11:22 AM, Kong, Fande <<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Sep 25, 2017 at 10:05 AM, Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>> wrote:<br>
> > If you know the union of the different sparsity patterns, after you preallocate you can set all zeros to use all the entries. This way PETSc will not complain about new nonzeros in successive assemblies.<br>
> ><br>
> ><br>
> > Thanks, Stefano,<br>
> ><br>
> > Yes, we are actually using this way right now. We are explicitly setting zeros to the matrix to stop petsc shrinking the memory.<br>
><br>
> This<br>
> > But we want to know why we free the extra memory? Yes, we shrink the memory by moving all data together to have an efficiency computation. But it is still possible to not throw away our preallocated memory space if we want to use latter.<br>
<br>
</span> We don't actually "throw out" the extra memory we just don't use it and it becomes unaccessible.<br>
<br>
Yes, one could actually keep the preallocation information. This would essentially require<br>
<br>
1) an additional array of length number of rows that is allocated and filled with the user provide nonzero counts when the user sets the preallocation (currently this information is lost when the matrix is "shrunk") and<br>
<br>
2) A API say MatResetPreallocation() that used this saved information to fill in the ilen and other integer arrays in the matrix as if the user had called MatPreallocateXXX() again.<br>
<br>
Actually now that I say this I realize it is pretty easy. You could make a pull request and introduce this functionality.<br></blockquote><div><br></div></span><div>Yes, this is what I want. I will be working on this and making a PR.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Fande,</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="m_-5530934836905249599HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="m_-5530934836905249599HOEnZb"><div class="m_-5530934836905249599h5"><br>
<br>
><br>
> contradicts this.<br>
><br>
> If at the beginning you put in all the zeros you will ever need then PETSc will not "throw away" preallocated space. Most likely you are not actually setting the initial nonzero structure using the union of all future nonzero structures.<br>
><br>
> We are explicitly setting zeros, and the code is working. But setting zeros is not a free function. In this email, I am trying to understand why we have to do in this way. If we could not throw away the extra memory when we do not explicitly set zeros, it would be nice.<br>
><br>
><br>
> If the nonzero structure changes dramatically over time, for instance if the mesh is moving around removing lots of old connections and introducing lots of new ones then you do not want to just preallocate. Instead you need to preallocate for each totally new nonzero structure.<br>
><br>
> There is no way to "preserve" the initial preallocation information through later time except by explicitly putting zero entries into the matrix.<br>
><br>
> OK. Got it.<br>
><br>
> Thanks,<br>
><br>
> Fande,<br>
><br>
><br>
> Barry<br>
><br>
> ><br>
> ><br>
> > Fande,<br>
> ><br>
> ><br>
> > Il 25 Set 2017 7:01 PM, "Kong, Fande" <<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>> ha scritto:<br>
> > Hi Matt,<br>
> ><br>
> > Thanks for your reply.<br>
> ><br>
> > The sparsity pattern is slightly different from one Newton iteration to another. We preallocate enough memory at the beginning, and want to use that memory for the following iterations.<br>
> ><br>
> > Does PETSc accutally free the preallocated (extra) memory? I so cannot use it during the second iteration.<br>
> ><br>
> ><br>
> ><br>
> > Fande,<br>
> ><br>
> > On Mon, Sep 25, 2017 at 9:43 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
> > On Mon, Sep 25, 2017 at 11:39 AM, Kong, Fande <<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>> wrote:<br>
> > Hi All,<br>
> ><br>
> > A matrix is created with the right preallocation, and then MatAssembly is called. The preallocation info will be removed. We insert any values then, and will encounter an malloc error.<br>
> ><br>
> > My question is that we was intending to design like this way? Attached simple example demonstrates what I am talking about.<br>
> ><br>
> > Yes, this is the intent. Why are you assembling? Could you use MAT_ASSEMBLY_FLUSH?<br>
> ><br>
> > Matt<br>
> ><br>
> ><br>
> > Fande,<br>
> ><br>
> ><br>
> ><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>
> ><br>
> > <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cse.buffalo.edu_-7Eknepley_&d=DwIFAg&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=U9L00IdHyC-4OTIJws8B4BeQTX1DBhNdzqB-NGUI3Es&s=ZakQrYVOAFg6ShY9i0MSYHkgGWvqwRfACulWOiIX07o&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__www.cse<wbr>.buffalo.edu_-7Eknepley_&d=DwI<wbr>FAg&c=54IZrppPQZKX9mLzcGdPfFD1<wbr>hxrcB__aEkJFOKJFd00&r=<wbr>DUUt3SRGI0_JgtNaS3udV68GRkgV4t<wbr>s7XKfj2opmiCY&m=U9L00IdHyC-4OT<wbr>IJws8B4BeQTX1DBhNdzqB-NGUI3Es&<wbr>s=ZakQrYVOAFg6ShY9i0MSYHkgGWvq<wbr>wRfACulWOiIX07o&e=</a><br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>