leaks in multiple calls for preallocating AIJ matrices

[Lisandro Dalcin]

So the rule should be the one below?:

if (A->was_assembled || A->assembled)
  SETERRQ(...)

or perhaps:

if (A->preallocated && (A->was_assembled || A->assembled))
  SETERRQ(...)

I'm not sure what to follow, regarding that PETSc use some inheritance
tricks for some matrix types, like AIJMUMPS.

BTW, now I think this change can impact user-code, so better push this
only on petsc-dev.



On 10/25/07, Matthew Knepley <knepley at gmail.com> wrote:
> I agree that you should not be able to reset the preallocation after
> assembly, Unless you change the type (meaning recreate the impl).
>
>   Matt
>
> On 10/25/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> > I have the fix almost ready, but a new issue arises and I want to know
> > your opinions
> >
> > What to do if MatXXXSetPreallocation() is called after a matrix was
> > assembled? Should we generate an error? See the behavior of this in
> > action with a simple python snipet of code:
> >
> > A = PETSc.Mat().create()
> > A.setSizes([5,5])
> > A.setFromOptions()
> > A.setPreallocation(nz=3)
> > for i in range(5): A[i,i] = 1
> > A.assemble()
> > A.view()
> > print
> > A.setPreallocation(nz=3)
> > A.view()
> >
> > the output of this is
> >
> > row 0: (0, 1)
> > row 1: (1, 1)
> > row 2: (2, 1)
> > row 3: (3, 1)
> > row 4: (4, 1)
> >
> > row 0: (0, 0)  (0, 0)  (0, 0)
> > row 1: (0, 0)  (0, 0)  (0, 0)
> > row 2: (0, 0)  (0, 0)  (0, 0)
> > row 3: (0, 0)  (0, 0)  (0, 0)
> > row 4: (0, 0)  (0, 0)  (0, 0)
> >
> > The matrix structure is completely broken. The easiest way to go is
> > not enable users to reset preallocation if the matrix was ever
> > assembled.
> >
> > What do you think?
> >
> >
> > On 10/23/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > >
> > >   Fine.
> > >
> > > On Tue, 23 Oct 2007, Lisandro Dalcin wrote:
> > >
> > > > Of course, the space that can be reutilized are the arrays with
> > > > preallocation info, not the ones with actual matrix entries (a,i,j).
> > > >
> > > > On 10/23/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> > > > > Looking at the actual code, it seems there is not need to actually
> > > > > reallocate space, the same space can be reutilized. Do you think I'm
> > > > > missing something?
> > > > >
> > > > > And please, tell me: should I fix this in release-2.3.3? I believe
> > > > > this will not impact previous user code in any way.
> > > > >
> > > > >
> > > > >
> > > > > On 10/23/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > > > >
> > > > > >   Lisandro,
> > > > > >
> > > > > >     I agree we should support multiple calls (or at worst generate an
> > > > > > error on the second call). Presumably the specific
> > > > > > MatXXXYYYSetPreallocation() routines would simply free up their
> > > > > > current points and then (as it does now) allocate the appropriate new
> > > > > > space. Feel free to add this.
> > > > > >
> > > > > >    Barry
> > > > > >
> > > > > >
> > > > > > On Mon, 22 Oct 2007, Lisandro Dalcin wrote:
> > > > > >
> > > > > > > Currently, making sucessive calls for preallocating AIJ matrices seem
> > > > > > > to originate memory leaks.
> > > > > > >
> > > > > > > How should this be corrected? I would prefer that this is a valid
> > > > > > > operation, and fix appropriate routines to deallocate/reuse previous
> > > > > > > memory, and set the new user-specified preallocation data.
> > > > > > >
> > > > > > > Other point: should this fix go to release-2.3.3?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lisandro Dalcín
> > > > > ---------------
> > > > > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> > > > > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> > > > > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> > > > > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> > > > > Tel/Fax: +54-(0)342-451.1594
> > > > >
> > > >
> > > >
> > > >
> >
> >
> > --
> > Lisandro Dalcín
> > ---------------
> > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> > Tel/Fax: +54-(0)342-451.1594
> >
> >
>
>
> --
> 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
>
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594