[petsc-dev] MatAssembly removes all preallocation info

[Kong, Fande]

On Mon, Sep 25, 2017 at 12:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> > On Sep 25, 2017, at 1:17 PM, Kong, Fande <fande.kong at inl.gov> wrote:
> >
> >
> >
> > On Mon, Sep 25, 2017 at 11:41 AM, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> >
> > > On Sep 25, 2017, at 11:22 AM, Kong, Fande <fande.kong at inl.gov> wrote:
> > >
> > >
> > >
> > > On Mon, Sep 25, 2017 at 10:05 AM, Stefano Zampini <
> stefano.zampini at gmail.com> wrote:
> > > 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.
> > >
> > >
> > > Thanks, Stefano,
> > >
> > > Yes, we are actually using this way right now. We are explicitly
> setting zeros to the matrix to stop petsc shrinking the memory.
> >
> >    This
> > >  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.
>
>    We don't actually "throw out" the extra memory we just don't use it and
> it becomes unaccessible.
>
>    Yes, one could actually keep the preallocation information. This would
> essentially require
>
> 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
>
> 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.
>
>   Actually now that I say this I realize it is pretty easy. You could make
> a pull request and introduce this functionality.
>

Yes, this is what I want. I will be working on this and making a PR.

Fande,


>
>   Barry
>
>
> >
> >    contradicts this.
> >
> >    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.
> >
> > 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.
> >
> >
> >    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.
> >
> >    There is no way to "preserve" the initial preallocation information
> through later time except by explicitly putting zero entries into the
> matrix.
> >
> > OK. Got it.
> >
> > Thanks,
> >
> > Fande,
> >
> >
> >   Barry
> >
> > >
> > >
> > > Fande,
> > >
> > >
> > > Il 25 Set 2017 7:01 PM, "Kong, Fande" <fande.kong at inl.gov> ha scritto:
> > > Hi Matt,
> > >
> > > Thanks for your reply.
> > >
> > > 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.
> > >
> > > Does PETSc accutally free the preallocated (extra) memory? I so cannot
> use it during the second iteration.
> > >
> > >
> > >
> > > Fande,
> > >
> > > On Mon, Sep 25, 2017 at 9:43 AM, Matthew Knepley <knepley at gmail.com>
> wrote:
> > > On Mon, Sep 25, 2017 at 11:39 AM, Kong, Fande <fande.kong at inl.gov>
> wrote:
> > > Hi All,
> > >
> > > 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.
> > >
> > > My question is that we was intending to design like this way? Attached
> simple example demonstrates what I am talking about.
> > >
> > > Yes, this is the intent. Why are you assembling? Could you use
> MAT_ASSEMBLY_FLUSH?
> > >
> > >   Matt
> > >
> > >
> > > Fande,
> > >
> > >
> > >
> > > --
> > > 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
> > >
> > > 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=ZakQrYVOAFg6ShY9i0MSYHkgGWvqwR
> fACulWOiIX07o&e=
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170925/fb508ea0/attachment-0001.html>