[petsc-dev] MatAssembly removes all preallocation info

[Kong, Fande]

Hi Barry,

Just added a PR for this.
https://bitbucket.org/petsc/petsc/pull-requests/760/matresetpreallocation/diff


Fande,

On Mon, Sep 25, 2017 at 12:35 PM, Kong, Fande <fande.kong at inl.gov> wrote:

>
>
> 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=54IZrppPQZKX9mLzcGdPfFD1
>> hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4t
>> s7XKfj2opmiCY&m=U9L00IdHyC-4OTIJws8B4BeQTX1DBhNdzqB-NGUI3Es&
>> s=ZakQrYVOAFg6ShY9i0MSYHkgGWvqwRfACulWOiIX07o&e=
>> > >
>> > >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170927/0ef447e7/attachment.html>