Fix memory leak with updated matrices and Block preconditioner
Issue/feature addressed
The Block preconditioner initialises a GS mapping for communicating vertex data. This mapping is by default not deallocated when the preconditioner object is destroyed. The mappings do not change in time and can be saved instead of re-initialised every time step.
Proposed solution
Only initialise the gs mapping upon first creation of a PreconditionerBlock
and save it in the AssemblyMap
.
Implementation
The AssemblyMapCG
holds a vector with gs mapping(s) which are handed to any PreconditionerBlock
upon initialisation. The first call to PreconditionerBlock::BuildPreconditioner()
initialises the mapping and hands a copy to the AssemblyMapCG
.
Additionally this merge fixes the PreconditionerBlock
for low polynomial orders where Edges/Faces or the volume element have zero interior DoFs.
Tests
- We do not have tests with memory-constraint environments. However, I added a test with the
BlockPreconditioner
specifically to make sure this change is not breaking any code.
Suggested reviewers
Notes
- This memory leak also occurs with the
LowEnergyBlock
preconditioner. However, freeing or saving the gs mappings alone does not fix the leak. Still need to work out what causes the memory leak.
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).