Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • Nektar Nektar
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 90
    • Issues 90
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 60
    • Merge requests 60
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Nektar
  • NektarNektar
  • Merge requests
  • !1475

Implicit Incompressible Solver using Velocity-Correction scheme

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Henrik Wustenberg requested to merge hwustenb/nektar:feature/IncNS-ImplicitSolver into master Jan 17, 2023
  • Overview 6
  • Commits 102
  • Pipelines 14
  • Changes 46

Issue/feature addressed

Simulations of convection-dominated flows (high Reynolds number) with the Semi-Implicit VelocityCorrectionScheme often have strong restrictions on the time step size. This restrictions requires users to set significantly smaller time-step sizes due to stability rather than accuracy of the physical solution. Consequntly, the user must deal with higher computational cost to reach large physical times.

Proposed solution

This MR adds an implicit scheme for the IncNavierStokesSolver to Nektar++. This scheme allows the user to choose larger time-step sizes in exchange for a cost-overhead. It is based on the work by Dong and Shen (2010).

Implementation

The scheme is derived from the VelocityCorrectionScheme class. It uses most of the existing function, however, modifies the SolveUnsteadyStokes function call (that is the DoImplicitSolve-call). To account for this, the SolveUnsteadyStokes function is getting a virtual v_SolveUnstedyStokes.

Further, this scheme does not require extrapolating the advection terms and pressure boundary conditions. Therefore, the EvaluateAdvection_SetPressureBCs(..) function is modified. Explicit advection is instead evaluated immediately in SetupPressureForcing() and SetupViscousForcing(), since it is required for the advection velocity. We should be able to reduce this double evaluate to a single evaluation of advection by saving the terms.

Similarly, the pressure boundary conditions are almost equivalent to VCSWeakPressure. Only, the extrapolation is removed. Therefore, the implicit scheme uses the class ImplicitExtrapolate which itself derives from WeakPressureExtrapolate.

Minor changes allow non-symmetric Laplacian matrices via varcoeffs. Also, there is a switch that detects matrix keys of type: AdvectionDiffusionReaction and changes the iterative solver to GMRES, if it was not already selected.

Tests

  • Test for stability of the scheme on 2D Kovasznay flow with 4-Quad mesh using polynomial order P=9 and P=15
  • Check for Taylor-Hood expansions on 2D Kovasznay flow
  • Tests for the HOutflow and convective-like boundary conditions (Based on tests for VelocityCorrectionScheme)

Suggested reviewers

  • David Moxey
  • Spencer Sherwin

Notes

  • The scheme is currently implemented and tested for 2D only.
  • There was an issue with making SolveUnsteadyStokes virtual. The SmoothedProfileMethod is derived from VelocityCorrectionScheme and constructs a virtual function of SolveUnsteadyStokes. This merge resolves this by defining a virtual SolveUnsteadyStokes within VelocityCorrectionScheme instead, see commit 61f1b6f9
  • There was an issue with the GMRES-Switch and the LinearElasticSolver test of L-Domain.xml. The switch now detects only AdvectionDiffusionReaction, instead of any Advection type matrix, because the LinearElasticSolver uses an AdvectionReaction key, but the L-Domain test fails when it does not run on a CG solver. There is likely a better method to detect a non-symmetric matrix in Nektar (e.g. the MatrixStorageType?)
  • There is room for improvement, however, this first merge should allow the solver to evolve more inline with current developments on the master branch, instead of working on a year-old branch.

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 Jan 26, 2023 by Henrik Wustenberg
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: feature/IncNS-ImplicitSolver