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 <[email protected]> wrote: > > > On Mon, Sep 25, 2017 at 12:26 PM, Barry Smith <[email protected]> wrote: > >> >> > On Sep 25, 2017, at 1:17 PM, Kong, Fande <[email protected]> wrote: >> > >> > >> > >> > On Mon, Sep 25, 2017 at 11:41 AM, Barry Smith <[email protected]> >> wrote: >> > >> > > On Sep 25, 2017, at 11:22 AM, Kong, Fande <[email protected]> wrote: >> > > >> > > >> > > >> > > On Mon, Sep 25, 2017 at 10:05 AM, Stefano Zampini < >> [email protected]> 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" <[email protected]> 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 <[email protected]> >> wrote: >> > > On Mon, Sep 25, 2017 at 11:39 AM, Kong, Fande <[email protected]> >> 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= >> > > >> > > >> >> >
