Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • F fluidsim
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 25
    • Issues 25
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 4
    • Merge requests 4
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • fluiddyn
  • fluidsim
  • Issues
  • #54

Closed
Open
Created Apr 30, 2020 by Jason Reneuve@jreneuveDeveloper

Bad dealiasing of RK schemes

Runge-Kutta time schemes seem to be badly dealiased. Dealiasing happens at the end of the time-step only, allowing aliases to appear under the spectral truncation threshold during successive substeps.

This can be seen in the attached notebook:

test_alias.ipynb

by choosing RK2 for the time scheme and setting the dealiasing coefficient to 0.66. Even though aliases above the truncation limit are removed, some alias appear under this limit from the multiple evaluations of the nonlinear tendencies inside the time step.

To solve this, the method oper.dealiasing should be applied at the end of every substep in RK methods.

Edited Apr 30, 2020 by Jason Reneuve
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking