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

[Zhang, Hong]

CCing Ruipeng. I think he can help with this.

Hong (Mr.)

> On Oct 27, 2022, at 3:53 PM, Barry Smith <bsmith at petsc.dev> wrote:
> 
> 
>  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
>