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
