Skip to content

Change normal velocity evaluation into an extrapolation operator

Issue/feature addressed

Limited computational performance of the sub-stepping scheme due to excessive communication when calculating the normal velocity in substepping IncNS solver.

Proposed solution

  1. Added timers around the high-level routines that are called when the sub-stepping scheme is activated. They are useful for some components of solvers that are using a Discontinuous Galerkin projection.
  2. Stop extracting the trace from the extrpolated field at each substep to evaluate the normal velocity (which requires communication in parallel and therefore blocking) and instead extract the trace from the outer time steps and then extrapolate these values. Mathematically it is the same but involves much less communciation so there is less risk of load imbalance leading to problems.

Implementation

  • Introduced m_previousVnFields array member to store the continuous velocity field of the previous timestep (outer loop).
  • Edited SubSteppingExtrapolate::SubStepExtrapolateField routine to extrapolate not only the velocity field but also the normal velocity on the trace, Vn, based on the data stored in m_previousVnFields.
  • Edited SubSteppingExtrapolate::AddAdvectionPenaltyFlux to receive as input the extrapolated velocity Vn and removed the lines of the routine that were responsible at extrapolating the current solution of the unsteady advection equation to the next sub-step.
  • Edited SubSteppingExtrapolate::v_SubStepSaveFields to update m_previousVnFields at each outer timestep.

Tests

Use existing test with new formalation and observe they give the same answer.

Suggested reviewers

Alexandra

Notes

  • This branch has been tested in HX1 using the extruded IFW as geometry and showed 8 % improvement in Total Computation Time.
  • It improves the robustness of the scheme, especially for industrial geometries such as the full 3D IFW at a Reynolds number of 200 000.

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 Spencer Sherwin

Merge request reports