<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">It appears this is a bug in the PETSc interface to hypre: <a href="https://github.com/hypre-space/hypre/issues/764">https://github.com/hypre-space/hypre/issues/764</a><div><br></div><div>Thanks,</div><div>Pierre<br><div><br><blockquote type="cite"><div>On 29 Oct 2022, at 5:56 AM, Pierre Jolivet <pierre@joliv.et> wrote:</div><br class="Apple-interchange-newline"><div><div><br><br><blockquote type="cite">On 29 Oct 2022, at 12:55 AM, Jed Brown <jed@jedbrown.org> wrote:<br><br>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).<br></blockquote><br>Yes, got the release numbers mixed up, sorry.<br>I tried yesterday on my box with Valgrind and I got the same leak as you, so your intuition is correct.<br><br>Thanks,<br>Pierre<br><br><blockquote type="cite">Pierre Jolivet <pierre@joliv.et> writes:<br><br><blockquote type="cite">Please do note that we are currently stuck with version 2.15.0<br>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.<br>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).<br>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?<br><br>Thanks,<br>Pierre<br><br><blockquote type="cite"><blockquote type="cite">On 27 Oct 2022, at 11:43 PM, Zhang, Hong via petsc-dev <petsc-dev@mcs.anl.gov> wrote:<br></blockquote><br>CCing Ruipeng. I think he can help with this.<br><br>Hong (Mr.)<br><br><blockquote type="cite">On Oct 27, 2022, at 3:53 PM, Barry Smith <bsmith@petsc.dev> wrote:<br><br><br>My quick examination of hypre.c shows the only relevant code in PETSc is <br><br>PetscCall(PetscOptionsEList("-pc_hypre_boomeramg_smooth_type", "Enable more complex smoothers", "None", HYPREBoomerAMGSmoothType, PETSC_STATIC_ARRAY_LENGTH(HYPREBoomerAMGSmoothType), HYPREBoomerAMGSmoothType[0], &indx, &flg));<br>if (flg) {<br> jac->smoothtype = indx;<br> PetscCallExternal(HYPRE_BoomerAMGSetSmoothType, jac->hsolver, indx + 6);<br><br>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.<br><br>Thus my conclusion is the memory leak is within hypre. Likely valgrind would locate the exact position easily.<br><br><blockquote type="cite">On Oct 27, 2022, at 4:27 PM, Emil Constantinescu via petsc-dev <petsc-dev@mcs.anl.gov> wrote:<br><br>Hi there,<br><br>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.<br><br>For instance, one can try ex15 under TS:<br><br>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<br><br>I am not sure if it's PETSc - hypre that causes the memory use or hypre itself.<br><br>Can someone with more sophisticated tools take a look at it?<br><br>Emil<br></blockquote><br></blockquote><br></blockquote></blockquote></blockquote></div></div></blockquote></div><br></div></body></html>