Skip to content

Fix to prevent memory leak from the DisContField object destruction when the sub-stepping is activated

Issue/feature addressed

Memory Leak in the IncNavierStokesSolver when the SubSteppingScheme is used

Proposed solution

The memory leak was caused while destroying all the DisContField objects and was preventing job schedulers from identifying that the IncNavierStokesSolver executable was finished. When the SubStepping is activated, then the Mixed_CG_Discontinuous projection is used which requires the initialization of both ContField and DisContField objects. Upon construction of the DisContField objects, the SetUpDG routine was called without any specifier for the field, hence the "DefaultVar" option was used. Inside SetUpDG the m_traceMap is initialized but without the specifier of the field, we were generating copies of the shared pointer to the first field. In the end of the code execution, the first shared pointer was destroyed and then the copies to this pointer didn't know what to destroy and it was causing a memory leak. This is fixed by connecting the m_traceMap to each input field using the variable string as input to SetUpDG.

Implementation

Added variable option as an input the SetUpDG routine which is called from the "Mixed_CG_Discontinuous", or "MIXEDCGDG" if-statement upon construction of a DisContField object

Tests

Suggested reviewers

@ssherw

Notes

It was preventing job schedulers from realising that the IncNavierStokes executable is finished.

Checklist

  • Functions and classes, or changes to them, are documented.
  • User guide/documentation is updated.
  • Changelog is updated.
  • Suitable tests added for new functionality.
  • Contributed code is correctly formatted. (See the contributing guidelines).
  • License added to any new files.
  • No extraneous files have been added (e.g. compiler output or test data files).
Edited by Alexandra Liosi

Merge request reports