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@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
