Skip to content

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.


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.


  • 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

@dmoxey @ssherw @CFD-Xing


  • 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.


  • 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 Henrik Wustenberg

Merge request reports