Hi Doug,

Yes, sadly I have experienced the same but wasn’t able to allot the time to figure out if it was indeed a bug in Sacado (and maybe something that’s already been fixed upstream in a newer version of Trilinos than I was using) or something that we did. I’m really glad that you managed to supply them with a MWE that definitely reproduces the issue, since this disambiguates their code from our drivers. Thank you for that. For your interest, I’ve attached the MWE that I made at the time. I can only suppose that back then I wasn’t confident that I’d recreated the conditions for the leak, because the valgrind logs that I still have didn’t report and memory as being “definitely lost”. I guess the trick would have been to have stuck all of this in a loop, which I clearly didn’t think to do :-/

Since you’ve confirmed that you’ve experienced the same, I think that it would be worthwhile to add a note to this effect in our documentation. If you'd like to do so yourself, then free to make a suggestion where you think it would be appropriate to be. My first inclination would have been where the enumerated type sacado_rad_fad is documented, i.e.
but of course that’s completely up for discussion. Either way, I think that this should be documented because this issue may persist for some time, and it would be good to have a warning in place until we know which version of Trilinos has a fix in place. Perhaps we should also add a link there to your issue on their GitHub page so that the reader can easily find where to check the status of the issue?

I hope that you’ve spotted the sacado_fad_fad alternative that should work without issue. In many cases I would expect it to be less performant than the (buggy) Rad-Fad implementation but they both still have, at the very least, some use in debugging or prototyping.

Best,
Jean-Paul

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/32BE3FC9-0855-44EA-8058-F7820D7D2686%40gmail.com.

Attachment: sacado_rad_fad_memleak.cc
Description: Binary data



On 10 Aug 2020, at 20:22, Doug Shi-Dong <doug.shid...@gmail.com> wrote:

Hello everyone,

I found that Sacado's nested reverse and forward mode AD leads to a memory leak when use multiple times. I have opened an issue on their end:
and the steps to reproduce are pretty simple.

However, I've found that the community here is pretty good at responding. I was wondering if anyone here has previously encountered/fixed this. I know that J-P Perlteret's code-gallery example Quasi_static_Finite_strain_Compressible_Elasticity with this AD type turned on by using
does lead to a memory leak.

Basically, for every cell's computation, a little bit of memory leaks, which quickly blows up for large problems. 

Please let me know what you think. It's likely completely in the hand of the Sacado group unless I start digging in their code. However, if it is something that will likely not get fixed, we might want to put a warning on the "Supported automatic differentiation libraries" page.

Best regards,

Doug

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/9efa2b48-dd67-4a2b-ab92-0849b307b99dn%40googlegroups.com.

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/32BE3FC9-0855-44EA-8058-F7820D7D2686%40gmail.com.

Reply via email to