> On Nov 18, 2014, at 11:54 AM, Miguel Angel Salazar de Troya
> <[email protected]> wrote:
>
> PetscFinalize() is inside of the class destructor (the last line of the
> destructor), so when the object goes out of scope, the class destructor is
> called and PetscFinalize() as well. Is it better to have PetscFinalize()
> outside of the destructor and call the destructor explicitly before?
It shouldn't really matter.
My guess is you must be missing calling a destroy or restore on one of the
PETSc objects.
Barry
>
> Miguel
>
> On Tue, Nov 18, 2014 at 11:32 AM, Barry Smith <[email protected]> wrote:
>
> > On Nov 18, 2014, at 11:19 AM, Miguel Angel Salazar de Troya
> > <[email protected]> wrote:
> >
> > Hi
> >
> > I'm implementing a problem using the TS. Most of my functions are methods
> > inside of a class, except for the callbacks (to form the RHS and the TS
> > monitor), which are outside of the class, although in the same .C file
> > where the class methods are implemented. For these callbacks I followed the
> > network example:
> >
> > https://bitbucket.org/petsc/petsc/src/a614f7369d93d476173b8fc6bf2463276dcbdb3a/src/snes/examples/tutorials/network/pflow/pf.c?at=master
> >
> > Therefore, the callbacks have the PetscFunctionBegin at the beginning and
> > PetscFunctionReturn(0) at the end. My problems come when I run the program
> > with -malloc_dump and I get a lot of unfreed memory. Inspecting the output
> > I see that the line of my code where the memory is allocated corresponds
> > with the line when PetscFunctionBegin is called.
>
> This is normal. We cannot register the exact line the memory allocated,
> only the location of the PETScFunctionBegin;
>
>
> > Later in the file, I see that the function DMGetLocalVector() is called
> > within a petsc internal routine (at the file dmget.c). I also call this
> > routine in my callback methods few lines after PetscFunctionBegin. The
> > procedure that I follow to use the local vectors is as the one in the
> > network example. For vectors that I want to modify this is:
> >
> > ierr = DMGetLocalVector(networkdm,&localX);CHKERRQ(ierr);
> > ierr =
> > DMGlobalToLocalBegin(networkdm,X,INSERT_VALUES,localX);CHKERRQ(ierr);
> > ierr = DMGlobalToLocalEnd(networkdm,X,INSERT_VALUES,localX);CHKERRQ(ierr);
> > ierr = VecGetArray(localX,&xarr);CHKERRQ(ierr);
> >
> > Modify values in xarr
> >
> > ierr = VecRestoreArray(localX,&xarr);CHKERRQ(ierr);
> > ierr =
> > DMLocalToGlobalBegin(networkdm,localX,INSERT_VALUES,X);CHKERRQ(ierr);
> > ierr = DMLocalToGlobalEnd(networkdm,localX,INSERT_VALUES,X);CHKERRQ(ierr);
> > ierr = DMRestoreLocalVector(networkdm,&localX);CHKERRQ(ierr);
> >
> > One last thing that I think it might be a issue here is how I destroy the
> > petsc objects. I create the petsc objects within a class. For instance, the
> > class has a petsc vector that later passes to the TS object to get the
> > solution. To destroy the petsc objects, I use the class destructor, where
> > at the end I call PetscFinalize() Inside the class I pass the callbacks to
> > the TS routines that need them (e.g. TSSetRHSFunction() ) I can compile the
> > code and run it, but many memory allocations are not freed. What can be the
> > issue here? Do you know of an example using C++ classes to implement PETSc
> > methods? Thanks in advance.
>
> Do you call the class destructor yourself explicitly before the
> PetscFinalize()? You need to, otherwise the class may not be destroyed until
> after PetscFinalize() and hence the PETSc objects won't be freed when you
> call PetscFinalize().
>
> You also need to make sure that you destroy ALL PETSc objects, if you miss
> even one PETSc object, since the objects have references to each other it may
> be that many PETSc objects do not get freed and hence -malloc_dump shows many
> objects still alive.
>
> Barry
>
> >
> > Miguel
> >
> > --
> > Miguel Angel Salazar de Troya
> > Graduate Research Assistant
> > Department of Mechanical Science and Engineering
> > University of Illinois at Urbana-Champaign
> > (217) 550-2360
> > [email protected]
> >
>
>
>
>
> --
> Miguel Angel Salazar de Troya
> Graduate Research Assistant
> Department of Mechanical Science and Engineering
> University of Illinois at Urbana-Champaign
> (217) 550-2360
> [email protected]
>
