On Mon, Jul 24, 2017 at 9:36 AM, Jed Brown <j...@jedbrown.org> wrote:
> "Kong, Fande" <fande.k...@inl.gov> writes: > > > On Sun, Jul 23, 2017 at 5:31 PM, Jed Brown <j...@jedbrown.org> wrote: > > > >> Barry Smith <bsm...@mcs.anl.gov> writes: > >> > >> > Anything stopping us from making a PETSc release? > >> > >> I need to finish/test the SF support for MPIUNI that you asked me to do > >> in June. > >> > >> I've also been meaning to add hashtable support for assembly when people > >> don't preallocate. I think we should make it automatic. It isn't much > >> code and would save the weekly assembly performance emails and would > >> help a lot for model coupling where our preallocation interfaces (for > >> off-diagonal blocks) are terrible and the requisite user code is > >> arguably dirtier than assembly itself. > >> > > > > > > I am so interested in this. I am having hard time to make the > > preallocation right for users because they have all kinds of crazy > physics > > that coupling different PDEs together based on their own rules. So if we > > could make the preallocate work automatically, it would be great. > > > > If we have this code in, the preallocation is not necessary for users any > > more? Still worthwhile to have the right preallocation if possible? > > Correct. The hash needs to be converted to a matrix so the maximum > memory usage is about double that of precise preallocation in advance. > Will the memory be released in the hash after assembling the matrix? > But this is only the first assembly, which is usually done before > setting up preconditioners and Krylov spaces so in most cases would not > significantly affect the maximum memory usage of the application. > If the nonzero structure changes over Newton iterations, and the maximum memory usage of the application may be larger than that with the precise preallocation. Fande,