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

[Pierre Jolivet]

It appears this is a bug in the PETSc interface to hypre: https://github.com/hypre-space/hypre/issues/764

Thanks,
Pierre

> On 29 Oct 2022, at 5:56 AM, Pierre Jolivet <pierre at joliv.et> wrote:
> 
> 
> 
>> 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
>>>>> 
>>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20221031/1b6e34ad/attachment.html>