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

[Jed Brown]

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).

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