Skip to content

Fix overwritten forcing function when using StaticCond + GMRES

Henrik Wustenberg requested to merge hwustenb/nektar:fix/gmres_staticCond into master

Issue/feature addressed

The issue is described in detail in #331 (closed). The summary of the issue is that the CG and GMRES solver overwrite the forcing term of the boundary dofs with a Static Condensation approach whenever DoMatrixMultiply is called.

Essentially, the GlobalLinSysStaticCond class is allocating an array m_wsp upon initialisation. m_wsp is accessed once when the right hand side is computed in GlobalLinSysStaticCond::v_Solve and, for every GlobalLinSysIterativeStaticCond::v_DoMatrixMultiply call, m_wsp is used for temporary holding the coefficients in local space.

DoMatrixMultiply (called via m_operator.DoNekSysLhsEval inside GMRES) accesses m_wsp + nLocal which is equivalent to where the forcing term is stored: m_wsp + nLocBndDofs. So, this is where we overwrite the forcing term before restarting the GMRES.

Proposed solution

I cannot come up with a solution where we do not allocate additional memory. A simple fix would be to solve this problem by allocating additional memory for m_wsp and use this in the DoMatrixMultiply call.

Implementation

The above solution is implemented. This solution allocates more memory upon initialisation, but does not require memory allocation for every DoMatrixMultiply call. This might be relevant to performance in large-scale runs. For example, the IncNavierStokesSolver where we typically use the VelocityCorrectionScheme with an IterativeStaticCond approach.

Tests

  • Added a test using the IncNavierStokesSolver which cannot converge due to the error, but runs with this fix

Suggested reviewers

@dmoxey @ccantwel

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).
Edited by Henrik Wustenberg

Merge request reports