[petsc-dev] Potential memory leak in PETSc - hypre interface when using Euclid

[Barry Smith]

  My quick examination of hypre.c shows the only relevant code in PETSc is 

 PetscCall(PetscOptionsEList("-pc_hypre_boomeramg_smooth_type", "Enable more complex smoothers", "None", HYPREBoomerAMGSmoothType, PETSC_STATIC_ARRAY_LENGTH(HYPREBoomerAMGSmoothType), HYPREBoomerAMGSmoothType[0], &indx, &flg));
  if (flg) {
    jac->smoothtype = indx;
    PetscCallExternal(HYPRE_BoomerAMGSetSmoothType, jac->hsolver, indx + 6);

In other words PETSc just sends this option off to hypre and does not create any objects or allocate any memory based on this option.

Thus my conclusion is the memory leak is within hypre. Likely valgrind would locate the exact position easily.

> On Oct 27, 2022, at 4:27 PM, Emil Constantinescu via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
> 
> Hi there,
> 
> Tang Qi (LANL) reported a potential memory leak when using hypre/Euclid. Upon rudimentary testing, I could reproduce it for many examples in PETSc TS. The symptom is memory usage (measured with top)  with the number of time steps. Without Euclid, memory use does not increase.
> 
> For instance, one can try ex15 under TS:
> 
> ex15  -da_grid_x 50 -da_grid_y 50 -boundary 0 -ts_max_steps 20 -Jtype 1 -ts_monitor -pc_type hypre -pc_hypre_boomeramg_smooth_type Euclid
> 
> I am not sure if it's PETSc - hypre that causes the memory use or hypre itself.
> 
> Can someone with more sophisticated tools take a look at it?
> 
> Emil