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

[Pierre Jolivet]

> On 29 Oct 2022, at 12:55 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> I think you mean 2.25 versus 2.26, and we can use --download-hypre-commit=origin/v2.26.0 to test if the Euclid issue is fixed (likely no because Euclid hasn't seen much activity this release cycle).

Yes, got the release numbers mixed up, sorry.
I tried yesterday on my box with Valgrind and I got the same leak as you, so your intuition is correct.

Thanks,
Pierre

> Pierre Jolivet <pierre at joliv.et> writes:
> 
>> Please do note that we are currently stuck with version 2.15.0
>> They broke something — using make instead of $(MAKE) — in 2.16.0 which is making PETSc pipelines fail on FreeBSD boxes, cf. https://github.com/hypre-space/hypre/issues/755#issuecomment-1279336057.
>> We won’t be able to update hypre.py until this is resolved (or we would have to remove --download-hypre from FreeBSD runners, or stick to --download-hypre-commit=origin/v2.15.0).
>> Satish, could you please try to ping Rob about this? Maybe you’ll have more leverage, and maybe the leak is fixed in 2.16.0?
>> 
>> Thanks,
>> Pierre
>> 
>>>> On 27 Oct 2022, at 11:43 PM, Zhang, Hong via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
>>> 
>>> 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
>>>> 
>>>