CCing Ruipeng. I think he can help with this.
Hong (Mr.)
> On Oct 27, 2022, at 3:53 PM, Barry Smith <bsm...@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@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
>
