Skip to content

Prevent SegFault with Shock Capturing + C0 Smoother

Issue/feature addressed

The Compressible Flow Solver segfaults on some cases when the C0 smoother is used in combination with the shock capturing routines. This segfault occurs when the member variable m_C0ProjectExp inside the VariableConverter class is allocated inside the constructor, but no value of pGraph was passed to the constructor. The reason for this is that the member variable m_C0ProjectExp is always allocated if the C0 smoother was enabled in the session file, even if there is no mesh graph (pGraph) sent to the constructor. However, some instances of the VariableConverter class are not intended to do the C0 projection, just convert thermodynamic variables. Hence, these particular instances should not hold a C0 smoother.

Proposed solution

Ideally, the code should be refactored such that the C0 smoother is moved to a separate class. However, for the time being, the issue can be solved by simply checking whether pGraph was sent to the constructor or not, and then avoid allocating the C0 smoother if this is not the case. This check has now been added to the constructor for the VariableConverter class. In addition to this, another safety check was added to the function VariableConverter::ApplyC0Smooth(). This check makes sure that the member variable m_C0ProjectExp has been allocated, before trying to use it to apply the C0 smoothing.

Implementation

Small changes to the constructor for the class VariableConverter was added. In addition to this, an ASSERTL0 was added to the function VariableConverter::ApplyC0Smooth().

Tests

A test which would segfault without the above changes would be beneficial.

Notes

Please add any other information that could be useful for reviewers.

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

Warning

On the 19.07 the code formatting (code style) was standardised using clang-format, over the whole Nektar++ code. This means changes in your branch will conflict with formatting changes on the master branch. To resolve these conflicts , see #295 (closed)

Edited by Chris Cantwell

Merge request reports