April 2011 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] memory leaks in BCGSL when using KSPReset()
by Lisandro Dalcin 12 Apr '11

12 Apr '11

On 12 April 2011 10:26, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Apr 11, 2011, at 10:02 PM, Lisandro Dalcin wrote: > >> After adding this test in petsc4py-dev/test/test_ksp.py : >> >> def testResetAndSolve(self): >> self.ksp.reset() >> self.testSolve() >> self.ksp.reset() >> self.testSolve() >> self.ksp.reset() >> >> it seems there is some memory bleeding: >> >> [0]Total space allocated 256 bytes >> [ 0]80 bytes KSPSetUp_BCGSL() line 476 in >> /home/devel/petsc/dev/src/ksp/ksp/impls/bcgsl/bcgsl.c >> [0] KSPSetUp() line 184 in >> /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c >> [0] KSPSolve() line 332 in >> /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c >> >> These are workspace arrays that are re-allocated at every KSPSetup_BCGSL call. >> >> Not sure about the proper way to fix this, but I would deallocate the >> arrays at KSPReset_BCGSL. Can anyone help me with this? >> > This could be a problem in many places: for example if eigenvalue computing is done with CG then I think those arrays will be reallocated. > Indeed. I'm not testing eigenvalue computing. I could try to add the options to my testsuite and see what happens. > Previously I guess KSPSetUp_XXX() never had a reason to be called more than once, with reset now it is. So that means that all arrays allocated in KSPSetUp_XXX() should be freed in KSPReset_XXX()? If this is correct then it is easily fixed by moving them from KSPDestroy_XXX(). > Well, In my latest push I was lazy enough as to not remove the PetscFree() call to Reset_XXX. After all, PetscFree() nullifies the pointer, so we are safe. If you want me to fix this, let me know. PS: Barry, could you check BCGLS for a few "ksp->setupstage = KSP_SETUP_NEW;" lines? This really smells, such approach forces a full KSPSetup(), not just the subype. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] memory leaks in BCGSL when using KSPReset()
by Lisandro Dalcin 12 Apr '11

12 Apr '11

On 12 April 2011 00:50, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Tue, 12 Apr 2011, Lisandro Dalcin wrote: > >> After adding this test in petsc4py-dev/test/test_ksp.py : >> >> def testResetAndSolve(self): >> self.ksp.reset() >> self.testSolve() >> self.ksp.reset() >> self.testSolve() >> self.ksp.reset() >> >> it seems there is some memory bleeding: >> >> [0]Total space allocated 256 bytes >> [ 0]80 bytes KSPSetUp_BCGSL() line 476 in >> /home/devel/petsc/dev/src/ksp/ksp/impls/bcgsl/bcgsl.c >> [0] KSPSetUp() line 184 in >> /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c >> [0] KSPSolve() line 332 in >> /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c >> >> These are workspace arrays that are re-allocated at every KSPSetup_BCGSL call. >> >> Not sure about the proper way to fix this, but I would deallocate the >> arrays at KSPReset_BCGSL. Can anyone help me with this? >> Never mind, I've pushed the fix I proposed above. >> >> PS: Will we ever have petsc4py in the nightly builds? Is there >> something to be done from my side? > > Sorry - will check on adding one.. > I was not complaining. But I think petsc4py do help to catch bugs in core PETSc. BTW, take a look here: http://code.google.com/p/petsc4py/source/browse/misc/makefile.dev . Ideally, you should test many PETSC_ARCH's as possible. PS: Could you add mpiuni+single+complex to the nighties? I recently fixed an mpiuni issue for this case. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] memory leaks in BCGSL when using KSPReset()
by Barry Smith 12 Apr '11

12 Apr '11

On Apr 11, 2011, at 10:02 PM, Lisandro Dalcin wrote: > After adding this test in petsc4py-dev/test/test_ksp.py : > > def testResetAndSolve(self): > self.ksp.reset() > self.testSolve() > self.ksp.reset() > self.testSolve() > self.ksp.reset() > > it seems there is some memory bleeding: > > [0]Total space allocated 256 bytes > [ 0]80 bytes KSPSetUp_BCGSL() line 476 in > /home/devel/petsc/dev/src/ksp/ksp/impls/bcgsl/bcgsl.c > [0] KSPSetUp() line 184 in > /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c > [0] KSPSolve() line 332 in > /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c > > These are workspace arrays that are re-allocated at every KSPSetup_BCGSL call. > > Not sure about the proper way to fix this, but I would deallocate the > arrays at KSPReset_BCGSL. Can anyone help me with this? > This could be a problem in many places: for example if eigenvalue computing is done with CG then I think those arrays will be reallocated. Previously I guess KSPSetUp_XXX() never had a reason to be called more than once, with reset now it is. So that means that all arrays allocated in KSPSetUp_XXX() should be freed in KSPReset_XXX()? If this is correct then it is easily fixed by moving them from KSPDestroy_XXX(). Barry > > PS: Will we ever have petsc4py in the nightly builds? Is there > something to be done from my side? > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] memory leaks in BCGSL when using KSPReset()
by Satish Balay 11 Apr '11

11 Apr '11

On Tue, 12 Apr 2011, Lisandro Dalcin wrote: > After adding this test in petsc4py-dev/test/test_ksp.py : > > def testResetAndSolve(self): > self.ksp.reset() > self.testSolve() > self.ksp.reset() > self.testSolve() > self.ksp.reset() > > it seems there is some memory bleeding: > > [0]Total space allocated 256 bytes > [ 0]80 bytes KSPSetUp_BCGSL() line 476 in > /home/devel/petsc/dev/src/ksp/ksp/impls/bcgsl/bcgsl.c > [0] KSPSetUp() line 184 in > /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c > [0] KSPSolve() line 332 in > /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c > > These are workspace arrays that are re-allocated at every KSPSetup_BCGSL call. > > Not sure about the proper way to fix this, but I would deallocate the > arrays at KSPReset_BCGSL. Can anyone help me with this? > > > PS: Will we ever have petsc4py in the nightly builds? Is there > something to be done from my side? Sorry - will check on adding one.. Satish

1 0

memory leaks in BCGSL when using KSPReset()
by Lisandro Dalcin 11 Apr '11

11 Apr '11

After adding this test in petsc4py-dev/test/test_ksp.py : def testResetAndSolve(self): self.ksp.reset() self.testSolve() self.ksp.reset() self.testSolve() self.ksp.reset() it seems there is some memory bleeding: [0]Total space allocated 256 bytes [ 0]80 bytes KSPSetUp_BCGSL() line 476 in /home/devel/petsc/dev/src/ksp/ksp/impls/bcgsl/bcgsl.c [0] KSPSetUp() line 184 in /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c [0] KSPSolve() line 332 in /home/devel/petsc/dev/src/ksp/ksp/interface/itfunc.c These are workspace arrays that are re-allocated at every KSPSetup_BCGSL call. Not sure about the proper way to fix this, but I would deallocate the arrays at KSPReset_BCGSL. Can anyone help me with this? PS: Will we ever have petsc4py in the nightly builds? Is there something to be done from my side? -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Barry Smith 11 Apr '11

11 Apr '11

On Apr 11, 2011, at 10:07 AM, Lisandro Dalcin wrote: > Barry, I'm working on getting petsc4py ready for our XXXDestroy > change. A quick question: Are the XXXDestroy_YYY functions of subtypes > going to change? I would ask you to NOT change them (it's harder for > you to implement, it's harder for me to provide backward > compatibility, IMHO there is not a compelling reason as these > destructors should not set the pointer to zero, etc.). I did a great deal of changes one day but have been totally sidetracked by proposals since then so have not concluded the process. I'll take your concerns into consideration, at first glance it does seem unnecessary and possibly even bad to pass the pointer down into the XXXDestroy_YYY Barry > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Jed Brown 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 18:06, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Hey!... Isn't that the model of DA's in petsc-dev? My current issues > in petsc4py are more realted to backward compatibility than anything. > But even if I manage to remove the #define DA DM, petsc4py will still > use DA for the class name (unless there is some strong arguments from > any of you). > There is no such thing as a DA in petsc-dev. As far as the C type system is concerned, there is only DM. The dynamic type may be DMDA, but that is not revealed to the type system. I'm not saying I agree with this choice, but that's the way it is. This difference in object model is the impedance mismatch that "typedef DM DA" is covering. Petsc4py does not have GMRES as a visible subtype of KSP, nor ASM as a subtype of PC, etc. > > It is not useful to C callers without also having > > petsc4py/src/include/custom.h. > > I you use the new DMDAxxx API' from petsc-dev, you should not need > petsc4py/src/include/custom.h at all... It is just the #define DA DM, > and that is required only for the case of using "cimport" in Cython > code (I mean, SWIG wrappers or hand-written C should not suffer from > this issue). > This means that you have to update your code to the new interface. Matt seemed to be asserting that petsccompat.h was for backward compatibility (a way to build your old 3.1 code using petsc-dev/3.2) which is something PETSc has never supported. I would not immediately object to maintaining one version of backward compatibility when a macro is activated, but it's a slippery slope. In any case, include/petsccompat.h does not currently provide backward compatibility in any meaningful sense.

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Lisandro Dalcin 11 Apr '11

11 Apr '11

On 11 April 2011 12:56, Jed Brown <jed(a)59a2.org> wrote: > On Mon, Apr 11, 2011 at 17:51, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> Not only is it useful, its needed by petsc4py :) > > Only because petsc4py is managing a different object model where "DA" is a > subtype of "DM". Hey!... Isn't that the model of DA's in petsc-dev? My current issues in petsc4py are more realted to backward compatibility than anything. But even if I manage to remove the #define DA DM, petsc4py will still use DA for the class name (unless there is some strong arguments from any of you). > It is not useful to C callers without also having > petsc4py/src/include/custom.h. I you use the new DMDAxxx API' from petsc-dev, you should not need petsc4py/src/include/custom.h at all... It is just the #define DA DM, and that is required only for the case of using "cimport" in Cython code (I mean, SWIG wrappers or hand-written C should not suffer from this issue). -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Lisandro Dalcin 11 Apr '11

11 Apr '11

On 11 April 2011 12:51, Matthew Knepley <knepley(a)gmail.com> wrote: > On Mon, Apr 11, 2011 at 10:45 AM, Jed Brown <jed(a)59a2.org> wrote: >> >> On Mon, Apr 11, 2011 at 17:43, Matthew Knepley <knepley(a)gmail.com> wrote: >>> >>> Lisandro, this is now include/petsccompat.h >> Yes, I noticed it when you added it. >> The file exists, but its contents are not currently useful. > But the intention is to make it useful. > Not only is it useful, its needed by petsc4py :) > Matt > But just when using Cython's "cimport" statement. Hopefully, I'll be able to get rid of this hack. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Jed Brown 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 17:51, Matthew Knepley <knepley(a)gmail.com> wrote: > Not only is it useful, its needed by petsc4py :) Only because petsc4py is managing a different object model where "DA" is a subtype of "DM". It is not useful to C callers without also having petsc4py/src/include/custom.h.

1 0