From dad98c607a3b91c34f143ac2a2415fced2b51b4d Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Wed, 13 Mar 2024 10:55:21 +0000 Subject: [PATCH] build based on ab46420 --- previews/PR1835/.documenter-siteinfo.json | 2 +- previews/PR1835/authors/index.html | 2 +- previews/PR1835/callbacks/index.html | 2 +- previews/PR1835/code_of_conduct/index.html | 2 +- previews/PR1835/contributing/index.html | 2 +- previews/PR1835/conventions/index.html | 2 +- previews/PR1835/development/index.html | 2 +- previews/PR1835/github-git/index.html | 2 +- previews/PR1835/index.html | 2 +- previews/PR1835/license/index.html | 2 +- .../PR1835/meshes/dgmulti_mesh/index.html | 2 +- previews/PR1835/meshes/p4est_mesh/index.html | 2 +- .../PR1835/meshes/structured_mesh/index.html | 2 +- previews/PR1835/meshes/tree_mesh/index.html | 2 +- .../meshes/unstructured_quad_mesh/index.html | 2 +- .../PR1835/multi-physics_coupling/index.html | 2 +- previews/PR1835/overview/index.html | 2 +- previews/PR1835/parallelization/index.html | 2 +- previews/PR1835/performance/index.html | 2 +- previews/PR1835/reference-trixi/index.html | 302 +- .../PR1835/reference-trixi2vtk/index.html | 2 +- .../PR1835/reference-trixibase/index.html | 2 +- previews/PR1835/restart/index.html | 2 +- previews/PR1835/styleguide/index.html | 2 +- previews/PR1835/testing/index.html | 2 +- previews/PR1835/time_integration/index.html | 2 +- previews/PR1835/troubleshooting/index.html | 2 +- .../DGMulti_1/{b49c8972.svg => 1159a452.svg} | 8254 +++++------ .../DGMulti_1/{a41c3abe.svg => 165d3f48.svg} | 230 +- .../DGMulti_1/{c2ebbb1c.svg => 3d8b8e1d.svg} | 12350 ++++++++-------- .../DGMulti_1/{3042e87c.svg => 7536ace2.svg} | 230 +- .../DGMulti_1/{4dcdc332.svg => 7730dd6a.svg} | 230 +- .../DGMulti_1/{4353f897.svg => a00a48c5.svg} | 3650 ++--- .../PR1835/tutorials/DGMulti_1/index.html | 98 +- .../PR1835/tutorials/DGMulti_2/index.html | 2 +- .../{d81d7bd0.svg => 249f04e3.svg} | 230 +- .../{927838a6.svg => 639d223c.svg} | 230 +- .../tutorials/DGSEM_FluxDiff/index.html | 30 +- .../{8eb1db25.svg => 607e3074.svg} | 878 +- .../adaptive_mesh_refinement/index.html | 4 +- .../{3b21af9a.svg => 1c661b9e.svg} | 62 +- .../adding_new_parabolic_terms/index.html | 4 +- .../{c29c41b0.svg => 26e4e929.svg} | 58 +- .../{b17c4f05.svg => 73d46f7b.svg} | 56 +- .../{3d23858d.svg => a931fbe2.svg} | 56 +- .../{8199393f.svg => acf97b90.svg} | 56 +- .../{223a7602.svg => d1a47d62.svg} | 64 +- .../adding_new_scalar_equations/index.html | 12 +- .../{f55b9925.svg => 553857a9.svg} | 122 +- .../index.html | 4 +- .../{9994ad4e.svg => 132fbcb2.svg} | 68 +- .../index.html | 2 +- .../{a604b369.svg => 56a8fb97.svg} | 72 +- .../{c24d0a73.svg => 8bc5ac1e.svg} | 64 +- .../{2fe83752.svg => a64c606b.svg} | 72 +- .../{96179ca3.svg => ae081023.svg} | 72 +- .../{737b8a41.svg => b86cb1e7.svg} | 68 +- .../custom_semidiscretization/index.html | 152 +- .../{b4a7087c.svg => 28d58282.svg} | 586 +- .../{80fb0600.svg => 3339c3ca.svg} | 1588 +- .../{ea31ab8a.svg => 3954f8e0.svg} | 64 +- .../{374ba720.svg => 4b058978.svg} | 64 +- .../{f07a1f19.svg => 63272b9a.svg} | 3136 ++-- .../{dca3fd7b.svg => ae932e05.svg} | 1594 +- .../{cef264fd.svg => d21e5579.svg} | 2126 +-- .../{f4642025.svg => fcfadeff.svg} | 4172 +++--- .../differentiable_programming/index.html | 18 +- .../first_steps/changing_trixi/index.html | 2 +- .../{f5dec46f.svg => 0cba9fc8.svg} | 62 +- .../{d622a1c2.svg => b9bcdf45.svg} | 554 +- .../first_steps/create_first_setup/index.html | 114 +- .../{daf23232.svg => 53769630.svg} | 230 +- .../{2bf4d40c.svg => 77395e61.svg} | 230 +- .../first_steps/getting_started/index.html | 68 +- .../tutorials/hohqmesh_tutorial/index.html | 2 +- .../PR1835/tutorials/introduction/index.html | 2 +- .../{e628e252.svg => d93b48d6.svg} | 72 +- .../non_periodic_boundaries/index.html | 4 +- .../PR1835/tutorials/out/restart_000050.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/restart_000100.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/restart_000150.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/restart_000180.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000000.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000010.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000020.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000030.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000040.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000050.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000060.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000065.h5 | Bin 205696 -> 205696 bytes .../PR1835/tutorials/out/solution_000070.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000080.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000090.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000100.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000110.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000120.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000130.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000140.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000150.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000160.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000170.h5 | Bin 11976 -> 11976 bytes .../PR1835/tutorials/out/solution_000180.h5 | Bin 11976 -> 11976 bytes .../tutorials/p4est_from_gmsh/index.html | 2 +- .../{73a348c6.svg => 84078dd1.svg} | 62 +- .../tutorials/parabolic_terms/index.html | 4 +- .../{5624a9e5.svg => 191ea9ea.svg} | 68 +- .../{6bbbd4c8.svg => 26e729f0.svg} | 64 +- .../{ca81c37e.svg => 5a4c5908.svg} | 64 +- .../{27406f5d.svg => 74e747e6.svg} | 68 +- .../{7bea790c.svg => a9ad06c9.svg} | 64 +- .../{7990a57f.svg => d494c926.svg} | 80 +- .../scalar_linear_advection_1d/index.html | 14 +- .../{640f5006.svg => 7121189c.svg} | 230 +- .../tutorials/shock_capturing/index.html | 4 +- .../{d770c223.svg => 58c073b0.svg} | 2102 +-- .../{01ba6501.svg => 74a5d515.svg} | 246 +- .../{a2879fc8.svg => b1940c56.svg} | 2114 +-- .../structured_mesh_mapping/index.html | 28 +- .../PR1835/tutorials/time_stepping/index.html | 2 +- .../PR1835/tutorials/upwind_fdsbp/index.html | 2 +- previews/PR1835/visualization/index.html | 2 +- 121 files changed, 23871 insertions(+), 23871 deletions(-) rename previews/PR1835/tutorials/DGMulti_1/{b49c8972.svg => 1159a452.svg} (90%) rename previews/PR1835/tutorials/DGMulti_1/{a41c3abe.svg => 165d3f48.svg} (96%) rename previews/PR1835/tutorials/DGMulti_1/{c2ebbb1c.svg => 3d8b8e1d.svg} (90%) rename previews/PR1835/tutorials/DGMulti_1/{3042e87c.svg => 7536ace2.svg} (96%) rename previews/PR1835/tutorials/DGMulti_1/{4dcdc332.svg => 7730dd6a.svg} (96%) rename previews/PR1835/tutorials/DGMulti_1/{4353f897.svg => a00a48c5.svg} (89%) rename previews/PR1835/tutorials/DGSEM_FluxDiff/{d81d7bd0.svg => 249f04e3.svg} (95%) rename previews/PR1835/tutorials/DGSEM_FluxDiff/{927838a6.svg => 639d223c.svg} (94%) rename previews/PR1835/tutorials/adaptive_mesh_refinement/{8eb1db25.svg => 607e3074.svg} (85%) rename previews/PR1835/tutorials/adding_new_parabolic_terms/{3b21af9a.svg => 1c661b9e.svg} (93%) rename previews/PR1835/tutorials/adding_new_scalar_equations/{c29c41b0.svg => 26e4e929.svg} (85%) rename previews/PR1835/tutorials/adding_new_scalar_equations/{b17c4f05.svg => 73d46f7b.svg} (84%) rename previews/PR1835/tutorials/adding_new_scalar_equations/{3d23858d.svg => a931fbe2.svg} (92%) rename previews/PR1835/tutorials/adding_new_scalar_equations/{8199393f.svg => acf97b90.svg} (92%) rename previews/PR1835/tutorials/adding_new_scalar_equations/{223a7602.svg => d1a47d62.svg} (91%) rename previews/PR1835/tutorials/adding_nonconservative_equation/{f55b9925.svg => 553857a9.svg} (84%) rename previews/PR1835/tutorials/behind_the_scenes_simulation_setup/{9994ad4e.svg => 132fbcb2.svg} (91%) rename previews/PR1835/tutorials/custom_semidiscretization/{a604b369.svg => 56a8fb97.svg} (86%) rename previews/PR1835/tutorials/custom_semidiscretization/{c24d0a73.svg => 8bc5ac1e.svg} (85%) rename previews/PR1835/tutorials/custom_semidiscretization/{2fe83752.svg => a64c606b.svg} (86%) rename previews/PR1835/tutorials/custom_semidiscretization/{96179ca3.svg => ae081023.svg} (86%) rename previews/PR1835/tutorials/custom_semidiscretization/{737b8a41.svg => b86cb1e7.svg} (86%) rename previews/PR1835/tutorials/differentiable_programming/{b4a7087c.svg => 28d58282.svg} (69%) rename previews/PR1835/tutorials/differentiable_programming/{80fb0600.svg => 3339c3ca.svg} (65%) rename previews/PR1835/tutorials/differentiable_programming/{ea31ab8a.svg => 3954f8e0.svg} (84%) rename previews/PR1835/tutorials/differentiable_programming/{374ba720.svg => 4b058978.svg} (85%) rename previews/PR1835/tutorials/differentiable_programming/{f07a1f19.svg => 63272b9a.svg} (67%) rename previews/PR1835/tutorials/differentiable_programming/{dca3fd7b.svg => ae932e05.svg} (68%) rename previews/PR1835/tutorials/differentiable_programming/{cef264fd.svg => d21e5579.svg} (68%) rename previews/PR1835/tutorials/differentiable_programming/{f4642025.svg => fcfadeff.svg} (66%) rename previews/PR1835/tutorials/first_steps/create_first_setup/{f5dec46f.svg => 0cba9fc8.svg} (93%) rename previews/PR1835/tutorials/first_steps/create_first_setup/{d622a1c2.svg => b9bcdf45.svg} (86%) rename previews/PR1835/tutorials/first_steps/getting_started/{daf23232.svg => 53769630.svg} (88%) rename previews/PR1835/tutorials/first_steps/getting_started/{2bf4d40c.svg => 77395e61.svg} (95%) rename previews/PR1835/tutorials/non_periodic_boundaries/{e628e252.svg => d93b48d6.svg} (81%) rename previews/PR1835/tutorials/parabolic_terms/{73a348c6.svg => 84078dd1.svg} (93%) rename previews/PR1835/tutorials/scalar_linear_advection_1d/{5624a9e5.svg => 191ea9ea.svg} (85%) rename previews/PR1835/tutorials/scalar_linear_advection_1d/{6bbbd4c8.svg => 26e729f0.svg} (82%) rename previews/PR1835/tutorials/scalar_linear_advection_1d/{ca81c37e.svg => 5a4c5908.svg} (83%) rename previews/PR1835/tutorials/scalar_linear_advection_1d/{27406f5d.svg => 74e747e6.svg} (85%) rename previews/PR1835/tutorials/scalar_linear_advection_1d/{7bea790c.svg => a9ad06c9.svg} (83%) rename previews/PR1835/tutorials/scalar_linear_advection_1d/{7990a57f.svg => d494c926.svg} (79%) rename previews/PR1835/tutorials/shock_capturing/{640f5006.svg => 7121189c.svg} (95%) rename previews/PR1835/tutorials/structured_mesh_mapping/{d770c223.svg => 58c073b0.svg} (92%) rename previews/PR1835/tutorials/structured_mesh_mapping/{01ba6501.svg => 74a5d515.svg} (96%) rename previews/PR1835/tutorials/structured_mesh_mapping/{a2879fc8.svg => b1940c56.svg} (86%) diff --git a/previews/PR1835/.documenter-siteinfo.json b/previews/PR1835/.documenter-siteinfo.json index 7883dd70c2a..9a364ba9ee6 100644 --- a/previews/PR1835/.documenter-siteinfo.json +++ b/previews/PR1835/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2024-03-12T11:51:29","documenter_version":"1.3.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2024-03-13T10:54:44","documenter_version":"1.3.0"}} \ No newline at end of file diff --git a/previews/PR1835/authors/index.html b/previews/PR1835/authors/index.html index 8050224e1b0..6115b579581 100644 --- a/previews/PR1835/authors/index.html +++ b/previews/PR1835/authors/index.html @@ -1,2 +1,2 @@ -Authors · Trixi.jl
GitHub

Authors

Trixi.jl's development is coordinated by a group of principal developers, who are also its main contributors and who can be contacted in case of questions about Trixi.jl. In addition, there are contributors who have provided substantial additions or modifications. Together, these two groups form "The Trixi.jl Authors" as mentioned under License.

Principal Developers

Contributors

The following people contributed major additions or modifications to Trixi.jl and are listed in alphabetical order:

  • Maximilian D. Bertrand
  • Benjamin Bolm
  • Simon Candelaresi
  • Jesse Chan
  • Lars Christmann
  • Christof Czernik
  • Daniel Doehring
  • Patrick Ersing
  • Erik Faulhaber
  • Gregor Gassner
  • Lucas Gemein
  • Sven Goldberg
  • Joshua Lampert
  • Julia Odenthal
  • Sigrun Ortleb
  • Hendrik Ranocha
  • Andrés M. Rueda-Ramírez
  • Felipe Santillan
  • Michael Schlottke-Lakemper
  • Toskan Theine
  • Andrew Winters
+Authors · Trixi.jl
GitHub

Authors

Trixi.jl's development is coordinated by a group of principal developers, who are also its main contributors and who can be contacted in case of questions about Trixi.jl. In addition, there are contributors who have provided substantial additions or modifications. Together, these two groups form "The Trixi.jl Authors" as mentioned under License.

Principal Developers

Contributors

The following people contributed major additions or modifications to Trixi.jl and are listed in alphabetical order:

  • Maximilian D. Bertrand
  • Benjamin Bolm
  • Simon Candelaresi
  • Jesse Chan
  • Lars Christmann
  • Christof Czernik
  • Daniel Doehring
  • Patrick Ersing
  • Erik Faulhaber
  • Gregor Gassner
  • Lucas Gemein
  • Sven Goldberg
  • Joshua Lampert
  • Julia Odenthal
  • Sigrun Ortleb
  • Hendrik Ranocha
  • Andrés M. Rueda-Ramírez
  • Felipe Santillan
  • Michael Schlottke-Lakemper
  • Toskan Theine
  • Andrew Winters
diff --git a/previews/PR1835/callbacks/index.html b/previews/PR1835/callbacks/index.html index 4d02d4e72da..d5d333a126d 100644 --- a/previews/PR1835/callbacks/index.html +++ b/previews/PR1835/callbacks/index.html @@ -12,4 +12,4 @@ julia> pd2 = PlotData1D(time_series, 2) -julia> plot(pd1["p_prime"]); plot!(pd2["p_prime"], xguide="t")

will yield the following plot:

image

Miscellaneous

Equation-specific callbacks

Some callbacks provided by Trixi.jl implement specific features for certain equations:

Usage of step callbacks

Step callbacks are passed to the solve method from the ODE solver via the keyword argument callback. If you want to use a single callback cb, pass it as callback=cb. When using two or more callbacks, you need to turn them into a CallbackSet first by calling callbacks = CallbackSet(cb1, cb2) and passing it as callback=callbacks.

Note

There are some restrictions regarding the order of callbacks in a CallbackSet.

The callbacks are called after each time step but some callbacks actually belong to the next time step. Therefore, the callbacks should be ordered in the following way:

  • Callbacks that belong to the current time step:
    • SummaryCallback controls, among other things, timers and should thus be first
    • SteadyStateCallback may mark a time step as the last one
    • AnalysisCallback may do some checks that mark a time step as the last one
    • AliveCallback should be nearby AnalysisCallback
    • SaveSolutionCallback/SaveRestartCallback should save the current solution before it is degraded by AMR
    • VisualizationCallback should be called before the mesh is adapted
  • Callbacks that belong to the next time step:
    • AMRCallback
    • StepsizeCallback must be called after AMRCallback to accommodate potential changes to the mesh
    • GlmSpeedCallback must be called after StepsizeCallback because the step size affects the value of c_h
    • LBMCollisionCallback is already part of the calculations of the next time step and should therefore be called after StepsizeCallback

Stage callbacks

PositivityPreservingLimiterZhangShu is a positivity-preserving limiter, used to enforce physical constraints. An example elixir using this feature can be found at examples/tree_2d_dgsem/elixir_euler_positivity.jl.

Implementing new callbacks

Since Trixi.jl is compatible with OrdinaryDiffEq.jl, both packages share the same callback interface. A detailed description of it can be found in the OrdinaryDiffEq.jl documentation. Step callbacks are just called callbacks. Stage callbacks are called stage_limiter!.

An example elixir showing how to implement a new simple stage callback and a new simple step callback can be found at examples/tree_2d_dgsem/elixir_advection_callbacks.jl.

+julia> plot(pd1["p_prime"]); plot!(pd2["p_prime"], xguide="t")

will yield the following plot:

image

Miscellaneous

Equation-specific callbacks

Some callbacks provided by Trixi.jl implement specific features for certain equations:

Usage of step callbacks

Step callbacks are passed to the solve method from the ODE solver via the keyword argument callback. If you want to use a single callback cb, pass it as callback=cb. When using two or more callbacks, you need to turn them into a CallbackSet first by calling callbacks = CallbackSet(cb1, cb2) and passing it as callback=callbacks.

Note

There are some restrictions regarding the order of callbacks in a CallbackSet.

The callbacks are called after each time step but some callbacks actually belong to the next time step. Therefore, the callbacks should be ordered in the following way:

  • Callbacks that belong to the current time step:
    • SummaryCallback controls, among other things, timers and should thus be first
    • SteadyStateCallback may mark a time step as the last one
    • AnalysisCallback may do some checks that mark a time step as the last one
    • AliveCallback should be nearby AnalysisCallback
    • SaveSolutionCallback/SaveRestartCallback should save the current solution before it is degraded by AMR
    • VisualizationCallback should be called before the mesh is adapted
  • Callbacks that belong to the next time step:
    • AMRCallback
    • StepsizeCallback must be called after AMRCallback to accommodate potential changes to the mesh
    • GlmSpeedCallback must be called after StepsizeCallback because the step size affects the value of c_h
    • LBMCollisionCallback is already part of the calculations of the next time step and should therefore be called after StepsizeCallback

Stage callbacks

PositivityPreservingLimiterZhangShu is a positivity-preserving limiter, used to enforce physical constraints. An example elixir using this feature can be found at examples/tree_2d_dgsem/elixir_euler_positivity.jl.

Implementing new callbacks

Since Trixi.jl is compatible with OrdinaryDiffEq.jl, both packages share the same callback interface. A detailed description of it can be found in the OrdinaryDiffEq.jl documentation. Step callbacks are just called callbacks. Stage callbacks are called stage_limiter!.

An example elixir showing how to implement a new simple stage callback and a new simple step callback can be found at examples/tree_2d_dgsem/elixir_advection_callbacks.jl.

diff --git a/previews/PR1835/code_of_conduct/index.html b/previews/PR1835/code_of_conduct/index.html index 8328a0473d3..b6fd0e28d53 100644 --- a/previews/PR1835/code_of_conduct/index.html +++ b/previews/PR1835/code_of_conduct/index.html @@ -1,2 +1,2 @@ -Code of Conduct · Trixi.jl
GitHub

Code of Conduct

Contributor Covenant Code of Conduct

Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

  • Demonstrating empathy and kindness toward other people
  • Being respectful of differing opinions, viewpoints, and experiences
  • Giving and gracefully accepting constructive feedback
  • Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
  • Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

  • The use of sexualized language or imagery, and sexual attention or advances of any kind
  • Trolling, insulting or derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or email address, without their explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to Michael Schlottke-Lakemper, Hendrik Ranocha, or any other of the principal developers responsible for enforcement listed in Authors. All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at https://www.contributor-covenant.org/version/2/0/codeofconduct.html.

Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

+Code of Conduct · Trixi.jl
GitHub

Code of Conduct

Contributor Covenant Code of Conduct

Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

  • Demonstrating empathy and kindness toward other people
  • Being respectful of differing opinions, viewpoints, and experiences
  • Giving and gracefully accepting constructive feedback
  • Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
  • Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

  • The use of sexualized language or imagery, and sexual attention or advances of any kind
  • Trolling, insulting or derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or email address, without their explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to Michael Schlottke-Lakemper, Hendrik Ranocha, or any other of the principal developers responsible for enforcement listed in Authors. All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at https://www.contributor-covenant.org/version/2/0/codeofconduct.html.

Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

diff --git a/previews/PR1835/contributing/index.html b/previews/PR1835/contributing/index.html index 809cc1ea048..9e91aa72277 100644 --- a/previews/PR1835/contributing/index.html +++ b/previews/PR1835/contributing/index.html @@ -35,4 +35,4 @@ are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. + this project or the open source license(s) involved. diff --git a/previews/PR1835/conventions/index.html b/previews/PR1835/conventions/index.html index 142852c2bc0..7f10d04b433 100644 --- a/previews/PR1835/conventions/index.html +++ b/previews/PR1835/conventions/index.html @@ -1,2 +1,2 @@ -Conventions · Trixi.jl
GitHub

Conventions

Spatial dimensions and directions

We use the following numbering schemes on Cartesian or curved structured meshes.

  • The orientations are numbered as 1 => x, 2 => y, 3 => z. For example, numerical fluxes such as flux_central(u_ll, u_rr, orientation, equations::AbstractEquations) use the orientation in this way.
  • The directions are numbered as 1 => -x, 2 => +x, 3 => -y, 4 => +y, 5 => -z, 6 => +z. For example, the boundary_conditions are ordered in this way when a Tuple of boundary conditions per direction is passed to the constructor of a SemidiscretizationHyperbolic.
  • For structured and unstructured curved meshes the concept of direction is generalized via the variable normal_direction. This variable points in the normal direction at a given, curved surface. For the computation of boundary fluxes the normal_direction is normalized to be a normal_vector used, for example, in FluxRotated.

Cells vs. elements vs. nodes

To uniquely distinguish between different components of the discretization, we use the following naming conventions:

  • The computational domain is discretized by a mesh, which is made up of individual cells. In general, neither the mesh nor the cells should be aware of any solver-specific knowledge, i.e., they should not store anything that goes beyond the geometrical information and the connectivity.
  • The numerical solvers do not directly store their information inside the mesh, but use own data structures. Specifically, for each cell on which a solver wants to operate, the solver creates an element to store solver-specific data.
  • For discretization schemes such as the discontinuous Galerkin or the finite element method, inside each element multiple nodes may be defined, which hold nodal information. The nodes are again a solver-specific component, just like the elements.
  • We often identify elements, nodes, etc. with their (local or global) integer index. Convenience iterators such as eachelement, eachnode use these indices.

Keywords in elixirs

Trixi.jl is distributed with several examples in the form of elixirs, small Julia scripts containing everything to set up and run a simulation. Working interactively from the Julia REPL with these scripts can be quite convenient while for exploratory research and development of Trixi.jl. For example, you can use the convenience function trixi_include to include an elixir with some modified arguments. To enable this, it is helpful to use a consistent naming scheme in elixirs, since trixi_include can only perform simple replacements. Some standard variables names are

  • polydeg for the polynomial degree of a solver
  • surface_flux for the numerical flux at surfaces
  • volume_flux for the numerical flux used in flux differencing volume terms

Moreover, convergence_test requires that the spatial resolution is set via the keywords

Variable names

  • Use descriptive names (using snake_case for variables/functions and CamelCase for types)
  • Use a suffix _ as in name_ for local variables that would otherwise hide existing symbols.
  • Use a prefix _ as in _name to indicate internal methods/data that are "fragile" in the sense that there's no guarantee that they might get changed without notice. These are also not documented with a docstring (but maybe with comments using #).

Array types and wrapping

To allow adaptive mesh refinement efficiently when using time integrators from OrdinaryDiffEq, Trixi.jl allows to represent numerical solutions in two different ways. Some discussion can be found online and in form of comments describing Trixi.wrap_array and Trixi.wrap_array_native in the source code of Trixi.jl. The flexibility introduced by this possible wrapping enables additional performance optimizations. However, it comes at the cost of some additional abstractions (and needs to be used with caution, as described in the source code of Trixi.jl). Thus, we use the following conventions to distinguish between arrays visible to the time integrator and wrapped arrays mainly used internally.

  • Arrays visible to the time integrator have a suffix _ode, e.g., du_ode, u_ode.
  • Wrapped arrays do not have a suffix, e.g., du, u.

Methods either accept arrays visible to the time integrator or wrapped arrays based on the following rules.

  • When some solution is passed together with a semidiscretization semi, the solution must be a u_ode that needs to be wrapped via wrap_array(u_ode, semi) (or wrap_array_native(u_ode, semi)) for further processing.
  • When some solution is passed together with the mesh, equations, solver, cache, ..., it is already wrapped via wrap_array (or wrap_array_native).
  • Exceptions of this rule are possible, e.g. for AMR, but must be documented in the code.
  • wrap_array should be used as default option. wrap_array_native should only be used when necessary, e.g., to avoid additional overhead when interfacing with external C libraries such as HDF5, MPI, or visualization.
+Conventions · Trixi.jl
GitHub

Conventions

Spatial dimensions and directions

We use the following numbering schemes on Cartesian or curved structured meshes.

  • The orientations are numbered as 1 => x, 2 => y, 3 => z. For example, numerical fluxes such as flux_central(u_ll, u_rr, orientation, equations::AbstractEquations) use the orientation in this way.
  • The directions are numbered as 1 => -x, 2 => +x, 3 => -y, 4 => +y, 5 => -z, 6 => +z. For example, the boundary_conditions are ordered in this way when a Tuple of boundary conditions per direction is passed to the constructor of a SemidiscretizationHyperbolic.
  • For structured and unstructured curved meshes the concept of direction is generalized via the variable normal_direction. This variable points in the normal direction at a given, curved surface. For the computation of boundary fluxes the normal_direction is normalized to be a normal_vector used, for example, in FluxRotated.

Cells vs. elements vs. nodes

To uniquely distinguish between different components of the discretization, we use the following naming conventions:

  • The computational domain is discretized by a mesh, which is made up of individual cells. In general, neither the mesh nor the cells should be aware of any solver-specific knowledge, i.e., they should not store anything that goes beyond the geometrical information and the connectivity.
  • The numerical solvers do not directly store their information inside the mesh, but use own data structures. Specifically, for each cell on which a solver wants to operate, the solver creates an element to store solver-specific data.
  • For discretization schemes such as the discontinuous Galerkin or the finite element method, inside each element multiple nodes may be defined, which hold nodal information. The nodes are again a solver-specific component, just like the elements.
  • We often identify elements, nodes, etc. with their (local or global) integer index. Convenience iterators such as eachelement, eachnode use these indices.

Keywords in elixirs

Trixi.jl is distributed with several examples in the form of elixirs, small Julia scripts containing everything to set up and run a simulation. Working interactively from the Julia REPL with these scripts can be quite convenient while for exploratory research and development of Trixi.jl. For example, you can use the convenience function trixi_include to include an elixir with some modified arguments. To enable this, it is helpful to use a consistent naming scheme in elixirs, since trixi_include can only perform simple replacements. Some standard variables names are

  • polydeg for the polynomial degree of a solver
  • surface_flux for the numerical flux at surfaces
  • volume_flux for the numerical flux used in flux differencing volume terms

Moreover, convergence_test requires that the spatial resolution is set via the keywords

Variable names

  • Use descriptive names (using snake_case for variables/functions and CamelCase for types)
  • Use a suffix _ as in name_ for local variables that would otherwise hide existing symbols.
  • Use a prefix _ as in _name to indicate internal methods/data that are "fragile" in the sense that there's no guarantee that they might get changed without notice. These are also not documented with a docstring (but maybe with comments using #).

Array types and wrapping

To allow adaptive mesh refinement efficiently when using time integrators from OrdinaryDiffEq, Trixi.jl allows to represent numerical solutions in two different ways. Some discussion can be found online and in form of comments describing Trixi.wrap_array and Trixi.wrap_array_native in the source code of Trixi.jl. The flexibility introduced by this possible wrapping enables additional performance optimizations. However, it comes at the cost of some additional abstractions (and needs to be used with caution, as described in the source code of Trixi.jl). Thus, we use the following conventions to distinguish between arrays visible to the time integrator and wrapped arrays mainly used internally.

  • Arrays visible to the time integrator have a suffix _ode, e.g., du_ode, u_ode.
  • Wrapped arrays do not have a suffix, e.g., du, u.

Methods either accept arrays visible to the time integrator or wrapped arrays based on the following rules.

  • When some solution is passed together with a semidiscretization semi, the solution must be a u_ode that needs to be wrapped via wrap_array(u_ode, semi) (or wrap_array_native(u_ode, semi)) for further processing.
  • When some solution is passed together with the mesh, equations, solver, cache, ..., it is already wrapped via wrap_array (or wrap_array_native).
  • Exceptions of this rule are possible, e.g. for AMR, but must be documented in the code.
  • wrap_array should be used as default option. wrap_array_native should only be used when necessary, e.g., to avoid additional overhead when interfacing with external C libraries such as HDF5, MPI, or visualization.
diff --git a/previews/PR1835/development/index.html b/previews/PR1835/development/index.html index 08966ee2fae..8eff245469b 100644 --- a/previews/PR1835/development/index.html +++ b/previews/PR1835/development/index.html @@ -39,4 +39,4 @@ Trixi.IdealGlmMhdEquations2D Trixi.IdealGlmMhdMulticomponentEquations1D [...]

Text editors

When writing code, the choice of text editor can have a significant impact on productivity and developer satisfaction. While using the default text editor of the operating system has its own benefits (specifically the lack of an explicit installation procure), usually it makes sense to switch to a more programming-friendly tool. In the following, a few of the many options are listed and discussed:

VS Code

Visual Studio Code is a modern open source editor with good support for Julia. While Juno had some better support in the past, the developers of Juno and the Julia VS Code plugin are joining forces and concentrating on VS Code since support of Atom has been suspended. Basically, all comments on Juno below also apply to VS Code.

Juno

If you are new to programming or do not have a preference for a text editor yet, Juno is a good choice for developing Julia code. It is based on Atom, a sophisticated and widely used editor for software developers, and is enhanced with several Julia-specific features. Furthermore and especially helpful for novice programmers, it has a MATLAB-like appearance with easy and interactive access to the current variables, the help system, and a debugger.

Vim or Emacs

Vim and Emacs are both very popular editors that work great with Julia. One of their advantages is that they are text editors without a GUI and as such are available for almost any operating system. They also are preinstalled on virtually all Unix-like systems. However, Vim and Emacs come with their own, steep learning curve if they have never been used before. Therefore, if in doubt, it is probably easier to get started with a classic GUI-based text editor (like Juno). If you decide to use Vim or Emacs, make sure that you install the corresponding Vim plugin julia-vim or Emacs major mode julia-emacs.

Debugging

Julia offers several options for debugging. A classical debugger is available with the Debugger.jl package or in the Julia extension for VS Code. However, it can be quite slow and, at the time of writing (January 2023), currently does not work properly with Trixi.jl. The Infiltrator.jl package on the other hand does not offer all features of a full debugger, but is a fast and simple tool that allows users to set breakpoints to open a local REPL session and access the call stack and variables.

Infiltrator

The Infiltrator package provides fast, interactive breakpoints using the @infiltrate command, which drops the user into a local REPL session. From there, it is possible to access local variables, see the call stack, and execute statements.

The package can be installed in the Julia REPL by executing

(@v1.9) pkg> add Infiltrator

To load the package in the Julia REPL execute

julia> using Infiltrator

Breakpoints can be set by adding a line with the @infiltrate macro at the respective position in the code. Use Revise if you want to set and delete breakpoints in your package without having to restart Julia.

Use `@autoinfiltrate` when debugging Trixi.jl

When running Julia inside a package environment, e.g., inside the source code of Trixi.jl itself, the @infiltrate macro only works if Infiltrator has been added to the package dependencies. To avoid this, you can use the (non-exported) @autoinfiltrate macro in Trixi.jl, which only requires Infiltrator.jl to be available in the current environment stack and will auto-load it for you.

Triggering the breakpoint starts a REPL session where it is possible to interact with the current local scope. Possible commands are:

To finish a debugging session, either use @continue to continue and eventually stop at the next breakpoint or @exit to skip further breakpoints. After the code has finished, local variables saved with @exfiltrate can be accessed in the REPL using the safehouse variable.

Limitations of using Infiltrator.jl are that local variables cannot be changed, and that it is not possible to step into further calls or access other function scopes.

Releasing a new version of Trixi.jl, Trixi2Vtk

Preview of the documentation

You can build the documentation of Trixi.jl locally by running

julia --project=docs -e 'using Pkg; Pkg.develop(PackageSpec(path=pwd())); Pkg.instantiate()'
-julia --project=docs --color=yes docs/make.jl

from the Trixi.jl main directory. Then, you can look at the html files generated in docs/build. For PRs triggered from branches inside the Trixi.jl main repository previews of the new documentation are generated at https://trixi-framework.github.io/Trixi.jl/previews/PRXXX, where XXX is the number of the PR. This does not work for PRs from forks for security reasons (since anyone could otherwise push arbitrary stuff to the Trixi.jl website, including malicious code).

Developing Trixi2Vtk

Trixi2Vtk has Trixi.jl as dependency and uses Trixi.jl's implementation to, e.g., load mesh files. When developing Trixi2Vtk, one may want to change functions in Trixi.jl to allow them to be reused in Trixi2Vtk. To use a locally modified Trixi.jl clone instead of a Trixi.jl release, one can tell Pkg to use the local source code of Trixi.jl instead of a registered version by running

(@v1.9) pkg> develop path/to/Trixi.jl
+julia --project=docs --color=yes docs/make.jl

from the Trixi.jl main directory. Then, you can look at the html files generated in docs/build. For PRs triggered from branches inside the Trixi.jl main repository previews of the new documentation are generated at https://trixi-framework.github.io/Trixi.jl/previews/PRXXX, where XXX is the number of the PR. This does not work for PRs from forks for security reasons (since anyone could otherwise push arbitrary stuff to the Trixi.jl website, including malicious code).

Developing Trixi2Vtk

Trixi2Vtk has Trixi.jl as dependency and uses Trixi.jl's implementation to, e.g., load mesh files. When developing Trixi2Vtk, one may want to change functions in Trixi.jl to allow them to be reused in Trixi2Vtk. To use a locally modified Trixi.jl clone instead of a Trixi.jl release, one can tell Pkg to use the local source code of Trixi.jl instead of a registered version by running

(@v1.9) pkg> develop path/to/Trixi.jl
diff --git a/previews/PR1835/github-git/index.html b/previews/PR1835/github-git/index.html index 6db77fed9ef..5a4ed6f129f 100644 --- a/previews/PR1835/github-git/index.html +++ b/previews/PR1835/github-git/index.html @@ -41,4 +41,4 @@ git rebase # Clean reflog and force garbage collection -git reflog expire --expire=now --all && git gc --prune=now --aggressive

IMPORTANT: You need to do a git rebase instead of a git pull when updating the fixed branch.

+git reflog expire --expire=now --all && git gc --prune=now --aggressive

IMPORTANT: You need to do a git rebase instead of a git pull when updating the fixed branch.

diff --git a/previews/PR1835/index.html b/previews/PR1835/index.html index f1016168415..79d0ebc68a2 100644 --- a/previews/PR1835/index.html +++ b/previews/PR1835/index.html @@ -111,4 +111,4 @@ NumFOCUS --> -

This project has benefited from funding by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) through the following grants:

This project has benefited from funding from the European Research Council through the ERC Starting Grant "An Exascale aware and Un-crashable Space-Time-Adaptive Discontinuous Spectral Element Solver for Non-Linear Conservation Laws" (Extreme), ERC grant agreement no. 714487.

This project has benefited from funding from Vetenskapsrådet (VR, Swedish Research Council), Sweden through the VR Starting Grant "Shallow water flows including sediment transport and morphodynamics", VR grant agreement 2020-03642 VR.

This project has benefited from funding from the United States National Science Foundation (NSF) under awards DMS-1719818 and DMS-1943186.

This project has benefited from funding from the German Federal Ministry of Education and Research (BMBF) through the project grant "Adaptive earth system modeling with significantly reduced computation time for exascale supercomputers (ADAPTEX)" (funding id: 16ME0668K).

This project has benefited from funding by the Daimler und Benz Stiftung (Daimler and Benz Foundation) through grant no. 32-10/22.

Trixi.jl is supported by NumFOCUS as an Affiliated Project.

+

This project has benefited from funding by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) through the following grants:

This project has benefited from funding from the European Research Council through the ERC Starting Grant "An Exascale aware and Un-crashable Space-Time-Adaptive Discontinuous Spectral Element Solver for Non-Linear Conservation Laws" (Extreme), ERC grant agreement no. 714487.

This project has benefited from funding from Vetenskapsrådet (VR, Swedish Research Council), Sweden through the VR Starting Grant "Shallow water flows including sediment transport and morphodynamics", VR grant agreement 2020-03642 VR.

This project has benefited from funding from the United States National Science Foundation (NSF) under awards DMS-1719818 and DMS-1943186.

This project has benefited from funding from the German Federal Ministry of Education and Research (BMBF) through the project grant "Adaptive earth system modeling with significantly reduced computation time for exascale supercomputers (ADAPTEX)" (funding id: 16ME0668K).

This project has benefited from funding by the Daimler und Benz Stiftung (Daimler and Benz Foundation) through grant no. 32-10/22.

Trixi.jl is supported by NumFOCUS as an Affiliated Project.

diff --git a/previews/PR1835/license/index.html b/previews/PR1835/license/index.html index 0a9487657a8..7881dab9fd2 100644 --- a/previews/PR1835/license/index.html +++ b/previews/PR1835/license/index.html @@ -1,2 +1,2 @@ -License · Trixi.jl
GitHub

License

MIT License

Copyright (c) 2020-present The Trixi.jl Authors (see Authors)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

+License · Trixi.jl
GitHub

License

MIT License

Copyright (c) 2020-present The Trixi.jl Authors (see Authors)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

diff --git a/previews/PR1835/meshes/dgmulti_mesh/index.html b/previews/PR1835/meshes/dgmulti_mesh/index.html index d3621401434..c64f0de34a5 100644 --- a/previews/PR1835/meshes/dgmulti_mesh/index.html +++ b/previews/PR1835/meshes/dgmulti_mesh/index.html @@ -5,4 +5,4 @@ surface_flux=flux_central, surface_integral=SurfaceIntegralWeakForm(surface_flux), volume_integral=VolumeIntegralWeakForm(), - RefElemData_kwargs...)

Here, element_type can be Tri(), Quad(), Tet(), or Hex(), and approximation_type can be

Additional options can also be specified through RefElemData_kwargs:

The GaussSBP() approximation type on Quad() and Hex() meshes

When using VolumeIntegralFluxDifferencing on Quad() and Hex() meshes, one can also specify approximation_type = GaussSBP() to use an entropy stable Gauss collocation scheme. Here, GaussSBP() refers to "generalized" summation-by-parts operators (see for example Ranocha 2018 or Fernandez and Zingg 2015).

Unlike traditional SBP operators, generalized SBP operators are constructed from nodes which do not include boundary nodes (i.e., Gauss quadrature nodes as opposed to Gauss-Lobatto quadrature nodes). This makes the computation of interface fluxes slightly more expensive, but also usually results in a more accurate solution. Roughly speaking, an entropy stable Gauss collocation scheme will yield results similar to a modal entropy stable scheme using a Polynomial() approximation type, but will be more efficient at high orders of approximation.

Trixi.jl elixirs on simplicial and tensor product element meshes

Example elixirs with triangular, quadrilateral, and tetrahedral meshes can be found in the examples/dgmulti_2d/ and examples/dgmulti_3d/ folders. Some key elixirs to look at:

For developers

DGMultiMesh wrapper type

DGMulti meshes in Trixi.jl are represented using a DGMultiMesh{NDIMS, ...} type. This mesh type is assumed to have fields md::MeshData, which contains geometric terms derived from the mapping between the reference and physical elements, and boundary_faces, which contains a Dict of boundary segment names (symbols) and list of faces which lie on that boundary segment.

A DGMultiMesh can be constructed in several ways. For example, DGMultiMesh(dg::DGMulti) will return a Cartesian mesh on $[-1, 1]^d$ with element types specified by dg. DGMulti meshes can also be constructed by specifying a list of vertex coordinates vertex_coordinates_x, vertex_coordinates_y, vertex_coordinates_z and a connectivity matrix EToV where EToV[e,:] gives the vertices which correspond to element e. These quantities are available from most unstructured mesh generators.

Initial support for curved DGMultiMeshes is available for flux differencing solvers using SBP and GaussSBP approximation types on quadrilateral and hexahedral meshes. These can be called by specifying mesh = DGMultiMesh(dg, cells_per_dimension, mapping), where mapping is a function which specifies the warping of the mesh (e.g., mapping(xi, eta) = SVector{2}(xi, eta) is the identity mapping) similar to the mapping argument used by StructuredMesh.

Variable naming conventions

We use the convention that coordinates on the reference element are $r$ in 1D, $r, s$ in 2D, or $r, s, t$ in 3D. Physical coordinates use the standard conventions $x$ (1D), $x, y$ (2D), and $x, y, z$ (3D).

"Ref-to-physical mapping"

Derivatives of reference coordinates with respect to physical coordinates are abbreviated, e.g., $\frac{\partial r}{\partial x} = r_x$. Additionally, $J$ is used to denote the determinant of the Jacobian of the reference-to-physical mapping.

Variable meanings and conventions in StartUpDG.jl

StartUpDG.jl exports structs RefElemData{NDIMS, ElemShape, ...} (which contains data associated with the reference element, such as interpolation points, quadrature rules, face nodes, normals, and differentiation/interpolation/projection matrices) and MeshData{NDIMS} (which contains geometric data associated with a mesh). These are currently used for evaluating DG formulations in a matrix-free fashion. These structs contain fields similar (but not identical) to those in Globals1D, Globals2D, Globals3D in the Matlab codes from "Nodal Discontinuous Galerkin Methods" by Hesthaven and Warburton (2007).

In general, we use the following code conventions:

Quantities in rd::RefElemData:

Quantities in md::MeshData:

For more details, please see the StartUpDG.jl docs.

+ RefElemData_kwargs...)

Here, element_type can be Tri(), Quad(), Tet(), or Hex(), and approximation_type can be

Additional options can also be specified through RefElemData_kwargs:

The GaussSBP() approximation type on Quad() and Hex() meshes

When using VolumeIntegralFluxDifferencing on Quad() and Hex() meshes, one can also specify approximation_type = GaussSBP() to use an entropy stable Gauss collocation scheme. Here, GaussSBP() refers to "generalized" summation-by-parts operators (see for example Ranocha 2018 or Fernandez and Zingg 2015).

Unlike traditional SBP operators, generalized SBP operators are constructed from nodes which do not include boundary nodes (i.e., Gauss quadrature nodes as opposed to Gauss-Lobatto quadrature nodes). This makes the computation of interface fluxes slightly more expensive, but also usually results in a more accurate solution. Roughly speaking, an entropy stable Gauss collocation scheme will yield results similar to a modal entropy stable scheme using a Polynomial() approximation type, but will be more efficient at high orders of approximation.

Trixi.jl elixirs on simplicial and tensor product element meshes

Example elixirs with triangular, quadrilateral, and tetrahedral meshes can be found in the examples/dgmulti_2d/ and examples/dgmulti_3d/ folders. Some key elixirs to look at:

For developers

DGMultiMesh wrapper type

DGMulti meshes in Trixi.jl are represented using a DGMultiMesh{NDIMS, ...} type. This mesh type is assumed to have fields md::MeshData, which contains geometric terms derived from the mapping between the reference and physical elements, and boundary_faces, which contains a Dict of boundary segment names (symbols) and list of faces which lie on that boundary segment.

A DGMultiMesh can be constructed in several ways. For example, DGMultiMesh(dg::DGMulti) will return a Cartesian mesh on $[-1, 1]^d$ with element types specified by dg. DGMulti meshes can also be constructed by specifying a list of vertex coordinates vertex_coordinates_x, vertex_coordinates_y, vertex_coordinates_z and a connectivity matrix EToV where EToV[e,:] gives the vertices which correspond to element e. These quantities are available from most unstructured mesh generators.

Initial support for curved DGMultiMeshes is available for flux differencing solvers using SBP and GaussSBP approximation types on quadrilateral and hexahedral meshes. These can be called by specifying mesh = DGMultiMesh(dg, cells_per_dimension, mapping), where mapping is a function which specifies the warping of the mesh (e.g., mapping(xi, eta) = SVector{2}(xi, eta) is the identity mapping) similar to the mapping argument used by StructuredMesh.

Variable naming conventions

We use the convention that coordinates on the reference element are $r$ in 1D, $r, s$ in 2D, or $r, s, t$ in 3D. Physical coordinates use the standard conventions $x$ (1D), $x, y$ (2D), and $x, y, z$ (3D).

"Ref-to-physical mapping"

Derivatives of reference coordinates with respect to physical coordinates are abbreviated, e.g., $\frac{\partial r}{\partial x} = r_x$. Additionally, $J$ is used to denote the determinant of the Jacobian of the reference-to-physical mapping.

Variable meanings and conventions in StartUpDG.jl

StartUpDG.jl exports structs RefElemData{NDIMS, ElemShape, ...} (which contains data associated with the reference element, such as interpolation points, quadrature rules, face nodes, normals, and differentiation/interpolation/projection matrices) and MeshData{NDIMS} (which contains geometric data associated with a mesh). These are currently used for evaluating DG formulations in a matrix-free fashion. These structs contain fields similar (but not identical) to those in Globals1D, Globals2D, Globals3D in the Matlab codes from "Nodal Discontinuous Galerkin Methods" by Hesthaven and Warburton (2007).

In general, we use the following code conventions:

Quantities in rd::RefElemData:

Quantities in md::MeshData:

For more details, please see the StartUpDG.jl docs.

diff --git a/previews/PR1835/meshes/p4est_mesh/index.html b/previews/PR1835/meshes/p4est_mesh/index.html index 91b0aead378..713be4e8521 100644 --- a/previews/PR1835/meshes/p4est_mesh/index.html +++ b/previews/PR1835/meshes/p4est_mesh/index.html @@ -345,4 +345,4 @@ 37, 38, 39, 40, 41, 42, 43, 44, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, -94, 95, 96, 97, 98, +94, 95, 96, 97, 98, diff --git a/previews/PR1835/meshes/structured_mesh/index.html b/previews/PR1835/meshes/structured_mesh/index.html index 4fdba4cfdce..fe82585b769 100644 --- a/previews/PR1835/meshes/structured_mesh/index.html +++ b/previews/PR1835/meshes/structured_mesh/index.html @@ -1,2 +1,2 @@ -Structured mesh · Trixi.jl
GitHub

Structured mesh

The StructuredMesh is a structured, curvilinear, conforming mesh type available for one-, two-, and three-dimensional simulations.

Due to its curvilinear nature, (numerical) fluxes need to implement methods dispatching on the normal::AbstractVector. Rotationally invariant equations such as the compressible Euler equations can use FluxRotated to wrap numerical fluxes implemented only for Cartesian meshes. This simplifies the re-use of existing functionality for the TreeMesh but is usually less efficient, cf. PR #550.

+Structured mesh · Trixi.jl
GitHub

Structured mesh

The StructuredMesh is a structured, curvilinear, conforming mesh type available for one-, two-, and three-dimensional simulations.

Due to its curvilinear nature, (numerical) fluxes need to implement methods dispatching on the normal::AbstractVector. Rotationally invariant equations such as the compressible Euler equations can use FluxRotated to wrap numerical fluxes implemented only for Cartesian meshes. This simplifies the re-use of existing functionality for the TreeMesh but is usually less efficient, cf. PR #550.

diff --git a/previews/PR1835/meshes/tree_mesh/index.html b/previews/PR1835/meshes/tree_mesh/index.html index d98da0e71d4..e33c1aa33b1 100644 --- a/previews/PR1835/meshes/tree_mesh/index.html +++ b/previews/PR1835/meshes/tree_mesh/index.html @@ -1,2 +1,2 @@ -Tree mesh · Trixi.jl
GitHub

Tree mesh

The TreeMesh is a Cartesian, $h$-non-conforming mesh type used in many parts of Trixi.jl. Often, the support for this mesh type is developed best since it was the first mesh type in Trixi.jl, and it is available in one, two, and three space dimensions.

It is limited to hypercube domains but supports AMR via the AMRCallback. Due to its Cartesian nature, (numerical) fluxes need to implement methods dispatching on the orientation::Integer as described in the conventions.

+Tree mesh · Trixi.jl
GitHub

Tree mesh

The TreeMesh is a Cartesian, $h$-non-conforming mesh type used in many parts of Trixi.jl. Often, the support for this mesh type is developed best since it was the first mesh type in Trixi.jl, and it is available in one, two, and three space dimensions.

It is limited to hypercube domains but supports AMR via the AMRCallback. Due to its Cartesian nature, (numerical) fluxes need to implement methods dispatching on the orientation::Integer as described in the conventions.

diff --git a/previews/PR1835/meshes/unstructured_quad_mesh/index.html b/previews/PR1835/meshes/unstructured_quad_mesh/index.html index 1d5ef7b8914..897288956c0 100644 --- a/previews/PR1835/meshes/unstructured_quad_mesh/index.html +++ b/previews/PR1835/meshes/unstructured_quad_mesh/index.html @@ -76,4 +76,4 @@ * Upload to YouTube * Obtain responsive code by inserting link on https://embedresponsively.com --> -
+
diff --git a/previews/PR1835/multi-physics_coupling/index.html b/previews/PR1835/multi-physics_coupling/index.html index 6eb0031c9c9..130a5ab23ad 100644 --- a/previews/PR1835/multi-physics_coupling/index.html +++ b/previews/PR1835/multi-physics_coupling/index.html @@ -1,2 +1,2 @@ -Coupling · Trixi.jl
GitHub

Multi-physics coupling

A complex simulation can consist of different spatial domains in which different equations are being solved, different numerical methods being used or the grid structure is different. One example would be a fluid in a tank and an extended hot plate attached to it. We would then like to solve the Navier-Stokes equations in the fluid domain and the heat conduction equations in the plate. The coupling would happen at the interface through the exchange of thermal energy.

Converter coupling

It may happen that the two systems to be coupled do not share any variables, but share some of the physics. In such a situation, the same physics is just represented in a different form and with a different set of variables. This is the case, for instance assuming two domains, if there is a fluid system in one domain and a Vlasov system in the other domain. In that case we would have variables representing distribution functions of the Vlasov system on one side and variables representing the mechanical quantities, like density, of the fluid system. To translate the fields from one description to the other one needs to use converter functions. These functions need to be hand tailored by the user in the elixir file where each pair of coupled systems requires two coupling functions, one for each direction.

In the general case, we have a system $A$ with $m$ variables $u_{A,i}, \: i = 1, \dots, m$ and another system $B$ with $n$ variables $u_{B,j}, \: j = 1, \dots, n$. We then define two coupling functions, one that transforms $u_A$ into $u_B$ and one that goes the other way.

In their minimal form they take the position vector $x$, state vector $u$ and the equations of the two coupled systems and return the transformed variables. By passing the equations we can make use of their parameters, if they are required. Examples can be seen in examples/structured_2d_dgsem/elixir_advection_coupled.jl.

Warning about binary compatibility

Currently the coordinate values on the nodes can differ by machine precision when simulating the mesh and when splitting the mesh in multiple domains. This is an issue coming from the coordinate interpolation on the nodes. As a result, running a simulation in a single system and in two coupled domains may result in a difference of the order of the machine precision. While this is not an issue for most practical problems, it is best to keep this in mind when comparing test runs.

+Coupling · Trixi.jl
GitHub

Multi-physics coupling

A complex simulation can consist of different spatial domains in which different equations are being solved, different numerical methods being used or the grid structure is different. One example would be a fluid in a tank and an extended hot plate attached to it. We would then like to solve the Navier-Stokes equations in the fluid domain and the heat conduction equations in the plate. The coupling would happen at the interface through the exchange of thermal energy.

Converter coupling

It may happen that the two systems to be coupled do not share any variables, but share some of the physics. In such a situation, the same physics is just represented in a different form and with a different set of variables. This is the case, for instance assuming two domains, if there is a fluid system in one domain and a Vlasov system in the other domain. In that case we would have variables representing distribution functions of the Vlasov system on one side and variables representing the mechanical quantities, like density, of the fluid system. To translate the fields from one description to the other one needs to use converter functions. These functions need to be hand tailored by the user in the elixir file where each pair of coupled systems requires two coupling functions, one for each direction.

In the general case, we have a system $A$ with $m$ variables $u_{A,i}, \: i = 1, \dots, m$ and another system $B$ with $n$ variables $u_{B,j}, \: j = 1, \dots, n$. We then define two coupling functions, one that transforms $u_A$ into $u_B$ and one that goes the other way.

In their minimal form they take the position vector $x$, state vector $u$ and the equations of the two coupled systems and return the transformed variables. By passing the equations we can make use of their parameters, if they are required. Examples can be seen in examples/structured_2d_dgsem/elixir_advection_coupled.jl.

Warning about binary compatibility

Currently the coordinate values on the nodes can differ by machine precision when simulating the mesh and when splitting the mesh in multiple domains. This is an issue coming from the coordinate interpolation on the nodes. As a result, running a simulation in a single system and in two coupled domains may result in a difference of the order of the machine precision. While this is not an issue for most practical problems, it is best to keep this in mind when comparing test runs.

diff --git a/previews/PR1835/overview/index.html b/previews/PR1835/overview/index.html index 01723a0d0a7..bcc46e53513 100644 --- a/previews/PR1835/overview/index.html +++ b/previews/PR1835/overview/index.html @@ -1,2 +1,2 @@ -Overview · Trixi.jl
GitHub

Overview of the structure of Trixi.jl

Trixi.jl is designed as a library of components for discretizations of hyperbolic conservation laws. Thus, it is not a monolithic PDE solver that is configured at runtime via parameter files, as it is often found in classical numerical simulation codes. Instead, each simulation is configured by pure Julia code. Many examples of such simulation setups, called elixirs in Trixi.jl, are provided in the examples/ folder.

Trixi.jl uses the method of lines, i.e., the full space-time discretization is separated into two steps; the spatial semidiscretization is performed at first and the resulting ODE system is solved numerically using a suitable time integration method. Thus, the main ingredients of an elixir designed to solve a PDE numerically are the spatial semidiscretization and the time integration scheme.

Semidiscretizations

Semidiscretizations are high-level descriptions of spatial discretizations specialized for certain PDEs. Trixi.jl's main focus is on hyperbolic conservation laws represented in a SemidiscretizationHyperbolic. Such semidiscretizations are usually named semi in Trixi.jl

semidiscretization_overview

The basic building blocks of a semidiscretization are

  • a mesh describing the geometry of the domain
  • a set of equations describing the physical model
  • a solver describing the numerical approach

In addition, a semidiscretization bundles initial and boundary conditions, and possible source terms. These different ingredients of a semidiscretization can be configured individually and combined together. When a semidiscretization is constructed, it will create an internal cache, i.e., a collection of setup-specific data structures, that is usually passed to all lower level functions.

Due to Trixi.jl's modular nature using Julia's multiple dispatch features, new ingredients can be created specifically for a certain combination of other ingredients. For example, a new mesh type can be created and implemented at first only for a specific solver. Thus, there is no need to consider all possible combinations of meshes, equations, and solvers when implementing new features. This allows rapid prototyping of new ideas and is one of the main design goals behind Trixi.jl. Below is a brief overview of the availability of different features on different mesh types.

FeatureTreeMeshStructuredMeshUnstructuredMesh2DP4estMeshDGMultiMeshFurther reading
Spatial dimension1D, 2D, 3D1D, 2D, 3D2D2D, 3D1D, 2D, 3D
CoordinatesCartesiancurvilinearcurvilinearcurvilinearcurvilinear
Connectivityh-nonconformingconformingconformingh-nonconformingconforming
Element typeline, square, cubeline, quadᵃ, hexᵃquadᵃquadᵃ, hexᵃsimplex, quadᵃ, hexᵃ
Adaptive mesh refinement✅❌❌✅❌AMRCallback
Solver typeDGSEMDGSEMDGSEMDGSEMDGMulti
Domainhypercubemapped hypercubearbitraryarbitraryarbitrary
Weak form✅✅✅✅✅VolumeIntegralWeakForm
Flux differencing✅✅✅✅✅VolumeIntegralFluxDifferencing
Shock capturing✅✅✅✅❌VolumeIntegralShockCapturingHG
Nonconservative equations✅✅✅✅✅e.g., GLM MHD or shallow water equations
Parabolic terms✅✅❌✅✅e.g., CompressibleNavierStokesDiffusion2D

ᵃ: quad = quadrilateral, hex = hexahedron

Time integration methods

Trixi.jl is compatible with the SciML ecosystem for ordinary differential equations. In particular, a spatial semidiscretization can be wrapped in an ODE problem using semidiscretize, which returns an ODEProblem. This ODEProblem is a wrapper of Trixi.rhs!(du_ode, u_ode, semi, t), which gets called in ODE solvers. Further information can be found in the section on time integration methods.

Next steps

We explicitly encourage people interested in Trixi.jl to have a look at the examples/ bundled with Trixi.jl to get an impression of what is possible and the general look and feel of Trixi.jl. Before doing that, it is usually good to get an idea of how to visualize numerical results.

If you like learning by doing, looking at the tutorials and trying to mix your own elixirs based thereon is probably a good next step. Otherwise, you can further dig into the documentation by looking at Trixi.jl's basic building blocks.

+Overview · Trixi.jl
GitHub

Overview of the structure of Trixi.jl

Trixi.jl is designed as a library of components for discretizations of hyperbolic conservation laws. Thus, it is not a monolithic PDE solver that is configured at runtime via parameter files, as it is often found in classical numerical simulation codes. Instead, each simulation is configured by pure Julia code. Many examples of such simulation setups, called elixirs in Trixi.jl, are provided in the examples/ folder.

Trixi.jl uses the method of lines, i.e., the full space-time discretization is separated into two steps; the spatial semidiscretization is performed at first and the resulting ODE system is solved numerically using a suitable time integration method. Thus, the main ingredients of an elixir designed to solve a PDE numerically are the spatial semidiscretization and the time integration scheme.

Semidiscretizations

Semidiscretizations are high-level descriptions of spatial discretizations specialized for certain PDEs. Trixi.jl's main focus is on hyperbolic conservation laws represented in a SemidiscretizationHyperbolic. Such semidiscretizations are usually named semi in Trixi.jl

semidiscretization_overview

The basic building blocks of a semidiscretization are

  • a mesh describing the geometry of the domain
  • a set of equations describing the physical model
  • a solver describing the numerical approach

In addition, a semidiscretization bundles initial and boundary conditions, and possible source terms. These different ingredients of a semidiscretization can be configured individually and combined together. When a semidiscretization is constructed, it will create an internal cache, i.e., a collection of setup-specific data structures, that is usually passed to all lower level functions.

Due to Trixi.jl's modular nature using Julia's multiple dispatch features, new ingredients can be created specifically for a certain combination of other ingredients. For example, a new mesh type can be created and implemented at first only for a specific solver. Thus, there is no need to consider all possible combinations of meshes, equations, and solvers when implementing new features. This allows rapid prototyping of new ideas and is one of the main design goals behind Trixi.jl. Below is a brief overview of the availability of different features on different mesh types.

FeatureTreeMeshStructuredMeshUnstructuredMesh2DP4estMeshDGMultiMeshFurther reading
Spatial dimension1D, 2D, 3D1D, 2D, 3D2D2D, 3D1D, 2D, 3D
CoordinatesCartesiancurvilinearcurvilinearcurvilinearcurvilinear
Connectivityh-nonconformingconformingconformingh-nonconformingconforming
Element typeline, square, cubeline, quadᵃ, hexᵃquadᵃquadᵃ, hexᵃsimplex, quadᵃ, hexᵃ
Adaptive mesh refinement✅❌❌✅❌AMRCallback
Solver typeDGSEMDGSEMDGSEMDGSEMDGMulti
Domainhypercubemapped hypercubearbitraryarbitraryarbitrary
Weak form✅✅✅✅✅VolumeIntegralWeakForm
Flux differencing✅✅✅✅✅VolumeIntegralFluxDifferencing
Shock capturing✅✅✅✅❌VolumeIntegralShockCapturingHG
Nonconservative equations✅✅✅✅✅e.g., GLM MHD or shallow water equations
Parabolic terms✅✅❌✅✅e.g., CompressibleNavierStokesDiffusion2D

ᵃ: quad = quadrilateral, hex = hexahedron

Time integration methods

Trixi.jl is compatible with the SciML ecosystem for ordinary differential equations. In particular, a spatial semidiscretization can be wrapped in an ODE problem using semidiscretize, which returns an ODEProblem. This ODEProblem is a wrapper of Trixi.rhs!(du_ode, u_ode, semi, t), which gets called in ODE solvers. Further information can be found in the section on time integration methods.

Next steps

We explicitly encourage people interested in Trixi.jl to have a look at the examples/ bundled with Trixi.jl to get an impression of what is possible and the general look and feel of Trixi.jl. Before doing that, it is usually good to get an idea of how to visualize numerical results.

If you like learning by doing, looking at the tutorials and trying to mix your own elixirs based thereon is probably a good next step. Otherwise, you can further dig into the documentation by looking at Trixi.jl's basic building blocks.

diff --git a/previews/PR1835/parallelization/index.html b/previews/PR1835/parallelization/index.html index 4f59acaf086..bb72715a551 100644 --- a/previews/PR1835/parallelization/index.html +++ b/previews/PR1835/parallelization/index.html @@ -44,4 +44,4 @@ UUID("f67ccb44-e63f-5c2f-98bd-6dc0ccc4ba2f"), # UUID of HDF5.jl "libhdf5" => "/path/to/your/libhdf5.so", "libhdf5_hl" => "/path/to/your/libhdf5_hl.so", force = true)

Alternatively, with HDF5.jl v0.17.1 or higher you can use

julia> using HDF5
-julia> HDF5.API.set_libraries!("/path/to/your/libhdf5.so", "/path/to/your/libhdf5_hl.so")

For more information see also the documentation of HDF5.jl. In total, you should have a file called LocalPreferences.toml in the project directory that contains a section [MPIPreferences], a section [HDF5] with entries libhdf5 and libhdf5_hl, a section [P4est] with the entry libp4est as well as a section [T8code] with the entries libt8, libp4est and libsc. If you use HDF5.jl v0.16 or older, instead of setting the preferences for HDF5.jl, you need to set the environment variable JULIA_HDF5_PATH to the path, where the HDF5 binaries are located and then call ]build HDF5 from Julia.

If HDF5 is not MPI-enabled, Trixi.jl will fall back on a less efficient I/O mechanism. In that case, all disk I/O is performed only on rank zero and data is distributed to/gathered from the other ranks using regular MPI communication.

+julia> HDF5.API.set_libraries!("/path/to/your/libhdf5.so", "/path/to/your/libhdf5_hl.so")

For more information see also the documentation of HDF5.jl. In total, you should have a file called LocalPreferences.toml in the project directory that contains a section [MPIPreferences], a section [HDF5] with entries libhdf5 and libhdf5_hl, a section [P4est] with the entry libp4est as well as a section [T8code] with the entries libt8, libp4est and libsc. If you use HDF5.jl v0.16 or older, instead of setting the preferences for HDF5.jl, you need to set the environment variable JULIA_HDF5_PATH to the path, where the HDF5 binaries are located and then call ]build HDF5 from Julia.

If HDF5 is not MPI-enabled, Trixi.jl will fall back on a less efficient I/O mechanism. In that case, all disk I/O is performed only on rank zero and data is distributed to/gathered from the other ranks using regular MPI communication.

diff --git a/previews/PR1835/performance/index.html b/previews/PR1835/performance/index.html index 479f5a3fb23..e8d05f74e1d 100644 --- a/previews/PR1835/performance/index.html +++ b/previews/PR1835/performance/index.html @@ -52,4 +52,4 @@ BenchmarkConfig(juliacmd=`$(Base.julia_cmd()) --check-bounds=no --threads=1`, id="main") # baseline ) -julia> export_markdown(pkgdir(Trixi, "benchmark", "results.md"), results)

By default, the target is the current state of the repository. Remember that you need to be in a clean state (commit or stash your changes) to run this successfully. You can also run this comparison and an additional one using two threads via

julia> include("benchmark/run_benchmarks.jl")

Then, markdown files including the results are saved in benchmark/. This example result was obtained using a GitHub action for the PR #535. Note that GitHub actions run on in the cloud in a virtual machine. Hence, we do not really have control over it and performance results must be taken with a grain of salt. Nevertheless, significant runtime differences and differences of memory allocations should be robust indicators of performance changes.

Runtime performance vs. latency aka using @nospecialize selectively

Usually, Julia will compile specialized versions of each method, using as much information from the types of function arguments as possible (based on some heuristics). The compiler will generate code that is as efficient as comparable code written in a low-level language such as C or Fortran. However, there are cases where the runtime performance does not really matter but the time needed to compile specializations becomes significant. This is related to latency or the time-to-first-plot problem, well-known in the Julia community. In such a case, it can be useful to remove some burden from the compiler by avoiding specialization on every possible argument types using the macro @nospecialize. A prime example of such a case is pretty printing of structs in the Julia REPL, see the associated PR for further discussions.

As a rule of thumb:

Performance metrics of the AnalysisCallback

The AnalysisCallback computes two performance indicators that you can use to evaluate the serial and parallel performance of Trixi.jl. They represent measured run times that are normalized by the number of rhs! evaluations and the number of degrees of freedom of the problem setup. The normalization ensures that we can compare different measurements for each type of indicator independent of the number of time steps or mesh size. All indicators have in common that they are still in units of time, thus lower is better for each of them.

Here, the term "degrees of freedom" (DOFs) refers to the number of independent state vectors that are used to represent the numerical solution. For example, if you use a DGSEM-type scheme in 2D on a mesh with 8 elements and with 5-by-5 Gauss-Lobatto nodes in each element (i.e., a polynomial degree of 4), the total number of DOFs would be

\[n_\text{DOFs,DGSEM} = \{\text{number of elements}\} \cdot \{\text{number of nodes per element}\} = 8 \cdot (5 \cdot 5) = 200.\]

In contrast, for a finite volume-type scheme on a mesh with 8 elements, the total number of DOFs would be (independent of the number of spatial dimensions)

\[n_\text{DOFs,FV} = \{\text{number of elements}\} = 8,\]

since for standard finite volume methods you store a single state vector in each element. Note that we specifically count the number of state vectors and not the number of state variables for the DOFs. That is, in the previous example $n_\text{DOFs,FV}$ is equal to 8 independent of whether this is a compressible Euler setup with 5 state variables or a linear scalar advection setup with one state variable.

For each indicator, the measurements are always since the last invocation of the AnalysisCallback. That is, if the analysis callback is called multiple times, the indicators are repeatedly computed and can thus also be used to track the performance over the course of a longer simulation, e.g., to analyze setups with varying performance characteristics. Note that the time spent in the AnalysisCallback itself is always excluded, i.e., the performance measurements are not distorted by potentially expensive solution analysis computations. All other parts of a Trixi.jl simulation are included, however, thus make sure that you disable everything you do not want to be measured (such as I/O callbacks, visualization etc.).

Performance indicators and adaptive mesh refinement

Currently it is not possible to compute meaningful performance indicators for a simulation with arbitrary adaptive mesh refinement, since this would require to explicitly keep track of the number of DOF updates due to the mesh size changing repeatedly. The only way to do this at the moment is by setting the analysis interval to the same value as the AMR interval.

Local, rhs!-only indicator

The local, rhs!-only indicator is computed as

\[\text{time/DOF/rhs!} = \frac{t_\text{\texttt{rhs!}}}{n_\text{DOFs,local} \cdot n_\text{calls,\texttt{rhs!}}},\]

where $t_\text{\texttt{rhs!}}$ is the accumulated time spent in rhs!, $n_\text{DOFs,local}$ is the local number of DOFs (i.e., on the current MPI rank; if doing a serial run, you can just think of this as the number of DOFs), and $n_\text{calls,\texttt{rhs!}}$ is the number of times the rhs! function has been evaluated. Note that for this indicator, we measure only the time spent in rhs!, i.e., by definition all computations outside of rhs! - specifically all other callbacks and the time integration method - are not taken into account.

The local, rhs!-only indicator is usually most useful if you do serial measurements and are interested in the performance of the implementation of your core numerical methods (e.g., when doing performance tuning).

Performance index (PID)

The performance index (PID) is computed as

\[\text{PID} = \frac{t_\text{wall} \cdot n_\text{ranks,MPI}}{n_\text{DOFs,global} \cdot n_\text{calls,\texttt{rhs!}}},\]

where $t_\text{wall}$ is the walltime since the last call to the AnalysisCallback, $n_\text{ranks,MPI}$ is the number of MPI ranks used, $n_\text{DOFs,global}$ is the global number of DOFs (i.e., the sum of DOFs over all MPI ranks; if doing a serial run, you can just think of this as the number of DOFs), and $n_\text{calls,\texttt{rhs!}}$ is the number of times the rhs! function has been evaluated since the last call to the AnalysisCallback. The PID measures everything except the time spent in the AnalysisCallback itself - specifically, all other callbacks and the time integration method itself are included.

The PID is usually most useful if you would like to compare the parallel performance of your code to its serial performance. Specifically, it allows you to evaluate the parallelization overhead of your code by giving you a measure of the resources that are necessary to solve a given simulation setup. In a sense, it mimics the "core hours" metric that is often used by supercomputer centers to measure how many resources a particular compute job requires. It can thus be seen as a proxy for "energy used" and, as an extension, "monetary cost".

Initialization overhead in measurements

When using one of the integration schemes from OrdinaryDiffEq.jl, their implementation will initialize some OrdinaryDiffEq.jl-specific information during the first time step. Among other things, one additional call to rhs! is performed. Therefore, make sure that for performance measurements using the PID either the number of timesteps or the workload per rhs! call is large enough to make the initialization overhead negligible. Note that the extra call to rhs! is properly accounted for in both the number of calls and the measured time, so you do not need to worry about it being expensive. If you want a perfect timing result, you need to set the analysis interval such that the AnalysisCallback is invoked at least once during the course of the simulation and discard the first PID value.

Performance issues with multi-threaded reductions

False sharing is a known performance issue for systems with distributed caches. It also occurred for the implementation of a thread parallel bounds checking routine for the subcell IDP limiting in PR #1736. After some testing and discussion, it turned out that initializing a vector of length n * Threads.nthreads() and only using every n-th entry instead of a vector of length Threads.nthreads() fixes the problem. Since there are no processors with caches over 128B, we use n = 128B / size(uEltype). Now, the bounds checking routine of the IDP limiting scales as hoped.

+julia> export_markdown(pkgdir(Trixi, "benchmark", "results.md"), results)

By default, the target is the current state of the repository. Remember that you need to be in a clean state (commit or stash your changes) to run this successfully. You can also run this comparison and an additional one using two threads via

julia> include("benchmark/run_benchmarks.jl")

Then, markdown files including the results are saved in benchmark/. This example result was obtained using a GitHub action for the PR #535. Note that GitHub actions run on in the cloud in a virtual machine. Hence, we do not really have control over it and performance results must be taken with a grain of salt. Nevertheless, significant runtime differences and differences of memory allocations should be robust indicators of performance changes.

Runtime performance vs. latency aka using @nospecialize selectively

Usually, Julia will compile specialized versions of each method, using as much information from the types of function arguments as possible (based on some heuristics). The compiler will generate code that is as efficient as comparable code written in a low-level language such as C or Fortran. However, there are cases where the runtime performance does not really matter but the time needed to compile specializations becomes significant. This is related to latency or the time-to-first-plot problem, well-known in the Julia community. In such a case, it can be useful to remove some burden from the compiler by avoiding specialization on every possible argument types using the macro @nospecialize. A prime example of such a case is pretty printing of structs in the Julia REPL, see the associated PR for further discussions.

As a rule of thumb:

Performance metrics of the AnalysisCallback

The AnalysisCallback computes two performance indicators that you can use to evaluate the serial and parallel performance of Trixi.jl. They represent measured run times that are normalized by the number of rhs! evaluations and the number of degrees of freedom of the problem setup. The normalization ensures that we can compare different measurements for each type of indicator independent of the number of time steps or mesh size. All indicators have in common that they are still in units of time, thus lower is better for each of them.

Here, the term "degrees of freedom" (DOFs) refers to the number of independent state vectors that are used to represent the numerical solution. For example, if you use a DGSEM-type scheme in 2D on a mesh with 8 elements and with 5-by-5 Gauss-Lobatto nodes in each element (i.e., a polynomial degree of 4), the total number of DOFs would be

\[n_\text{DOFs,DGSEM} = \{\text{number of elements}\} \cdot \{\text{number of nodes per element}\} = 8 \cdot (5 \cdot 5) = 200.\]

In contrast, for a finite volume-type scheme on a mesh with 8 elements, the total number of DOFs would be (independent of the number of spatial dimensions)

\[n_\text{DOFs,FV} = \{\text{number of elements}\} = 8,\]

since for standard finite volume methods you store a single state vector in each element. Note that we specifically count the number of state vectors and not the number of state variables for the DOFs. That is, in the previous example $n_\text{DOFs,FV}$ is equal to 8 independent of whether this is a compressible Euler setup with 5 state variables or a linear scalar advection setup with one state variable.

For each indicator, the measurements are always since the last invocation of the AnalysisCallback. That is, if the analysis callback is called multiple times, the indicators are repeatedly computed and can thus also be used to track the performance over the course of a longer simulation, e.g., to analyze setups with varying performance characteristics. Note that the time spent in the AnalysisCallback itself is always excluded, i.e., the performance measurements are not distorted by potentially expensive solution analysis computations. All other parts of a Trixi.jl simulation are included, however, thus make sure that you disable everything you do not want to be measured (such as I/O callbacks, visualization etc.).

Performance indicators and adaptive mesh refinement

Currently it is not possible to compute meaningful performance indicators for a simulation with arbitrary adaptive mesh refinement, since this would require to explicitly keep track of the number of DOF updates due to the mesh size changing repeatedly. The only way to do this at the moment is by setting the analysis interval to the same value as the AMR interval.

Local, rhs!-only indicator

The local, rhs!-only indicator is computed as

\[\text{time/DOF/rhs!} = \frac{t_\text{\texttt{rhs!}}}{n_\text{DOFs,local} \cdot n_\text{calls,\texttt{rhs!}}},\]

where $t_\text{\texttt{rhs!}}$ is the accumulated time spent in rhs!, $n_\text{DOFs,local}$ is the local number of DOFs (i.e., on the current MPI rank; if doing a serial run, you can just think of this as the number of DOFs), and $n_\text{calls,\texttt{rhs!}}$ is the number of times the rhs! function has been evaluated. Note that for this indicator, we measure only the time spent in rhs!, i.e., by definition all computations outside of rhs! - specifically all other callbacks and the time integration method - are not taken into account.

The local, rhs!-only indicator is usually most useful if you do serial measurements and are interested in the performance of the implementation of your core numerical methods (e.g., when doing performance tuning).

Performance index (PID)

The performance index (PID) is computed as

\[\text{PID} = \frac{t_\text{wall} \cdot n_\text{ranks,MPI}}{n_\text{DOFs,global} \cdot n_\text{calls,\texttt{rhs!}}},\]

where $t_\text{wall}$ is the walltime since the last call to the AnalysisCallback, $n_\text{ranks,MPI}$ is the number of MPI ranks used, $n_\text{DOFs,global}$ is the global number of DOFs (i.e., the sum of DOFs over all MPI ranks; if doing a serial run, you can just think of this as the number of DOFs), and $n_\text{calls,\texttt{rhs!}}$ is the number of times the rhs! function has been evaluated since the last call to the AnalysisCallback. The PID measures everything except the time spent in the AnalysisCallback itself - specifically, all other callbacks and the time integration method itself are included.

The PID is usually most useful if you would like to compare the parallel performance of your code to its serial performance. Specifically, it allows you to evaluate the parallelization overhead of your code by giving you a measure of the resources that are necessary to solve a given simulation setup. In a sense, it mimics the "core hours" metric that is often used by supercomputer centers to measure how many resources a particular compute job requires. It can thus be seen as a proxy for "energy used" and, as an extension, "monetary cost".

Initialization overhead in measurements

When using one of the integration schemes from OrdinaryDiffEq.jl, their implementation will initialize some OrdinaryDiffEq.jl-specific information during the first time step. Among other things, one additional call to rhs! is performed. Therefore, make sure that for performance measurements using the PID either the number of timesteps or the workload per rhs! call is large enough to make the initialization overhead negligible. Note that the extra call to rhs! is properly accounted for in both the number of calls and the measured time, so you do not need to worry about it being expensive. If you want a perfect timing result, you need to set the analysis interval such that the AnalysisCallback is invoked at least once during the course of the simulation and discard the first PID value.

Performance issues with multi-threaded reductions

False sharing is a known performance issue for systems with distributed caches. It also occurred for the implementation of a thread parallel bounds checking routine for the subcell IDP limiting in PR #1736. After some testing and discussion, it turned out that initializing a vector of length n * Threads.nthreads() and only using every n-th entry instead of a vector of length Threads.nthreads() fixes the problem. Since there are no processors with caches over 128B, we use n = 128B / size(uEltype). Now, the bounds checking routine of the IDP limiting scales as hoped.

diff --git a/previews/PR1835/reference-trixi/index.html b/previews/PR1835/reference-trixi/index.html index 298fad97170..9e21d4cedc3 100644 --- a/previews/PR1835/reference-trixi/index.html +++ b/previews/PR1835/reference-trixi/index.html @@ -1,9 +1,9 @@ -Trixi.jl · Trixi.jl
GitHub

Trixi.jl API

Trixi.Trixi — Module
Trixi

Trixi.jl is a numerical simulation framework for hyperbolic conservation laws. A key objective for the framework is to be useful to both scientists and students. Therefore, next to having an extensible design with a fast implementation, Trixi.jl is focused on being easy to use for new or inexperienced users, including the installation and postprocessing procedures.

To get started, run your first simulation with Trixi.jl using

trixi_include(default_example())

See also: trixi-framework/Trixi.jl

source
Trixi.AMRCallback — Type
AMRCallback(semi, controller [,adaptor=AdaptorAMR(semi)];
+Trixi.jl · Trixi.jl
GitHub
Trixi.jl API
Trixi.Trixi — Module
Trixi
Trixi.jl is a numerical simulation framework for hyperbolic conservation laws. A key objective for the framework is to be useful to both scientists and students. Therefore, next to having an extensible design with a fast implementation, Trixi.jl is focused on being easy to use for new or inexperienced users, including the installation and postprocessing procedures.
To get started, run your first simulation with Trixi.jl using
trixi_include(default_example())
See also: trixi-framework/Trixi.jl
source
Trixi.AMRCallback — Type
AMRCallback(semi, controller [,adaptor=AdaptorAMR(semi)];
             interval,
             adapt_initial_condition=true,
             adapt_initial_condition_only_refine=true,
-            dynamic_load_balancing=true)
Performs adaptive mesh refinement (AMR) every interval time steps for a given semidiscretization semi using the chosen controller.
source
Trixi.AbstractEquations — Type
AbstractEquations{NDIMS, NVARS}
An abstract supertype of specific equations such as the compressible Euler equations. The type parameters encode the number of spatial dimensions (NDIMS) and the number of primary variables (NVARS) of the physics model.
source
Trixi.AbstractMesh — Type
AbstractMesh{NDIMS}
An abstract supertype of specific mesh types such as TreeMesh or StructuredMesh. The type parameters encode the number of spatial dimensions (NDIMS).
source
Trixi.AcousticPerturbationEquations2D — Type
AcousticPerturbationEquations2D(v_mean_global, c_mean_global, rho_mean_global)
Acoustic perturbation equations (APE) in two space dimensions. The equations are given by
\[\begin{aligned}
+            dynamic_load_balancing=true)

Performs adaptive mesh refinement (AMR) every interval time steps for a given semidiscretization semi using the chosen controller.

source
Trixi.AbstractEquations — Type
AbstractEquations{NDIMS, NVARS}

An abstract supertype of specific equations such as the compressible Euler equations. The type parameters encode the number of spatial dimensions (NDIMS) and the number of primary variables (NVARS) of the physics model.

source
Trixi.AbstractMesh — Type
AbstractMesh{NDIMS}

An abstract supertype of specific mesh types such as TreeMesh or StructuredMesh. The type parameters encode the number of spatial dimensions (NDIMS).

source
Trixi.AcousticPerturbationEquations2D — Type
AcousticPerturbationEquations2D(v_mean_global, c_mean_global, rho_mean_global)

Acoustic perturbation equations (APE) in two space dimensions. The equations are given by

\[\begin{aligned} \frac{\partial\mathbf{v'}}{\partial t} + \nabla (\bar{\mathbf{v}}\cdot\mathbf{v'}) + \nabla\left( \frac{\bar{c}^2 \tilde{p}'}{\bar{\rho}} \right) &= 0 \\ \frac{\partial \tilde{p}'}{\partial t} + @@ -11,13 +11,13 @@ \end{aligned}\]

The bar $\bar{(\cdot)}$ indicates time-averaged quantities. The unknowns of the APE are the perturbed velocities $\mathbf{v'} = (v_1', v_2')^T$ and the scaled perturbed pressure $\tilde{p}' = \frac{p'}{\bar{c}^2}$, where $p'$ denotes the perturbed pressure and the perturbed variables are defined by $\phi' = \phi - \bar{\phi}$.

In addition to the unknowns, Trixi.jl currently stores the mean values in the state vector, i.e. the state vector used internally is given by

\[\mathbf{u} = \begin{pmatrix} v_1' \\ v_2' \\ \tilde{p}' \\ \bar{v}_1 \\ \bar{v}_2 \\ \bar{c} \\ \bar{\rho} - \end{pmatrix}.\]

This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the mean values must be zero.
  • The mean values have to be considered when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes these variables too.
  • Trixi.jl's visualization tools will visualize the mean values by default.

The constructor accepts a 2-tuple v_mean_global and scalars c_mean_global and rho_mean_global which can be used to make the definition of initial conditions for problems with constant mean flow more flexible. These values are ignored if the mean values are defined internally in an initial condition.

The equations are based on the APE-4 system introduced in the following paper:

source
Trixi.Adiabatic — Type
struct Adiabatic

Used to create a no-slip boundary condition with BoundaryConditionNavierStokesWall. The field boundary_value_normal_flux_function should be a function with signature boundary_value_normal_flux_function(x, t, equations) and return a scalar value for the normal heat flux at point x and time t.

source
Trixi.AliveCallback — Type
AliveCallback(analysis_interval=0, alive_interval=analysis_interval÷10)

Inexpensive callback showing that a simulation is still running by printing some information such as the current time to the screen every alive_interval time steps. If analysis_interval ≂̸ 0, the output is omitted every analysis_interval time steps.

source
Trixi.AnalysisCallback — Type
AnalysisCallback(semi; interval=0,
+  \end{pmatrix}.\]
This affects the implementation and use of these equations in various ways:
  • The flux values corresponding to the mean values must be zero.
  • The mean values have to be considered when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes these variables too.
  • Trixi.jl's visualization tools will visualize the mean values by default.
The constructor accepts a 2-tuple v_mean_global and scalars c_mean_global and rho_mean_global which can be used to make the definition of initial conditions for problems with constant mean flow more flexible. These values are ignored if the mean values are defined internally in an initial condition.
The equations are based on the APE-4 system introduced in the following paper:
source
Trixi.Adiabatic — Type
struct Adiabatic

Used to create a no-slip boundary condition with BoundaryConditionNavierStokesWall. The field boundary_value_normal_flux_function should be a function with signature boundary_value_normal_flux_function(x, t, equations) and return a scalar value for the normal heat flux at point x and time t.

source
Trixi.AliveCallback — Type
AliveCallback(analysis_interval=0, alive_interval=analysis_interval÷10)

Inexpensive callback showing that a simulation is still running by printing some information such as the current time to the screen every alive_interval time steps. If analysis_interval ≂̸ 0, the output is omitted every analysis_interval time steps.

source
Trixi.AnalysisCallback — Type
AnalysisCallback(semi; interval=0,
                        save_analysis=false,
                        output_directory="out",
                        analysis_filename="analysis.dat",
                        extra_analysis_errors=Symbol[],
-                       extra_analysis_integrals=())

Analyze a numerical solution every interval time steps and print the results to the screen. If save_analysis, the results are also saved in joinpath(output_directory, analysis_filename).

Additional errors can be computed, e.g. by passing extra_analysis_errors = (:l2_error_primitive, :linf_error_primitive) or extra_analysis_errors = (:conservation_error,).

If you want to omit the computation (to safe compute-time) of the default_analysis_errors, specify analysis_errors = Symbol[]. Note: default_analysis_errors are :l2_error and :linf_error for all equations. If you want to compute extra_analysis_errors such as :conservation_error solely, i.e., without :l2_error, :linf_error you need to specify analysis_errors = [:conservation_error] instead of extra_analysis_errors = [:conservation_error].

Further scalar functions func in extra_analysis_integrals are applied to the numerical solution and integrated over the computational domain. Some examples for this are entropy, energy_kinetic, energy_internal, and energy_total. You can also write your own function with the same signature as the examples listed above and pass it via extra_analysis_integrals. See the developer comments about Trixi.analyze, Trixi.pretty_form_utf, and Trixi.pretty_form_ascii for further information on how to create custom analysis quantities.

In addition, the analysis callback records and outputs a number of quantities that are useful for evaluating the computational performance, such as the total runtime, the performance index (time/DOF/rhs!), the time spent in garbage collection (GC), or the current memory usage (alloc'd memory).

source
Trixi.AnalysisCallbackCoupled — Type
AnalysisCallbackCoupled(semi, callbacks...)

Combine multiple analysis callbacks for coupled simulations with a SemidiscretizationCoupled. For each coupled system, an indididual AnalysisCallback must be created and passed to the AnalysisCallbackCoupled in order, i.e., in the same sequence as the indidvidual semidiscretizations are stored in the SemidiscretizationCoupled.

Experimental code

This is an experimental feature and can change any time.

source
Trixi.AveragingCallback — Type
AveragingCallback(semi::SemidiscretizationHyperbolic, tspan; output_directory="out",
-                  filename="averaging.h5")
Experimental code

This callback is experimental and may change in any future release.

A callback that averages the flow field described by semi which must be a semidiscretization of the compressible Euler equations in two dimensions. The callback records the mean velocity, mean speed of sound, mean density, and mean vorticity for each node over the time interval given by tspan and stores the results in an HDF5 file filename in the directory output_directory. Note that this callback does not support adaptive mesh refinement (AMRCallback).

source
Trixi.BoundaryConditionCoupled — Type
BoundaryConditionCoupled(other_semi_index, indices, uEltype, coupling_converter)

Boundary condition to glue two meshes together. Solution values at the boundary of another mesh will be used as boundary values. This requires the use of SemidiscretizationCoupled. The other mesh is specified by other_semi_index, which is the index of the mesh in the tuple of semidiscretizations.

Note that the elements and nodes of the two meshes at the coupled boundary must coincide. This is currently only implemented for StructuredMesh.

Arguments

  • other_semi_index: the index in SemidiscretizationCoupled of the semidiscretization from which the values are copied
  • indices::Tuple: node/cell indices at the boundary of the mesh in the other semidiscretization. See examples below.
  • uEltype::Type: element type of solution
  • coupling_converter::CouplingConverter: function to call for converting the solution state of one system to the other system

Examples

# Connect the left boundary of mesh 2 to our boundary such that our positive
+                       extra_analysis_integrals=())

Analyze a numerical solution every interval time steps and print the results to the screen. If save_analysis, the results are also saved in joinpath(output_directory, analysis_filename).

Additional errors can be computed, e.g. by passing extra_analysis_errors = (:l2_error_primitive, :linf_error_primitive) or extra_analysis_errors = (:conservation_error,).

If you want to omit the computation (to safe compute-time) of the default_analysis_errors, specify analysis_errors = Symbol[]. Note: default_analysis_errors are :l2_error and :linf_error for all equations. If you want to compute extra_analysis_errors such as :conservation_error solely, i.e., without :l2_error, :linf_error you need to specify analysis_errors = [:conservation_error] instead of extra_analysis_errors = [:conservation_error].

Further scalar functions func in extra_analysis_integrals are applied to the numerical solution and integrated over the computational domain. Some examples for this are entropy, energy_kinetic, energy_internal, and energy_total. You can also write your own function with the same signature as the examples listed above and pass it via extra_analysis_integrals. See the developer comments about Trixi.analyze, Trixi.pretty_form_utf, and Trixi.pretty_form_ascii for further information on how to create custom analysis quantities.

In addition, the analysis callback records and outputs a number of quantities that are useful for evaluating the computational performance, such as the total runtime, the performance index (time/DOF/rhs!), the time spent in garbage collection (GC), or the current memory usage (alloc'd memory).

source
Trixi.AnalysisCallbackCoupled — Type
AnalysisCallbackCoupled(semi, callbacks...)

Combine multiple analysis callbacks for coupled simulations with a SemidiscretizationCoupled. For each coupled system, an indididual AnalysisCallback must be created and passed to the AnalysisCallbackCoupled in order, i.e., in the same sequence as the indidvidual semidiscretizations are stored in the SemidiscretizationCoupled.

Experimental code

This is an experimental feature and can change any time.

source
Trixi.AveragingCallback — Type
AveragingCallback(semi::SemidiscretizationHyperbolic, tspan; output_directory="out",
+                  filename="averaging.h5")
Experimental code

This callback is experimental and may change in any future release.

A callback that averages the flow field described by semi which must be a semidiscretization of the compressible Euler equations in two dimensions. The callback records the mean velocity, mean speed of sound, mean density, and mean vorticity for each node over the time interval given by tspan and stores the results in an HDF5 file filename in the directory output_directory. Note that this callback does not support adaptive mesh refinement (AMRCallback).

source
Trixi.BoundaryConditionCoupled — Type
BoundaryConditionCoupled(other_semi_index, indices, uEltype, coupling_converter)

Boundary condition to glue two meshes together. Solution values at the boundary of another mesh will be used as boundary values. This requires the use of SemidiscretizationCoupled. The other mesh is specified by other_semi_index, which is the index of the mesh in the tuple of semidiscretizations.

Note that the elements and nodes of the two meshes at the coupled boundary must coincide. This is currently only implemented for StructuredMesh.

Arguments

  • other_semi_index: the index in SemidiscretizationCoupled of the semidiscretization from which the values are copied
  • indices::Tuple: node/cell indices at the boundary of the mesh in the other semidiscretization. See examples below.
  • uEltype::Type: element type of solution
  • coupling_converter::CouplingConverter: function to call for converting the solution state of one system to the other system

Examples

# Connect the left boundary of mesh 2 to our boundary such that our positive
 # boundary direction will match the positive y direction of the other boundary
 BoundaryConditionCoupled(2, (:begin, :i), Float64, fun)
 
@@ -25,7 +25,7 @@
 BoundaryConditionCoupled(2, (:begin, :i_backwards), Float64, fun)
 
 # Using this as y_neg boundary will connect `our_cells[i, 1, j]` to `other_cells[j, end-i, end]`
-BoundaryConditionCoupled(2, (:j, :i_backwards, :end), Float64, fun)
Experimental code

This is an experimental feature and can change any time.

source
Trixi.BoundaryConditionDirichlet — Type
BoundaryConditionDirichlet(boundary_value_function)

Create a Dirichlet boundary condition that uses the function boundary_value_function to specify the values at the boundary. This can be used to create a boundary condition that specifies exact boundary values by passing the exact solution of the equation. The passed boundary value function will be called with the same arguments as an initial condition function is called, i.e., as

boundary_value_function(x, t, equations)

where x specifies the coordinates, t is the current time, and equation is the corresponding system of equations.

Examples

julia> BoundaryConditionDirichlet(initial_condition_convergence_test)
source
Trixi.BoundaryConditionNavierStokesWall — Type
struct BoundaryConditionNavierStokesWall

Creates a wall-type boundary conditions for the compressible Navier-Stokes equations. The fields boundary_condition_velocity and boundary_condition_heat_flux are intended to be boundary condition types such as the NoSlip velocity boundary condition and the Adiabatic or Isothermal heat boundary condition.

source
Trixi.BoundaryConditionNeumann — Type
BoundaryConditionNeumann(boundary_normal_flux_function)

Similar to BoundaryConditionDirichlet, but creates a Neumann boundary condition for parabolic equations that uses the function boundary_normal_flux_function to specify the values of the normal flux at the boundary. The passed boundary value function will be called with the same arguments as an initial condition function is called, i.e., as

boundary_normal_flux_function(x, t, equations)

where x specifies the coordinates, t is the current time, and equation is the corresponding system of equations.

source
Trixi.BoundsCheckCallback — Type
BoundsCheckCallback(; output_directory="out", save_errors=false, interval=1)

Subcell limiting techniques with SubcellLimiterIDP are constructed to adhere certain local or global bounds. To make sure that these bounds are actually met, this callback calculates the maximum deviation from the bounds. The maximum deviation per applied bound is printed to the screen at the end of the simulation. For more insights, when setting save_errors=true the occurring errors are exported every interval time steps during the simulation. Then, the maximum deviations since the last export are saved in "output_directory/deviations.txt". The BoundsCheckCallback has to be applied as a stage callback for the SSPRK time integration scheme.

Note

For SubcellLimiterIDP, the solution is corrected in the a posteriori correction stage SubcellLimiterIDPCorrection. So, to check the final solution, this bounds check callback must be called after the correction stage.

source
Trixi.CarpenterKennedy2N54 — Type
CarpenterKennedy2N54()

The following structures and methods provide a minimal implementation of the low-storage explicit Runge-Kutta method of

Carpenter, Kennedy (1994) Fourth order 2N storage RK schemes, Solution 3

using the same interface as OrdinaryDiffEq.jl.

source
Trixi.CompressibleEulerEquations1D — Type
CompressibleEulerEquations1D(gamma)

The compressible Euler equations

\[\frac{\partial}{\partial t} +BoundaryConditionCoupled(2, (:j, :i_backwards, :end), Float64, fun)

Experimental code

This is an experimental feature and can change any time.

source
Trixi.BoundaryConditionDirichlet — Type
BoundaryConditionDirichlet(boundary_value_function)

Create a Dirichlet boundary condition that uses the function boundary_value_function to specify the values at the boundary. This can be used to create a boundary condition that specifies exact boundary values by passing the exact solution of the equation. The passed boundary value function will be called with the same arguments as an initial condition function is called, i.e., as

boundary_value_function(x, t, equations)

where x specifies the coordinates, t is the current time, and equation is the corresponding system of equations.

Examples

julia> BoundaryConditionDirichlet(initial_condition_convergence_test)
source
Trixi.BoundaryConditionNavierStokesWall — Type
struct BoundaryConditionNavierStokesWall

Creates a wall-type boundary conditions for the compressible Navier-Stokes equations. The fields boundary_condition_velocity and boundary_condition_heat_flux are intended to be boundary condition types such as the NoSlip velocity boundary condition and the Adiabatic or Isothermal heat boundary condition.

source
Trixi.BoundaryConditionNeumann — Type
BoundaryConditionNeumann(boundary_normal_flux_function)

Similar to BoundaryConditionDirichlet, but creates a Neumann boundary condition for parabolic equations that uses the function boundary_normal_flux_function to specify the values of the normal flux at the boundary. The passed boundary value function will be called with the same arguments as an initial condition function is called, i.e., as

boundary_normal_flux_function(x, t, equations)

where x specifies the coordinates, t is the current time, and equation is the corresponding system of equations.

source
Trixi.BoundsCheckCallback — Type
BoundsCheckCallback(; output_directory="out", save_errors=false, interval=1)

Subcell limiting techniques with SubcellLimiterIDP are constructed to adhere certain local or global bounds. To make sure that these bounds are actually met, this callback calculates the maximum deviation from the bounds. The maximum deviation per applied bound is printed to the screen at the end of the simulation. For more insights, when setting save_errors=true the occurring errors are exported every interval time steps during the simulation. Then, the maximum deviations since the last export are saved in "output_directory/deviations.txt". The BoundsCheckCallback has to be applied as a stage callback for the SSPRK time integration scheme.

Note

For SubcellLimiterIDP, the solution is corrected in the a posteriori correction stage SubcellLimiterIDPCorrection. So, to check the final solution, this bounds check callback must be called after the correction stage.

source
Trixi.CarpenterKennedy2N54 — Type
CarpenterKennedy2N54()

The following structures and methods provide a minimal implementation of the low-storage explicit Runge-Kutta method of

Carpenter, Kennedy (1994) Fourth order 2N storage RK schemes, Solution 3

using the same interface as OrdinaryDiffEq.jl.

source
Trixi.CompressibleEulerEquations1D — Type
CompressibleEulerEquations1D(gamma)

The compressible Euler equations

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho v_1 \\ \rho e \end{pmatrix} @@ -37,7 +37,7 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 -\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in one space dimension. Here, $\rho$ is the density, $v_1$ the velocity, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho v_1^2 \right)\]

the pressure.

source
Trixi.CompressibleEulerEquations2D — Type
CompressibleEulerEquations2D(gamma)

The compressible Euler equations

\[\frac{\partial}{\partial t} +\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in one space dimension. Here, $\rho$ is the density, $v_1$ the velocity, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho v_1^2 \right)\]

the pressure.

source
Trixi.CompressibleEulerEquations2D — Type
CompressibleEulerEquations2D(gamma)

The compressible Euler equations

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho v_1 \\ \rho v_2 \\ \rho e \end{pmatrix} @@ -54,7 +54,7 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 \\ 0 -\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in two space dimensions. Here, $\rho$ is the density, $v_1$, $v_2$ the velocities, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2) \right)\]

the pressure.

source
Trixi.CompressibleEulerEquations3D — Type
CompressibleEulerEquations3D(gamma)

The compressible Euler equations

\[\frac{\partial}{\partial t} +\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in two space dimensions. Here, $\rho$ is the density, $v_1$, $v_2$ the velocities, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2) \right)\]

the pressure.

source
Trixi.CompressibleEulerEquations3D — Type
CompressibleEulerEquations3D(gamma)

The compressible Euler equations

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho v_1 \\ \rho v_2 \\ \rho v_3 \\ \rho e \end{pmatrix} @@ -76,7 +76,7 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 \\ 0 \\ 0 -\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in three space dimensions. Here, $\rho$ is the density, $v_1$, $v_2$, $v_3$ the velocities, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2+v_3^2) \right)\]

the pressure.

source
Trixi.CompressibleEulerEquationsQuasi1D — Type
CompressibleEulerEquationsQuasi1D(gamma)

The quasi-1d compressible Euler equations (see Chan et al. DOI: 10.48550/arXiv.2307.12089 for details)

\[\frac{\partial}{\partial t} +\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in three space dimensions. Here, $\rho$ is the density, $v_1$, $v_2$, $v_3$ the velocities, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2+v_3^2) \right)\]

the pressure.

source
Trixi.CompressibleEulerEquationsQuasi1D — Type
CompressibleEulerEquationsQuasi1D(gamma)

The quasi-1d compressible Euler equations (see Chan et al. DOI: 10.48550/arXiv.2307.12089 for details)

\[\frac{\partial}{\partial t} \begin{pmatrix} a \rho \\ a \rho v_1 \\ a e \end{pmatrix} @@ -93,7 +93,7 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 -\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in one space dimension. Here, $\rho$ is the density, $v_1$ the velocity, $e$ the specific total energy rather than specific internal energy, $a$ the (possibly) variable nozzle width, and

\[p = (\gamma - 1) \left( e - \frac{1}{2} \rho v_1^2 \right)\]

the pressure.

The nozzle width function $a(x)$ is set inside the initial condition routine for a particular problem setup. To test the conservative form of the compressible Euler equations one can set the nozzle width variable $a$ to one.

In addition to the unknowns, Trixi.jl currently stores the nozzle width values at the approximation points despite being fixed in time. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the nozzle width must be zero.
  • The nozzle width values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the nozzle width by default.
source
Trixi.CompressibleEulerMulticomponentEquations1D — Type
CompressibleEulerMulticomponentEquations1D(; gammas, gas_constants)

Multicomponent version of the compressible Euler equations

\[\frac{\partial}{\partial t} +\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in one space dimension. Here, $\rho$ is the density, $v_1$ the velocity, $e$ the specific total energy rather than specific internal energy, $a$ the (possibly) variable nozzle width, and

\[p = (\gamma - 1) \left( e - \frac{1}{2} \rho v_1^2 \right)\]

the pressure.

The nozzle width function $a(x)$ is set inside the initial condition routine for a particular problem setup. To test the conservative form of the compressible Euler equations one can set the nozzle width variable $a$ to one.

In addition to the unknowns, Trixi.jl currently stores the nozzle width values at the approximation points despite being fixed in time. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the nozzle width must be zero.
  • The nozzle width values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the nozzle width by default.
source
Trixi.CompressibleEulerMulticomponentEquations1D — Type
CompressibleEulerMulticomponentEquations1D(; gammas, gas_constants)

Multicomponent version of the compressible Euler equations

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho v_1 \\ \rho e \\ \rho_1 \\ \rho_2 \\ \vdots \\ \rho_{n} \end{pmatrix} @@ -106,7 +106,7 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 \\ 0 \\ \vdots \\ 0 -\end{pmatrix}\]

for calorically perfect gas in one space dimension. Here, $\rho_i$ is the density of component $i$, $\rho=\sum_{i=1}^n\rho_i$ the sum of the individual $\rho_i$, $v_1$ the velocity, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho v_1^2 \right)\]

the pressure,

\[\gamma=\frac{\sum_{i=1}^n\rho_i C_{v,i}\gamma_i}{\sum_{i=1}^n\rho_i C_{v,i}}\]

total heat capacity ratio, $\gamma_i$ heat capacity ratio of component $i$,

\[C_{v,i}=\frac{R}{\gamma_i-1}\]

specific heat capacity at constant volume of component $i$.

In case of more than one component, the specific heat ratios gammas and the gas constants gas_constants should be passed as tuples, e.g., gammas=(1.4, 1.667).

The remaining variables like the specific heats at constant volume cv or the specific heats at constant pressure cp are then calculated considering a calorically perfect gas.

source
Trixi.CompressibleEulerMulticomponentEquations2D — Type
CompressibleEulerMulticomponentEquations2D(; gammas, gas_constants)

Multicomponent version of the compressible Euler equations

\[\frac{\partial}{\partial t} +\end{pmatrix}\]

for calorically perfect gas in one space dimension. Here, $\rho_i$ is the density of component $i$, $\rho=\sum_{i=1}^n\rho_i$ the sum of the individual $\rho_i$, $v_1$ the velocity, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho v_1^2 \right)\]

the pressure,

\[\gamma=\frac{\sum_{i=1}^n\rho_i C_{v,i}\gamma_i}{\sum_{i=1}^n\rho_i C_{v,i}}\]

total heat capacity ratio, $\gamma_i$ heat capacity ratio of component $i$,

\[C_{v,i}=\frac{R}{\gamma_i-1}\]

specific heat capacity at constant volume of component $i$.

In case of more than one component, the specific heat ratios gammas and the gas constants gas_constants should be passed as tuples, e.g., gammas=(1.4, 1.667).

The remaining variables like the specific heats at constant volume cv or the specific heats at constant pressure cp are then calculated considering a calorically perfect gas.

source
Trixi.CompressibleEulerMulticomponentEquations2D — Type
CompressibleEulerMulticomponentEquations2D(; gammas, gas_constants)

Multicomponent version of the compressible Euler equations

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho v_1 \\ \rho v_2 \\ \rho e \\ \rho_1 \\ \rho_2 \\ \vdots \\ \rho_{n} \end{pmatrix} @@ -123,7 +123,7 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 \\ 0 \\ 0 \\ \vdots \\ 0 -\end{pmatrix}\]

for calorically perfect gas in two space dimensions. Here, $\rho_i$ is the density of component $i$, $\rho=\sum_{i=1}^n\rho_i$ the sum of the individual $\rho_i$, $v_1$, $v_2$ the velocities, $e$ the specific total energy rather than specific internal energy, and

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2 + v_2^2) \right)\]

the pressure,

\[\gamma=\frac{\sum_{i=1}^n\rho_i C_{v,i}\gamma_i}{\sum_{i=1}^n\rho_i C_{v,i}}\]

total heat capacity ratio, $\gamma_i$ heat capacity ratio of component $i$,

\[C_{v,i}=\frac{R}{\gamma_i-1}\]

specific heat capacity at constant volume of component $i$.

In case of more than one component, the specific heat ratios gammas and the gas constants gas_constants in [kJ/(kg*K)] should be passed as tuples, e.g., gammas=(1.4, 1.667).

The remaining variables like the specific heats at constant volume cv or the specific heats at constant pressure cp are then calculated considering a calorically perfect gas.

source
Trixi.CompressibleNavierStokesDiffusion1D — Type
CompressibleNavierStokesDiffusion1D(equations; mu, Pr,
+\end{pmatrix}\]
for calorically perfect gas in two space dimensions. Here, $\rho_i$ is the density of component $i$, $\rho=\sum_{i=1}^n\rho_i$ the sum of the individual $\rho_i$, $v_1$, $v_2$ the velocities, $e$ the specific total energy rather than specific internal energy, and
\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2 + v_2^2) \right)\]
the pressure,
\[\gamma=\frac{\sum_{i=1}^n\rho_i C_{v,i}\gamma_i}{\sum_{i=1}^n\rho_i C_{v,i}}\]
total heat capacity ratio, $\gamma_i$ heat capacity ratio of component $i$,
\[C_{v,i}=\frac{R}{\gamma_i-1}\]
specific heat capacity at constant volume of component $i$.
In case of more than one component, the specific heat ratios gammas and the gas constants gas_constants in [kJ/(kg*K)] should be passed as tuples, e.g., gammas=(1.4, 1.667).
The remaining variables like the specific heats at constant volume cv or the specific heats at constant pressure cp are then calculated considering a calorically perfect gas.
source
Trixi.CompressibleNavierStokesDiffusion1D — Type
CompressibleNavierStokesDiffusion1D(equations; mu, Pr,
                                     gradient_variables=GradientVariablesPrimitive())

Contains the diffusion (i.e. parabolic) terms applied to mass, momenta, and total energy together with the advective terms from the CompressibleEulerEquations1D.

  • equations: instance of the CompressibleEulerEquations1D
  • mu: dynamic viscosity,
  • Pr: Prandtl number,
  • gradient_variables: which variables the gradients are taken with respect to. Defaults to GradientVariablesPrimitive().

Fluid properties such as the dynamic viscosity $\mu$ can be provided in any consistent unit system, e.g., [$\mu$] = kg m⁻¹ s⁻¹.

The particular form of the compressible Navier-Stokes implemented is

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho v \\ \rho e @@ -137,7 +137,7 @@ \frac{\partial}{\partial x} \begin{pmatrix} 0 \\ \tau \\ \tau v - q -\end{pmatrix}\]

where the system is closed with the ideal gas assumption giving

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho v^2 \right)\]

as the pressure. The value of the adiabatic constant gamma is taken from the CompressibleEulerEquations1D. The terms on the right hand side of the system above are built from the viscous stress

\[\tau = \mu \frac{\partial}{\partial x} v\]

where the heat flux is

\[q = -\kappa \frac{\partial}{\partial x} \left(T\right),\quad T = \frac{p}{R\rho}\]

where $T$ is the temperature and $\kappa$ is the thermal conductivity for Fick's law. Under the assumption that the gas has a constant Prandtl number, the thermal conductivity is

\[\kappa = \frac{\gamma \mu R}{(\gamma - 1)\textrm{Pr}}.\]

From this combination of temperature $T$ and thermal conductivity $\kappa$ we see that the gas constant R cancels and the heat flux becomes

\[q = -\kappa \frac{\partial}{\partial x} \left(T\right) = -\frac{\gamma \mu}{(\gamma - 1)\textrm{Pr}} \frac{\partial}{\partial x} \left(\frac{p}{\rho}\right)\]

which is the form implemented below in the flux function.

In one spatial dimensions we require gradients for two quantities, e.g., primitive quantities

\[\frac{\partial}{\partial x} v,\, \frac{\partial}{\partial x} T\]

or the entropy variables

\[\frac{\partial}{\partial x} w_2,\, \frac{\partial}{\partial x} w_3\]

where

\[w_2 = \frac{\rho v1}{p},\, w_3 = -\frac{\rho}{p}\]

source
Trixi.CompressibleNavierStokesDiffusion2D — Type
CompressibleNavierStokesDiffusion2D(equations; mu, Pr,
+\end{pmatrix}\]
where the system is closed with the ideal gas assumption giving
\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho v^2 \right)\]
as the pressure. The value of the adiabatic constant gamma is taken from the CompressibleEulerEquations1D. The terms on the right hand side of the system above are built from the viscous stress
\[\tau = \mu \frac{\partial}{\partial x} v\]
where the heat flux is
\[q = -\kappa \frac{\partial}{\partial x} \left(T\right),\quad T = \frac{p}{R\rho}\]
where $T$ is the temperature and $\kappa$ is the thermal conductivity for Fick's law. Under the assumption that the gas has a constant Prandtl number, the thermal conductivity is
\[\kappa = \frac{\gamma \mu R}{(\gamma - 1)\textrm{Pr}}.\]
From this combination of temperature $T$ and thermal conductivity $\kappa$ we see that the gas constant R cancels and the heat flux becomes
\[q = -\kappa \frac{\partial}{\partial x} \left(T\right) = -\frac{\gamma \mu}{(\gamma - 1)\textrm{Pr}} \frac{\partial}{\partial x} \left(\frac{p}{\rho}\right)\]
which is the form implemented below in the flux function.
In one spatial dimensions we require gradients for two quantities, e.g., primitive quantities
\[\frac{\partial}{\partial x} v,\, \frac{\partial}{\partial x} T\]
or the entropy variables
\[\frac{\partial}{\partial x} w_2,\, \frac{\partial}{\partial x} w_3\]
where
\[w_2 = \frac{\rho v1}{p},\, w_3 = -\frac{\rho}{p}\]
source
Trixi.CompressibleNavierStokesDiffusion2D — Type
CompressibleNavierStokesDiffusion2D(equations; mu, Pr,
                                     gradient_variables=GradientVariablesPrimitive())

Contains the diffusion (i.e. parabolic) terms applied to mass, momenta, and total energy together with the advective terms from the CompressibleEulerEquations2D.

  • equations: instance of the CompressibleEulerEquations2D
  • mu: dynamic viscosity,
  • Pr: Prandtl number,
  • gradient_variables: which variables the gradients are taken with respect to. Defaults to GradientVariablesPrimitive().

Fluid properties such as the dynamic viscosity $\mu$ can be provided in any consistent unit system, e.g., [$\mu$] = kg m⁻¹ s⁻¹.

The particular form of the compressible Navier-Stokes implemented is

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho \mathbf{v} \\ \rho e @@ -151,7 +151,7 @@ \nabla \cdot \begin{pmatrix} 0 \\ \underline{\tau} \\ \underline{\tau}\mathbf{v} - \mathbf{q} -\end{pmatrix}\]

where the system is closed with the ideal gas assumption giving

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2) \right)\]

as the pressure. The value of the adiabatic constant gamma is taken from the CompressibleEulerEquations2D. The terms on the right hand side of the system above are built from the viscous stress tensor

\[\underline{\tau} = \mu \left(\nabla\mathbf{v} + \left(\nabla\mathbf{v}\right)^T\right) - \frac{2}{3} \mu \left(\nabla\cdot\mathbf{v}\right)\underline{I}\]

where $\underline{I}$ is the $2\times 2$ identity matrix and the heat flux is

\[\mathbf{q} = -\kappa\nabla\left(T\right),\quad T = \frac{p}{R\rho}\]

where $T$ is the temperature and $\kappa$ is the thermal conductivity for Fick's law. Under the assumption that the gas has a constant Prandtl number, the thermal conductivity is

\[\kappa = \frac{\gamma \mu R}{(\gamma - 1)\textrm{Pr}}.\]

From this combination of temperature $T$ and thermal conductivity $\kappa$ we see that the gas constant R cancels and the heat flux becomes

\[\mathbf{q} = -\kappa\nabla\left(T\right) = -\frac{\gamma \mu}{(\gamma - 1)\textrm{Pr}}\nabla\left(\frac{p}{\rho}\right)\]

which is the form implemented below in the flux function.

In two spatial dimensions we require gradients for three quantities, e.g., primitive quantities

\[\nabla v_1,\, \nabla v_2,\, \nabla T\]

or the entropy variables

\[\nabla w_2,\, \nabla w_3,\, \nabla w_4\]

where

\[w_2 = \frac{\rho v_1}{p},\, w_3 = \frac{\rho v_2}{p},\, w_4 = -\frac{\rho}{p}\]

source
Trixi.CompressibleNavierStokesDiffusion3D — Type
CompressibleNavierStokesDiffusion3D(equations; mu, Pr,
+\end{pmatrix}\]
where the system is closed with the ideal gas assumption giving
\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2) \right)\]
as the pressure. The value of the adiabatic constant gamma is taken from the CompressibleEulerEquations2D. The terms on the right hand side of the system above are built from the viscous stress tensor
\[\underline{\tau} = \mu \left(\nabla\mathbf{v} + \left(\nabla\mathbf{v}\right)^T\right) - \frac{2}{3} \mu \left(\nabla\cdot\mathbf{v}\right)\underline{I}\]
where $\underline{I}$ is the $2\times 2$ identity matrix and the heat flux is
\[\mathbf{q} = -\kappa\nabla\left(T\right),\quad T = \frac{p}{R\rho}\]
where $T$ is the temperature and $\kappa$ is the thermal conductivity for Fick's law. Under the assumption that the gas has a constant Prandtl number, the thermal conductivity is
\[\kappa = \frac{\gamma \mu R}{(\gamma - 1)\textrm{Pr}}.\]
From this combination of temperature $T$ and thermal conductivity $\kappa$ we see that the gas constant R cancels and the heat flux becomes
\[\mathbf{q} = -\kappa\nabla\left(T\right) = -\frac{\gamma \mu}{(\gamma - 1)\textrm{Pr}}\nabla\left(\frac{p}{\rho}\right)\]
which is the form implemented below in the flux function.
In two spatial dimensions we require gradients for three quantities, e.g., primitive quantities
\[\nabla v_1,\, \nabla v_2,\, \nabla T\]
or the entropy variables
\[\nabla w_2,\, \nabla w_3,\, \nabla w_4\]
where
\[w_2 = \frac{\rho v_1}{p},\, w_3 = \frac{\rho v_2}{p},\, w_4 = -\frac{\rho}{p}\]
source
Trixi.CompressibleNavierStokesDiffusion3D — Type
CompressibleNavierStokesDiffusion3D(equations; mu, Pr,
                                     gradient_variables=GradientVariablesPrimitive())

Contains the diffusion (i.e. parabolic) terms applied to mass, momenta, and total energy together with the advective terms from the CompressibleEulerEquations3D.

  • equations: instance of the CompressibleEulerEquations3D
  • mu: dynamic viscosity,
  • Pr: Prandtl number,
  • gradient_variables: which variables the gradients are taken with respect to. Defaults to GradientVariablesPrimitive().

Fluid properties such as the dynamic viscosity $\mu$ can be provided in any consistent unit system, e.g., [$\mu$] = kg m⁻¹ s⁻¹.

The particular form of the compressible Navier-Stokes implemented is

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho \mathbf{v} \\ \rho e @@ -165,41 +165,41 @@ \nabla \cdot \begin{pmatrix} 0 \\ \underline{\tau} \\ \underline{\tau}\mathbf{v} - \mathbf{q} -\end{pmatrix}\]

where the system is closed with the ideal gas assumption giving

\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2+v_3^2) \right)\]

as the pressure. The value of the adiabatic constant gamma is taken from the CompressibleEulerEquations2D. The terms on the right hand side of the system above are built from the viscous stress tensor

\[\underline{\tau} = \mu \left(\nabla\mathbf{v} + \left(\nabla\mathbf{v}\right)^T\right) - \frac{2}{3} \mu \left(\nabla\cdot\mathbf{v}\right)\underline{I}\]

where $\underline{I}$ is the $3\times 3$ identity matrix and the heat flux is

\[\mathbf{q} = -\kappa\nabla\left(T\right),\quad T = \frac{p}{R\rho}\]

where $T$ is the temperature and $\kappa$ is the thermal conductivity for Fick's law. Under the assumption that the gas has a constant Prandtl number, the thermal conductivity is

\[\kappa = \frac{\gamma \mu R}{(\gamma - 1)\textrm{Pr}}.\]

From this combination of temperature $T$ and thermal conductivity $\kappa$ we see that the gas constant R cancels and the heat flux becomes

\[\mathbf{q} = -\kappa\nabla\left(T\right) = -\frac{\gamma \mu}{(\gamma - 1)\textrm{Pr}}\nabla\left(\frac{p}{\rho}\right)\]

which is the form implemented below in the flux function.

In two spatial dimensions we require gradients for three quantities, e.g., primitive quantities

\[\nabla v_1,\, \nabla v_2,\, \nabla v_3,\, \nabla T\]

or the entropy variables

\[\nabla w_2,\, \nabla w_3,\, \nabla w_4\, \nabla w_5\]

where

\[w_2 = \frac{\rho v_1}{p},\, w_3 = \frac{\rho v_2}{p},\, w_4 = \frac{\rho v_3}{p},\, w_5 = -\frac{\rho}{p}\]

source
Trixi.ControllerThreeLevel — Type
ControllerThreeLevel(semi, indicator; base_level=1,
+\end{pmatrix}\]
where the system is closed with the ideal gas assumption giving
\[p = (\gamma - 1) \left( \rho e - \frac{1}{2} \rho (v_1^2+v_2^2+v_3^2) \right)\]
as the pressure. The value of the adiabatic constant gamma is taken from the CompressibleEulerEquations2D. The terms on the right hand side of the system above are built from the viscous stress tensor
\[\underline{\tau} = \mu \left(\nabla\mathbf{v} + \left(\nabla\mathbf{v}\right)^T\right) - \frac{2}{3} \mu \left(\nabla\cdot\mathbf{v}\right)\underline{I}\]
where $\underline{I}$ is the $3\times 3$ identity matrix and the heat flux is
\[\mathbf{q} = -\kappa\nabla\left(T\right),\quad T = \frac{p}{R\rho}\]
where $T$ is the temperature and $\kappa$ is the thermal conductivity for Fick's law. Under the assumption that the gas has a constant Prandtl number, the thermal conductivity is
\[\kappa = \frac{\gamma \mu R}{(\gamma - 1)\textrm{Pr}}.\]
From this combination of temperature $T$ and thermal conductivity $\kappa$ we see that the gas constant R cancels and the heat flux becomes
\[\mathbf{q} = -\kappa\nabla\left(T\right) = -\frac{\gamma \mu}{(\gamma - 1)\textrm{Pr}}\nabla\left(\frac{p}{\rho}\right)\]
which is the form implemented below in the flux function.
In two spatial dimensions we require gradients for three quantities, e.g., primitive quantities
\[\nabla v_1,\, \nabla v_2,\, \nabla v_3,\, \nabla T\]
or the entropy variables
\[\nabla w_2,\, \nabla w_3,\, \nabla w_4\, \nabla w_5\]
where
\[w_2 = \frac{\rho v_1}{p},\, w_3 = \frac{\rho v_2}{p},\, w_4 = \frac{\rho v_3}{p},\, w_5 = -\frac{\rho}{p}\]
source
Trixi.ControllerThreeLevel — Type
ControllerThreeLevel(semi, indicator; base_level=1,
                                       med_level=base_level, med_threshold=0.0,
-                                      max_level=base_level, max_threshold=1.0)

An AMR controller based on three levels (in descending order of precedence):

  • set the target level to max_level if indicator > max_threshold
  • set the target level to med_level if indicator > med_threshold; if med_level < 0, set the target level to the current level
  • set the target level to base_level otherwise
source
Trixi.ControllerThreeLevelCombined — Type
ControllerThreeLevelCombined(semi, indicator_primary, indicator_secondary;
+                                      max_level=base_level, max_threshold=1.0)

An AMR controller based on three levels (in descending order of precedence):

  • set the target level to max_level if indicator > max_threshold
  • set the target level to med_level if indicator > med_threshold; if med_level < 0, set the target level to the current level
  • set the target level to base_level otherwise
source
Trixi.ControllerThreeLevelCombined — Type
ControllerThreeLevelCombined(semi, indicator_primary, indicator_secondary;
                              base_level=1,
                              med_level=base_level, med_threshold=0.0,
                              max_level=base_level, max_threshold=1.0,
-                             max_threshold_secondary=1.0)

An AMR controller based on three levels (in descending order of precedence):

  • set the target level to max_level if indicator_primary > max_threshold
  • set the target level to med_level if indicator_primary > med_threshold; if med_level < 0, set the target level to the current level
  • set the target level to base_level otherwise

If indicator_secondary >= max_threshold_secondary, set the target level to max_level.

source
Trixi.DGMulti — Method
DGMulti(approximation_type::AbstractDerivativeOperator;
+                             max_threshold_secondary=1.0)

An AMR controller based on three levels (in descending order of precedence):

  • set the target level to max_level if indicator_primary > max_threshold
  • set the target level to med_level if indicator_primary > med_threshold; if med_level < 0, set the target level to the current level
  • set the target level to base_level otherwise

If indicator_secondary >= max_threshold_secondary, set the target level to max_level.

source
Trixi.DGMulti — Method
DGMulti(approximation_type::AbstractDerivativeOperator;
         element_type::AbstractElemShape,
         surface_flux=flux_central,
         surface_integral=SurfaceIntegralWeakForm(surface_flux),
         volume_integral=VolumeIntegralWeakForm(),
-        kwargs...)

Create a summation by parts (SBP) discretization on the given element_type using a tensor product structure based on the 1D SBP derivative operator passed as approximation_type.

For more info, see the documentations of StartUpDG.jl and SummationByPartsOperators.jl.

source
Trixi.DGMulti — Method
DGMulti(; polydeg::Integer,
+        kwargs...)

Create a summation by parts (SBP) discretization on the given element_type using a tensor product structure based on the 1D SBP derivative operator passed as approximation_type.

For more info, see the documentations of StartUpDG.jl and SummationByPartsOperators.jl.

source
Trixi.DGMulti — Method
DGMulti(; polydeg::Integer,
           element_type::AbstractElemShape,
           approximation_type=Polynomial(),
           surface_flux=flux_central,
           surface_integral=SurfaceIntegralWeakForm(surface_flux),
           volume_integral=VolumeIntegralWeakForm(),
-          RefElemData_kwargs...)

Create a discontinuous Galerkin method which uses

  • approximations of polynomial degree polydeg
  • element type element_type (Tri(), Quad(), Tet(), and Hex() currently supported)

Optional:

  • approximation_type (default is Polynomial(); SBP() also supported for Tri(), Quad(), and Hex() element types).
  • RefElemData_kwargs are additional keyword arguments for RefElemData, such as quad_rule_vol. For more info, see the StartUpDG.jl docs.
source
Trixi.DGMultiMesh — Type
DGMultiMesh{NDIMS, ...}

DGMultiMesh describes a mesh type which wraps StartUpDG.MeshData and boundary_faces in a dispatchable type. This is intended to store geometric data and connectivities for any type of mesh (Cartesian, affine, curved, structured/unstructured).

source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti{2, Tri}, triangulateIO, boundary_dict::Dict{Symbol, Int})
  • dg::DGMulti contains information associated with to the reference element (e.g., quadrature, basis evaluation, differentiation, etc).
  • triangulateIO is a TriangulateIO mesh representation
  • boundary_dict is a Dict{Symbol, Int} which associates each integer TriangulateIO boundary tag with a Symbol.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti)

Constructs a single-element DGMultiMesh for a single periodic element given a DGMulti with approximation_type set to a periodic (finite difference) SBP operator from SummationByPartsOperators.jl.

source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti{NDIMS}, vertex_coordinates, EToV;
+          RefElemData_kwargs...)

Create a discontinuous Galerkin method which uses

  • approximations of polynomial degree polydeg
  • element type element_type (Tri(), Quad(), Tet(), and Hex() currently supported)

Optional:

  • approximation_type (default is Polynomial(); SBP() also supported for Tri(), Quad(), and Hex() element types).
  • RefElemData_kwargs are additional keyword arguments for RefElemData, such as quad_rule_vol. For more info, see the StartUpDG.jl docs.
source
Trixi.DGMultiMesh — Type
DGMultiMesh{NDIMS, ...}

DGMultiMesh describes a mesh type which wraps StartUpDG.MeshData and boundary_faces in a dispatchable type. This is intended to store geometric data and connectivities for any type of mesh (Cartesian, affine, curved, structured/unstructured).

source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti{2, Tri}, triangulateIO, boundary_dict::Dict{Symbol, Int})
  • dg::DGMulti contains information associated with to the reference element (e.g., quadrature, basis evaluation, differentiation, etc).
  • triangulateIO is a TriangulateIO mesh representation
  • boundary_dict is a Dict{Symbol, Int} which associates each integer TriangulateIO boundary tag with a Symbol.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti)

Constructs a single-element DGMultiMesh for a single periodic element given a DGMulti with approximation_type set to a periodic (finite difference) SBP operator from SummationByPartsOperators.jl.

source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti{NDIMS}, vertex_coordinates, EToV;
             is_on_boundary=nothing,
-            periodicity=ntuple(_->false, NDIMS)) where {NDIMS}
  • dg::DGMulti contains information associated with to the reference element (e.g., quadrature, basis evaluation, differentiation, etc).
  • vertex_coordinates is a tuple of vectors containing x,y,... components of the vertex coordinates
  • EToV is a 2D array containing element-to-vertex connectivities for each element
  • is_on_boundary specifies boundary using a Dict{Symbol, <:Function}
  • periodicity is a tuple of booleans specifying if the domain is periodic true/false in the (x,y,z) direction.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti{NDIMS}, cells_per_dimension, mapping;
+            periodicity=ntuple(_->false, NDIMS)) where {NDIMS}
  • dg::DGMulti contains information associated with to the reference element (e.g., quadrature, basis evaluation, differentiation, etc).
  • vertex_coordinates is a tuple of vectors containing x,y,... components of the vertex coordinates
  • EToV is a 2D array containing element-to-vertex connectivities for each element
  • is_on_boundary specifies boundary using a Dict{Symbol, <:Function}
  • periodicity is a tuple of booleans specifying if the domain is periodic true/false in the (x,y,z) direction.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti{NDIMS}, cells_per_dimension, mapping;
             is_on_boundary=nothing,
-            periodicity=ntuple(_ -> false, NDIMS), kwargs...) where {NDIMS}

Constructs a Curved() DGMultiMesh with element type dg.basis.element_type.

  • mapping is a function which maps from a reference [-1, 1]^NDIMS domain to a mapped domain, e.g., xy = mapping(x, y) in 2D.
  • is_on_boundary specifies boundary using a Dict{Symbol, <:Function}
  • periodicity is a tuple of Bools specifying periodicity = true/false in the (x,y,z) direction.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti, cells_per_dimension;
+            periodicity=ntuple(_ -> false, NDIMS), kwargs...) where {NDIMS}

Constructs a Curved() DGMultiMesh with element type dg.basis.element_type.

  • mapping is a function which maps from a reference [-1, 1]^NDIMS domain to a mapped domain, e.g., xy = mapping(x, y) in 2D.
  • is_on_boundary specifies boundary using a Dict{Symbol, <:Function}
  • periodicity is a tuple of Bools specifying periodicity = true/false in the (x,y,z) direction.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti, cells_per_dimension;
             coordinates_min=(-1.0, -1.0), coordinates_max=(1.0, 1.0),
             is_on_boundary=nothing,
-            periodicity=ntuple(_ -> false, NDIMS))

Constructs a Cartesian DGMultiMesh with element type dg.basis.element_type. The domain is the tensor product of the intervals [coordinates_min[i], coordinates_max[i]].

  • is_on_boundary specifies boundary using a Dict{Symbol, <:Function}
  • periodicity is a tuple of Bools specifying periodicity = true/false in the (x,y,z) direction.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti, filename::String)
  • dg::DGMulti contains information associated with the reference element (e.g., quadrature, basis evaluation, differentiation, etc).
  • filename is a path specifying a .mesh file generated by HOHQMesh.
source
Trixi.DGSEM — Type
DGSEM(; RealT=Float64, polydeg::Integer,
+            periodicity=ntuple(_ -> false, NDIMS))

Constructs a Cartesian DGMultiMesh with element type dg.basis.element_type. The domain is the tensor product of the intervals [coordinates_min[i], coordinates_max[i]].

  • is_on_boundary specifies boundary using a Dict{Symbol, <:Function}
  • periodicity is a tuple of Bools specifying periodicity = true/false in the (x,y,z) direction.
source
Trixi.DGMultiMesh — Method
DGMultiMesh(dg::DGMulti, filename::String)
  • dg::DGMulti contains information associated with the reference element (e.g., quadrature, basis evaluation, differentiation, etc).
  • filename is a path specifying a .mesh file generated by HOHQMesh.
source
Trixi.DGSEM — Type
DGSEM(; RealT=Float64, polydeg::Integer,
         surface_flux=flux_central,
         surface_integral=SurfaceIntegralWeakForm(surface_flux),
         volume_integral=VolumeIntegralWeakForm(),
-        mortar=MortarL2(basis))

Create a discontinuous Galerkin spectral element method (DGSEM) using a LobattoLegendreBasis with polynomials of degree polydeg.

source
Trixi.DissipationLocalLaxFriedrichs — Type
DissipationLocalLaxFriedrichs(max_abs_speed=max_abs_speed_naive)

Create a local Lax-Friedrichs dissipation operator where the maximum absolute wave speed is estimated as max_abs_speed(u_ll, u_rr, orientation_or_normal_direction, equations), defaulting to max_abs_speed_naive.

source
Trixi.EulerAcousticsCouplingCallback — Type
EulerAcousticsCouplingCallback
Experimental code

This callback is experimental and may change in any future release.

A callback that couples the acoustic perturbation equations and compressible Euler equations. Must be used in conjunction with SemidiscretizationEulerAcoustics. This callback manages the flow solver - which is always one time step ahead of the acoustics solver - and calculates the acoustic source term after each time step. The linearized Lamb vector is used as the source term, i.e.

\[\mathbf{s} = -(\mathbf{\omega'} \times \bar{\mathbf{v}} - + \bar{\mathbf{\omega}} \times \mathbf{v'}),\]

where $\mathbf{v}$ denotes the velocity, $\mathbf{\omega}$ denotes the vorticity, the bar $\bar{(\cdot)}$ indicates time-averaged quantities (see AveragingCallback) and prime $(\cdot)'$ denotes perturbed quantities defined by $\phi' = \phi - \bar{\phi}$. Note that the perturbed quantities here are based entirely on the pure flow solution and should not be confused with the state variables of the acoustic perturbation equations.

In addition, this callback manages the time step size for both solvers and initializes the mean values of the acoustic perturbation equations using results obtained with the AveragingCallback.

source
Trixi.EulerAcousticsCouplingCallback — Method
EulerAcousticsCouplingCallback(ode_euler, averaging_file::AbstractString, alg,
-                               cfl_acoustics::Real, cfl_euler::Real; kwargs...)
Experimental code

This callback is experimental and may change in any future release.

Creates an EulerAcousticsCouplingCallback based on the pure flow ODEProblem given by ode_euler. Creates an integrator using the time integration method alg and the keyword arguments to solve ode_euler (consult the OrdinaryDiffEq documentation for further information). Manages the step size for both solvers by using the minimum of the maximum step size obtained with CFL numbers cfl_acoustics for the acoustics solver and cfl_euler for and flow solver, respectively. The mean values for the acoustic perturbation equations are read from averaging_file (see AveragingCallback).

source
Trixi.DissipationLocalLaxFriedrichs — Type
DissipationLocalLaxFriedrichs(max_abs_speed=max_abs_speed_naive)

Create a local Lax-Friedrichs dissipation operator where the maximum absolute wave speed is estimated as max_abs_speed(u_ll, u_rr, orientation_or_normal_direction, equations), defaulting to max_abs_speed_naive.

source
Trixi.EulerAcousticsCouplingCallback — Type
EulerAcousticsCouplingCallback
Experimental code

This callback is experimental and may change in any future release.

A callback that couples the acoustic perturbation equations and compressible Euler equations. Must be used in conjunction with SemidiscretizationEulerAcoustics. This callback manages the flow solver - which is always one time step ahead of the acoustics solver - and calculates the acoustic source term after each time step. The linearized Lamb vector is used as the source term, i.e.

\[\mathbf{s} = -(\mathbf{\omega'} \times \bar{\mathbf{v}} + + \bar{\mathbf{\omega}} \times \mathbf{v'}),\]

where $\mathbf{v}$ denotes the velocity, $\mathbf{\omega}$ denotes the vorticity, the bar $\bar{(\cdot)}$ indicates time-averaged quantities (see AveragingCallback) and prime $(\cdot)'$ denotes perturbed quantities defined by $\phi' = \phi - \bar{\phi}$. Note that the perturbed quantities here are based entirely on the pure flow solution and should not be confused with the state variables of the acoustic perturbation equations.

In addition, this callback manages the time step size for both solvers and initializes the mean values of the acoustic perturbation equations using results obtained with the AveragingCallback.

source
Trixi.EulerAcousticsCouplingCallback — Method
EulerAcousticsCouplingCallback(ode_euler, averaging_file::AbstractString, alg,
+                               cfl_acoustics::Real, cfl_euler::Real; kwargs...)
Experimental code

This callback is experimental and may change in any future release.

Creates an EulerAcousticsCouplingCallback based on the pure flow ODEProblem given by ode_euler. Creates an integrator using the time integration method alg and the keyword arguments to solve ode_euler (consult the OrdinaryDiffEq documentation for further information). Manages the step size for both solvers by using the minimum of the maximum step size obtained with CFL numbers cfl_acoustics for the acoustics solver and cfl_euler for and flow solver, respectively. The mean values for the acoustic perturbation equations are read from averaging_file (see AveragingCallback).

source
Trixi.EulerAcousticsCouplingCallback — Method
EulerAcousticsCouplingCallback(ode_euler,
                                averaging_callback::DiscreteCallback{<:Any, <:AveragingCallback},
-                               alg, cfl_acoustics::Real, cfl_euler::Real; kwargs...)
Experimental code

This callback is experimental and may change in any future release.

Creates an EulerAcousticsCouplingCallback based on the pure flow ODEProblem given by ode_euler. Creates an integrator using the time integration method alg and the keyword arguments to solve ode_euler (consult the OrdinaryDiffEq documentation for further information). Manages the step size for both solvers by using the minimum of the maximum step size obtained with CFL numbers cfl_acoustics for the acoustics solver and cfl_euler for and flow solver, respectively. The mean values for the acoustic perturbation equations are read from averaging_callback (see AveragingCallback).

source
Trixi.FDSBP — Type
FDSBP(D_SBP; surface_integral, volume_integral)

Specialization of DG methods that uses general summation by parts (SBP) operators from SummationByPartsOperators.jl. In particular, this includes classical finite difference (FD) SBP methods. These methods have the same structure as classical DG methods - local operations on elements with connectivity through interfaces without imposing any continuity constraints.

D_SBP is an SBP derivative operator from SummationByPartsOperators.jl. The other arguments have the same meaning as in DG or DGSEM.

Experimental implementation (upwind SBP)

This is an experimental feature and may change in future releases.

source
Trixi.FluxHLL — Type
FluxHLL(min_max_speed=min_max_speed_davis)

Create an HLL (Harten, Lax, van Leer) numerical flux where the minimum and maximum wave speeds are estimated as λ_min, λ_max = min_max_speed(u_ll, u_rr, orientation_or_normal_direction, equations), defaulting to min_max_speed_davis. Original paper:

  • Amiram Harten, Peter D. Lax, Bram van Leer (1983) On Upstream Differencing and Godunov-Type Schemes for Hyperbolic Conservation Laws DOI: 10.1137/1025002
source
Trixi.FluxHydrostaticReconstruction — Type
FluxHydrostaticReconstruction(numerical_flux, hydrostatic_reconstruction)
Experimental code

This numerical flux is experimental and may change in any future release.

Allow for some kind of hydrostatic reconstruction of the solution state prior to the surface flux computation. This is a particular strategy to ensure that the method remains well-balanced for the shallow water equations, see ShallowWaterEquations1D or ShallowWaterEquations2D.

For example, the hydrostatic reconstruction from Audusse et al. is implemented in one and two spatial dimensions, see hydrostatic_reconstruction_audusse_etal or the original paper

  • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090

Other hydrostatic reconstruction techniques are available, particularly to handle wet / dry fronts. A good overview of the development and application of hydrostatic reconstruction can be found in

  • Guoxian Chen and Sebastian Noelle A unified surface-gradient and hydrostatic reconstruction scheme for the shallow water equations (2021) RWTH Aachen preprint
  • Andreas Buttinger-Kreuzhuber, Zsolt Horváth, Sebastian Noelle, Günter Blöschl and Jürgen Waser (2019) A fast second-order shallow water scheme on two-dimensional structured grids over abrupt topography DOI: 10.1016/j.advwatres.2019.03.010
source
Trixi.FluxLMARS — Type
FluxLMARS(c)(u_ll, u_rr, orientation_or_normal_direction,
-             equations::CompressibleEulerEquations2D)

Low Mach number approximate Riemann solver (LMARS) for atmospheric flows using an estimate c of the speed of sound.

References:

  • Xi Chen et al. (2013) A Control-Volume Model of the Compressible Euler Equations with a Vertical Lagrangian Coordinate DOI: 10.1175/MWR-D-12-00129.1
source
Trixi.FluxLMARS — Method
FluxLMARS(c)(u_ll, u_rr, orientation_or_normal_direction,
-             equations::CompressibleEulerEquations3D)

Low Mach number approximate Riemann solver (LMARS) for atmospheric flows using an estimate c of the speed of sound.

References:

  • Xi Chen et al. (2013) A Control-Volume Model of the Compressible Euler Equations with a Vertical Lagrangian Coordinate DOI: 10.1175/MWR-D-12-00129.1
source
Trixi.FluxPlusDissipation — Type
FluxPlusDissipation(numerical_flux, dissipation)

Combine a numerical_flux with a dissipation operator to create a new numerical flux.

source
Trixi.FluxRotated — Type
FluxRotated(numerical_flux)

Compute a numerical_flux flux in direction of a normal vector by rotating the solution, computing the numerical flux in x-direction, and rotating the calculated flux back.

Requires a rotationally invariant equation with equation-specific functions rotate_to_x and rotate_from_x.

source
Trixi.FluxUpwind — Type
FluxUpwind(splitting)

A numerical flux f(u_left, u_right) = f⁺(u_left) + f⁻(u_right) based on flux vector splitting.

The SurfaceIntegralUpwind with a given splitting is equivalent to the SurfaceIntegralStrongForm with FluxUpwind(splitting) as numerical flux (up to floating point differences). Note, that SurfaceIntegralUpwind is only available on TreeMesh.

Experimental implementation (upwind SBP)

This is an experimental feature and may change in future releases.

source
Trixi.GlmSpeedCallback — Type
GlmSpeedCallback(; glm_scale=0.5, cfl, semi_indices=())

Update the divergence cleaning wave speed c_h according to the time step computed in StepsizeCallback for the ideal GLM-MHD equations. The cfl number should be set to the same value as for the time step size calculation. The glm_scale ensures that the GLM wave speed is lower than the fastest physical waves in the MHD solution and should thus be set to a value within the interval [0,1]. Note that glm_scale = 0 deactivates the divergence cleaning. In case of coupling semidiscretizations, specify for which semi_index the divergence cleaning should be applied.

source
Trixi.GradientVariablesPrimitive — Type

GradientVariablesPrimitive and GradientVariablesEntropy are gradient variable type parameters for CompressibleNavierStokesDiffusion1D. By default, the gradient variables are set to be GradientVariablesPrimitive. Specifying GradientVariablesEntropy instead uses the entropy variable formulation from

  • Hughes, Mallet, Franca (1986) A new finite element formulation for computational fluid dynamics: I. Symmetric forms of the compressible Euler and Navier-Stokes equations and the second law of thermodynamics. https://doi.org/10.1016/0045-7825(86)90127-1

Under GradientVariablesEntropy, the Navier-Stokes discretization is provably entropy stable.

source
Trixi.HypDiffN3Erk3Sstar52 — Type
HypDiffN3Erk3Sstar52()

Five stage, second-order accurate explicit Runge-Kutta scheme with stability region optimized for the hyperbolic diffusion equation with LLF flux and polynomials of degree polydeg=3.

source
Trixi.HyperbolicDiffusionEquations1D — Type
HyperbolicDiffusionEquations1D

The linear hyperbolic diffusion equations in one space dimension. A description of this system can be found in Sec. 2.5 of the book

Further analysis can be found in the paper

source
Trixi.IdealGlmMhdEquations1D — Type
IdealGlmMhdEquations1D(gamma)

The ideal compressible GLM-MHD equations for an ideal gas with ratio of specific heats gamma in one space dimension.

Note

There is no divergence cleaning variable psi because the divergence-free constraint is satisfied trivially in one spatial dimension.

source
Trixi.IdealGlmMhdEquations2D — Type
IdealGlmMhdEquations2D(gamma)

The ideal compressible GLM-MHD equations for an ideal gas with ratio of specific heats gamma in two space dimensions.

source
Trixi.IdealGlmMhdEquations3D — Type
IdealGlmMhdEquations3D(gamma)

The ideal compressible GLM-MHD equations for an ideal gas with ratio of specific heats gamma in three space dimensions.

source
Trixi.IndicatorHennemannGassner — Type
IndicatorHennemannGassner(equations::AbstractEquations, basis;
+                               alg, cfl_acoustics::Real, cfl_euler::Real; kwargs...)
Experimental code

This callback is experimental and may change in any future release.

Creates an EulerAcousticsCouplingCallback based on the pure flow ODEProblem given by ode_euler. Creates an integrator using the time integration method alg and the keyword arguments to solve ode_euler (consult the OrdinaryDiffEq documentation for further information). Manages the step size for both solvers by using the minimum of the maximum step size obtained with CFL numbers cfl_acoustics for the acoustics solver and cfl_euler for and flow solver, respectively. The mean values for the acoustic perturbation equations are read from averaging_callback (see AveragingCallback).

source
Trixi.FDSBP — Type
FDSBP(D_SBP; surface_integral, volume_integral)

Specialization of DG methods that uses general summation by parts (SBP) operators from SummationByPartsOperators.jl. In particular, this includes classical finite difference (FD) SBP methods. These methods have the same structure as classical DG methods - local operations on elements with connectivity through interfaces without imposing any continuity constraints.

D_SBP is an SBP derivative operator from SummationByPartsOperators.jl. The other arguments have the same meaning as in DG or DGSEM.

Experimental implementation (upwind SBP)

This is an experimental feature and may change in future releases.

source
Trixi.FluxHLL — Type
FluxHLL(min_max_speed=min_max_speed_davis)

Create an HLL (Harten, Lax, van Leer) numerical flux where the minimum and maximum wave speeds are estimated as λ_min, λ_max = min_max_speed(u_ll, u_rr, orientation_or_normal_direction, equations), defaulting to min_max_speed_davis. Original paper:

  • Amiram Harten, Peter D. Lax, Bram van Leer (1983) On Upstream Differencing and Godunov-Type Schemes for Hyperbolic Conservation Laws DOI: 10.1137/1025002
source
Trixi.FluxHydrostaticReconstruction — Type
FluxHydrostaticReconstruction(numerical_flux, hydrostatic_reconstruction)
Experimental code

This numerical flux is experimental and may change in any future release.

Allow for some kind of hydrostatic reconstruction of the solution state prior to the surface flux computation. This is a particular strategy to ensure that the method remains well-balanced for the shallow water equations, see ShallowWaterEquations1D or ShallowWaterEquations2D.

For example, the hydrostatic reconstruction from Audusse et al. is implemented in one and two spatial dimensions, see hydrostatic_reconstruction_audusse_etal or the original paper

  • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090

Other hydrostatic reconstruction techniques are available, particularly to handle wet / dry fronts. A good overview of the development and application of hydrostatic reconstruction can be found in

  • Guoxian Chen and Sebastian Noelle A unified surface-gradient and hydrostatic reconstruction scheme for the shallow water equations (2021) RWTH Aachen preprint
  • Andreas Buttinger-Kreuzhuber, Zsolt Horváth, Sebastian Noelle, Günter Blöschl and Jürgen Waser (2019) A fast second-order shallow water scheme on two-dimensional structured grids over abrupt topography DOI: 10.1016/j.advwatres.2019.03.010
source
Trixi.FluxLMARS — Type
FluxLMARS(c)(u_ll, u_rr, orientation_or_normal_direction,
+             equations::CompressibleEulerEquations2D)

Low Mach number approximate Riemann solver (LMARS) for atmospheric flows using an estimate c of the speed of sound.

References:

  • Xi Chen et al. (2013) A Control-Volume Model of the Compressible Euler Equations with a Vertical Lagrangian Coordinate DOI: 10.1175/MWR-D-12-00129.1
source
Trixi.FluxLMARS — Method
FluxLMARS(c)(u_ll, u_rr, orientation_or_normal_direction,
+             equations::CompressibleEulerEquations3D)

Low Mach number approximate Riemann solver (LMARS) for atmospheric flows using an estimate c of the speed of sound.

References:

  • Xi Chen et al. (2013) A Control-Volume Model of the Compressible Euler Equations with a Vertical Lagrangian Coordinate DOI: 10.1175/MWR-D-12-00129.1
source
Trixi.FluxPlusDissipation — Type
FluxPlusDissipation(numerical_flux, dissipation)

Combine a numerical_flux with a dissipation operator to create a new numerical flux.

source
Trixi.FluxRotated — Type
FluxRotated(numerical_flux)

Compute a numerical_flux flux in direction of a normal vector by rotating the solution, computing the numerical flux in x-direction, and rotating the calculated flux back.

Requires a rotationally invariant equation with equation-specific functions rotate_to_x and rotate_from_x.

source
Trixi.FluxUpwind — Type
FluxUpwind(splitting)

A numerical flux f(u_left, u_right) = f⁺(u_left) + f⁻(u_right) based on flux vector splitting.

The SurfaceIntegralUpwind with a given splitting is equivalent to the SurfaceIntegralStrongForm with FluxUpwind(splitting) as numerical flux (up to floating point differences). Note, that SurfaceIntegralUpwind is only available on TreeMesh.

Experimental implementation (upwind SBP)

This is an experimental feature and may change in future releases.

source
Trixi.GlmSpeedCallback — Type
GlmSpeedCallback(; glm_scale=0.5, cfl, semi_indices=())

Update the divergence cleaning wave speed c_h according to the time step computed in StepsizeCallback for the ideal GLM-MHD equations. The cfl number should be set to the same value as for the time step size calculation. The glm_scale ensures that the GLM wave speed is lower than the fastest physical waves in the MHD solution and should thus be set to a value within the interval [0,1]. Note that glm_scale = 0 deactivates the divergence cleaning. In case of coupling semidiscretizations, specify for which semi_index the divergence cleaning should be applied.

source
Trixi.GradientVariablesPrimitive — Type

GradientVariablesPrimitive and GradientVariablesEntropy are gradient variable type parameters for CompressibleNavierStokesDiffusion1D. By default, the gradient variables are set to be GradientVariablesPrimitive. Specifying GradientVariablesEntropy instead uses the entropy variable formulation from

  • Hughes, Mallet, Franca (1986) A new finite element formulation for computational fluid dynamics: I. Symmetric forms of the compressible Euler and Navier-Stokes equations and the second law of thermodynamics. https://doi.org/10.1016/0045-7825(86)90127-1

Under GradientVariablesEntropy, the Navier-Stokes discretization is provably entropy stable.

source
Trixi.HypDiffN3Erk3Sstar52 — Type
HypDiffN3Erk3Sstar52()

Five stage, second-order accurate explicit Runge-Kutta scheme with stability region optimized for the hyperbolic diffusion equation with LLF flux and polynomials of degree polydeg=3.

source
Trixi.HyperbolicDiffusionEquations1D — Type
HyperbolicDiffusionEquations1D

The linear hyperbolic diffusion equations in one space dimension. A description of this system can be found in Sec. 2.5 of the book

Further analysis can be found in the paper

source
Trixi.IdealGlmMhdEquations1D — Type
IdealGlmMhdEquations1D(gamma)

The ideal compressible GLM-MHD equations for an ideal gas with ratio of specific heats gamma in one space dimension.

Note

There is no divergence cleaning variable psi because the divergence-free constraint is satisfied trivially in one spatial dimension.

source
Trixi.IdealGlmMhdEquations2D — Type
IdealGlmMhdEquations2D(gamma)

The ideal compressible GLM-MHD equations for an ideal gas with ratio of specific heats gamma in two space dimensions.

source
Trixi.IdealGlmMhdEquations3D — Type
IdealGlmMhdEquations3D(gamma)

The ideal compressible GLM-MHD equations for an ideal gas with ratio of specific heats gamma in three space dimensions.

source
Trixi.IndicatorHennemannGassner — Type
IndicatorHennemannGassner(equations::AbstractEquations, basis;
                           alpha_max=0.5,
                           alpha_min=0.001,
                           alpha_smooth=true,
@@ -208,20 +208,20 @@
                           alpha_max=0.5,
                           alpha_min=0.001,
                           alpha_smooth=true,
-                          variable)

Indicator used for shock-capturing (when passing the equations and the basis) or adaptive mesh refinement (AMR, when passing the semi).

See also VolumeIntegralShockCapturingHG.

References

  • Hennemann, Gassner (2020) "A provably entropy stable subcell shock capturing approach for high order split form DG" arXiv: 2008.12044
source
Trixi.IndicatorLöhner — Type
IndicatorLöhner (equivalent to IndicatorLoehner)
+                          variable)

Indicator used for shock-capturing (when passing the equations and the basis) or adaptive mesh refinement (AMR, when passing the semi).

See also VolumeIntegralShockCapturingHG.

References

  • Hennemann, Gassner (2020) "A provably entropy stable subcell shock capturing approach for high order split form DG" arXiv: 2008.12044
source
Trixi.IndicatorLöhner — Type
IndicatorLöhner (equivalent to IndicatorLoehner)
 
 IndicatorLöhner(equations::AbstractEquations, basis;
                 f_wave=0.2, variable)
 IndicatorLöhner(semi::AbstractSemidiscretization;
-                f_wave=0.2, variable)

AMR indicator adapted from a FEM indicator by Löhner (1987), also used in the FLASH code as standard AMR indicator. The indicator estimates a weighted second derivative of a specified variable locally.

When constructed to be used for AMR, pass the semi. Pass the equations, and basis if this indicator should be used for shock capturing.

References

source
Trixi.IndicatorMax — Type
IndicatorMax(equations::AbstractEquations, basis; variable)
-IndicatorMax(semi::AbstractSemidiscretization; variable)

A simple indicator returning the maximum of variable in an element. When constructed to be used for AMR, pass the semi. Pass the equations, and basis if this indicator should be used for shock capturing.

source
Trixi.Isothermal — Type
struct Isothermal

Used to create a no-slip boundary condition with BoundaryConditionNavierStokesWall. The field boundary_value_function should be a function with signature boundary_value_function(x, t, equations) and return a scalar value for the temperature at point x and time t.

source
Trixi.LaplaceDiffusion1D — Type
LaplaceDiffusion1D(diffusivity, equations)

LaplaceDiffusion1D represents a scalar diffusion term $\nabla \cdot (\kappa\nabla u))$ with diffusivity $\kappa$ applied to each solution component defined by equations.

source
Trixi.LaplaceDiffusion2D — Type
LaplaceDiffusion2D(diffusivity, equations)

LaplaceDiffusion2D represents a scalar diffusion term $\nabla \cdot (\kappa\nabla u))$ with diffusivity $\kappa$ applied to each solution component defined by equations.

source
Trixi.LaplaceDiffusion3D — Type
LaplaceDiffusion3D(diffusivity, equations)

LaplaceDiffusion3D represents a scalar diffusion term $\nabla \cdot (\kappa\nabla u))$ with diffusivity $\kappa$ applied to each solution component defined by equations.

source
Trixi.LatticeBoltzmannEquations2D — Type
LatticeBoltzmannEquations2D(; Ma, Re, collision_op=collision_bgk,
+                f_wave=0.2, variable)

AMR indicator adapted from a FEM indicator by Löhner (1987), also used in the FLASH code as standard AMR indicator. The indicator estimates a weighted second derivative of a specified variable locally.

When constructed to be used for AMR, pass the semi. Pass the equations, and basis if this indicator should be used for shock capturing.

References

source
Trixi.IndicatorMax — Type
IndicatorMax(equations::AbstractEquations, basis; variable)
+IndicatorMax(semi::AbstractSemidiscretization; variable)

A simple indicator returning the maximum of variable in an element. When constructed to be used for AMR, pass the semi. Pass the equations, and basis if this indicator should be used for shock capturing.

source
Trixi.Isothermal — Type
struct Isothermal

Used to create a no-slip boundary condition with BoundaryConditionNavierStokesWall. The field boundary_value_function should be a function with signature boundary_value_function(x, t, equations) and return a scalar value for the temperature at point x and time t.

source
Trixi.LaplaceDiffusion1D — Type
LaplaceDiffusion1D(diffusivity, equations)

LaplaceDiffusion1D represents a scalar diffusion term $\nabla \cdot (\kappa\nabla u))$ with diffusivity $\kappa$ applied to each solution component defined by equations.

source
Trixi.LaplaceDiffusion2D — Type
LaplaceDiffusion2D(diffusivity, equations)

LaplaceDiffusion2D represents a scalar diffusion term $\nabla \cdot (\kappa\nabla u))$ with diffusivity $\kappa$ applied to each solution component defined by equations.

source
Trixi.LaplaceDiffusion3D — Type
LaplaceDiffusion3D(diffusivity, equations)

LaplaceDiffusion3D represents a scalar diffusion term $\nabla \cdot (\kappa\nabla u))$ with diffusivity $\kappa$ applied to each solution component defined by equations.

source
Trixi.LatticeBoltzmannEquations2D — Type
LatticeBoltzmannEquations2D(; Ma, Re, collision_op=collision_bgk,
                            c=1, L=1, rho0=1, u0=nothing, nu=nothing)

The Lattice-Boltzmann equations

\[\partial_t u_\alpha + v_{\alpha,1} \partial_1 u_\alpha + v_{\alpha,2} \partial_2 u_\alpha = 0\]

in two space dimensions for the D2Q9 scheme.

The characteristic Mach number and Reynolds numbers are specified as Ma and Re. By the default, the collision operator collision_op is set to the BGK model. c, L, and rho0 specify the mean thermal molecular velocity, the characteristic length, and the reference density, respectively. They can usually be left to the default values. If desired, instead of the Mach number, one can set the macroscopic reference velocity u0 directly (Ma needs to be set to nothing in this case). Likewise, instead of the Reynolds number one can specify the kinematic viscosity nu directly (in this case, Re needs to be set to nothing).

The nine discrete velocity directions of the D2Q9 scheme are sorted as follows [4]:

  6     2     5       y
     ┌───┼───┐         │
     │       │         │
   3 ┼   9   ┼ 1        ──── x
     │       │        ╱
     └───┼───┘       ╱
-  7     4     8    z

Note that usually the velocities are numbered from 0 to 8, where 0 corresponds to the zero velocity. Due to Julia using 1-based indexing, here we use indices from 1 to 9, where 1 through 8 correspond to the velocity directions in [4] and 9 is the zero velocity.

The corresponding opposite directions are:

  • 1 ←→ 3
  • 2 ←→ 4
  • 3 ←→ 1
  • 4 ←→ 2
  • 5 ←→ 7
  • 6 ←→ 8
  • 7 ←→ 5
  • 8 ←→ 6
  • 9 ←→ 9

The main sources for the base implementation were

  1. Misun Min, Taehun Lee, A spectral-element discontinuous Galerkin lattice Boltzmann method for nearly incompressible flows, J Comput Phys 230(1), 2011 doi:10.1016/j.jcp.2010.09.024
  2. Karsten Golly, Anwendung der Lattice-Boltzmann Discontinuous Galerkin Spectral Element Method (LB-DGSEM) auf laminare und turbulente nahezu inkompressible Strömungen im dreidimensionalen Raum, Master Thesis, University of Cologne, 2018.
  3. Dieter Hänel, Molekulare Gasdynamik, Springer-Verlag Berlin Heidelberg, 2004 doi:10.1007/3-540-35047-0
  4. Dieter Krüger et al., The Lattice Boltzmann Method, Springer International Publishing, 2017 doi:10.1007/978-3-319-44649-3
source
Trixi.LatticeBoltzmannEquations3D — Type
LatticeBoltzmannEquations3D(; Ma, Re, collision_op=collision_bgk,
+  7     4     8    z

Note that usually the velocities are numbered from 0 to 8, where 0 corresponds to the zero velocity. Due to Julia using 1-based indexing, here we use indices from 1 to 9, where 1 through 8 correspond to the velocity directions in [4] and 9 is the zero velocity.

The corresponding opposite directions are:

  • 1 ←→ 3
  • 2 ←→ 4
  • 3 ←→ 1
  • 4 ←→ 2
  • 5 ←→ 7
  • 6 ←→ 8
  • 7 ←→ 5
  • 8 ←→ 6
  • 9 ←→ 9

The main sources for the base implementation were

  1. Misun Min, Taehun Lee, A spectral-element discontinuous Galerkin lattice Boltzmann method for nearly incompressible flows, J Comput Phys 230(1), 2011 doi:10.1016/j.jcp.2010.09.024
  2. Karsten Golly, Anwendung der Lattice-Boltzmann Discontinuous Galerkin Spectral Element Method (LB-DGSEM) auf laminare und turbulente nahezu inkompressible Strömungen im dreidimensionalen Raum, Master Thesis, University of Cologne, 2018.
  3. Dieter Hänel, Molekulare Gasdynamik, Springer-Verlag Berlin Heidelberg, 2004 doi:10.1007/3-540-35047-0
  4. Dieter Krüger et al., The Lattice Boltzmann Method, Springer International Publishing, 2017 doi:10.1007/978-3-319-44649-3
source
Trixi.LatticeBoltzmannEquations3D — Type
LatticeBoltzmannEquations3D(; Ma, Re, collision_op=collision_bgk,
                            c=1, L=1, rho0=1, u0=nothing, nu=nothing)

The Lattice-Boltzmann equations

\[\partial_t u_\alpha + v_{\alpha,1} \partial_1 u_\alpha + v_{\alpha,2} \partial_2 u_\alpha + v_{\alpha,3} \partial_3 u_\alpha = 0\]

in three space dimensions for the D3Q27 scheme.

The characteristic Mach number and Reynolds numbers are specified as Ma and Re. By the default, the collision operator collision_op is set to the BGK model. c, L, and rho0 specify the mean thermal molecular velocity, the characteristic length, and the reference density, respectively. They can usually be left to the default values. If desired, instead of the Mach number, one can set the macroscopic reference velocity u0 directly (Ma needs to be set to nothing in this case). Likewise, instead of the Reynolds number one can specify the kinematic viscosity nu directly (in this case, Re needs to be set to nothing).

The twenty-seven discrete velocity directions of the D3Q27 scheme are sorted as follows [4]:

  • plane at z = -1:
      24    17     21       y
      ┌───┼───┐          │
      │       │          │
@@ -240,7 +240,7 @@
   16 ┼   5   ┼ 9         ──── x
      │       │         ╱
      └───┼───┘        ╱
-  22    18     23    z

Note that usually the velocities are numbered from 0 to 26, where 0 corresponds to the zero velocity. Due to Julia using 1-based indexing, here we use indices from 1 to 27, where 1 through 26 correspond to the velocity directions in [4] and 27 is the zero velocity.

The corresponding opposite directions are:

  • 1 ←→ 2
  • 2 ←→ 1
  • 3 ←→ 4
  • 4 ←→ 3
  • 5 ←→ 6
  • 6 ←→ 5
  • 7 ←→ 8
  • 8 ←→ 7
  • 9 ←→ 10
  • 10 ←→ 9
  • 11 ←→ 12
  • 12 ←→ 11
  • 13 ←→ 14
  • 14 ←→ 13
  • 15 ←→ 16
  • 16 ←→ 15
  • 17 ←→ 18
  • 18 ←→ 17
  • 19 ←→ 20
  • 20 ←→ 19
  • 21 ←→ 22
  • 22 ←→ 21
  • 23 ←→ 24
  • 24 ←→ 23
  • 25 ←→ 26
  • 26 ←→ 25
  • 27 ←→ 27

The main sources for the base implementation were

  1. Misun Min, Taehun Lee, A spectral-element discontinuous Galerkin lattice Boltzmann method for nearly incompressible flows, J Comput Phys 230(1), 2011 doi:10.1016/j.jcp.2010.09.024
  2. Karsten Golly, Anwendung der Lattice-Boltzmann Discontinuous Galerkin Spectral Element Method (LB-DGSEM) auf laminare und turbulente nahezu inkompressible Strömungen im dreidimensionalen Raum, Master Thesis, University of Cologne, 2018.
  3. Dieter Hänel, Molekulare Gasdynamik, Springer-Verlag Berlin Heidelberg, 2004 doi:10.1007/3-540-35047-0
  4. Dieter Krüger et al., The Lattice Boltzmann Method, Springer International Publishing, 2017 doi:10.1007/978-3-319-44649-3
source
Trixi.LinearScalarAdvectionEquation2D — Type
LinearScalarAdvectionEquation2D

The linear scalar advection equation

\[\partial_t u + a_1 \partial_1 u + a_2 \partial_2 u = 0\]

in two space dimensions with constant velocity a.

source
Trixi.LinearScalarAdvectionEquation3D — Type
LinearScalarAdvectionEquation3D

The linear scalar advection equation

\[\partial_t u + a_1 \partial_1 u + a_2 \partial_2 u + a_3 \partial_3 u = 0\]

in three space dimensions with constant velocity a.

source
Trixi.LinearizedEulerEquations2D — Type
LinearizedEulerEquations2D(v_mean_global, c_mean_global, rho_mean_global)

Linearized euler equations in two space dimensions. The equations are given by

\[\partial_t + 22 18 23 z

Note that usually the velocities are numbered from 0 to 26, where 0 corresponds to the zero velocity. Due to Julia using 1-based indexing, here we use indices from 1 to 27, where 1 through 26 correspond to the velocity directions in [4] and 27 is the zero velocity.

The corresponding opposite directions are:

  • 1 ←→ 2
  • 2 ←→ 1
  • 3 ←→ 4
  • 4 ←→ 3
  • 5 ←→ 6
  • 6 ←→ 5
  • 7 ←→ 8
  • 8 ←→ 7
  • 9 ←→ 10
  • 10 ←→ 9
  • 11 ←→ 12
  • 12 ←→ 11
  • 13 ←→ 14
  • 14 ←→ 13
  • 15 ←→ 16
  • 16 ←→ 15
  • 17 ←→ 18
  • 18 ←→ 17
  • 19 ←→ 20
  • 20 ←→ 19
  • 21 ←→ 22
  • 22 ←→ 21
  • 23 ←→ 24
  • 24 ←→ 23
  • 25 ←→ 26
  • 26 ←→ 25
  • 27 ←→ 27

The main sources for the base implementation were

  1. Misun Min, Taehun Lee, A spectral-element discontinuous Galerkin lattice Boltzmann method for nearly incompressible flows, J Comput Phys 230(1), 2011 doi:10.1016/j.jcp.2010.09.024
  2. Karsten Golly, Anwendung der Lattice-Boltzmann Discontinuous Galerkin Spectral Element Method (LB-DGSEM) auf laminare und turbulente nahezu inkompressible Strömungen im dreidimensionalen Raum, Master Thesis, University of Cologne, 2018.
  3. Dieter Hänel, Molekulare Gasdynamik, Springer-Verlag Berlin Heidelberg, 2004 doi:10.1007/3-540-35047-0
  4. Dieter Krüger et al., The Lattice Boltzmann Method, Springer International Publishing, 2017 doi:10.1007/978-3-319-44649-3
source
Trixi.LinearScalarAdvectionEquation2D — Type
LinearScalarAdvectionEquation2D

The linear scalar advection equation

\[\partial_t u + a_1 \partial_1 u + a_2 \partial_2 u = 0\]

in two space dimensions with constant velocity a.

source
Trixi.LinearScalarAdvectionEquation3D — Type
LinearScalarAdvectionEquation3D

The linear scalar advection equation

\[\partial_t u + a_1 \partial_1 u + a_2 \partial_2 u + a_3 \partial_3 u = 0\]

in three space dimensions with constant velocity a.

source
Trixi.LinearizedEulerEquations2D — Type
LinearizedEulerEquations2D(v_mean_global, c_mean_global, rho_mean_global)

Linearized euler equations in two space dimensions. The equations are given by

\[\partial_t \begin{pmatrix} \rho' \\ v_1' \\ v_2' \\ p' \end{pmatrix} @@ -257,20 +257,20 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 \\ 0 -\end{pmatrix}\]

The bar $\bar{(\cdot)}$ indicates uniform mean flow variables and c is the speed of sound. The unknowns are the acoustic velocities $v' = (v_1', v_2')$, the pressure $p'$ and the density $\rho'$.

source
Trixi.LobattoLegendreBasis — Type
LobattoLegendreBasis([RealT=Float64,] polydeg::Integer)

Create a nodal Lobatto-Legendre basis for polynomials of degree polydeg.

For the special case polydeg=0 the DG method reduces to a finite volume method. Therefore, this function sets the center point of the cell as single node. This exceptional case is currently only supported for TreeMesh!

source
Trixi.NoSlip — Type
struct NoSlip

Use to create a no-slip boundary condition with BoundaryConditionNavierStokesWall. The field boundary_value_function should be a function with signature boundary_value_function(x, t, equations) and should return a SVector{NDIMS} whose entries are the velocity vector at a point x and time t.

source
Trixi.NonConservativeLocal — Type
NonConservativeLocal()

Struct used for multiple dispatch on non-conservative flux functions in the format of "local * symmetric". When the argument nonconservative_type is of type NonConservativeLocal, the function returns the local part of the non-conservative term.

source
Trixi.NonConservativeSymmetric — Type
NonConservativeSymmetric()

Struct used for multiple dispatch on non-conservative flux functions in the format of "local * symmetric". When the argument nonconservative_type is of type NonConservativeSymmetric, the function returns the symmetric part of the non-conservative term.

source
Trixi.P4estMesh — Type
P4estMesh{NDIMS} <: AbstractMesh{NDIMS}

An unstructured curved mesh based on trees that uses the C library p4est to manage trees and mesh refinement.

source
Trixi.P4estMesh — Method
P4estMesh(trees_per_dimension; polydeg,
+\end{pmatrix}\]
The bar $\bar{(\cdot)}$ indicates uniform mean flow variables and c is the speed of sound. The unknowns are the acoustic velocities $v' = (v_1', v_2')$, the pressure $p'$ and the density $\rho'$.
source
Trixi.LobattoLegendreBasis — Type
LobattoLegendreBasis([RealT=Float64,] polydeg::Integer)

Create a nodal Lobatto-Legendre basis for polynomials of degree polydeg.

For the special case polydeg=0 the DG method reduces to a finite volume method. Therefore, this function sets the center point of the cell as single node. This exceptional case is currently only supported for TreeMesh!

source
Trixi.NoSlip — Type
struct NoSlip

Use to create a no-slip boundary condition with BoundaryConditionNavierStokesWall. The field boundary_value_function should be a function with signature boundary_value_function(x, t, equations) and should return a SVector{NDIMS} whose entries are the velocity vector at a point x and time t.

source
Trixi.NonConservativeLocal — Type
NonConservativeLocal()

Struct used for multiple dispatch on non-conservative flux functions in the format of "local * symmetric". When the argument nonconservative_type is of type NonConservativeLocal, the function returns the local part of the non-conservative term.

source
Trixi.NonConservativeSymmetric — Type
NonConservativeSymmetric()

Struct used for multiple dispatch on non-conservative flux functions in the format of "local * symmetric". When the argument nonconservative_type is of type NonConservativeSymmetric, the function returns the symmetric part of the non-conservative term.

source
Trixi.P4estMesh — Type
P4estMesh{NDIMS} <: AbstractMesh{NDIMS}

An unstructured curved mesh based on trees that uses the C library p4est to manage trees and mesh refinement.

source
Trixi.P4estMesh — Method
P4estMesh(trees_per_dimension; polydeg,
           mapping=nothing, faces=nothing, coordinates_min=nothing, coordinates_max=nothing,
           RealT=Float64, initial_refinement_level=0, periodicity=true, unsaved_changes=true,
-          p4est_partition_allow_for_coarsening=true)

Create a structured curved P4estMesh of the specified size.

There are three ways to map the mesh to the physical domain.

  1. Define a mapping that maps the hypercube [-1, 1]^n.
  2. Specify a Tuple faces of functions that parametrize each face.
  3. Create a rectangular mesh by specifying coordinates_min and coordinates_max.

Non-periodic boundaries will be called :x_neg, :x_pos, :y_neg, :y_pos, :z_neg, :z_pos.

Arguments

  • trees_per_dimension::NTupleE{NDIMS, Int}: the number of trees in each dimension.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the reference mesh ([-1, 1]^n) to the physical domain. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • faces::NTuple{2*NDIMS}: a tuple of 2 * NDIMS functions that describe the faces of the domain. Each function must take NDIMS-1 arguments. faces[1] describes the face onto which the face in negative x-direction of the unit hypercube is mapped. The face in positive x-direction of the unit hypercube will be mapped onto the face described by faces[2]. faces[3:4] describe the faces in positive and negative y-direction respectively (in 2D and 3D). faces[5:6] describe the faces in positive and negative z-direction respectively (in 3D). Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_min: vector or tuple of the coordinates of the corner in the negative direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_max: vector or tuple of the coordinates of the corner in the positive direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • p4est_partition_allow_for_coarsening::Bool: Must be true when using AMR to make mesh adaptivity independent of domain partitioning. Should be false for static meshes to permit more fine-grained partitioning.
source
Trixi.P4estMesh — Method
P4estMesh{NDIMS}(meshfile::String;
+          p4est_partition_allow_for_coarsening=true)

Create a structured curved P4estMesh of the specified size.

There are three ways to map the mesh to the physical domain.

  1. Define a mapping that maps the hypercube [-1, 1]^n.
  2. Specify a Tuple faces of functions that parametrize each face.
  3. Create a rectangular mesh by specifying coordinates_min and coordinates_max.

Non-periodic boundaries will be called :x_neg, :x_pos, :y_neg, :y_pos, :z_neg, :z_pos.

Arguments

  • trees_per_dimension::NTupleE{NDIMS, Int}: the number of trees in each dimension.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the reference mesh ([-1, 1]^n) to the physical domain. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • faces::NTuple{2*NDIMS}: a tuple of 2 * NDIMS functions that describe the faces of the domain. Each function must take NDIMS-1 arguments. faces[1] describes the face onto which the face in negative x-direction of the unit hypercube is mapped. The face in positive x-direction of the unit hypercube will be mapped onto the face described by faces[2]. faces[3:4] describe the faces in positive and negative y-direction respectively (in 2D and 3D). faces[5:6] describe the faces in positive and negative z-direction respectively (in 3D). Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_min: vector or tuple of the coordinates of the corner in the negative direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_max: vector or tuple of the coordinates of the corner in the positive direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • p4est_partition_allow_for_coarsening::Bool: Must be true when using AMR to make mesh adaptivity independent of domain partitioning. Should be false for static meshes to permit more fine-grained partitioning.
source
Trixi.P4estMesh — Method
P4estMesh{NDIMS}(meshfile::String;
                  mapping=nothing, polydeg=1, RealT=Float64,
                  initial_refinement_level=0, unsaved_changes=true,
                  p4est_partition_allow_for_coarsening=true,
-                 boundary_symbols = nothing)

Main mesh constructor for the P4estMesh that imports an unstructured, conforming mesh from an Abaqus mesh file (.inp). Each element of the conforming mesh parsed from the meshfile is created as a p4est tree datatype.

To create a curved unstructured mesh P4estMesh two strategies are available:

  • p4est_mesh_from_hohqmesh_abaqus: High-order, curved boundary information created by HOHQMesh.jl is available in the meshfile. The mesh polynomial degree polydeg of the boundaries is provided from the meshfile. The computation of the mapped tree coordinates is done with transfinite interpolation with linear blending similar to UnstructuredMesh2D. Boundary name information is also parsed from the meshfile such that different boundary conditions can be set at each named boundary on a given tree.
  • p4est_mesh_from_standard_abaqus: By default, with mapping=nothing and polydeg=1, this creates a straight-sided from the information parsed from the meshfile. If a mapping function is specified then it computes the mapped tree coordinates via polynomial interpolants with degree polydeg. The mesh created by this function will only have one boundary :all if boundary_symbols is not specified. If boundary_symbols is specified the mesh file will be parsed for nodesets defining the boundary nodes from which boundary edges (2D) and faces (3D) will be assigned.

Note that the mapping and polydeg keyword arguments are only used by the p4est_mesh_from_standard_abaqus function. The p4est_mesh_from_hohqmesh_abaqus function obtains the mesh polydeg directly from the meshfile and constructs the transfinite mapping internally.

The particular strategy is selected according to the header present in the meshfile where the constructor checks whether or not the meshfile was created with HOHQMesh.jl. If the Abaqus file header is not present in the meshfile then the P4estMesh is created with the function p4est_mesh_from_standard_abaqus.

The default keyword argument initial_refinement_level=0 corresponds to a forest where the number of trees is the same as the number of elements in the original meshfile. Increasing the initial_refinement_level allows one to uniformly refine the base mesh given in the meshfile to create a forest with more trees before the simulation begins. For example, if a two-dimensional base mesh contains 25 elements then setting initial_refinement_level=1 creates an initial forest of 2^2 * 25 = 100 trees.

Arguments

  • meshfile::String: an uncurved Abaqus mesh file that can be imported by p4est.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • p4est_partition_allow_for_coarsening::Bool: Must be true when using AMR to make mesh adaptivity independent of domain partitioning. Should be false for static meshes to permit more fine-grained partitioning.
  • boundary_symbols::Vector{Symbol}: A vector of symbols that correspond to the boundary names in the meshfile. If nothing is passed then all boundaries are named :all.
source
Trixi.ParametersEulerGravity — Type
ParametersEulerGravity(; background_density=0.0,
+                 boundary_symbols = nothing)

Main mesh constructor for the P4estMesh that imports an unstructured, conforming mesh from an Abaqus mesh file (.inp). Each element of the conforming mesh parsed from the meshfile is created as a p4est tree datatype.

To create a curved unstructured mesh P4estMesh two strategies are available:

  • p4est_mesh_from_hohqmesh_abaqus: High-order, curved boundary information created by HOHQMesh.jl is available in the meshfile. The mesh polynomial degree polydeg of the boundaries is provided from the meshfile. The computation of the mapped tree coordinates is done with transfinite interpolation with linear blending similar to UnstructuredMesh2D. Boundary name information is also parsed from the meshfile such that different boundary conditions can be set at each named boundary on a given tree.
  • p4est_mesh_from_standard_abaqus: By default, with mapping=nothing and polydeg=1, this creates a straight-sided from the information parsed from the meshfile. If a mapping function is specified then it computes the mapped tree coordinates via polynomial interpolants with degree polydeg. The mesh created by this function will only have one boundary :all if boundary_symbols is not specified. If boundary_symbols is specified the mesh file will be parsed for nodesets defining the boundary nodes from which boundary edges (2D) and faces (3D) will be assigned.

Note that the mapping and polydeg keyword arguments are only used by the p4est_mesh_from_standard_abaqus function. The p4est_mesh_from_hohqmesh_abaqus function obtains the mesh polydeg directly from the meshfile and constructs the transfinite mapping internally.

The particular strategy is selected according to the header present in the meshfile where the constructor checks whether or not the meshfile was created with HOHQMesh.jl. If the Abaqus file header is not present in the meshfile then the P4estMesh is created with the function p4est_mesh_from_standard_abaqus.

The default keyword argument initial_refinement_level=0 corresponds to a forest where the number of trees is the same as the number of elements in the original meshfile. Increasing the initial_refinement_level allows one to uniformly refine the base mesh given in the meshfile to create a forest with more trees before the simulation begins. For example, if a two-dimensional base mesh contains 25 elements then setting initial_refinement_level=1 creates an initial forest of 2^2 * 25 = 100 trees.

Arguments

  • meshfile::String: an uncurved Abaqus mesh file that can be imported by p4est.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • p4est_partition_allow_for_coarsening::Bool: Must be true when using AMR to make mesh adaptivity independent of domain partitioning. Should be false for static meshes to permit more fine-grained partitioning.
  • boundary_symbols::Vector{Symbol}: A vector of symbols that correspond to the boundary names in the meshfile. If nothing is passed then all boundaries are named :all.
source
Trixi.PerformanceCounter — Type
PerformanceCounter()

A PerformanceCounter can be used to track the runtime performance of some calls. Add a new runtime measurement via put!(counter, runtime) and get the averaged runtime of all measurements added so far via take!(counter), resetting the counter.

source
Trixi.PerformanceCounterList — Type
PerformanceCounterList{N}()

A PerformanceCounterList{N} can be used to track the runtime performance of calls to multiple functions, adding them up. Add a new runtime measurement via put!(counter.counters[i], runtime) and get the averaged runtime of all measurements added so far via take!(counter), resetting the counter.

source
Trixi.PlotData1D — Type
PlotData1D

Holds all relevant data for creating 1D plots of multiple solution variables and to visualize the mesh.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PlotData1D — Method
PlotData1D(u, semi [or mesh, equations, solver, cache];
-           solution_variables=nothing, nvisnodes=nothing)

Create a new PlotData1D object that can be used for visualizing 1D DGSEM solution data array u with Plots.jl. All relevant geometrical information is extracted from the semidiscretization semi. By default, the primitive variables (if existent) or the conservative variables (otherwise) from the solution are used for plotting. This can be changed by passing an appropriate conversion function to solution_variables.

nvisnodes specifies the number of visualization nodes to be used. If it is nothing, twice the number of solution DG nodes are used for visualization, and if set to 0, exactly the number of nodes in the DG elements are used.

When visualizing data from a two-dimensional simulation, a 1D slice is extracted for plotting. slice specifies the axis along which the slice is extracted and may be :x, or :y. The slice position is specified by a point that lies on it, which defaults to (0.0, 0.0). Both of these values are ignored when visualizing 1D data. This applies analogously to three-dimensional simulations, where slice may be :xy, :xz, or :yz.

Another way to visualize 2D/3D data is by creating a plot along a given curve. This is done with the keyword argument curve. It can be set to a list of 2D/3D points which define the curve. When using curve any other input from slice or point will be ignored.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PlotData1D — Method
PlotData1D(sol; kwargs...)

Create a PlotData1D object from a solution object created by either OrdinaryDiffEq.solve! (which returns a SciMLBase.ODESolution) or Trixi.jl's own solve! (which returns a TimeIntegratorSolution).

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PlotData2DCartesian — Type
PlotData2D

Holds all relevant data for creating 2D plots of multiple solution variables and to visualize the mesh.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PerformanceCounter — Type
PerformanceCounter()

A PerformanceCounter can be used to track the runtime performance of some calls. Add a new runtime measurement via put!(counter, runtime) and get the averaged runtime of all measurements added so far via take!(counter), resetting the counter.

source
Trixi.PerformanceCounterList — Type
PerformanceCounterList{N}()

A PerformanceCounterList{N} can be used to track the runtime performance of calls to multiple functions, adding them up. Add a new runtime measurement via put!(counter.counters[i], runtime) and get the averaged runtime of all measurements added so far via take!(counter), resetting the counter.

source
Trixi.PlotData1D — Type
PlotData1D

Holds all relevant data for creating 1D plots of multiple solution variables and to visualize the mesh.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PlotData1D — Method
PlotData1D(u, semi [or mesh, equations, solver, cache];
+           solution_variables=nothing, nvisnodes=nothing)

Create a new PlotData1D object that can be used for visualizing 1D DGSEM solution data array u with Plots.jl. All relevant geometrical information is extracted from the semidiscretization semi. By default, the primitive variables (if existent) or the conservative variables (otherwise) from the solution are used for plotting. This can be changed by passing an appropriate conversion function to solution_variables.

nvisnodes specifies the number of visualization nodes to be used. If it is nothing, twice the number of solution DG nodes are used for visualization, and if set to 0, exactly the number of nodes in the DG elements are used.

When visualizing data from a two-dimensional simulation, a 1D slice is extracted for plotting. slice specifies the axis along which the slice is extracted and may be :x, or :y. The slice position is specified by a point that lies on it, which defaults to (0.0, 0.0). Both of these values are ignored when visualizing 1D data. This applies analogously to three-dimensional simulations, where slice may be :xy, :xz, or :yz.

Another way to visualize 2D/3D data is by creating a plot along a given curve. This is done with the keyword argument curve. It can be set to a list of 2D/3D points which define the curve. When using curve any other input from slice or point will be ignored.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PlotData1D — Method
PlotData1D(sol; kwargs...)

Create a PlotData1D object from a solution object created by either OrdinaryDiffEq.solve! (which returns a SciMLBase.ODESolution) or Trixi.jl's own solve! (which returns a TimeIntegratorSolution).

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PlotData2DCartesian — Type
PlotData2D

Holds all relevant data for creating 2D plots of multiple solution variables and to visualize the mesh.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.PolytropicEulerEquations2D — Type
PolytropicEulerEquations2D(gamma, kappa)

The polytropic Euler equations

\[\frac{\partial}{\partial t} \begin{pmatrix} \rho \\ \rho v_1 \\ \rho v_2 \end{pmatrix} @@ -287,65 +287,65 @@ = \begin{pmatrix} 0 \\ 0 \\ 0 -\end{pmatrix}\]

for an ideal gas with ratio of specific heats gamma in two space dimensions. Here, $\rho$ is the density and $v_1$ andv_2 the velocities and

\[p = \kappa\rho^\gamma\]

the pressure, which we replaced using this relation.

source
Trixi.PositivityPreservingLimiterZhangShu — Type
PositivityPreservingLimiterZhangShu(; threshold, variables)

The fully-discrete positivity-preserving limiter of

  • Zhang, Shu (2011) Maximum-principle-satisfying and positivity-preserving high-order schemes for conservation laws: survey and new developments doi: 10.1098/rspa.2011.0153

The limiter is applied to all scalar variables in their given order using the associated thresholds to determine the minimal acceptable values. The order of the variables is important and might have a strong influence on the robustness.

source
Trixi.SaveRestartCallback — Type
SaveRestartCallback(; interval=0,
+\end{pmatrix}\]
for an ideal gas with ratio of specific heats gamma in two space dimensions. Here, $\rho$ is the density and $v_1$ andv_2 the velocities and
\[p = \kappa\rho^\gamma\]
the pressure, which we replaced using this relation.
source
Trixi.PositivityPreservingLimiterZhangShu — Type
PositivityPreservingLimiterZhangShu(; threshold, variables)

The fully-discrete positivity-preserving limiter of

  • Zhang, Shu (2011) Maximum-principle-satisfying and positivity-preserving high-order schemes for conservation laws: survey and new developments doi: 10.1098/rspa.2011.0153

The limiter is applied to all scalar variables in their given order using the associated thresholds to determine the minimal acceptable values. The order of the variables is important and might have a strong influence on the robustness.

source
Trixi.SaveRestartCallback — Type
SaveRestartCallback(; interval=0,
                       save_final_restart=true,
-                      output_directory="out")

Save the current numerical solution in a restart file every interval time steps.

source
Trixi.SaveSolutionCallback — Type
SaveSolutionCallback(; interval::Integer=0,
+                      output_directory="out")

Save the current numerical solution in a restart file every interval time steps.

source
Trixi.SaveSolutionCallback — Type
SaveSolutionCallback(; interval::Integer=0,
                        dt=nothing,
                        save_initial_solution=true,
                        save_final_solution=true,
                        output_directory="out",
-                       solution_variables=cons2prim)

Save the current numerical solution in regular intervals. Either pass interval to save every interval time steps or pass dt to save in intervals of dt in terms of integration time by adding additional (shortened) time steps where necessary (note that this may change the solution). solution_variables can be any callable that converts the conservative variables at a single point to a set of solution variables. The first parameter passed to solution_variables will be the set of conservative variables and the second parameter is the equation struct.

source
Trixi.SemidiscretizationCoupled — Type
SemidiscretizationCoupled

A struct used to bundle multiple semidiscretizations. semidiscretize will return an ODEProblem that synchronizes time steps between the semidiscretizations. Each call of rhs! will call rhs! for each semidiscretization individually. The semidiscretizations can be coupled by gluing meshes together using BoundaryConditionCoupled.

Experimental code

This is an experimental feature and can change any time.

source
Trixi.SemidiscretizationEulerAcoustics — Type
SemidiscretizationEulerAcoustics(semi_acoustics::SemiAcoustics, semi_euler::SemiEuler;
-                                 source_region=x->true, weights=x->1.0)
Experimental code

This semidiscretization is experimental and may change in any future release.

Construct a semidiscretization of the acoustic perturbation equations that is coupled with the compressible Euler equations via source terms for the perturbed velocity. Both semidiscretizations have to use the same mesh and solvers with a shared basis. The coupling region is described by a function source_region that maps the coordinates of a single node to true or false depending on whether the point lies within the coupling region or not. A weighting function weights that maps coordinates to weights is applied to the acoustic source terms. Note that this semidiscretization should be used in conjunction with EulerAcousticsCouplingCallback and only works in two dimensions.

source
Trixi.SemidiscretizationEulerGravity — Type
SemidiscretizationEulerGravity

A struct containing everything needed to describe a spatial semidiscretization of a the compressible Euler equations with self-gravity, reformulating the Poisson equation for the gravitational potential as steady-state problem of the hyperblic diffusion equations.

  • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) "A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics" arXiv: 2008.10593
source
Trixi.SemidiscretizationHyperbolic — Method
SemidiscretizationHyperbolic(mesh, equations, initial_condition, solver;
+                       solution_variables=cons2prim)

Save the current numerical solution in regular intervals. Either pass interval to save every interval time steps or pass dt to save in intervals of dt in terms of integration time by adding additional (shortened) time steps where necessary (note that this may change the solution). solution_variables can be any callable that converts the conservative variables at a single point to a set of solution variables. The first parameter passed to solution_variables will be the set of conservative variables and the second parameter is the equation struct.

source
Trixi.SemidiscretizationCoupled — Type
SemidiscretizationCoupled

A struct used to bundle multiple semidiscretizations. semidiscretize will return an ODEProblem that synchronizes time steps between the semidiscretizations. Each call of rhs! will call rhs! for each semidiscretization individually. The semidiscretizations can be coupled by gluing meshes together using BoundaryConditionCoupled.

Experimental code

This is an experimental feature and can change any time.

source
Trixi.SemidiscretizationEulerAcoustics — Type
SemidiscretizationEulerAcoustics(semi_acoustics::SemiAcoustics, semi_euler::SemiEuler;
+                                 source_region=x->true, weights=x->1.0)
Experimental code

This semidiscretization is experimental and may change in any future release.

Construct a semidiscretization of the acoustic perturbation equations that is coupled with the compressible Euler equations via source terms for the perturbed velocity. Both semidiscretizations have to use the same mesh and solvers with a shared basis. The coupling region is described by a function source_region that maps the coordinates of a single node to true or false depending on whether the point lies within the coupling region or not. A weighting function weights that maps coordinates to weights is applied to the acoustic source terms. Note that this semidiscretization should be used in conjunction with EulerAcousticsCouplingCallback and only works in two dimensions.

source
Trixi.SemidiscretizationEulerGravity — Type
SemidiscretizationEulerGravity

A struct containing everything needed to describe a spatial semidiscretization of a the compressible Euler equations with self-gravity, reformulating the Poisson equation for the gravitational potential as steady-state problem of the hyperblic diffusion equations.

  • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) "A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics" arXiv: 2008.10593
source
Trixi.SemidiscretizationHyperbolic — Method
SemidiscretizationHyperbolic(mesh, equations, initial_condition, solver;
                              source_terms=nothing,
                              boundary_conditions=boundary_condition_periodic,
                              RealT=real(solver),
                              uEltype=RealT,
-                             initial_cache=NamedTuple())

Construct a semidiscretization of a hyperbolic PDE.

source
Trixi.SemidiscretizationHyperbolicParabolic — Method
SemidiscretizationHyperbolicParabolic(mesh, both_equations, initial_condition, solver;
                                       solver_parabolic=default_parabolic_solver(),
                                       source_terms=nothing,
                                       both_boundary_conditions=(boundary_condition_periodic, boundary_condition_periodic),
                                       RealT=real(solver),
                                       uEltype=RealT,
-                                      both_initial_caches=(NamedTuple(), NamedTuple()))

Construct a semidiscretization of a hyperbolic-parabolic PDE.

source
Trixi.ShallowWaterEquations1D — Type
ShallowWaterEquations1D(; gravity, H0 = 0)

Shallow water equations (SWE) in one space dimension. The equations are given by

\[\begin{aligned} + both_initial_caches=(NamedTuple(), NamedTuple()))

Construct a semidiscretization of a hyperbolic-parabolic PDE.

source
Trixi.ShallowWaterEquations1D — Type
ShallowWaterEquations1D(; gravity, H0 = 0)

Shallow water equations (SWE) in one space dimension. The equations are given by

\[\begin{aligned} \frac{\partial h}{\partial t} + \frac{\partial}{\partial x}(h v) &= 0 \\ \frac{\partial}{\partial t}(h v) + \frac{\partial}{\partial x}\left(h v^2 + \frac{g}{2}h^2\right) + g h \frac{\partial b}{\partial x} &= 0 -\end{aligned}\]

The unknown quantities of the SWE are the water height $h$ and the velocity $v$. The gravitational constant is denoted by g and the (possibly) variable bottom topography function $b(x)$. Conservative variable water height $h$ is measured from the bottom topography $b$, therefore one also defines the total water height as $H = h + b$.

The additional quantity $H_0$ is also available to store a reference value for the total water height that is useful to set initial conditions or test the "lake-at-rest" well-balancedness.

The bottom topography function $b(x)$ is set inside the initial condition routine for a particular problem setup. To test the conservative form of the SWE one can set the bottom topography variable b to zero.

In addition to the unknowns, Trixi.jl currently stores the bottom topography values at the approximation points despite being fixed in time. This is done for convenience of computing the bottom topography gradients on the fly during the approximation as well as computing auxiliary quantities like the total water height $H$ or the entropy variables. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the bottom topography must be zero.
  • The bottom topography values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the bottom topography by default.

References for the SWE are many but a good introduction is available in Chapter 13 of the book:

source
Trixi.ShallowWaterEquations2D — Type
ShallowWaterEquations2D(; gravity, H0 = 0)

Shallow water equations (SWE) in two space dimensions. The equations are given by

\[\begin{aligned} +\end{aligned}\]

The unknown quantities of the SWE are the water height $h$ and the velocity $v$. The gravitational constant is denoted by g and the (possibly) variable bottom topography function $b(x)$. Conservative variable water height $h$ is measured from the bottom topography $b$, therefore one also defines the total water height as $H = h + b$.

The additional quantity $H_0$ is also available to store a reference value for the total water height that is useful to set initial conditions or test the "lake-at-rest" well-balancedness.

The bottom topography function $b(x)$ is set inside the initial condition routine for a particular problem setup. To test the conservative form of the SWE one can set the bottom topography variable b to zero.

In addition to the unknowns, Trixi.jl currently stores the bottom topography values at the approximation points despite being fixed in time. This is done for convenience of computing the bottom topography gradients on the fly during the approximation as well as computing auxiliary quantities like the total water height $H$ or the entropy variables. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the bottom topography must be zero.
  • The bottom topography values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the bottom topography by default.

References for the SWE are many but a good introduction is available in Chapter 13 of the book:

source
Trixi.ShallowWaterEquations2D — Type
ShallowWaterEquations2D(; gravity, H0 = 0)

Shallow water equations (SWE) in two space dimensions. The equations are given by

\[\begin{aligned} \frac{\partial h}{\partial t} + \frac{\partial}{\partial x}(h v_1) + \frac{\partial}{\partial y}(h v_2) &= 0 \\ \frac{\partial}{\partial t}(h v_1) + \frac{\partial}{\partial x}\left(h v_1^2 + \frac{g}{2}h^2\right) + \frac{\partial}{\partial y}(h v_1 v_2) + g h \frac{\partial b}{\partial x} &= 0 \\ \frac{\partial}{\partial t}(h v_2) + \frac{\partial}{\partial x}(h v_1 v_2) + \frac{\partial}{\partial y}\left(h v_2^2 + \frac{g}{2}h^2\right) + g h \frac{\partial b}{\partial y} &= 0. -\end{aligned}\]

The unknown quantities of the SWE are the water height $h$ and the velocities $\mathbf{v} = (v_1, v_2)^T$. The gravitational constant is denoted by g and the (possibly) variable bottom topography function $b(x,y)$. Conservative variable water height $h$ is measured from the bottom topography $b$, therefore one also defines the total water height as $H = h + b$.

The additional quantity $H_0$ is also available to store a reference value for the total water height that is useful to set initial conditions or test the "lake-at-rest" well-balancedness.

The bottom topography function $b(x,y)$ is set inside the initial condition routine for a particular problem setup. To test the conservative form of the SWE one can set the bottom topography variable b to zero.

In addition to the unknowns, Trixi.jl currently stores the bottom topography values at the approximation points despite being fixed in time. This is done for convenience of computing the bottom topography gradients on the fly during the approximation as well as computing auxiliary quantities like the total water height $H$ or the entropy variables. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the bottom topography must be zero.
  • The bottom topography values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the bottom topography by default.

References for the SWE are many but a good introduction is available in Chapter 13 of the book:

source
Trixi.ShallowWaterEquationsQuasi1D — Type
ShallowWaterEquationsQuasi1D(; gravity, H0 = 0, threshold_limiter = nothing threshold_wet = nothing)

The quasi-1D shallow water equations (SWE). The equations are given by

\[\begin{aligned} +\end{aligned}\]

The unknown quantities of the SWE are the water height $h$ and the velocities $\mathbf{v} = (v_1, v_2)^T$. The gravitational constant is denoted by g and the (possibly) variable bottom topography function $b(x,y)$. Conservative variable water height $h$ is measured from the bottom topography $b$, therefore one also defines the total water height as $H = h + b$.

The additional quantity $H_0$ is also available to store a reference value for the total water height that is useful to set initial conditions or test the "lake-at-rest" well-balancedness.

The bottom topography function $b(x,y)$ is set inside the initial condition routine for a particular problem setup. To test the conservative form of the SWE one can set the bottom topography variable b to zero.

In addition to the unknowns, Trixi.jl currently stores the bottom topography values at the approximation points despite being fixed in time. This is done for convenience of computing the bottom topography gradients on the fly during the approximation as well as computing auxiliary quantities like the total water height $H$ or the entropy variables. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the bottom topography must be zero.
  • The bottom topography values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the bottom topography by default.

References for the SWE are many but a good introduction is available in Chapter 13 of the book:

source
Trixi.ShallowWaterEquationsQuasi1D — Type
ShallowWaterEquationsQuasi1D(; gravity, H0 = 0, threshold_limiter = nothing threshold_wet = nothing)

The quasi-1D shallow water equations (SWE). The equations are given by

\[\begin{aligned} \frac{\partial}{\partial t}(a h) + \frac{\partial}{\partial x}(a h v) &= 0 \\ \frac{\partial}{\partial t}(a h v) + \frac{\partial}{\partial x}(a h v^2) + g a h \frac{\partial}{\partial x}(h + b) &= 0 -\end{aligned}\]

The unknown quantities of the Quasi-1D SWE are the water height $h$ and the scaled velocity $v$. The gravitational constant is denoted by g, the (possibly) variable bottom topography function $b(x)$, and (possibly) variable channel width $a(x)$. The water height $h$ is measured from the bottom topography $b$, therefore one also defines the total water height as $H = h + b$.

The additional quantity $H_0$ is also available to store a reference value for the total water height that is useful to set initial conditions or test the "lake-at-rest" well-balancedness.

The bottom topography function $b(x)$ and channel width $a(x)$ are set inside the initial condition routine for a particular problem setup. To test the conservative form of the SWE one can set the bottom topography variable b to zero and $a$ to one.

In addition to the unknowns, Trixi.jl currently stores the bottom topography and channel width values at the approximation points despite being fixed in time. This is done for convenience of computing the bottom topography gradients on the fly during the approximation as well as computing auxiliary quantities like the total water height $H$ or the entropy variables. This affects the implementation and use of these equations in various ways:

  • The flux values corresponding to the bottom topography and channel width must be zero.
  • The bottom topography and channel width values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the bottom topography and channel width by default.
source
Trixi.SimpleSSPRK33 — Type
SimpleSSPRK33(; stage_callbacks=())

The third-order SSP Runge-Kutta method of Shu and Osher.

References

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.StepsizeCallback — Type
StepsizeCallback(; cfl=1.0)

Set the time step size according to a CFL condition with CFL number cfl if the time integration method isn't adaptive itself.

source
Trixi.StructuredMesh — Type
StructuredMesh{NDIMS} <: AbstractMesh{NDIMS}

A structured curved mesh.

Different numbers of cells per dimension are possible and arbitrary functions can be used as domain faces.

source
Trixi.StructuredMesh — Method
StructuredMesh(cells_per_dimension, coordinates_min, coordinates_max; periodicity=true)

Create a StructuredMesh that represents a uncurved structured mesh with a rectangular domain.

Arguments

  • cells_per_dimension::NTuple{NDIMS, Int}: the number of cells in each dimension.
  • coordinates_min::NTuple{NDIMS, RealT}: coordinate of the corner in the negative direction of each dimension.
  • coordinates_max::NTuple{NDIMS, RealT}: coordinate of the corner in the positive direction of each dimension.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
source
Trixi.StructuredMesh — Method
StructuredMesh(cells_per_dimension, mapping; RealT=Float64, unsaved_changes=true, mapping_as_string=mapping2string(mapping, length(cells_per_dimension)))

Create a StructuredMesh of the given size and shape that uses RealT as coordinate type.

Arguments

  • cells_per_dimension::NTupleE{NDIMS, Int}: the number of cells in each dimension.
  • mapping: a function of NDIMS variables to describe the mapping, which transforms the reference mesh to the physical domain. If no mapping_as_string is defined, this function must be defined with the name mapping to allow for restarts. This will be changed in the future, see https://github.com/trixi-framework/Trixi.jl/issues/541.
  • RealT::Type: the type that should be used for coordinates.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • mapping_as_string::String: the code that defines the mapping. If CodeTracking can't find the function definition, it can be passed directly here. The code string must define the mapping function with the name mapping. This will be changed in the future, see https://github.com/trixi-framework/Trixi.jl/issues/541.
source
Trixi.StructuredMesh — Method
StructuredMesh(cells_per_dimension, faces; RealT=Float64, unsaved_changes=true, faces_as_string=faces2string(faces))

Create a StructuredMesh of the given size and shape that uses RealT as coordinate type.

Arguments

  • cells_per_dimension::NTupleE{NDIMS, Int}: the number of cells in each dimension.
  • faces::NTuple{2*NDIMS}: a tuple of 2 * NDIMS functions that describe the faces of the domain. Each function must take NDIMS-1 arguments. faces[1] describes the face onto which the face in negative x-direction of the unit hypercube is mapped. The face in positive x-direction of the unit hypercube will be mapped onto the face described by faces[2]. faces[3:4] describe the faces in positive and negative y-direction respectively (in 2D and 3D). faces[5:6] describe the faces in positive and negative z-direction respectively (in 3D).
  • RealT::Type: the type that should be used for coordinates.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
source
Trixi.SubcellLimiterIDP — Type
SubcellLimiterIDP(equations::AbstractEquations, basis;
+\end{aligned}\]
The unknown quantities of the Quasi-1D SWE are the water height $h$ and the scaled velocity $v$. The gravitational constant is denoted by g, the (possibly) variable bottom topography function $b(x)$, and (possibly) variable channel width $a(x)$. The water height $h$ is measured from the bottom topography $b$, therefore one also defines the total water height as $H = h + b$.
The additional quantity $H_0$ is also available to store a reference value for the total water height that is useful to set initial conditions or test the "lake-at-rest" well-balancedness.
The bottom topography function $b(x)$ and channel width $a(x)$ are set inside the initial condition routine for a particular problem setup. To test the conservative form of the SWE one can set the bottom topography variable b to zero and $a$ to one. 
In addition to the unknowns, Trixi.jl currently stores the bottom topography and channel width values at the approximation points  despite being fixed in time. This is done for convenience of computing the bottom topography gradients on the fly during the approximation as well as computing auxiliary quantities like the total water height $H$ or the entropy variables. This affects the implementation and use of these equations in various ways:
  • The flux values corresponding to the bottom topography and channel width must be zero.
  • The bottom topography and channel width values must be included when defining initial conditions, boundary conditions or source terms.
  • AnalysisCallback analyzes this variable.
  • Trixi.jl's visualization tools will visualize the bottom topography and channel width by default.
source
Trixi.SimpleSSPRK33 — Type
SimpleSSPRK33(; stage_callbacks=())

The third-order SSP Runge-Kutta method of Shu and Osher.

References

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.StepsizeCallback — Type
StepsizeCallback(; cfl=1.0)

Set the time step size according to a CFL condition with CFL number cfl if the time integration method isn't adaptive itself.

source
Trixi.StructuredMesh — Type
StructuredMesh{NDIMS} <: AbstractMesh{NDIMS}

A structured curved mesh.

Different numbers of cells per dimension are possible and arbitrary functions can be used as domain faces.

source
Trixi.StructuredMesh — Method
StructuredMesh(cells_per_dimension, coordinates_min, coordinates_max; periodicity=true)

Create a StructuredMesh that represents a uncurved structured mesh with a rectangular domain.

Arguments

  • cells_per_dimension::NTuple{NDIMS, Int}: the number of cells in each dimension.
  • coordinates_min::NTuple{NDIMS, RealT}: coordinate of the corner in the negative direction of each dimension.
  • coordinates_max::NTuple{NDIMS, RealT}: coordinate of the corner in the positive direction of each dimension.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
source
Trixi.StructuredMesh — Method
StructuredMesh(cells_per_dimension, mapping; RealT=Float64, unsaved_changes=true, mapping_as_string=mapping2string(mapping, length(cells_per_dimension)))

Create a StructuredMesh of the given size and shape that uses RealT as coordinate type.

Arguments

  • cells_per_dimension::NTupleE{NDIMS, Int}: the number of cells in each dimension.
  • mapping: a function of NDIMS variables to describe the mapping, which transforms the reference mesh to the physical domain. If no mapping_as_string is defined, this function must be defined with the name mapping to allow for restarts. This will be changed in the future, see https://github.com/trixi-framework/Trixi.jl/issues/541.
  • RealT::Type: the type that should be used for coordinates.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • mapping_as_string::String: the code that defines the mapping. If CodeTracking can't find the function definition, it can be passed directly here. The code string must define the mapping function with the name mapping. This will be changed in the future, see https://github.com/trixi-framework/Trixi.jl/issues/541.
source
Trixi.StructuredMesh — Method
StructuredMesh(cells_per_dimension, faces; RealT=Float64, unsaved_changes=true, faces_as_string=faces2string(faces))

Create a StructuredMesh of the given size and shape that uses RealT as coordinate type.

Arguments

  • cells_per_dimension::NTupleE{NDIMS, Int}: the number of cells in each dimension.
  • faces::NTuple{2*NDIMS}: a tuple of 2 * NDIMS functions that describe the faces of the domain. Each function must take NDIMS-1 arguments. faces[1] describes the face onto which the face in negative x-direction of the unit hypercube is mapped. The face in positive x-direction of the unit hypercube will be mapped onto the face described by faces[2]. faces[3:4] describe the faces in positive and negative y-direction respectively (in 2D and 3D). faces[5:6] describe the faces in positive and negative z-direction respectively (in 3D).
  • RealT::Type: the type that should be used for coordinates.
  • periodicity: either a Bool deciding if all of the boundaries are periodic or an NTuple{NDIMS, Bool} deciding for each dimension if the boundaries in this dimension are periodic.
source
Trixi.SubcellLimiterIDP — Type
SubcellLimiterIDP(equations::AbstractEquations, basis;
                   local_minmax_variables_cons = String[],
                   positivity_variables_cons = String[],
                   positivity_variables_nonlinear = [],
                   positivity_correction_factor = 0.1,
                   max_iterations_newton = 10,
                   newton_tolerances = (1.0e-12, 1.0e-14),
-                  gamma_constant_newton = 2 * ndims(equations))

Subcell invariant domain preserving (IDP) limiting used with VolumeIntegralSubcellLimiting including:

  • Local maximum/minimum Zalesak-type limiting for conservative variables (local_minmax_variables_cons)
  • Positivity limiting for conservative variables (positivity_variables_cons) and nonlinear variables

(positivity_variables_nonlinear)

Conservative variables to be limited are passed as a vector of strings, e.g. local_minmax_variables_cons = ["rho"] and positivity_variables_cons = ["rho"]. For nonlinear variables the specific functions are passed in a vector, e.g. positivity_variables_nonlinear = [pressure].

The bounds are calculated using the low-order FV solution. The positivity limiter uses positivity_correction_factor such that u^new >= positivity_correction_factor * u^FV. The limiting of nonlinear variables uses a Newton-bisection method with a maximum of max_iterations_newton iterations, relative and absolute tolerances of newton_tolerances and a provisional update constant gamma_constant_newton (gamma_constant_newton>=2*d, where d = #dimensions). See equation (20) of Pazner (2020) and equation (30) of Rueda-Ramírez et al. (2022).

Note

This limiter and the correction callback SubcellLimiterIDPCorrection only work together. Without the callback, no correction takes place, leading to a standard low-order FV scheme.

References

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.SubcellLimiterIDPCorrection — Type
SubcellLimiterIDPCorrection()

Perform antidiffusive correction stage for the a posteriori IDP limiter SubcellLimiterIDP called with VolumeIntegralSubcellLimiting.

Note

This callback and the actual limiter SubcellLimiterIDP only work together. This is not a replacement but a necessary addition.

References

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.SurfaceIntegralWeakForm — Type
SurfaceIntegralWeakForm(surface_flux=flux_central)

The classical weak form surface integral type for DG methods as explained in standard textbooks.

See also VolumeIntegralWeakForm.

References

source
Trixi.T8codeMesh — Type
T8codeMesh{NDIMS} <: AbstractMesh{NDIMS}

An unstructured curved mesh based on trees that uses the C library 't8code' to manage trees and mesh refinement.

source
Trixi.T8codeMesh — Method
T8codeMesh(trees_per_dimension; polydeg, mapping=identity,
-           RealT=Float64, initial_refinement_level=0, periodicity=true)

Create a structured potentially curved 'T8codeMesh' of the specified size.

Non-periodic boundaries will be called ':xneg', ':xpos', ':yneg', ':ypos', ':zneg', ':zpos'.

Arguments

  • 'treesperdimension::NTupleE{NDIMS, Int}': the number of trees in each dimension.
  • 'polydeg::Integer': polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the reference mesh ([-1, 1]^n) to the physical domain. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • faces::NTuple{2*NDIMS}: a tuple of 2 * NDIMS functions that describe the faces of the domain. Each function must take NDIMS-1 arguments. faces[1] describes the face onto which the face in negative x-direction of the unit hypercube is mapped. The face in positive x-direction of the unit hypercube will be mapped onto the face described by faces[2]. faces[3:4] describe the faces in positive and negative y-direction respectively (in 2D and 3D). faces[5:6] describe the faces in positive and negative z-direction respectively (in 3D). Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_min: vector or tuple of the coordinates of the corner in the negative direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_max: vector or tuple of the coordinates of the corner in the positive direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • 'RealT::Type': the type that should be used for coordinates.
  • 'initialrefinementlevel::Integer': refine the mesh uniformly to this level before the simulation starts.
  • 'periodicity': either a 'Bool' deciding if all of the boundaries are periodic or an 'NTuple{NDIMS, Bool}' deciding for each dimension if the boundaries in this dimension are periodic.
source
Trixi.T8codeMesh — Method
T8codeMesh(conn::Ptr{p4est_connectivity}; kwargs...)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a p4est_connectivity data structure.

Arguments

  • conn::Ptr{p4est_connectivity}: Pointer to a P4est connectivity object.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.T8codeMesh — Method
T8codeMesh(conn::Ptr{p8est_connectivity}; kwargs...)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a p4est_connectivity data structure.

Arguments

  • conn::Ptr{p4est_connectivity}: Pointer to a P4est connectivity object.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.T8codeMesh — Method
T8codeMesh(cmesh::Ptr{t8_cmesh},
+                  gamma_constant_newton = 2 * ndims(equations))

Subcell invariant domain preserving (IDP) limiting used with VolumeIntegralSubcellLimiting including:

  • Local maximum/minimum Zalesak-type limiting for conservative variables (local_minmax_variables_cons)
  • Positivity limiting for conservative variables (positivity_variables_cons) and nonlinear variables

(positivity_variables_nonlinear)

Conservative variables to be limited are passed as a vector of strings, e.g. local_minmax_variables_cons = ["rho"] and positivity_variables_cons = ["rho"]. For nonlinear variables the specific functions are passed in a vector, e.g. positivity_variables_nonlinear = [pressure].

The bounds are calculated using the low-order FV solution. The positivity limiter uses positivity_correction_factor such that u^new >= positivity_correction_factor * u^FV. The limiting of nonlinear variables uses a Newton-bisection method with a maximum of max_iterations_newton iterations, relative and absolute tolerances of newton_tolerances and a provisional update constant gamma_constant_newton (gamma_constant_newton>=2*d, where d = #dimensions). See equation (20) of Pazner (2020) and equation (30) of Rueda-Ramírez et al. (2022).

Note

This limiter and the correction callback SubcellLimiterIDPCorrection only work together. Without the callback, no correction takes place, leading to a standard low-order FV scheme.

References

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.SubcellLimiterIDPCorrection — Type
SubcellLimiterIDPCorrection()

Perform antidiffusive correction stage for the a posteriori IDP limiter SubcellLimiterIDP called with VolumeIntegralSubcellLimiting.

Note

This callback and the actual limiter SubcellLimiterIDP only work together. This is not a replacement but a necessary addition.

References

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.SurfaceIntegralWeakForm — Type
SurfaceIntegralWeakForm(surface_flux=flux_central)

The classical weak form surface integral type for DG methods as explained in standard textbooks.

See also VolumeIntegralWeakForm.

References

source
Trixi.T8codeMesh — Type
T8codeMesh{NDIMS} <: AbstractMesh{NDIMS}

An unstructured curved mesh based on trees that uses the C library 't8code' to manage trees and mesh refinement.

source
Trixi.T8codeMesh — Method
T8codeMesh(trees_per_dimension; polydeg, mapping=identity,
+           RealT=Float64, initial_refinement_level=0, periodicity=true)

Create a structured potentially curved 'T8codeMesh' of the specified size.

Non-periodic boundaries will be called ':xneg', ':xpos', ':yneg', ':ypos', ':zneg', ':zpos'.

Arguments

  • 'treesperdimension::NTupleE{NDIMS, Int}': the number of trees in each dimension.
  • 'polydeg::Integer': polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the reference mesh ([-1, 1]^n) to the physical domain. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • faces::NTuple{2*NDIMS}: a tuple of 2 * NDIMS functions that describe the faces of the domain. Each function must take NDIMS-1 arguments. faces[1] describes the face onto which the face in negative x-direction of the unit hypercube is mapped. The face in positive x-direction of the unit hypercube will be mapped onto the face described by faces[2]. faces[3:4] describe the faces in positive and negative y-direction respectively (in 2D and 3D). faces[5:6] describe the faces in positive and negative z-direction respectively (in 3D). Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_min: vector or tuple of the coordinates of the corner in the negative direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • coordinates_max: vector or tuple of the coordinates of the corner in the positive direction of each dimension to create a rectangular mesh. Use only one of mapping, faces and coordinates_min/coordinates_max.
  • 'RealT::Type': the type that should be used for coordinates.
  • 'initialrefinementlevel::Integer': refine the mesh uniformly to this level before the simulation starts.
  • 'periodicity': either a 'Bool' deciding if all of the boundaries are periodic or an 'NTuple{NDIMS, Bool}' deciding for each dimension if the boundaries in this dimension are periodic.
source
Trixi.T8codeMesh — Method
T8codeMesh(conn::Ptr{p4est_connectivity}; kwargs...)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a p4est_connectivity data structure.

Arguments

  • conn::Ptr{p4est_connectivity}: Pointer to a P4est connectivity object.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.T8codeMesh — Method
T8codeMesh(conn::Ptr{p8est_connectivity}; kwargs...)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a p4est_connectivity data structure.

Arguments

  • conn::Ptr{p4est_connectivity}: Pointer to a P4est connectivity object.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.T8codeMesh — Method
T8codeMesh(cmesh::Ptr{t8_cmesh},
            mapping=nothing, polydeg=1, RealT=Float64,
-           initial_refinement_level=0)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a t8_cmesh data structure.

Arguments

  • cmesh::Ptr{t8_cmesh}: Pointer to a cmesh object.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.T8codeMesh — Method
T8codeMesh(meshfile::String, ndims; kwargs...)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a Gmsh mesh file (.msh).

Arguments

  • meshfile::String: path to a Gmsh mesh file.
  • ndims: Mesh file dimension: 2 or 3.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.TimeSeriesCallback — Type
TimeSeriesCallback(semi, point_coordinates;
+           initial_refinement_level=0)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a t8_cmesh data structure.

Arguments

  • cmesh::Ptr{t8_cmesh}: Pointer to a cmesh object.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.T8codeMesh — Method
T8codeMesh(meshfile::String, ndims; kwargs...)

Main mesh constructor for the T8codeMesh that imports an unstructured, conforming mesh from a Gmsh mesh file (.msh).

Arguments

  • meshfile::String: path to a Gmsh mesh file.
  • ndims: Mesh file dimension: 2 or 3.
  • mapping: a function of NDIMS variables to describe the mapping that transforms the imported mesh to the physical domain. Use nothing for the identity map.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree. The default of 1 creates an uncurved geometry. Use a higher value if the mapping will curve the imported uncurved mesh.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
source
Trixi.TimeSeriesCallback — Type
TimeSeriesCallback(semi, point_coordinates;
                    interval=1, solution_variables=cons2cons,
                    output_directory="out", filename="time_series.h5",
-                   RealT=real(solver), uEltype=eltype(cache.elements))

Create a callback that records point-wise data at points given in point_coordinates every interval time steps. The point coordinates are to be specified either as a vector of coordinate tuples or as a two-dimensional array where the first dimension is the point number and the second dimension is the coordinate dimension. By default, the conservative variables are recorded, but this can be controlled by passing a different conversion function to solution_variables.

After the last time step, the results are stored in an HDF5 file filename in directory output_directory.

The real data type RealT and data type for solution variables uEltype default to the respective types used in the solver and the cache.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.TrafficFlowLWREquations1D — Type
TrafficFlowLWREquations1D

The classic Lighthill-Witham Richards (LWR) model for 1D traffic flow. The car density is denoted by $u \in [0, 1]$ and the maximum possible speed (e.g. due to speed limits) is $v_{\text{max}}$.

\[\partial_t u + v_{\text{max}} \partial_1 [u (1 - u)] = 0\]

For more details see e.g. Section 11.1 of

  • Randall LeVeque (2002)

Finite Volume Methods for Hyperbolic Problems [DOI: 10.1017/CBO9780511791253]https://doi.org/10.1017/CBO9780511791253

source
Trixi.TreeMesh — Type
TreeMesh{NDIMS} <: AbstractMesh{NDIMS}

A Cartesian mesh based on trees of hypercubes to support adaptive mesh refinement.

source
Trixi.UnstructuredMesh2D — Type
UnstructuredMesh2D <: AbstractMesh{2}

An unstructured (possibly curved) quadrilateral mesh.

UnstructuredMesh2D(filename; RealT=Float64, periodicity=false)

All mesh information, neighbour coupling, and boundary curve information is read in from a mesh file filename.

source
Trixi.UnstructuredSortedBoundaryTypes — Type
UnstructuredSortedBoundaryTypes

General container to sort the boundary conditions by type for some unstructured meshes/solvers. It stores a set of global indices for each boundary condition type to expedite computation during the call to calc_boundary_flux!. The original dictionary form of the boundary conditions set by the user in the elixir file is also stored for printing.

source
Trixi.ViscousFormulationLocalDG — Type
ViscousFormulationLocalDG(penalty_parameter)

The local DG (LDG) flux from "The Local Discontinuous Galerkin Method for Time-Dependent Convection-Diffusion Systems" by Cockburn and Shu (1998).

Note that, since this implementation does not involve the parabolic "upwinding" vector, the LDG solver is equivalent to ViscousFormulationBassiRebay1 with an LDG-type penalization.

source
Trixi.VisualizationCallback — Method
VisualizationCallback(; interval=0,
+                   RealT=real(solver), uEltype=eltype(cache.elements))

Create a callback that records point-wise data at points given in point_coordinates every interval time steps. The point coordinates are to be specified either as a vector of coordinate tuples or as a two-dimensional array where the first dimension is the point number and the second dimension is the coordinate dimension. By default, the conservative variables are recorded, but this can be controlled by passing a different conversion function to solution_variables.

After the last time step, the results are stored in an HDF5 file filename in directory output_directory.

The real data type RealT and data type for solution variables uEltype default to the respective types used in the solver and the cache.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.TrafficFlowLWREquations1D — Type
TrafficFlowLWREquations1D

The classic Lighthill-Witham Richards (LWR) model for 1D traffic flow. The car density is denoted by $u \in [0, 1]$ and the maximum possible speed (e.g. due to speed limits) is $v_{\text{max}}$.

\[\partial_t u + v_{\text{max}} \partial_1 [u (1 - u)] = 0\]

For more details see e.g. Section 11.1 of

  • Randall LeVeque (2002)

Finite Volume Methods for Hyperbolic Problems [DOI: 10.1017/CBO9780511791253]https://doi.org/10.1017/CBO9780511791253

source
Trixi.TreeMesh — Type
TreeMesh{NDIMS} <: AbstractMesh{NDIMS}

A Cartesian mesh based on trees of hypercubes to support adaptive mesh refinement.

source
Trixi.UnstructuredMesh2D — Type
UnstructuredMesh2D <: AbstractMesh{2}

An unstructured (possibly curved) quadrilateral mesh.

UnstructuredMesh2D(filename; RealT=Float64, periodicity=false)

All mesh information, neighbour coupling, and boundary curve information is read in from a mesh file filename.

source
Trixi.UnstructuredSortedBoundaryTypes — Type
UnstructuredSortedBoundaryTypes

General container to sort the boundary conditions by type for some unstructured meshes/solvers. It stores a set of global indices for each boundary condition type to expedite computation during the call to calc_boundary_flux!. The original dictionary form of the boundary conditions set by the user in the elixir file is also stored for printing.

source
Trixi.ViscousFormulationLocalDG — Type
ViscousFormulationLocalDG(penalty_parameter)

The local DG (LDG) flux from "The Local Discontinuous Galerkin Method for Time-Dependent Convection-Diffusion Systems" by Cockburn and Shu (1998).

Note that, since this implementation does not involve the parabolic "upwinding" vector, the LDG solver is equivalent to ViscousFormulationBassiRebay1 with an LDG-type penalization.

source
Trixi.VisualizationCallback — Method
VisualizationCallback(; interval=0,
                         solution_variables=cons2prim,
                         variable_names=[],
                         show_mesh=false,
                         plot_data_creator=PlotData2D,
                         plot_creator=show_plot,
-                        plot_arguments...)

Create a callback that visualizes results during a simulation, also known as in-situ visualization.

Experimental implementation

This is an experimental feature and may change in any future releases.

The interval specifies the number of time step iterations after which a new plot is generated. The available variables to plot are configured with the solution_variables parameter, which acts the same way as for the SaveSolutionCallback. The variables to be actually plotted can be selected by providing a single string or a list of strings to variable_names, and if show_mesh is true, an additional plot with the mesh will be generated.

To customize the generated figure, plot_data_creator allows to use different plot data types. With plot_creator you can further specify an own function to visualize results, which must support the same interface as the default implementation show_plot. All remaining keyword arguments are collected and passed as additional arguments to the plotting command.

source
Trixi.VolumeIntegralFluxDifferencing — Type
VolumeIntegralFluxDifferencing(volume_flux)

Volume integral type for DG methods based on SBP operators and flux differencing using a symmetric two-point volume_flux. This volume_flux needs to satisfy the interface of numerical fluxes in Trixi.jl.

References

source
Trixi.VolumeIntegralPureLGLFiniteVolume — Type
VolumeIntegralPureLGLFiniteVolume(volume_flux_fv)

A volume integral that only uses the subcell finite volume schemes of the VolumeIntegralShockCapturingHG.

This gives a formally O(1)-accurate finite volume scheme on an LGL-type subcell mesh (LGL = Legendre-Gauss-Lobatto).

Experimental implementation

This is an experimental feature and may change in future releases.

References

  • Hennemann, Gassner (2020) "A provably entropy stable subcell shock capturing approach for high order split form DG" arXiv: 2008.12044
source
Trixi.VolumeIntegralShockCapturingHG — Type
VolumeIntegralShockCapturingHG(indicator; volume_flux_dg=flux_central,
-                                          volume_flux_fv=flux_lax_friedrichs)

Shock-capturing volume integral type for DG methods using a convex blending of the finite volume method with numerical flux volume_flux_fv and the VolumeIntegralFluxDifferencing with volume flux volume_flux_dg. The amount of blending is determined by the indicator, e.g., IndicatorHennemannGassner.

References

  • Hennemann, Gassner (2020) "A provably entropy stable subcell shock capturing approach for high order split form DG" arXiv: 2008.12044
source
Trixi.VolumeIntegralSubcellLimiting — Type
VolumeIntegralSubcellLimiting(limiter;
-                              volume_flux_dg, volume_flux_fv)

A subcell limiting volume integral type for DG methods based on subcell blending approaches with a low-order FV method. Used with limiter SubcellLimiterIDP.

Note

Subcell limiting methods are not fully functional on non-conforming meshes. This is mainly because the implementation assumes that low- and high-order schemes have the same surface terms, which is not guaranteed for non-conforming meshes. The low-order scheme with a high-order mortar is not invariant domain preserving.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.VolumeIntegralUpwind — Type
VolumeIntegralUpwind(splitting)

Specialized volume integral for finite difference summation-by-parts (FDSBP) solvers. Can be used together with the upwind SBP operators of Mattsson (2017) implemented in SummationByPartsOperators.jl. The splitting controls the discretization.

See also splitting_steger_warming, splitting_lax_friedrichs, splitting_vanleer_haenel.

References

Experimental implementation (upwind SBP)

This is an experimental feature and may change in future releases.

source
Trixi.VolumeIntegralWeakForm — Type
VolumeIntegralWeakForm()

The classical weak form volume integral type for DG methods as explained in standard textbooks.

References

VolumeIntegralWeakForm() is only implemented for conserved terms as non-conservative terms should always be discretized in conjunction with a flux-splitting scheme, see VolumeIntegralFluxDifferencing. This treatment is required to achieve, e.g., entropy-stability or well-balancedness.

source
Base.getindex — Method
Base.getindex(pd::AbstractPlotData, variable_name)

Extract a single variable variable_name from pd for plotting with Plots.plot.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Base.resize! — Method
resize!(c::AbstractContainer, new_length) -> AbstractContainer

Resize c to contain new_length elements. If new_length is smaller than the current container length, the first new_length elements will be retained. If new_length is larger, the new elements are invalidated.

source
PolynomialBases.compute_coefficients — Method
compute_coefficients(func, t, semi::AbstractSemidiscretization)

Compute the discrete coefficients of the continuous function func at time t associated with the semidiscretization semi. For example, the discrete coefficients of func for a discontinuous Galerkin spectral element method (DGSEM) are the values of func at the Lobatto-Legendre nodes. Similarly, a classical finite difference method will use the values of func at the nodes of the grid assoociated with the semidiscretization semi.

For semidiscretizations semi associated with an initial condition, func can be omitted to use the given initial condition at time t.

source
PolynomialBases.integrate — Method
integrate(f, u, basis::LobattoLegendreBasis)

Map the function f to the coefficients u and integrate with respect to the quadrature rule given by basis.

source
PolynomialBases.integrate — Method
integrate([func=(u_node,equations)->u_node,] u_ode, semi::AbstractSemidiscretization; normalize=true)

Call func(u_node, equations) for each vector of nodal variables u_node in u_ode and integrate the result using a quadrature associated with the semidiscretization semi.

If normalize is true, the result is divided by the total volume of the computational domain.

source
SciMLBase.add_tstop! — Method
add_tstop!(integrator::SimpleIntegratorSSP, t)

Add a time stop during the time integration process. This function is called after the periodic SaveSolutionCallback to specify the next stop to save the solution.

source
SummationByPartsOperators.semidiscretize — Method
semidiscretize(semi::SemidiscretizationHyperbolicParabolic, tspan)

Wrap the semidiscretization semi as a split ODE problem in the time interval tspan that can be passed to solve from the SciML ecosystem. The parabolic right-hand side is the first function of the split ODE problem and will be used by default by the implicit part of IMEX methods from the SciML ecosystem.

source
SummationByPartsOperators.semidiscretize — Method
semidiscretize(semi::AbstractSemidiscretization, tspan, restart_file::AbstractString)

Wrap the semidiscretization semi as an ODE problem in the time interval tspan that can be passed to solve from the SciML ecosystem. The initial condition etc. is taken from the restart_file.

source
Trixi.DGMultiBasis — Method
DGMultiBasis(element_type, polydeg; approximation_type = Polynomial(), kwargs...)

Constructs a basis for DGMulti solvers. Returns a "StartUpDG.RefElemData" object. The kwargs arguments are additional keyword arguments for RefElemData, such as quad_rule_vol. These are the same as the RefElemData_kwargs used in DGMulti. For more info, see the StartUpDG.jl docs.

source
Trixi.P4estMeshCubedSphere — Method
P4estMeshCubedSphere(trees_per_face_dimension, layers, inner_radius, thickness;
+                        plot_arguments...)

Create a callback that visualizes results during a simulation, also known as in-situ visualization.

Experimental implementation

This is an experimental feature and may change in any future releases.

The interval specifies the number of time step iterations after which a new plot is generated. The available variables to plot are configured with the solution_variables parameter, which acts the same way as for the SaveSolutionCallback. The variables to be actually plotted can be selected by providing a single string or a list of strings to variable_names, and if show_mesh is true, an additional plot with the mesh will be generated.

To customize the generated figure, plot_data_creator allows to use different plot data types. With plot_creator you can further specify an own function to visualize results, which must support the same interface as the default implementation show_plot. All remaining keyword arguments are collected and passed as additional arguments to the plotting command.

source
Trixi.VolumeIntegralFluxDifferencing — Type
VolumeIntegralFluxDifferencing(volume_flux)

Volume integral type for DG methods based on SBP operators and flux differencing using a symmetric two-point volume_flux. This volume_flux needs to satisfy the interface of numerical fluxes in Trixi.jl.

References

source
Trixi.VolumeIntegralPureLGLFiniteVolume — Type
VolumeIntegralPureLGLFiniteVolume(volume_flux_fv)

A volume integral that only uses the subcell finite volume schemes of the VolumeIntegralShockCapturingHG.

This gives a formally O(1)-accurate finite volume scheme on an LGL-type subcell mesh (LGL = Legendre-Gauss-Lobatto).

Experimental implementation

This is an experimental feature and may change in future releases.

References

  • Hennemann, Gassner (2020) "A provably entropy stable subcell shock capturing approach for high order split form DG" arXiv: 2008.12044
source
Trixi.VolumeIntegralShockCapturingHG — Type
VolumeIntegralShockCapturingHG(indicator; volume_flux_dg=flux_central,
+                                          volume_flux_fv=flux_lax_friedrichs)

Shock-capturing volume integral type for DG methods using a convex blending of the finite volume method with numerical flux volume_flux_fv and the VolumeIntegralFluxDifferencing with volume flux volume_flux_dg. The amount of blending is determined by the indicator, e.g., IndicatorHennemannGassner.

References

  • Hennemann, Gassner (2020) "A provably entropy stable subcell shock capturing approach for high order split form DG" arXiv: 2008.12044
source
Trixi.VolumeIntegralSubcellLimiting — Type
VolumeIntegralSubcellLimiting(limiter;
+                              volume_flux_dg, volume_flux_fv)

A subcell limiting volume integral type for DG methods based on subcell blending approaches with a low-order FV method. Used with limiter SubcellLimiterIDP.

Note

Subcell limiting methods are not fully functional on non-conforming meshes. This is mainly because the implementation assumes that low- and high-order schemes have the same surface terms, which is not guaranteed for non-conforming meshes. The low-order scheme with a high-order mortar is not invariant domain preserving.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.VolumeIntegralUpwind — Type
VolumeIntegralUpwind(splitting)

Specialized volume integral for finite difference summation-by-parts (FDSBP) solvers. Can be used together with the upwind SBP operators of Mattsson (2017) implemented in SummationByPartsOperators.jl. The splitting controls the discretization.

See also splitting_steger_warming, splitting_lax_friedrichs, splitting_vanleer_haenel.

References

Experimental implementation (upwind SBP)

This is an experimental feature and may change in future releases.

source
Trixi.VolumeIntegralWeakForm — Type
VolumeIntegralWeakForm()

The classical weak form volume integral type for DG methods as explained in standard textbooks.

References

VolumeIntegralWeakForm() is only implemented for conserved terms as non-conservative terms should always be discretized in conjunction with a flux-splitting scheme, see VolumeIntegralFluxDifferencing. This treatment is required to achieve, e.g., entropy-stability or well-balancedness.

source
Base.getindex — Method
Base.getindex(pd::AbstractPlotData, variable_name)

Extract a single variable variable_name from pd for plotting with Plots.plot.

Experimental implementation

This is an experimental feature and may change in future releases.

source
Base.resize! — Method
resize!(c::AbstractContainer, new_length) -> AbstractContainer

Resize c to contain new_length elements. If new_length is smaller than the current container length, the first new_length elements will be retained. If new_length is larger, the new elements are invalidated.

source
PolynomialBases.compute_coefficients — Method
compute_coefficients(func, t, semi::AbstractSemidiscretization)

Compute the discrete coefficients of the continuous function func at time t associated with the semidiscretization semi. For example, the discrete coefficients of func for a discontinuous Galerkin spectral element method (DGSEM) are the values of func at the Lobatto-Legendre nodes. Similarly, a classical finite difference method will use the values of func at the nodes of the grid assoociated with the semidiscretization semi.

For semidiscretizations semi associated with an initial condition, func can be omitted to use the given initial condition at time t.

source
PolynomialBases.integrate — Method
integrate(f, u, basis::LobattoLegendreBasis)

Map the function f to the coefficients u and integrate with respect to the quadrature rule given by basis.

source
PolynomialBases.integrate — Method
integrate([func=(u_node,equations)->u_node,] u_ode, semi::AbstractSemidiscretization; normalize=true)

Call func(u_node, equations) for each vector of nodal variables u_node in u_ode and integrate the result using a quadrature associated with the semidiscretization semi.

If normalize is true, the result is divided by the total volume of the computational domain.

source
SciMLBase.add_tstop! — Method
add_tstop!(integrator::SimpleIntegratorSSP, t)

Add a time stop during the time integration process. This function is called after the periodic SaveSolutionCallback to specify the next stop to save the solution.

source
SummationByPartsOperators.semidiscretize — Method
semidiscretize(semi::SemidiscretizationHyperbolicParabolic, tspan)

Wrap the semidiscretization semi as a split ODE problem in the time interval tspan that can be passed to solve from the SciML ecosystem. The parabolic right-hand side is the first function of the split ODE problem and will be used by default by the implicit part of IMEX methods from the SciML ecosystem.

source
SummationByPartsOperators.semidiscretize — Method
semidiscretize(semi::AbstractSemidiscretization, tspan, restart_file::AbstractString)

Wrap the semidiscretization semi as an ODE problem in the time interval tspan that can be passed to solve from the SciML ecosystem. The initial condition etc. is taken from the restart_file.

source
Trixi.DGMultiBasis — Method
DGMultiBasis(element_type, polydeg; approximation_type = Polynomial(), kwargs...)

Constructs a basis for DGMulti solvers. Returns a "StartUpDG.RefElemData" object. The kwargs arguments are additional keyword arguments for RefElemData, such as quad_rule_vol. These are the same as the RefElemData_kwargs used in DGMulti. For more info, see the StartUpDG.jl docs.

source
Trixi.P4estMeshCubedSphere — Method
P4estMeshCubedSphere(trees_per_face_dimension, layers, inner_radius, thickness;
                      polydeg, RealT=Float64,
                      initial_refinement_level=0, unsaved_changes=true,
-                     p4est_partition_allow_for_coarsening=true)

Build a "Cubed Sphere" mesh as P4estMesh with 6 * trees_per_face_dimension^2 * layers trees.

The mesh will have two boundaries, :inside and :outside.

Arguments

  • trees_per_face_dimension::Integer: the number of trees in the first two local dimensions of each face.
  • layers::Integer: the number of trees in the third local dimension of each face, i.e., the number of layers of the sphere.
  • inner_radius::Integer: the inner radius of the sphere.
  • thickness::Integer: the thickness of the sphere. The outer radius will be inner_radius + thickness.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • p4est_partition_allow_for_coarsening::Bool: Must be true when using AMR to make mesh adaptivity independent of domain partitioning. Should be false for static meshes to permit more fine-grained partitioning.
source
Trixi.PlotData2D — Method
PlotData2D(u, semi [or mesh, equations, solver, cache];
+                     p4est_partition_allow_for_coarsening=true)

Build a "Cubed Sphere" mesh as P4estMesh with 6 * trees_per_face_dimension^2 * layers trees.

The mesh will have two boundaries, :inside and :outside.

Arguments

  • trees_per_face_dimension::Integer: the number of trees in the first two local dimensions of each face.
  • layers::Integer: the number of trees in the third local dimension of each face, i.e., the number of layers of the sphere.
  • inner_radius::Integer: the inner radius of the sphere.
  • thickness::Integer: the thickness of the sphere. The outer radius will be inner_radius + thickness.
  • polydeg::Integer: polynomial degree used to store the geometry of the mesh. The mapping will be approximated by an interpolation polynomial of the specified degree for each tree.
  • RealT::Type: the type that should be used for coordinates.
  • initial_refinement_level::Integer: refine the mesh uniformly to this level before the simulation starts.
  • unsaved_changes::Bool: if set to true, the mesh will be saved to a mesh file.
  • p4est_partition_allow_for_coarsening::Bool: Must be true when using AMR to make mesh adaptivity independent of domain partitioning. Should be false for static meshes to permit more fine-grained partitioning.
source
Trixi.PlotData2D — Method
PlotData2D(u, semi [or mesh, equations, solver, cache];
            solution_variables=nothing,
            grid_lines=true, max_supported_level=11, nvisnodes=nothing,
            slice=:xy, point=(0.0, 0.0, 0.0))

Create a new PlotData2D object that can be used for visualizing 2D/3D DGSEM solution data array u with Plots.jl. All relevant geometrical information is extracted from the semidiscretization semi. By default, the primitive variables (if existent) or the conservative variables (otherwise) from the solution are used for plotting. This can be changed by passing an appropriate conversion function to solution_variables.

If grid_lines is true, also extract grid vertices for visualizing the mesh. The output resolution is indirectly set via max_supported_level: all data is interpolated to 2^max_supported_level uniformly distributed points in each spatial direction, also setting the maximum allowed refinement level in the solution. nvisnodes specifies the number of visualization nodes to be used. If it is nothing, twice the number of solution DG nodes are used for visualization, and if set to 0, exactly the number of nodes in the DG elements are used.

When visualizing data from a three-dimensional simulation, a 2D slice is extracted for plotting. slice specifies the plane that is being sliced and may be :xy, :xz, or :yz. The slice position is specified by a point that lies on it, which defaults to (0.0, 0.0, 0.0). Both of these values are ignored when visualizing 2D data.

Experimental implementation

This is an experimental feature and may change in future releases.

Examples

julia> using Trixi, Plots
@@ -360,7 +360,7 @@
 
 julia> plot(pd["scalar"]) # To plot only a single variable
 
-julia> plot!(getmesh(pd)) # To add grid lines to the plot
source
Trixi.PlotData2D — Method
PlotData2D(sol; kwargs...)

Create a PlotData2D object from a solution object created by either OrdinaryDiffEq.solve! (which returns a SciMLBase.ODESolution) or Trixi.jl's own solve! (which returns a TimeIntegratorSolution).

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.ScalarPlotData2D — Method
ScalarPlotData2D(u, semi::AbstractSemidiscretization; kwargs...)

Returns an PlotData2DTriangulated object which is used to visualize a single scalar field. u should be an array whose entries correspond to values of the scalar field at nodal points.

source
Trixi.SummaryCallback — Function
SummaryCallback()

Create and return a callback that prints a human-readable summary of the simulation setup at the beginning of a simulation and then resets the timer. When the returned callback is executed directly, the current timer values are shown.

source
Trixi.adapt! — Method
Trixi.adapt!(mesh::T8codeMesh, adapt_callback; kwargs...)

Adapt a T8codeMesh according to a user-defined adapt_callback.

Arguments

  • mesh::T8codeMesh: Initialized mesh object.

  • adapt_callback: A user-defined callback which tells the adaption routines if an element should be refined, coarsened or stay unchanged.

    The expected callback signature is as follows:

    `adapt_callback(forest, ltreeid, eclass_scheme, lelemntid, elements, is_family, user_data)`
+julia> plot!(getmesh(pd)) # To add grid lines to the plot
source
Trixi.PlotData2D — Method
PlotData2D(sol; kwargs...)

Create a PlotData2D object from a solution object created by either OrdinaryDiffEq.solve! (which returns a SciMLBase.ODESolution) or Trixi.jl's own solve! (which returns a TimeIntegratorSolution).

Experimental implementation

This is an experimental feature and may change in future releases.

source
Trixi.ScalarPlotData2D — Method
ScalarPlotData2D(u, semi::AbstractSemidiscretization; kwargs...)

Returns an PlotData2DTriangulated object which is used to visualize a single scalar field. u should be an array whose entries correspond to values of the scalar field at nodal points.

source
Trixi.SummaryCallback — Function
SummaryCallback()

Create and return a callback that prints a human-readable summary of the simulation setup at the beginning of a simulation and then resets the timer. When the returned callback is executed directly, the current timer values are shown.

source
Trixi.adapt! — Method
Trixi.adapt!(mesh::T8codeMesh, adapt_callback; kwargs...)

Adapt a T8codeMesh according to a user-defined adapt_callback.

Arguments

  • mesh::T8codeMesh: Initialized mesh object.

  • adapt_callback: A user-defined callback which tells the adaption routines if an element should be refined, coarsened or stay unchanged.

    The expected callback signature is as follows:

    `adapt_callback(forest, ltreeid, eclass_scheme, lelemntid, elements, is_family, user_data)`
   # Arguments
   - `forest`: Pointer to the analyzed forest.
   - `ltreeid`: Local index of the current tree where the analyzed elements are part of.
@@ -373,189 +373,189 @@
   # Returns
     -1 : Coarsen family of elements.
      0 : Stay unchanged.
-     1 : Refine element.

  • kwargs:

    • recursive = true: Adapt the forest recursively. If true the caller must ensure that the callback returns 0 for every analyzed element at some point to stop the recursion.
    • balance = true: Make sure the adapted forest is 2^(NDIMS-1):1 balanced.
    • partition = true: Partition the forest to redistribute elements evenly among MPI ranks.
    • ghost = true: Create a ghost layer for MPI data exchange.
    • user_data = C_NULL: Pointer to some arbitrary user-defined data.
source
Trixi.adapt_to_mesh_level! — Method
adapt_to_mesh_level!(u_ode, semi, level)
-adapt_to_mesh_level!(sol::Trixi.TrixiODESolution, level)

Like adapt_to_mesh_level, but modifies the solution and parts of the semidiscretization (mesh and caches) in place.

source
Trixi.adapt_to_mesh_level — Method
adapt_to_mesh_level(u_ode, semi, level)
-adapt_to_mesh_level(sol::Trixi.TrixiODESolution, level)

Use the regular adaptive mesh refinement routines to adaptively refine/coarsen the solution u_ode with semidiscretization semi towards a uniformly refined grid with refinement level level. The solution and semidiscretization are copied such that the original objects remain unaltered.

A convenience method accepts an ODE solution object, from which solution and semidiscretization are extracted as needed.

See also: adapt_to_mesh_level!

source
Trixi.balance! — Method
Trixi.balance!(mesh::T8codeMesh)

Balance a T8codeMesh to ensure 2^(NDIMS-1):1 face neighbors.

source
Trixi.boundary_condition_linear_x — Method
boundary_condition_linear_x(u_inner, orientation, direction, x, t,
+     1 : Refine element.

  • kwargs:

    • recursive = true: Adapt the forest recursively. If true the caller must ensure that the callback returns 0 for every analyzed element at some point to stop the recursion.
    • balance = true: Make sure the adapted forest is 2^(NDIMS-1):1 balanced.
    • partition = true: Partition the forest to redistribute elements evenly among MPI ranks.
    • ghost = true: Create a ghost layer for MPI data exchange.
    • user_data = C_NULL: Pointer to some arbitrary user-defined data.
    • source
    Trixi.adapt_to_mesh_level! — Method
    adapt_to_mesh_level!(u_ode, semi, level)
+adapt_to_mesh_level!(sol::Trixi.TrixiODESolution, level)

    Like adapt_to_mesh_level, but modifies the solution and parts of the semidiscretization (mesh and caches) in place.

    source
    Trixi.adapt_to_mesh_level — Method
    adapt_to_mesh_level(u_ode, semi, level)
+adapt_to_mesh_level(sol::Trixi.TrixiODESolution, level)

    Use the regular adaptive mesh refinement routines to adaptively refine/coarsen the solution u_ode with semidiscretization semi towards a uniformly refined grid with refinement level level. The solution and semidiscretization are copied such that the original objects remain unaltered.

    A convenience method accepts an ODE solution object, from which solution and semidiscretization are extracted as needed.

    See also: adapt_to_mesh_level!

    source
    Trixi.balance! — Method
    Trixi.balance!(mesh::T8codeMesh)

    Balance a T8codeMesh to ensure 2^(NDIMS-1):1 face neighbors.

    source
    Trixi.boundary_condition_noslip_wall — Method
    boundary_condition_noslip_wall(u_inner, orientation, direction, x, t,
                                surface_flux_function,
-                               equations::LatticeBoltzmannEquations2D)

    No-slip wall boundary condition using the bounce-back approach.

    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
-                             equations::AcousticPerturbationEquations2D)

    Use an orthogonal projection of the perturbed velocities to zero out the normal velocity while retaining the possibility of a tangential velocity in the boundary state. Further details are available in the paper:

    • Marcus Bauer, Jürgen Dierke and Roland Ewert (2011) Application of a discontinuous Galerkin method to discretize acoustic perturbation equations DOI: 10.2514/1.J050333
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
-                             equations::CompressibleEulerEquations2D)

    Determine the boundary numerical surface flux for a slip wall condition. Imposes a zero normal velocity at the wall. Density is taken from the internal solution state and pressure is computed as an exact solution of a 1D Riemann problem. Further details about this boundary state are available in the paper:

    • J. J. W. van der Vegt and H. van der Ven (2002) Slip flow boundary conditions in discontinuous Galerkin discretizations of the Euler equations of gas dynamics PDF

    Details about the 1D pressure Riemann solution can be found in Section 6.3.3 of the book

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction 3rd edition DOI: 10.1007/b79761

    Should be used together with UnstructuredMesh2D.

    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
-                             equations::CompressibleEulerEquations3D)

    Determine the boundary numerical surface flux for a slip wall condition. Imposes a zero normal velocity at the wall. Density is taken from the internal solution state and pressure is computed as an exact solution of a 1D Riemann problem. Further details about this boundary state are available in the paper:

    • J. J. W. van der Vegt and H. van der Ven (2002) Slip flow boundary conditions in discontinuous Galerkin discretizations of the Euler equations of gas dynamics PDF

    Details about the 1D pressure Riemann solution can be found in Section 6.3.3 of the book

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction 3rd edition DOI: 10.1007/b79761
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
-                             equations::ShallowWaterEquations2D)

    Create a boundary state by reflecting the normal velocity component and keep the tangential velocity component unchanged. The boundary water height is taken from the internal value. For details see Section 9.2.5 of the book:

    • Eleuterio F. Toro (2001) Shock-Capturing Methods for Free-Surface Shallow Flows 1st edition ISBN 0471987662
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, orientation, direction, x, t,
-                             surface_flux_function, equations::CompressibleEulerEquations1D)

    Determine the boundary numerical surface flux for a slip wall condition. Imposes a zero normal velocity at the wall. Density is taken from the internal solution state and pressure is computed as an exact solution of a 1D Riemann problem. Further details about this boundary state are available in the paper:

    • J. J. W. van der Vegt and H. van der Ven (2002) Slip flow boundary conditions in discontinuous Galerkin discretizations of the Euler equations of gas dynamics PDF

      Should be used together with TreeMesh.

    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, orientation_or_normal, x, t, surface_flux_function,
-                              equations::ShallowWaterEquations1D)

    Create a boundary state by reflecting the normal velocity component and keep the tangential velocity component unchanged. The boundary water height is taken from the internal value.

    For details see Section 9.2.5 of the book:

    • Eleuterio F. Toro (2001) Shock-Capturing Methods for Free-Surface Shallow Flows 1st edition ISBN 0471987662
    source
    Trixi.boundary_condition_wall — Method
    boundary_condition_wall(u_inner, orientation, direction, x, t, surface_flux_function,
-                        equations::AcousticPerturbationEquations2D)

    Boundary conditions for a solid wall.

    source
    Trixi.boundary_condition_wall — Method
    boundary_condition_wall(u_inner, orientation, direction, x, t, surface_flux_function,
-                            equations::LinearizedEulerEquations2D)

    Boundary conditions for a solid wall.

    source
    Trixi.calc_error_norms — Method
    calc_error_norms([func=(u_node,equations)->u_node,] u_ode, t, analyzer, semi::AbstractSemidiscretization, cache_analysis)

    Calculate discrete L2 and L∞ error norms of func applied to each nodal variable u_node in u_ode. If no exact solution is available, "errors" are calculated using some reference state and can be useful for regression tests.

    source
    Trixi.calc_fast_wavespeed_roe — Method
    calc_fast_wavespeed_roe(u_ll, u_rr, direction, equations::IdealGlmMhdEquations1D)

    Compute the fast magnetoacoustic wave speed using Roe averages as given by

    • Cargo and Gallice (1997) Roe Matrices for Ideal MHD and Systematic Construction of Roe Matrices for Systems of Conservation Laws DOI: 10.1006/jcph.1997.5773
    source
    Trixi.calc_fast_wavespeed_roe — Method
    calc_fast_wavespeed_roe(u_ll, u_rr, orientation_or_normal_direction, equations::IdealGlmMhdEquations2D)

    Compute the fast magnetoacoustic wave speed using Roe averages as given by

    • Cargo and Gallice (1997) Roe Matrices for Ideal MHD and Systematic Construction of Roe Matrices for Systems of Conservation Laws DOI: 10.1006/jcph.1997.5773
    source
    Trixi.calc_fast_wavespeed_roe — Method
    calc_fast_wavespeed_roe(u_ll, u_rr, orientation_or_normal_direction, equations::IdealGlmMhdEquations3D)

    Compute the fast magnetoacoustic wave speed using Roe averages as given by

    • Cargo and Gallice (1997) Roe Matrices for Ideal MHD and Systematic Construction of Roe Matrices for Systems of Conservation Laws DOI: 10.1006/jcph.1997.5773
    source
    Trixi.calc_wavespeed_roe — Method
    calc_wavespeed_roe(u_ll, u_rr, direction::Integer,
-                   equations::ShallowWaterEquations1D)

    Calculate Roe-averaged velocity v_roe and wavespeed c_roe = sqrt{g * h_roe} See for instance equation (62) in

    • Paul A. Ullrich, Christiane Jablonowski, and Bram van Leer (2010) High-order finite-volume methods for the shallow-water equations on the sphere DOI: 10.1016/j.jcp.2010.04.044

    Or equation (9.17) in this lecture notes.

    source
    Trixi.calc_wavespeed_roe — Method
    calc_wavespeed_roe(u_ll, u_rr, direction::Integer,
-                   equations::ShallowWaterEquations2D)

    Calculate Roe-averaged velocity v_roe and wavespeed c_roe = sqrt{g * h_roe} depending on direction. See for instance equation (62) in

    • Paul A. Ullrich, Christiane Jablonowski, and Bram van Leer (2010) High-order finite-volume methods for the shallow-water equations on the sphere DOI: 10.1016/j.jcp.2010.04.044

    Or this slides, slides 8 and 9.

    source
    Trixi.collision_bgk — Method
    collision_bgk(u, dt, equations::LatticeBoltzmannEquations2D)

    Collision operator for the Bhatnagar, Gross, and Krook (BGK) model.

    source
    Trixi.collision_bgk — Method
    collision_bgk(u, dt, equations::LatticeBoltzmannEquations3D)

    Collision operator for the Bhatnagar, Gross, and Krook (BGK) model.

    source
    Trixi.cons2cons — Method
    cons2cons(u, equations)

    Return the conserved variables u. While this function is as trivial as identity, it is also as useful.

    source
    Trixi.cons2entropy — Function
    cons2entropy(u, equations)

    Convert the conserved variables u to the entropy variables for a given set of equations with chosen standard entropy.

    u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by entropy2cons.

    source
    Trixi.cons2prim — Function
    cons2prim(u, equations)

    Convert the conserved variables u to the primitive variables for a given set of equations. u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by prim2cons.

    source
    Trixi.convergence_test — Method
    convergence_test([mod::Module=Main,] elixir::AbstractString, iterations; kwargs...)

    Run iterations Trixi.jl simulations using the setup given in elixir and compute the experimental order of convergence (EOC) in the $L^2$ and $L^\infty$ norm. In each iteration, the resolution of the respective mesh will be doubled. Additional keyword arguments kwargs... and the optional module mod are passed directly to trixi_include.

    This function assumes that the spatial resolution is set via the keywords initial_refinement_level (an integer) or cells_per_dimension (a tuple of integers, one per spatial dimension).

    source
    Trixi.default_example_unstructured — Method
    default_example_unstructured()

    Return the path to an example elixir that can be used to quickly see Trixi.jl in action on an UnstructuredMesh2D. This simulation is run on the example curved, unstructured mesh given in the Trixi.jl documentation regarding unstructured meshes.

    source
    Trixi.density — Method
    density(p::Real, equations::LatticeBoltzmannEquations2D)
-density(u, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic density from the pressure p or the particle distribution functions u.

    source
    Trixi.density — Method
    density(p::Real, equations::LatticeBoltzmannEquations3D)
-density(u, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic density from the pressure p or the particle distribution functions u.

    source
    Trixi.download — Method
    Trixi.download(src_url, file_path)

    Download a file from given src_url to given file_path if file_path is not already a file. This function just returns file_path. This is a small wrapper of Downloads.download(src_url, file_path) that avoids race conditions when multiple MPI ranks are used.

    source
    Trixi.each_dof_global — Method
    each_dof_global(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the degrees of freedom (DOF) in dg. In particular, not the DOFs themselves are returned.

    source
    Trixi.each_face_node — Method
    each_face_node(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the face nodes in dg. In particular, not the face_nodes themselves are returned.

    source
    Trixi.each_face_node_global — Method
    each_face_node_global(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the face nodes in mesh. In particular, not the face nodes themselves are returned.

    source
    Trixi.each_quad_node — Method
    each_quad_node(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the quadrature nodes in dg. In particular, not the quadrature nodes themselves are returned.

    source
    Trixi.each_quad_node_global — Method
    each_quad_node_global(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the global quadrature nodes in mesh. In particular, not the quadrature nodes themselves are returned.

    source
    Trixi.eachboundary — Method
    eachboundary(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the boundaries in cache. In particular, not the boundaries themselves are returned.

    source
    Trixi.eachcomponent — Method
    eachcomponent(equations::AbstractCompressibleEulerMulticomponentEquations)

    Return an iterator over the indices that specify the location in relevant data structures for the components in AbstractCompressibleEulerMulticomponentEquations. In particular, not the components themselves are returned.

    source
    Trixi.eachcomponent — Method
    eachcomponent(equations::AbstractIdealGlmMhdMulticomponentEquations)

    Return an iterator over the indices that specify the location in relevant data structures for the components in AbstractIdealGlmMhdMulticomponentEquations. In particular, not the components themselves are returned.

    source
    Trixi.eachdim — Method
    eachdim(mesh)

    Return an iterator over the indices that specify the location in relevant data structures for the dimensions in AbstractTree. In particular, not the dimensions themselves are returned.

    source
    Trixi.eachdirection — Method
    eachdirection(tree::AbstractTree)

    Return an iterator over the indices that specify the location in relevant data structures for the directions in AbstractTree. In particular, not the directions themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in cache. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in mesh. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::ElementContainer1D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::ElementContainer2D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::ElementContainer3D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::UnstructuredElementContainer2D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachinterface — Method
    eachinterface(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the interfaces in cache. In particular, not the interfaces themselves are returned.

    source
    Trixi.eachmortar — Method
    eachmortar(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the mortars in cache. In particular, not the mortars themselves are returned.

    source
    Trixi.eachmpiinterface — Method
    eachmpiinterface(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the MPI interfaces in cache. In particular, not the interfaces themselves are returned.

    source
    Trixi.eachmpimortar — Method
    eachmpimortar(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the MPI mortars in cache. In particular, not the mortars themselves are returned.

    source
    Trixi.eachnode — Method
    eachnode(dg::DG)

    Return an iterator over the indices that specify the location in relevant data structures for the nodes in dg. In particular, not the nodes themselves are returned.

    source
    Trixi.eachnode — Method
    eachnode(basis::LobattoLegendreBasis)

    Return an iterator over the indices that specify the location in relevant data structures for the nodes in basis. In particular, not the nodes themselves are returned.

    source
    Trixi.eachnode — Method
    eachnode(analyzer::LobattoLegendreAnalyzer)

    Return an iterator over the indices that specify the location in relevant data structures for the nodes in analyzer. In particular, not the nodes themselves are returned.

    source
    Trixi.eachvariable — Method
    eachvariable(equations::AbstractEquations)

    Return an iterator over the indices that specify the location in relevant data structures for the variables in equations. In particular, not the variables themselves are returned.

    source
    Trixi.energy_internal — Function
    energy_internal(u, equations)

    Return the internal energy of the conserved variables u for a given set of equations, e.g., the CompressibleEulerEquations2D.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.energy_kinetic — Function
    energy_kinetic(u, equations)

    Return the kinetic energy of the conserved variables u for a given set of equations, e.g., the CompressibleEulerEquations2D.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.energy_total — Function
    energy_total(u, equations)

    Return the total energy of the conserved variables u for a given set of equations, e.g., the CompressibleEulerEquations2D.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.entropy — Function
    entropy(u, equations)

    Return the chosen entropy of the conserved variables u for a given set of equations.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.entropy2cons — Function
    entropy2cons(w, equations)

    Convert the entropy variables w based on a standard entropy to the conserved variables for a given set of equations. u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by cons2entropy.

    source
    Trixi.equilibrium_distribution — Method
    equilibrium_distribution(alpha, rho, v1, v2, v3, equations::LatticeBoltzmannEquations3D)

    Calculate the local equilibrium distribution for the distribution function with index alpha and given the macroscopic state defined by rho, v1, v2, v3.

    source
    Trixi.equilibrium_distribution — Method
    equilibrium_distribution(alpha, rho, v1, v2, equations::LatticeBoltzmannEquations2D)

    Calculate the local equilibrium distribution for the distribution function with index alpha and given the macroscopic state defined by rho, v1, v2.

    source
    Trixi.examples_dir — Method
    examples_dir()

    Return the directory where the example files provided with Trixi.jl are located. If Trixi.jl is installed as a regular package (with ]add Trixi), these files are read-only and should not be modified. To find out which files are available, use, e.g., readdir:

    Examples

    readdir(examples_dir())
    source
    Trixi.flux — Function
    flux(u, orientation_or_normal, equations)

    Given the conservative variables u, calculate the (physical) flux in Cartesian direction orientation::Integer or in arbitrary direction normal::AbstractVector for the corresponding set of governing equations. orientation is 1, 2, and 3 for the x-, y-, and z-directions, respectively.

    source
    Trixi.flux — Method
    flux(u, normal_direction::AbstractVector, equations::AbstractEquations{1})

    Enables calling flux with a non-integer argument normal_direction for one-dimensional equations. Returns the value of flux(u, 1, equations) scaled by normal_direction[1].

    source
    Trixi.flux_central — Method
    flux_central(u_ll, u_rr, orientation_or_normal_direction, equations::AbstractEquations)

    The classical central numerical flux f((u_ll) + f(u_rr)) / 2. When this flux is used as volume flux, the discretization is equivalent to the classical weak form DG method (except floating point errors).

    source
    Trixi.flux_chan_etal — Method

    @inline function fluxchanetal(ull, urr, orientation::Integer, equations::CompressibleEulerEquationsQuasi1D)

    Conservative (symmetric) part of the entropy conservative flux for quasi 1D compressible Euler equations split form. This flux is a generalization of flux_ranocha for CompressibleEulerEquations1D. Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_chan_etal — Method
    flux_chan_etal(u_ll, u_rr, orientation,
-               equations::ShallowWaterEquationsQuasi1D)

    Total energy conservative (mathematical entropy for quasi 1D shallow water equations) split form. When the bottom topography is nonzero this scheme will be well-balanced when used as a volume_flux. The surface_flux should still use, e.g., FluxPlusDissipation(flux_chan_etal, DissipationLocalLaxFriedrichs()).

    Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    Entropy conserving two-point flux by

    • Chandrashekar (2013) Kinetic Energy Preserving and Entropy Stable Finite Volume Schemes for Compressible Euler and Navier-Stokes Equations DOI: 10.4208/cicp.170712.010313a
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerEquations2D)

    Entropy conserving two-point flux by

    • Chandrashekar (2013) Kinetic Energy Preserving and Entropy Stable Finite Volume Schemes for Compressible Euler and Navier-Stokes Equations DOI: 10.4208/cicp.170712.010313a
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerEquations3D)

    Entropy conserving two-point flux by

    • Chandrashekar (2013) Kinetic Energy Preserving and Entropy Stable Finite Volume Schemes for Compressible Euler and Navier-Stokes Equations DOI: 10.4208/cicp.170712.010313a
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerMulticomponentEquations1D)

    Entropy conserving two-point flux by

    • Ayoub Gouasmi, Karthik Duraisamy (2020) "Formulation of Entropy-Stable schemes for the multicomponent compressible Euler equations" arXiv:1904.00972v3 [math.NA] 4 Feb 2020
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerMulticomponentEquations2D)

    Adaption of the entropy conserving two-point flux by

    • Ayoub Gouasmi, Karthik Duraisamy (2020) "Formulation of Entropy-Stable schemes for the multicomponent compressible Euler equations" arXiv:1904.00972v3 [math.NA] 4 Feb 2020
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations1D)

    Entropy conserving two-point flux by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations2D)

    Entropy conserving two-point flux by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations3D)

    Entropy conserving two-point flux by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations1D)

    Entropy conserving two-point flux adapted by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations for multicomponent DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdMulticomponentEquations2D)

    Entropy conserving two-point flux adapted by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations for multicomponent DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_fjordholm_etal — Method
    flux_fjordholm_etal(u_ll, u_rr, orientation,
-                    equations::ShallowWaterEquations1D)

    Total energy conservative (mathematical entropy for shallow water equations). When the bottom topography is nonzero this should only be used as a surface flux otherwise the scheme will not be well-balanced. For well-balancedness in the volume flux use flux_wintermeyer_etal.

    Details are available in Eq. (4.1) in the paper:

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042
    source
    Trixi.flux_fjordholm_etal — Method
    flux_fjordholm_etal(u_ll, u_rr, orientation_or_normal_direction,
-                    equations::ShallowWaterEquations2D)

    Total energy conservative (mathematical entropy for shallow water equations). When the bottom topography is nonzero this should only be used as a surface flux otherwise the scheme will not be well-balanced. For well-balancedness in the volume flux use flux_wintermeyer_etal.

    Details are available in Eq. (4.1) in the paper:

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042
    source
    Trixi.flux_godunov — Method
    flux_godunov(u_ll, u_rr, orientation_or_normal_direction,
-             equations::LinearizedEulerEquations2D)

    An upwind flux for the linearized Euler equations based on diagonalization of the physical flux matrix. Given the physical flux $Au$, $A=T \Lambda T^{-1}$ with $\Lambda$ being a diagonal matrix that holds the eigenvalues of $A$, decompose $\Lambda = \Lambda^+ + \Lambda^-$ where $\Lambda^+$ and $\Lambda^-$ are diagonal matrices holding the positive and negative eigenvalues of $A$, respectively. Then for left and right states $u_L, u_R$, the numerical flux calculated by this function is given by $A^+ u_L + A^- u_R$ where $A^{\pm} = T \Lambda^{\pm} T^{-1}$.

    The diagonalization of the flux matrix can be found in

    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
-                        equations::IdealGlmMhdEquations1D)

    Entropy conserving and kinetic energy preserving two-point flux of Hindenlang and Gassner (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
-                        equations::IdealGlmMhdEquations2D)

    Entropy conserving and kinetic energy preserving two-point flux of Hindenlang and Gassner (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
-                        equations::IdealGlmMhdEquations3D)

    Entropy conserving and kinetic energy preserving two-point flux of Hindenlang and Gassner (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
-                        equations::IdealGlmMhdMulticomponentEquations1D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux of Hindenlang (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
-                        equations::IdealGlmMhdMulticomponentEquations2D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux of Hindenlang (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_kennedy_gruber — Method
    flux_kennedy_gruber(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    Kinetic energy preserving two-point flux by

    • Kennedy and Gruber (2008) Reduced aliasing formulations of the convective terms within the Navier-Stokes equations for a compressible fluid DOI: 10.1016/j.jcp.2007.09.020
    source
    Trixi.flux_kennedy_gruber — Method
    flux_kennedy_gruber(u_ll, u_rr, orientation_or_normal_direction,
-                    equations::CompressibleEulerEquations2D)

    Kinetic energy preserving two-point flux by

    • Kennedy and Gruber (2008) Reduced aliasing formulations of the convective terms within the Navier-Stokes equations for a compressible fluid DOI: 10.1016/j.jcp.2007.09.020
    source
    Trixi.flux_kennedy_gruber — Method
    flux_kennedy_gruber(u_ll, u_rr, orientation_or_normal_direction,
-                    equations::CompressibleEulerEquations3D)

    Kinetic energy preserving two-point flux by

    • Kennedy and Gruber (2008) Reduced aliasing formulations of the convective terms within the Navier-Stokes equations for a compressible fluid DOI: 10.1016/j.jcp.2007.09.020
    source
    Trixi.flux_nonconservative_audusse_etal — Method
    flux_nonconservative_audusse_etal(u_ll, u_rr, orientation::Integer,
-                                  equations::ShallowWaterEquations1D)

    Non-symmetric two-point surface flux that discretizes the nonconservative (source) term. The discretization uses the hydrostatic_reconstruction_audusse_etal on the conservative variables.

    This hydrostatic reconstruction ensures that the finite volume numerical fluxes remain well-balanced for discontinuous bottom topographies ShallowWaterEquations1D. Should be used together with FluxHydrostaticReconstruction and hydrostatic_reconstruction_audusse_etal in the surface flux to ensure consistency.

    Further details on the hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
+                             equations::AcousticPerturbationEquations2D)

    Use an orthogonal projection of the perturbed velocities to zero out the normal velocity while retaining the possibility of a tangential velocity in the boundary state. Further details are available in the paper:

    • Marcus Bauer, Jürgen Dierke and Roland Ewert (2011) Application of a discontinuous Galerkin method to discretize acoustic perturbation equations DOI: 10.2514/1.J050333
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
+                             equations::CompressibleEulerEquations2D)

    Determine the boundary numerical surface flux for a slip wall condition. Imposes a zero normal velocity at the wall. Density is taken from the internal solution state and pressure is computed as an exact solution of a 1D Riemann problem. Further details about this boundary state are available in the paper:

    • J. J. W. van der Vegt and H. van der Ven (2002) Slip flow boundary conditions in discontinuous Galerkin discretizations of the Euler equations of gas dynamics PDF

    Details about the 1D pressure Riemann solution can be found in Section 6.3.3 of the book

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction 3rd edition DOI: 10.1007/b79761

    Should be used together with UnstructuredMesh2D.

    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
+                             equations::CompressibleEulerEquations3D)

    Determine the boundary numerical surface flux for a slip wall condition. Imposes a zero normal velocity at the wall. Density is taken from the internal solution state and pressure is computed as an exact solution of a 1D Riemann problem. Further details about this boundary state are available in the paper:

    • J. J. W. van der Vegt and H. van der Ven (2002) Slip flow boundary conditions in discontinuous Galerkin discretizations of the Euler equations of gas dynamics PDF

    Details about the 1D pressure Riemann solution can be found in Section 6.3.3 of the book

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction 3rd edition DOI: 10.1007/b79761
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, normal_direction, x, t, surface_flux_function,
+                             equations::ShallowWaterEquations2D)

    Create a boundary state by reflecting the normal velocity component and keep the tangential velocity component unchanged. The boundary water height is taken from the internal value. For details see Section 9.2.5 of the book:

    • Eleuterio F. Toro (2001) Shock-Capturing Methods for Free-Surface Shallow Flows 1st edition ISBN 0471987662
    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, orientation, direction, x, t,
+                             surface_flux_function, equations::CompressibleEulerEquations1D)

    Determine the boundary numerical surface flux for a slip wall condition. Imposes a zero normal velocity at the wall. Density is taken from the internal solution state and pressure is computed as an exact solution of a 1D Riemann problem. Further details about this boundary state are available in the paper:

    • J. J. W. van der Vegt and H. van der Ven (2002) Slip flow boundary conditions in discontinuous Galerkin discretizations of the Euler equations of gas dynamics PDF

      Should be used together with TreeMesh.

    source
    Trixi.boundary_condition_slip_wall — Method
    boundary_condition_slip_wall(u_inner, orientation_or_normal, x, t, surface_flux_function,
+                              equations::ShallowWaterEquations1D)

    Create a boundary state by reflecting the normal velocity component and keep the tangential velocity component unchanged. The boundary water height is taken from the internal value.

    For details see Section 9.2.5 of the book:

    • Eleuterio F. Toro (2001) Shock-Capturing Methods for Free-Surface Shallow Flows 1st edition ISBN 0471987662
    source
    Trixi.boundary_condition_wall — Method
    boundary_condition_wall(u_inner, orientation, direction, x, t, surface_flux_function,
+                        equations::AcousticPerturbationEquations2D)

    Boundary conditions for a solid wall.

    source
    Trixi.boundary_condition_wall — Method
    boundary_condition_wall(u_inner, orientation, direction, x, t, surface_flux_function,
+                            equations::LinearizedEulerEquations2D)

    Boundary conditions for a solid wall.

    source
    Trixi.calc_error_norms — Method
    calc_error_norms([func=(u_node,equations)->u_node,] u_ode, t, analyzer, semi::AbstractSemidiscretization, cache_analysis)

    Calculate discrete L2 and L∞ error norms of func applied to each nodal variable u_node in u_ode. If no exact solution is available, "errors" are calculated using some reference state and can be useful for regression tests.

    source
    Trixi.calc_fast_wavespeed_roe — Method
    calc_fast_wavespeed_roe(u_ll, u_rr, direction, equations::IdealGlmMhdEquations1D)

    Compute the fast magnetoacoustic wave speed using Roe averages as given by

    • Cargo and Gallice (1997) Roe Matrices for Ideal MHD and Systematic Construction of Roe Matrices for Systems of Conservation Laws DOI: 10.1006/jcph.1997.5773
    source
    Trixi.calc_fast_wavespeed_roe — Method
    calc_fast_wavespeed_roe(u_ll, u_rr, orientation_or_normal_direction, equations::IdealGlmMhdEquations2D)

    Compute the fast magnetoacoustic wave speed using Roe averages as given by

    • Cargo and Gallice (1997) Roe Matrices for Ideal MHD and Systematic Construction of Roe Matrices for Systems of Conservation Laws DOI: 10.1006/jcph.1997.5773
    source
    Trixi.calc_fast_wavespeed_roe — Method
    calc_fast_wavespeed_roe(u_ll, u_rr, orientation_or_normal_direction, equations::IdealGlmMhdEquations3D)

    Compute the fast magnetoacoustic wave speed using Roe averages as given by

    • Cargo and Gallice (1997) Roe Matrices for Ideal MHD and Systematic Construction of Roe Matrices for Systems of Conservation Laws DOI: 10.1006/jcph.1997.5773
    source
    Trixi.calc_wavespeed_roe — Method
    calc_wavespeed_roe(u_ll, u_rr, direction::Integer,
+                   equations::ShallowWaterEquations1D)

    Calculate Roe-averaged velocity v_roe and wavespeed c_roe = sqrt{g * h_roe} See for instance equation (62) in

    • Paul A. Ullrich, Christiane Jablonowski, and Bram van Leer (2010) High-order finite-volume methods for the shallow-water equations on the sphere DOI: 10.1016/j.jcp.2010.04.044

    Or equation (9.17) in this lecture notes.

    source
    Trixi.calc_wavespeed_roe — Method
    calc_wavespeed_roe(u_ll, u_rr, direction::Integer,
+                   equations::ShallowWaterEquations2D)

    Calculate Roe-averaged velocity v_roe and wavespeed c_roe = sqrt{g * h_roe} depending on direction. See for instance equation (62) in

    • Paul A. Ullrich, Christiane Jablonowski, and Bram van Leer (2010) High-order finite-volume methods for the shallow-water equations on the sphere DOI: 10.1016/j.jcp.2010.04.044

    Or this slides, slides 8 and 9.

    source
    Trixi.collision_bgk — Method
    collision_bgk(u, dt, equations::LatticeBoltzmannEquations2D)

    Collision operator for the Bhatnagar, Gross, and Krook (BGK) model.

    source
    Trixi.collision_bgk — Method
    collision_bgk(u, dt, equations::LatticeBoltzmannEquations3D)

    Collision operator for the Bhatnagar, Gross, and Krook (BGK) model.

    source
    Trixi.cons2cons — Method
    cons2cons(u, equations)

    Return the conserved variables u. While this function is as trivial as identity, it is also as useful.

    source
    Trixi.cons2entropy — Function
    cons2entropy(u, equations)

    Convert the conserved variables u to the entropy variables for a given set of equations with chosen standard entropy.

    u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by entropy2cons.

    source
    Trixi.cons2prim — Function
    cons2prim(u, equations)

    Convert the conserved variables u to the primitive variables for a given set of equations. u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by prim2cons.

    source
    Trixi.convergence_test — Method
    convergence_test([mod::Module=Main,] elixir::AbstractString, iterations; kwargs...)

    Run iterations Trixi.jl simulations using the setup given in elixir and compute the experimental order of convergence (EOC) in the $L^2$ and $L^\infty$ norm. In each iteration, the resolution of the respective mesh will be doubled. Additional keyword arguments kwargs... and the optional module mod are passed directly to trixi_include.

    This function assumes that the spatial resolution is set via the keywords initial_refinement_level (an integer) or cells_per_dimension (a tuple of integers, one per spatial dimension).

    source
    Trixi.default_example_unstructured — Method
    default_example_unstructured()

    Return the path to an example elixir that can be used to quickly see Trixi.jl in action on an UnstructuredMesh2D. This simulation is run on the example curved, unstructured mesh given in the Trixi.jl documentation regarding unstructured meshes.

    source
    Trixi.density — Method
    density(p::Real, equations::LatticeBoltzmannEquations2D)
+density(u, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic density from the pressure p or the particle distribution functions u.

    source
    Trixi.density — Method
    density(p::Real, equations::LatticeBoltzmannEquations3D)
+density(u, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic density from the pressure p or the particle distribution functions u.

    source
    Trixi.download — Method
    Trixi.download(src_url, file_path)

    Download a file from given src_url to given file_path if file_path is not already a file. This function just returns file_path. This is a small wrapper of Downloads.download(src_url, file_path) that avoids race conditions when multiple MPI ranks are used.

    source
    Trixi.each_dof_global — Method
    each_dof_global(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the degrees of freedom (DOF) in dg. In particular, not the DOFs themselves are returned.

    source
    Trixi.each_face_node — Method
    each_face_node(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the face nodes in dg. In particular, not the face_nodes themselves are returned.

    source
    Trixi.each_face_node_global — Method
    each_face_node_global(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the face nodes in mesh. In particular, not the face nodes themselves are returned.

    source
    Trixi.each_quad_node — Method
    each_quad_node(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the quadrature nodes in dg. In particular, not the quadrature nodes themselves are returned.

    source
    Trixi.each_quad_node_global — Method
    each_quad_node_global(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the global quadrature nodes in mesh. In particular, not the quadrature nodes themselves are returned.

    source
    Trixi.eachboundary — Method
    eachboundary(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the boundaries in cache. In particular, not the boundaries themselves are returned.

    source
    Trixi.eachcomponent — Method
    eachcomponent(equations::AbstractCompressibleEulerMulticomponentEquations)

    Return an iterator over the indices that specify the location in relevant data structures for the components in AbstractCompressibleEulerMulticomponentEquations. In particular, not the components themselves are returned.

    source
    Trixi.eachcomponent — Method
    eachcomponent(equations::AbstractIdealGlmMhdMulticomponentEquations)

    Return an iterator over the indices that specify the location in relevant data structures for the components in AbstractIdealGlmMhdMulticomponentEquations. In particular, not the components themselves are returned.

    source
    Trixi.eachdim — Method
    eachdim(mesh)

    Return an iterator over the indices that specify the location in relevant data structures for the dimensions in AbstractTree. In particular, not the dimensions themselves are returned.

    source
    Trixi.eachdirection — Method
    eachdirection(tree::AbstractTree)

    Return an iterator over the indices that specify the location in relevant data structures for the directions in AbstractTree. In particular, not the directions themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in cache. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(mesh::DGMultiMesh, dg::DGMulti, other_args...)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in mesh. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::ElementContainer1D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::ElementContainer2D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::ElementContainer3D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachelement — Method
    eachelement(elements::UnstructuredElementContainer2D)

    Return an iterator over the indices that specify the location in relevant data structures for the elements in elements. In particular, not the elements themselves are returned.

    source
    Trixi.eachinterface — Method
    eachinterface(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the interfaces in cache. In particular, not the interfaces themselves are returned.

    source
    Trixi.eachmortar — Method
    eachmortar(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the mortars in cache. In particular, not the mortars themselves are returned.

    source
    Trixi.eachmpiinterface — Method
    eachmpiinterface(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the MPI interfaces in cache. In particular, not the interfaces themselves are returned.

    source
    Trixi.eachmpimortar — Method
    eachmpimortar(dg::DG, cache)

    Return an iterator over the indices that specify the location in relevant data structures for the MPI mortars in cache. In particular, not the mortars themselves are returned.

    source
    Trixi.eachnode — Method
    eachnode(dg::DG)

    Return an iterator over the indices that specify the location in relevant data structures for the nodes in dg. In particular, not the nodes themselves are returned.

    source
    Trixi.eachnode — Method
    eachnode(basis::LobattoLegendreBasis)

    Return an iterator over the indices that specify the location in relevant data structures for the nodes in basis. In particular, not the nodes themselves are returned.

    source
    Trixi.eachnode — Method
    eachnode(analyzer::LobattoLegendreAnalyzer)

    Return an iterator over the indices that specify the location in relevant data structures for the nodes in analyzer. In particular, not the nodes themselves are returned.

    source
    Trixi.eachvariable — Method
    eachvariable(equations::AbstractEquations)

    Return an iterator over the indices that specify the location in relevant data structures for the variables in equations. In particular, not the variables themselves are returned.

    source
    Trixi.energy_internal — Function
    energy_internal(u, equations)

    Return the internal energy of the conserved variables u for a given set of equations, e.g., the CompressibleEulerEquations2D.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.energy_kinetic — Function
    energy_kinetic(u, equations)

    Return the kinetic energy of the conserved variables u for a given set of equations, e.g., the CompressibleEulerEquations2D.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.energy_total — Function
    energy_total(u, equations)

    Return the total energy of the conserved variables u for a given set of equations, e.g., the CompressibleEulerEquations2D.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.entropy — Function
    entropy(u, equations)

    Return the chosen entropy of the conserved variables u for a given set of equations.

    u is a vector of the conserved variables at a single node, i.e., a vector of the correct length nvariables(equations).

    source
    Trixi.entropy2cons — Function
    entropy2cons(w, equations)

    Convert the entropy variables w based on a standard entropy to the conserved variables for a given set of equations. u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by cons2entropy.

    source
    Trixi.equilibrium_distribution — Method
    equilibrium_distribution(alpha, rho, v1, v2, v3, equations::LatticeBoltzmannEquations3D)

    Calculate the local equilibrium distribution for the distribution function with index alpha and given the macroscopic state defined by rho, v1, v2, v3.

    source
    Trixi.equilibrium_distribution — Method
    equilibrium_distribution(alpha, rho, v1, v2, equations::LatticeBoltzmannEquations2D)

    Calculate the local equilibrium distribution for the distribution function with index alpha and given the macroscopic state defined by rho, v1, v2.

    source
    Trixi.examples_dir — Method
    examples_dir()

    Return the directory where the example files provided with Trixi.jl are located. If Trixi.jl is installed as a regular package (with ]add Trixi), these files are read-only and should not be modified. To find out which files are available, use, e.g., readdir:

    Examples

    readdir(examples_dir())
    source
    Trixi.flux — Function
    flux(u, orientation_or_normal, equations)

    Given the conservative variables u, calculate the (physical) flux in Cartesian direction orientation::Integer or in arbitrary direction normal::AbstractVector for the corresponding set of governing equations. orientation is 1, 2, and 3 for the x-, y-, and z-directions, respectively.

    source
    Trixi.flux — Method
    flux(u, normal_direction::AbstractVector, equations::AbstractEquations{1})

    Enables calling flux with a non-integer argument normal_direction for one-dimensional equations. Returns the value of flux(u, 1, equations) scaled by normal_direction[1].

    source
    Trixi.flux_central — Method
    flux_central(u_ll, u_rr, orientation_or_normal_direction, equations::AbstractEquations)

    The classical central numerical flux f((u_ll) + f(u_rr)) / 2. When this flux is used as volume flux, the discretization is equivalent to the classical weak form DG method (except floating point errors).

    source
    Trixi.flux_chan_etal — Method

    @inline function fluxchanetal(ull, urr, orientation::Integer, equations::CompressibleEulerEquationsQuasi1D)

    Conservative (symmetric) part of the entropy conservative flux for quasi 1D compressible Euler equations split form. This flux is a generalization of flux_ranocha for CompressibleEulerEquations1D. Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_chan_etal — Method
    flux_chan_etal(u_ll, u_rr, orientation,
+               equations::ShallowWaterEquationsQuasi1D)

    Total energy conservative (mathematical entropy for quasi 1D shallow water equations) split form. When the bottom topography is nonzero this scheme will be well-balanced when used as a volume_flux. The surface_flux should still use, e.g., FluxPlusDissipation(flux_chan_etal, DissipationLocalLaxFriedrichs()).

    Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    Entropy conserving two-point flux by

    • Chandrashekar (2013) Kinetic Energy Preserving and Entropy Stable Finite Volume Schemes for Compressible Euler and Navier-Stokes Equations DOI: 10.4208/cicp.170712.010313a
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerEquations2D)

    Entropy conserving two-point flux by

    • Chandrashekar (2013) Kinetic Energy Preserving and Entropy Stable Finite Volume Schemes for Compressible Euler and Navier-Stokes Equations DOI: 10.4208/cicp.170712.010313a
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerEquations3D)

    Entropy conserving two-point flux by

    • Chandrashekar (2013) Kinetic Energy Preserving and Entropy Stable Finite Volume Schemes for Compressible Euler and Navier-Stokes Equations DOI: 10.4208/cicp.170712.010313a
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerMulticomponentEquations1D)

    Entropy conserving two-point flux by

    • Ayoub Gouasmi, Karthik Duraisamy (2020) "Formulation of Entropy-Stable schemes for the multicomponent compressible Euler equations" arXiv:1904.00972v3 [math.NA] 4 Feb 2020
    source
    Trixi.flux_chandrashekar — Method
    flux_chandrashekar(u_ll, u_rr, orientation, equations::CompressibleEulerMulticomponentEquations2D)

    Adaption of the entropy conserving two-point flux by

    • Ayoub Gouasmi, Karthik Duraisamy (2020) "Formulation of Entropy-Stable schemes for the multicomponent compressible Euler equations" arXiv:1904.00972v3 [math.NA] 4 Feb 2020
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations1D)

    Entropy conserving two-point flux by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations2D)

    Entropy conserving two-point flux by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations3D)

    Entropy conserving two-point flux by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations1D)

    Entropy conserving two-point flux adapted by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations for multicomponent DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_derigs_etal — Method
    flux_derigs_etal(u_ll, u_rr, orientation, equations::IdealGlmMhdMulticomponentEquations2D)

    Entropy conserving two-point flux adapted by

    • Derigs et al. (2018) Ideal GLM-MHD: About the entropy consistent nine-wave magnetic field divergence diminishing ideal magnetohydrodynamics equations for multicomponent DOI: 10.1016/j.jcp.2018.03.002
    source
    Trixi.flux_fjordholm_etal — Method
    flux_fjordholm_etal(u_ll, u_rr, orientation,
+                    equations::ShallowWaterEquations1D)

    Total energy conservative (mathematical entropy for shallow water equations). When the bottom topography is nonzero this should only be used as a surface flux otherwise the scheme will not be well-balanced. For well-balancedness in the volume flux use flux_wintermeyer_etal.

    Details are available in Eq. (4.1) in the paper:

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042
    source
    Trixi.flux_fjordholm_etal — Method
    flux_fjordholm_etal(u_ll, u_rr, orientation_or_normal_direction,
+                    equations::ShallowWaterEquations2D)

    Total energy conservative (mathematical entropy for shallow water equations). When the bottom topography is nonzero this should only be used as a surface flux otherwise the scheme will not be well-balanced. For well-balancedness in the volume flux use flux_wintermeyer_etal.

    Details are available in Eq. (4.1) in the paper:

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042
    source
    Trixi.flux_godunov — Method
    flux_godunov(u_ll, u_rr, orientation_or_normal_direction,
+             equations::LinearizedEulerEquations2D)

    An upwind flux for the linearized Euler equations based on diagonalization of the physical flux matrix. Given the physical flux $Au$, $A=T \Lambda T^{-1}$ with $\Lambda$ being a diagonal matrix that holds the eigenvalues of $A$, decompose $\Lambda = \Lambda^+ + \Lambda^-$ where $\Lambda^+$ and $\Lambda^-$ are diagonal matrices holding the positive and negative eigenvalues of $A$, respectively. Then for left and right states $u_L, u_R$, the numerical flux calculated by this function is given by $A^+ u_L + A^- u_R$ where $A^{\pm} = T \Lambda^{\pm} T^{-1}$.

    The diagonalization of the flux matrix can be found in

    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
+                        equations::IdealGlmMhdEquations1D)

    Entropy conserving and kinetic energy preserving two-point flux of Hindenlang and Gassner (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
+                        equations::IdealGlmMhdEquations2D)

    Entropy conserving and kinetic energy preserving two-point flux of Hindenlang and Gassner (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
+                        equations::IdealGlmMhdEquations3D)

    Entropy conserving and kinetic energy preserving two-point flux of Hindenlang and Gassner (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
+                        equations::IdealGlmMhdMulticomponentEquations1D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux of Hindenlang (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_hindenlang_gassner — Method
    flux_hindenlang_gassner(u_ll, u_rr, orientation_or_normal_direction,
+                        equations::IdealGlmMhdMulticomponentEquations2D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux of Hindenlang (2019), extending flux_ranocha to the MHD equations.

    References

    • Florian Hindenlang, Gregor Gassner (2019) A new entropy conservative two-point flux for ideal MHD equations derived from first principles. Presented at HONOM 2019: European workshop on high order numerical methods for evolutionary PDEs, theory and applications
    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig
    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_kennedy_gruber — Method
    flux_kennedy_gruber(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    Kinetic energy preserving two-point flux by

    • Kennedy and Gruber (2008) Reduced aliasing formulations of the convective terms within the Navier-Stokes equations for a compressible fluid DOI: 10.1016/j.jcp.2007.09.020
    source
    Trixi.flux_kennedy_gruber — Method
    flux_kennedy_gruber(u_ll, u_rr, orientation_or_normal_direction,
+                    equations::CompressibleEulerEquations2D)

    Kinetic energy preserving two-point flux by

    • Kennedy and Gruber (2008) Reduced aliasing formulations of the convective terms within the Navier-Stokes equations for a compressible fluid DOI: 10.1016/j.jcp.2007.09.020
    source
    Trixi.flux_kennedy_gruber — Method
    flux_kennedy_gruber(u_ll, u_rr, orientation_or_normal_direction,
+                    equations::CompressibleEulerEquations3D)

    Kinetic energy preserving two-point flux by

    • Kennedy and Gruber (2008) Reduced aliasing formulations of the convective terms within the Navier-Stokes equations for a compressible fluid DOI: 10.1016/j.jcp.2007.09.020
    source
    Trixi.flux_nonconservative_audusse_etal — Method
    flux_nonconservative_audusse_etal(u_ll, u_rr, orientation::Integer,
+                                  equations::ShallowWaterEquations1D)

    Non-symmetric two-point surface flux that discretizes the nonconservative (source) term. The discretization uses the hydrostatic_reconstruction_audusse_etal on the conservative variables.

    This hydrostatic reconstruction ensures that the finite volume numerical fluxes remain well-balanced for discontinuous bottom topographies ShallowWaterEquations1D. Should be used together with FluxHydrostaticReconstruction and hydrostatic_reconstruction_audusse_etal in the surface flux to ensure consistency.

    Further details on the hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.flux_nonconservative_audusse_etal — Method
    flux_nonconservative_audusse_etal(u_ll, u_rr, orientation::Integer,
                                   equations::ShallowWaterEquations2D)
 flux_nonconservative_audusse_etal(u_ll, u_rr,
                                   normal_direction_ll     ::AbstractVector,
                                   normal_direction_average::AbstractVector,
-                                  equations::ShallowWaterEquations2D)

    Non-symmetric two-point surface flux that discretizes the nonconservative (source) term. The discretization uses the hydrostatic_reconstruction_audusse_etal on the conservative variables.

    This hydrostatic reconstruction ensures that the finite volume numerical fluxes remain well-balanced for discontinuous bottom topographies ShallowWaterEquations2D. Should be used together with FluxHydrostaticReconstruction and hydrostatic_reconstruction_audusse_etal in the surface flux to ensure consistency.

    Further details for the hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.flux_nonconservative_chan_etal — Method
    flux_nonconservative_chan_etal(u_ll, u_rr, orientation::Integer,
+                                  equations::ShallowWaterEquations2D)

    Non-symmetric two-point surface flux that discretizes the nonconservative (source) term. The discretization uses the hydrostatic_reconstruction_audusse_etal on the conservative variables.

    This hydrostatic reconstruction ensures that the finite volume numerical fluxes remain well-balanced for discontinuous bottom topographies ShallowWaterEquations2D. Should be used together with FluxHydrostaticReconstruction and hydrostatic_reconstruction_audusse_etal in the surface flux to ensure consistency.

    Further details for the hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.flux_nonconservative_chan_etal — Method
    flux_nonconservative_chan_etal(u_ll, u_rr, orientation::Integer,
                                equations::CompressibleEulerEquationsQuasi1D)
 flux_nonconservative_chan_etal(u_ll, u_rr, normal_direction, 
                                equations::CompressibleEulerEquationsQuasi1D)
 flux_nonconservative_chan_etal(u_ll, u_rr, normal_ll, normal_rr,
-                               equations::CompressibleEulerEquationsQuasi1D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the pressure CompressibleEulerEquationsQuasi1D and the nozzle width.

    Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_nonconservative_chan_etal — Method
    flux_nonconservative_chan_etal(u_ll, u_rr, orientation::Integer,
+                               equations::CompressibleEulerEquationsQuasi1D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the pressure CompressibleEulerEquationsQuasi1D and the nozzle width.

    Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_nonconservative_chan_etal — Method
    flux_nonconservative_chan_etal(u_ll, u_rr, orientation::Integer,
                                equations::ShallowWaterEquationsQuasi1D)
 flux_nonconservative_chan_etal(u_ll, u_rr, normal_direction::AbstractVector,
                                equations::ShallowWaterEquationsQuasi1D)    
 flux_nonconservative_chan_etal(u_ll, u_rr, 
                                normal_ll::AbstractVector, normal_rr::AbstractVector,
-                               equations::ShallowWaterEquationsQuasi1D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquationsQuasi1D and the channel width.

    Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_nonconservative_ersing_etal — Method
    flux_nonconservative_ersing_etal(u_ll, u_rr, orientation::Integer,
-                                 equations::ShallowWaterEquations1D)
    Experimental code

    This numerical flux is experimental and may change in any future release.

    Non-symmetric path-conservative two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations1D.

    This is a modified version of flux_nonconservative_wintermeyer_etal that gives entropy conservation and well-balancedness in both the volume and surface when combined with flux_wintermeyer_etal.

    For further details see:

    • Patrick Ersing, Andrew R. Winters (2023) An entropy stable discontinuous Galerkin method for the two-layer shallow water equations on curvilinear meshes DOI: 10.48550/arXiv.2306.12699
    source
    Trixi.flux_nonconservative_ersing_etal — Method
    flux_nonconservative_ersing_etal(u_ll, u_rr, orientation::Integer,
+                               equations::ShallowWaterEquationsQuasi1D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquationsQuasi1D and the channel width.

    Further details are available in the paper:

    • Jesse Chan, Khemraj Shukla, Xinhui Wu, Ruofeng Liu, Prani Nalluri (2023) High order entropy stable schemes for the quasi-one-dimensional shallow water and compressible Euler equations DOI: 10.48550/arXiv.2307.12089
    source
    Trixi.flux_nonconservative_ersing_etal — Method
    flux_nonconservative_ersing_etal(u_ll, u_rr, orientation::Integer,
+                                 equations::ShallowWaterEquations1D)
    Experimental code

    This numerical flux is experimental and may change in any future release.

    Non-symmetric path-conservative two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations1D.

    This is a modified version of flux_nonconservative_wintermeyer_etal that gives entropy conservation and well-balancedness in both the volume and surface when combined with flux_wintermeyer_etal.

    For further details see:

    • Patrick Ersing, Andrew R. Winters (2023) An entropy stable discontinuous Galerkin method for the two-layer shallow water equations on curvilinear meshes DOI: 10.48550/arXiv.2306.12699
    source
    Trixi.flux_nonconservative_ersing_etal — Method
    flux_nonconservative_ersing_etal(u_ll, u_rr, orientation::Integer,
                                  equations::ShallowWaterEquations2D)
 flux_nonconservative_ersing_etal(u_ll, u_rr,
                                  normal_direction_ll::AbstractVector,
                                  normal_direction_average::AbstractVector,
-                                 equations::ShallowWaterEquations2D)
    Experimental code

    This numerical flux is experimental and may change in any future release.

    Non-symmetric path-conservative two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    This is a modified version of flux_nonconservative_wintermeyer_etal that gives entropy conservation and well-balancedness in both the volume and surface when combined with flux_wintermeyer_etal.

    For further details see:

    • Patrick Ersing, Andrew R. Winters (2023) An entropy stable discontinuous Galerkin method for the two-layer shallow water equations on curvilinear meshes DOI: 10.48550/arXiv.2306.12699
    source
    Trixi.flux_nonconservative_fjordholm_etal — Method
    flux_nonconservative_fjordholm_etal(u_ll, u_rr, orientation::Integer,
-                                    equations::ShallowWaterEquations1D)

    Non-symmetric two-point surface flux discretizing the nonconservative (source) term of that contains the gradient of the bottom topography ShallowWaterEquations1D.

    This contains additional terms compared to flux_nonconservative_wintermeyer_etal that account for possible discontinuities in the bottom topography function. Thus, this flux should be used in general at interfaces. For flux differencing volume terms, flux_nonconservative_wintermeyer_etal is analytically equivalent but slightly cheaper.

    Further details for the original finite volume formulation are available in

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042

    and for curvilinear 2D case in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_nonconservative_fjordholm_etal — Method
    flux_nonconservative_fjordholm_etal(u_ll, u_rr, orientation::Integer,
+                                 equations::ShallowWaterEquations2D)
    Experimental code

    This numerical flux is experimental and may change in any future release.

    Non-symmetric path-conservative two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    This is a modified version of flux_nonconservative_wintermeyer_etal that gives entropy conservation and well-balancedness in both the volume and surface when combined with flux_wintermeyer_etal.

    For further details see:

    • Patrick Ersing, Andrew R. Winters (2023) An entropy stable discontinuous Galerkin method for the two-layer shallow water equations on curvilinear meshes DOI: 10.48550/arXiv.2306.12699
    source
    Trixi.flux_nonconservative_fjordholm_etal — Method
    flux_nonconservative_fjordholm_etal(u_ll, u_rr, orientation::Integer,
+                                    equations::ShallowWaterEquations1D)

    Non-symmetric two-point surface flux discretizing the nonconservative (source) term of that contains the gradient of the bottom topography ShallowWaterEquations1D.

    This contains additional terms compared to flux_nonconservative_wintermeyer_etal that account for possible discontinuities in the bottom topography function. Thus, this flux should be used in general at interfaces. For flux differencing volume terms, flux_nonconservative_wintermeyer_etal is analytically equivalent but slightly cheaper.

    Further details for the original finite volume formulation are available in

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042

    and for curvilinear 2D case in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_nonconservative_fjordholm_etal — Method
    flux_nonconservative_fjordholm_etal(u_ll, u_rr, orientation::Integer,
                                     equations::ShallowWaterEquations2D)
 flux_nonconservative_fjordholm_etal(u_ll, u_rr,
                                     normal_direction_ll     ::AbstractVector,
                                     normal_direction_average::AbstractVector,
-                                    equations::ShallowWaterEquations2D)

    Non-symmetric two-point surface flux discretizing the nonconservative (source) term of that contains the gradient of the bottom topography ShallowWaterEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    This contains additional terms compared to flux_nonconservative_wintermeyer_etal that account for possible discontinuities in the bottom topography function. Thus, this flux should be used in general at interfaces. For flux differencing volume terms, flux_nonconservative_wintermeyer_etal is analytically equivalent but slightly cheaper.

    Further details for the original finite volume formulation are available in

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042

    and for curvilinear 2D case in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_nonconservative_powell — Method
    flux_nonconservative_powell(u_ll, u_rr, orientation::Integer,
+                                    equations::ShallowWaterEquations2D)

    Non-symmetric two-point surface flux discretizing the nonconservative (source) term of that contains the gradient of the bottom topography ShallowWaterEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    This contains additional terms compared to flux_nonconservative_wintermeyer_etal that account for possible discontinuities in the bottom topography function. Thus, this flux should be used in general at interfaces. For flux differencing volume terms, flux_nonconservative_wintermeyer_etal is analytically equivalent but slightly cheaper.

    Further details for the original finite volume formulation are available in

    • Ulrik S. Fjordholm, Siddhartha Mishr and Eitan Tadmor (2011) Well-balanced and energy stable schemes for the shallow water equations with discontinuous topography DOI: 10.1016/j.jcp.2011.03.042

    and for curvilinear 2D case in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_nonconservative_powell — Method
    flux_nonconservative_powell(u_ll, u_rr, orientation::Integer,
                             equations::IdealGlmMhdEquations2D)
 flux_nonconservative_powell(u_ll, u_rr,
                             normal_direction_ll     ::AbstractVector,
                             normal_direction_average::AbstractVector,
-                            equations::IdealGlmMhdEquations2D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    References

    • Marvin Bohm, Andrew R.Winters, Gregor J. Gassner, Dominik Derigs, Florian Hindenlang, Joachim Saur An entropy stable nodal discontinuous Galerkin method for the resistive MHD equations. Part I: Theory and numerical verification DOI: 10.1016/j.jcp.2018.06.027
    source
    Trixi.flux_nonconservative_powell — Method
    flux_nonconservative_powell(u_ll, u_rr, orientation::Integer,
+                            equations::IdealGlmMhdEquations2D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    References

    • Marvin Bohm, Andrew R.Winters, Gregor J. Gassner, Dominik Derigs, Florian Hindenlang, Joachim Saur An entropy stable nodal discontinuous Galerkin method for the resistive MHD equations. Part I: Theory and numerical verification DOI: 10.1016/j.jcp.2018.06.027
    source
    Trixi.flux_nonconservative_powell — Method
    flux_nonconservative_powell(u_ll, u_rr, orientation::Integer,
                             equations::IdealGlmMhdEquations3D)
 flux_nonconservative_powell(u_ll, u_rr,
                             normal_direction_ll     ::AbstractVector,
                             normal_direction_average::AbstractVector,
-                            equations::IdealGlmMhdEquations3D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdEquations3D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    References

    • Marvin Bohm, Andrew R.Winters, Gregor J. Gassner, Dominik Derigs, Florian Hindenlang, Joachim Saur An entropy stable nodal discontinuous Galerkin method for the resistive MHD equations. Part I: Theory and numerical verification DOI: 10.1016/j.jcp.2018.06.027
    source
    Trixi.flux_nonconservative_powell — Method
    flux_nonconservative_powell(u_ll, u_rr, orientation::Integer,
-                            equations::IdealGlmMhdMulticomponentEquations2D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdMulticomponentEquations2D.

    References

    • Marvin Bohm, Andrew R.Winters, Gregor J. Gassner, Dominik Derigs, Florian Hindenlang, Joachim Saur An entropy stable nodal discontinuous Galerkin method for the resistive MHD equations. Part I: Theory and numerical verification DOI: 10.1016/j.jcp.2018.06.027
    source
    Trixi.flux_nonconservative_powell_local_symmetric — Method
    flux_nonconservative_powell_local_symmetric(u_ll, orientation::Integer,
+                            equations::IdealGlmMhdEquations3D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdEquations3D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    References

    • Marvin Bohm, Andrew R.Winters, Gregor J. Gassner, Dominik Derigs, Florian Hindenlang, Joachim Saur An entropy stable nodal discontinuous Galerkin method for the resistive MHD equations. Part I: Theory and numerical verification DOI: 10.1016/j.jcp.2018.06.027
    source
    Trixi.flux_nonconservative_powell — Method
    flux_nonconservative_powell(u_ll, u_rr, orientation::Integer,
+                            equations::IdealGlmMhdMulticomponentEquations2D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdMulticomponentEquations2D.

    References

    • Marvin Bohm, Andrew R.Winters, Gregor J. Gassner, Dominik Derigs, Florian Hindenlang, Joachim Saur An entropy stable nodal discontinuous Galerkin method for the resistive MHD equations. Part I: Theory and numerical verification DOI: 10.1016/j.jcp.2018.06.027
    source
    Trixi.flux_nonconservative_powell_local_symmetric — Method
    flux_nonconservative_powell_local_symmetric(u_ll, orientation::Integer,
                                             equations::IdealGlmMhdEquations2D,
                                             nonconservative_type::NonConservativeSymmetric,
-                                            nonconservative_term::Integer)

    Symmetric part of the Powell and GLM non-conservative terms. Needed for the calculation of the non-conservative staggered "fluxes" for subcell limiting. See, e.g.,

    • Rueda-Ramírez, Gassner (2023). A Flux-Differencing Formula for Split-Form Summation By Parts Discretizations of Non-Conservative Systems. https://arxiv.org/pdf/2211.14009.pdf.

    This function is used to compute the subcell fluxes in dg2dsubcell_limiters.jl.

    source
    Trixi.flux_nonconservative_powell_local_symmetric — Method
    flux_nonconservative_powell_local_symmetric(u_ll, u_rr,
+                                            nonconservative_term::Integer)

    Symmetric part of the Powell and GLM non-conservative terms. Needed for the calculation of the non-conservative staggered "fluxes" for subcell limiting. See, e.g.,

    • Rueda-Ramírez, Gassner (2023). A Flux-Differencing Formula for Split-Form Summation By Parts Discretizations of Non-Conservative Systems. https://arxiv.org/pdf/2211.14009.pdf.

    This function is used to compute the subcell fluxes in dg2dsubcell_limiters.jl.

    source
    Trixi.flux_nonconservative_powell_local_symmetric — Method
    flux_nonconservative_powell_local_symmetric(u_ll, u_rr,
                                             orientation::Integer,
-                                            equations::IdealGlmMhdEquations2D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdEquations2D.

    This implementation uses a non-conservative term that can be written as the product of local and symmetric parts. It is equivalent to the non-conservative flux of Bohm et al. (flux_nonconservative_powell) for conforming meshes but it yields different results on non-conforming meshes(!).

    The two other flux functions with the same name return either the local or symmetric portion of the non-conservative flux based on the type of the nonconservativetype argument, employing multiple dispatch. They are used to compute the subcell fluxes in dg2dsubcelllimiters.jl.

    References

    • Rueda-Ramírez, Gassner (2023). A Flux-Differencing Formula for Split-Form Summation By Parts Discretizations of Non-Conservative Systems. https://arxiv.org/pdf/2211.14009.pdf.
    source
    Trixi.flux_nonconservative_powell_local_symmetric — Method
    flux_nonconservative_powell_local_symmetric(u_ll, orientation::Integer,
+                                            equations::IdealGlmMhdEquations2D)

    Non-symmetric two-point flux discretizing the nonconservative (source) term of Powell and the Galilean nonconservative term associated with the GLM multiplier of the IdealGlmMhdEquations2D.

    This implementation uses a non-conservative term that can be written as the product of local and symmetric parts. It is equivalent to the non-conservative flux of Bohm et al. (flux_nonconservative_powell) for conforming meshes but it yields different results on non-conforming meshes(!).

    The two other flux functions with the same name return either the local or symmetric portion of the non-conservative flux based on the type of the nonconservativetype argument, employing multiple dispatch. They are used to compute the subcell fluxes in dg2dsubcelllimiters.jl.

    References

    • Rueda-Ramírez, Gassner (2023). A Flux-Differencing Formula for Split-Form Summation By Parts Discretizations of Non-Conservative Systems. https://arxiv.org/pdf/2211.14009.pdf.
    source
    Trixi.flux_nonconservative_powell_local_symmetric — Method
    flux_nonconservative_powell_local_symmetric(u_ll, orientation::Integer,
                                             equations::IdealGlmMhdEquations2D,
                                             nonconservative_type::NonConservativeLocal,
-                                            nonconservative_term::Integer)

    Local part of the Powell and GLM non-conservative terms. Needed for the calculation of the non-conservative staggered "fluxes" for subcell limiting. See, e.g.,

    • Rueda-Ramírez, Gassner (2023). A Flux-Differencing Formula for Split-Form Summation By Parts Discretizations of Non-Conservative Systems. https://arxiv.org/pdf/2211.14009.pdf.

    This function is used to compute the subcell fluxes in dg2dsubcell_limiters.jl.

    source
    Trixi.flux_nonconservative_wintermeyer_etal — Method
    flux_nonconservative_wintermeyer_etal(u_ll, u_rr, orientation::Integer,
-                                      equations::ShallowWaterEquations1D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations1D.

    Further details are available in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_nonconservative_wintermeyer_etal — Method
    flux_nonconservative_wintermeyer_etal(u_ll, u_rr, orientation::Integer,
+                                            nonconservative_term::Integer)

    Local part of the Powell and GLM non-conservative terms. Needed for the calculation of the non-conservative staggered "fluxes" for subcell limiting. See, e.g.,

    • Rueda-Ramírez, Gassner (2023). A Flux-Differencing Formula for Split-Form Summation By Parts Discretizations of Non-Conservative Systems. https://arxiv.org/pdf/2211.14009.pdf.

    This function is used to compute the subcell fluxes in dg2dsubcell_limiters.jl.

    source
    Trixi.flux_nonconservative_wintermeyer_etal — Method
    flux_nonconservative_wintermeyer_etal(u_ll, u_rr, orientation::Integer,
+                                      equations::ShallowWaterEquations1D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations1D.

    Further details are available in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_nonconservative_wintermeyer_etal — Method
    flux_nonconservative_wintermeyer_etal(u_ll, u_rr, orientation::Integer,
                                       equations::ShallowWaterEquations2D)
 flux_nonconservative_wintermeyer_etal(u_ll, u_rr,
                                       normal_direction_ll     ::AbstractVector,
                                       normal_direction_average::AbstractVector,
-                                      equations::ShallowWaterEquations2D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    Further details are available in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction, equations::CompressibleEulerEquations1D)

    Entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
-             equations::CompressibleEulerEquations2D)

    Entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
-             equations::CompressibleEulerEquations3D)

    Entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
-             equations::CompressibleEulerMulticomponentEquations1D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
-             equations::CompressibleEulerMulticomponentEquations2D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_shima_etal — Method
    flux_shima_etal(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    This flux is is a modification of the original kinetic energy preserving two-point flux by

    • Yuichi Kuya, Kosuke Totani and Soshi Kawai (2018) Kinetic energy and entropy preserving schemes for compressible flows by split convective forms DOI: 10.1016/j.jcp.2018.08.058

    The modification is in the energy flux to guarantee pressure equilibrium and was developed by

    • Nao Shima, Yuichi Kuya, Yoshiharu Tamaki, Soshi Kawai (JCP 2020) Preventing spurious pressure oscillations in split convective form discretizations for compressible flows DOI: 10.1016/j.jcp.2020.110060
    source
    Trixi.flux_shima_etal — Method
    flux_shima_etal(u_ll, u_rr, orientation_or_normal_direction,
-                equations::CompressibleEulerEquations2D)

    This flux is is a modification of the original kinetic energy preserving two-point flux by

    • Yuichi Kuya, Kosuke Totani and Soshi Kawai (2018) Kinetic energy and entropy preserving schemes for compressible flows by split convective forms DOI: 10.1016/j.jcp.2018.08.058

    The modification is in the energy flux to guarantee pressure equilibrium and was developed by

    • Nao Shima, Yuichi Kuya, Yoshiharu Tamaki, Soshi Kawai (JCP 2020) Preventing spurious pressure oscillations in split convective form discretizations for compressible flows DOI: 10.1016/j.jcp.2020.110060
    source
    Trixi.flux_shima_etal — Method
    flux_shima_etal(u_ll, u_rr, orientation_or_normal_direction,
-                equations::CompressibleEulerEquations3D)

    This flux is is a modification of the original kinetic energy preserving two-point flux by

    • Yuichi Kuya, Kosuke Totani and Soshi Kawai (2018) Kinetic energy and entropy preserving schemes for compressible flows by split convective forms DOI: 10.1016/j.jcp.2018.08.058

    The modification is in the energy flux to guarantee pressure equilibrium and was developed by

    • Nao Shima, Yuichi Kuya, Yoshiharu Tamaki, Soshi Kawai (JCP 2020) Preventing spurious pressure oscillations in split convective form discretizations for compressible flows DOI: 10.1016/j.jcp.2020.110060
    source
    Trixi.flux_wintermeyer_etal — Method
    flux_wintermeyer_etal(u_ll, u_rr, orientation,
-                      equations::ShallowWaterEquations1D)

    Total energy conservative (mathematical entropy for shallow water equations) split form. When the bottom topography is nonzero this scheme will be well-balanced when used as a volume_flux. The surface_flux should still use, e.g., flux_fjordholm_etal.

    Further details are available in Theorem 1 of the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_wintermeyer_etal — Method
    flux_wintermeyer_etal(u_ll, u_rr, orientation_or_normal_direction,
-                      equations::ShallowWaterEquations2D)

    Total energy conservative (mathematical entropy for shallow water equations) split form. When the bottom topography is nonzero this scheme will be well-balanced when used as a volume_flux. The surface_flux should still use, e.g., flux_fjordholm_etal.

    Further details are available in Theorem 1 of the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_winters_etal — Method
    flux_winters_etal(u_ll, u_rr, orientation_or_normal_direction,
-                  equations::PolytropicEulerEquations2D)

    Entropy conserving two-point flux for isothermal or polytropic gases. Requires a special weighted Stolarsky mean for the evaluation of the density denoted here as stolarsky_mean. Note, for isothermal gases where gamma = 1 this stolarsky_mean becomes the ln_mean.

    For details see Section 3.2 of the following reference

    • Andrew R. Winters, Christof Czernik, Moritz B. Schily & Gregor J. Gassner (2020) Entropy stable numerical approximations for the isothermal and polytropic Euler equations DOI: 10.1007/s10543-019-00789-w
    source
    Trixi.get_boundary_outer_state — Method
    get_boundary_outer_state(boundary_condition::BoundaryConditionDirichlet,
-                         cache, t, equations, dg, indices...)

    For subcell limiting, the calculation of local bounds for non-periodic domains require the boundary outer state. This function returns the boundary value at time t and for node with spatial indices indices.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    source
    Trixi.get_name — Method
    get_name(x)

    Returns a name of x ready for pretty printing. By default, return string(y) if x isa Val{y} and return string(x) otherwise.

    Examples

    julia> Trixi.get_name("test")
+                                      equations::ShallowWaterEquations2D)

    Non-symmetric two-point volume flux discretizing the nonconservative (source) term that contains the gradient of the bottom topography ShallowWaterEquations2D.

    On curvilinear meshes, this nonconservative flux depends on both the contravariant vector (normal direction) at the current node and the averaged one. This is different from numerical fluxes used to discretize conservative terms.

    Further details are available in the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction, equations::CompressibleEulerEquations1D)

    Entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
+             equations::CompressibleEulerEquations2D)

    Entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
+             equations::CompressibleEulerEquations3D)

    Entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
+             equations::CompressibleEulerMulticomponentEquations1D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_ranocha — Method
    flux_ranocha(u_ll, u_rr, orientation_or_normal_direction,
+             equations::CompressibleEulerMulticomponentEquations2D)

    Adaption of the entropy conserving and kinetic energy preserving two-point flux by

    • Hendrik Ranocha (2018) Generalised Summation-by-Parts Operators and Entropy Stability of Numerical Methods for Hyperbolic Balance Laws PhD thesis, TU Braunschweig

    See also

    • Hendrik Ranocha (2020) Entropy Conserving and Kinetic Energy Preserving Numerical Methods for the Euler Equations Using Summation-by-Parts Operators Proceedings of ICOSAHOM 2018
    source
    Trixi.flux_shima_etal — Method
    flux_shima_etal(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    This flux is is a modification of the original kinetic energy preserving two-point flux by

    • Yuichi Kuya, Kosuke Totani and Soshi Kawai (2018) Kinetic energy and entropy preserving schemes for compressible flows by split convective forms DOI: 10.1016/j.jcp.2018.08.058

    The modification is in the energy flux to guarantee pressure equilibrium and was developed by

    • Nao Shima, Yuichi Kuya, Yoshiharu Tamaki, Soshi Kawai (JCP 2020) Preventing spurious pressure oscillations in split convective form discretizations for compressible flows DOI: 10.1016/j.jcp.2020.110060
    source
    Trixi.flux_shima_etal — Method
    flux_shima_etal(u_ll, u_rr, orientation_or_normal_direction,
+                equations::CompressibleEulerEquations2D)

    This flux is is a modification of the original kinetic energy preserving two-point flux by

    • Yuichi Kuya, Kosuke Totani and Soshi Kawai (2018) Kinetic energy and entropy preserving schemes for compressible flows by split convective forms DOI: 10.1016/j.jcp.2018.08.058

    The modification is in the energy flux to guarantee pressure equilibrium and was developed by

    • Nao Shima, Yuichi Kuya, Yoshiharu Tamaki, Soshi Kawai (JCP 2020) Preventing spurious pressure oscillations in split convective form discretizations for compressible flows DOI: 10.1016/j.jcp.2020.110060
    source
    Trixi.flux_shima_etal — Method
    flux_shima_etal(u_ll, u_rr, orientation_or_normal_direction,
+                equations::CompressibleEulerEquations3D)

    This flux is is a modification of the original kinetic energy preserving two-point flux by

    • Yuichi Kuya, Kosuke Totani and Soshi Kawai (2018) Kinetic energy and entropy preserving schemes for compressible flows by split convective forms DOI: 10.1016/j.jcp.2018.08.058

    The modification is in the energy flux to guarantee pressure equilibrium and was developed by

    • Nao Shima, Yuichi Kuya, Yoshiharu Tamaki, Soshi Kawai (JCP 2020) Preventing spurious pressure oscillations in split convective form discretizations for compressible flows DOI: 10.1016/j.jcp.2020.110060
    source
    Trixi.flux_wintermeyer_etal — Method
    flux_wintermeyer_etal(u_ll, u_rr, orientation,
+                      equations::ShallowWaterEquations1D)

    Total energy conservative (mathematical entropy for shallow water equations) split form. When the bottom topography is nonzero this scheme will be well-balanced when used as a volume_flux. The surface_flux should still use, e.g., flux_fjordholm_etal.

    Further details are available in Theorem 1 of the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_wintermeyer_etal — Method
    flux_wintermeyer_etal(u_ll, u_rr, orientation_or_normal_direction,
+                      equations::ShallowWaterEquations2D)

    Total energy conservative (mathematical entropy for shallow water equations) split form. When the bottom topography is nonzero this scheme will be well-balanced when used as a volume_flux. The surface_flux should still use, e.g., flux_fjordholm_etal.

    Further details are available in Theorem 1 of the paper:

    • Niklas Wintermeyer, Andrew R. Winters, Gregor J. Gassner and David A. Kopriva (2017) An entropy stable nodal discontinuous Galerkin method for the two dimensional shallow water equations on unstructured curvilinear meshes with discontinuous bathymetry DOI: 10.1016/j.jcp.2017.03.036
    source
    Trixi.flux_winters_etal — Method
    flux_winters_etal(u_ll, u_rr, orientation_or_normal_direction,
+                  equations::PolytropicEulerEquations2D)

    Entropy conserving two-point flux for isothermal or polytropic gases. Requires a special weighted Stolarsky mean for the evaluation of the density denoted here as stolarsky_mean. Note, for isothermal gases where gamma = 1 this stolarsky_mean becomes the ln_mean.

    For details see Section 3.2 of the following reference

    • Andrew R. Winters, Christof Czernik, Moritz B. Schily & Gregor J. Gassner (2020) Entropy stable numerical approximations for the isothermal and polytropic Euler equations DOI: 10.1007/s10543-019-00789-w
    source
    Trixi.get_boundary_outer_state — Method
    get_boundary_outer_state(boundary_condition::BoundaryConditionDirichlet,
+                         cache, t, equations, dg, indices...)

    For subcell limiting, the calculation of local bounds for non-periodic domains require the boundary outer state. This function returns the boundary value at time t and for node with spatial indices indices.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    source
    Trixi.get_name — Method
    get_name(x)

    Returns a name of x ready for pretty printing. By default, return string(y) if x isa Val{y} and return string(x) otherwise.

    Examples

    julia> Trixi.get_name("test")
 "test"
 
 julia> Trixi.get_name(Val(:test))
-"test"
    source
    Trixi.get_name — Method
    get_name(equations::AbstractEquations)

    Returns the canonical, human-readable name for the given system of equations.

    Examples

    julia> Trixi.get_name(CompressibleEulerEquations1D(1.4))
-"CompressibleEulerEquations1D"
    source
    Trixi.getmesh — Method
    getmesh(pd::AbstractPlotData)

    Extract grid lines from pd for plotting with Plots.plot.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    source
    Trixi.global_mean_vars — Method
    global_mean_vars(equations::AcousticPerturbationEquations2D)

    Returns the global mean variables stored in equations. This makes it easier to define flexible initial conditions for problems with constant mean flow.

    source
    Trixi.have_nonconservative_terms — Method
    have_nonconservative_terms(equations)

    Trait function determining whether equations represent a conservation law with or without nonconservative terms. Classical conservation laws such as the CompressibleEulerEquations2D do not have nonconservative terms. The ShallowWaterEquations2D with non-constant bottom topography are an example of equations with nonconservative terms. The return value will be True() or False() to allow dispatching on the return type.

    source
    Trixi.hydrostatic_reconstruction_audusse_etal — Method
    hydrostatic_reconstruction_audusse_etal(u_ll, u_rr, orientation::Integer,
-                                        equations::ShallowWaterEquations1D)

    A particular type of hydrostatic reconstruction on the water height to guarantee well-balancedness for a general bottom topography ShallowWaterEquations1D. The reconstructed solution states u_ll_star and u_rr_star variables are then used to evaluate the surface numerical flux at the interface. Use in combination with the generic numerical flux routine FluxHydrostaticReconstruction.

    Further details on this hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.hydrostatic_reconstruction_audusse_etal — Method
    hydrostatic_reconstruction_audusse_etal(u_ll, u_rr, orientation_or_normal_direction,
-                                        equations::ShallowWaterEquations2D)

    A particular type of hydrostatic reconstruction on the water height to guarantee well-balancedness for a general bottom topography ShallowWaterEquations2D. The reconstructed solution states u_ll_star and u_rr_star variables are used to evaluate the surface numerical flux at the interface. Use in combination with the generic numerical flux routine FluxHydrostaticReconstruction.

    Further details for the hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.init_mpi — Method
    init_mpi()

    Initialize MPI by calling MPI.Initialized(). The function will check if MPI is already initialized and if yes, do nothing, thus it is safe to call it multiple times.

    source
    Trixi.init_p4est — Method
    init_p4est()

    Initialize p4est by calling p4est_init and setting the log level to SC_LP_ERROR. This function will check if p4est is already initialized and if yes, do nothing, thus it is safe to call it multiple times.

    source
    Trixi.init_t8code — Method
    init_t8code()

    Initialize t8code by calling sc_init, p4est_init, and t8_init while setting the log level to SC_LP_ERROR. This function will check if t8code is already initialized and if yes, do nothing, thus it is safe to call it multiple times.

    source
    Trixi.initial_condition_constant — Method
    initial_condition_constant(x, t, equations::AcousticPerturbationEquations2D)

    A constant initial condition where the state variables are zero and the mean flow is constant. Uses the global mean values from equations.

    source
    Trixi.initial_condition_density_wave — Method
    initial_condition_density_wave(x, t, equations::CompressibleEulerEquations1D)

    A sine wave in the density with constant velocity and pressure; reduces the compressible Euler equations to the linear advection equations. This setup is the test case for stability of EC fluxes from paper

    • Gregor J. Gassner, Magnus Svärd, Florian J. Hindenlang (2020) Stability issues of entropy-stable and/or split-form high-order schemes arXiv: 2007.09026

    with the following parameters

    • domain [-1, 1]
    • mesh = 4x4
    • polydeg = 5
    source
    Trixi.initial_condition_density_wave — Method
    initial_condition_density_wave(x, t, equations::CompressibleEulerEquations2D)

    A sine wave in the density with constant velocity and pressure; reduces the compressible Euler equations to the linear advection equations. This setup is the test case for stability of EC fluxes from paper

    • Gregor J. Gassner, Magnus Svärd, Florian J. Hindenlang (2020) Stability issues of entropy-stable and/or split-form high-order schemes arXiv: 2007.09026

    with the following parameters

    • domain [-1, 1]
    • mesh = 4x4
    • polydeg = 5
    source
    Trixi.initial_condition_eoc_test_coupled_euler_gravity — Method
    initial_condition_eoc_test_coupled_euler_gravity(x, t, equations::CompressibleEulerEquations1D)

    One dimensional variant of the setup used for convergence tests of the Euler equations with self-gravity from

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593
    Note

    There is no additional source term necessary for the manufactured solution in one spatial dimension. Thus, source_terms_eoc_test_coupled_euler_gravity is not present there.

    source
    Trixi.initial_condition_eoc_test_coupled_euler_gravity — Method
    initial_condition_eoc_test_coupled_euler_gravity(x, t, equations::CompressibleEulerEquations2D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with source_terms_eoc_test_coupled_euler_gravity or source_terms_eoc_test_euler.

    source
    Trixi.initial_condition_eoc_test_coupled_euler_gravity — Method
    initial_condition_eoc_test_coupled_euler_gravity(x, t, equations::CompressibleEulerEquations3D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with source_terms_eoc_test_coupled_euler_gravity or source_terms_eoc_test_euler.

    source
    Trixi.initial_condition_gauss — Method
    initial_condition_gauss(x, t, equations::AcousticPerturbationEquations2D)

    A Gaussian pulse in a constant mean flow. Uses the global mean values from equations.

    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerEquations1D)

    A weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerEquations2D)

    A weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerEquations3D)

    A weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerMulticomponentEquations1D)

    A for multicomponent adapted weak blast wave adapted to multicomponent and taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerMulticomponentEquations2D)

    A for multicomponent adapted weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdEquations1D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdEquations2D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdEquations3D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdMulticomponentEquations1D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdMulticomponentEquations2D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::PolytropicEulerEquations2D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::ShallowWaterEquations1D)

    A weak blast wave discontinuity useful for testing, e.g., total energy conservation. Note for the shallow water equations to the total energy acts as a mathematical entropy function.

    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::ShallowWaterEquations2D)

    A weak blast wave discontinuity useful for testing, e.g., total energy conservation. Note for the shallow water equations to the total energy acts as a mathematical entropy function.

    source
    Trixi.integrate_via_indices — Method
    integrate_via_indices(func, u_ode, semi::AbstractSemidiscretization, args...; normalize=true)

    Call func(u, i..., element, equations, solver, args...) for all nodal indices i..., element and integrate the result using a quadrature associated with the semidiscretization semi.

    If normalize is true, the result is divided by the total volume of the computational domain.

    source
    Trixi.inv_ln_mean — Method
    inv_ln_mean(x, y)

    Compute the inverse 1 / ln_mean(x, y) of the logarithmic mean ln_mean.

    This function may be used to increase performance where the inverse of the logarithmic mean is needed, by replacing a (slow) division by a (fast) multiplication.

    source
    Trixi.get_name — Method
    get_name(equations::AbstractEquations)

    Returns the canonical, human-readable name for the given system of equations.

    Examples

    julia> Trixi.get_name(CompressibleEulerEquations1D(1.4))
+"CompressibleEulerEquations1D"
    source
    Trixi.getmesh — Method
    getmesh(pd::AbstractPlotData)

    Extract grid lines from pd for plotting with Plots.plot.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    source
    Trixi.global_mean_vars — Method
    global_mean_vars(equations::AcousticPerturbationEquations2D)

    Returns the global mean variables stored in equations. This makes it easier to define flexible initial conditions for problems with constant mean flow.

    source
    Trixi.have_nonconservative_terms — Method
    have_nonconservative_terms(equations)

    Trait function determining whether equations represent a conservation law with or without nonconservative terms. Classical conservation laws such as the CompressibleEulerEquations2D do not have nonconservative terms. The ShallowWaterEquations2D with non-constant bottom topography are an example of equations with nonconservative terms. The return value will be True() or False() to allow dispatching on the return type.

    source
    Trixi.hydrostatic_reconstruction_audusse_etal — Method
    hydrostatic_reconstruction_audusse_etal(u_ll, u_rr, orientation::Integer,
+                                        equations::ShallowWaterEquations1D)

    A particular type of hydrostatic reconstruction on the water height to guarantee well-balancedness for a general bottom topography ShallowWaterEquations1D. The reconstructed solution states u_ll_star and u_rr_star variables are then used to evaluate the surface numerical flux at the interface. Use in combination with the generic numerical flux routine FluxHydrostaticReconstruction.

    Further details on this hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.hydrostatic_reconstruction_audusse_etal — Method
    hydrostatic_reconstruction_audusse_etal(u_ll, u_rr, orientation_or_normal_direction,
+                                        equations::ShallowWaterEquations2D)

    A particular type of hydrostatic reconstruction on the water height to guarantee well-balancedness for a general bottom topography ShallowWaterEquations2D. The reconstructed solution states u_ll_star and u_rr_star variables are used to evaluate the surface numerical flux at the interface. Use in combination with the generic numerical flux routine FluxHydrostaticReconstruction.

    Further details for the hydrostatic reconstruction and its motivation can be found in

    • Emmanuel Audusse, François Bouchut, Marie-Odile Bristeau, Rupert Klein, and Benoit Perthame (2004) A fast and stable well-balanced scheme with hydrostatic reconstruction for shallow water flows DOI: 10.1137/S1064827503431090
    source
    Trixi.init_mpi — Method
    init_mpi()

    Initialize MPI by calling MPI.Initialized(). The function will check if MPI is already initialized and if yes, do nothing, thus it is safe to call it multiple times.

    source
    Trixi.init_p4est — Method
    init_p4est()

    Initialize p4est by calling p4est_init and setting the log level to SC_LP_ERROR. This function will check if p4est is already initialized and if yes, do nothing, thus it is safe to call it multiple times.

    source
    Trixi.init_t8code — Method
    init_t8code()

    Initialize t8code by calling sc_init, p4est_init, and t8_init while setting the log level to SC_LP_ERROR. This function will check if t8code is already initialized and if yes, do nothing, thus it is safe to call it multiple times.

    source
    Trixi.initial_condition_constant — Method
    initial_condition_constant(x, t, equations::AcousticPerturbationEquations2D)

    A constant initial condition where the state variables are zero and the mean flow is constant. Uses the global mean values from equations.

    source
    Trixi.initial_condition_density_wave — Method
    initial_condition_density_wave(x, t, equations::CompressibleEulerEquations1D)

    A sine wave in the density with constant velocity and pressure; reduces the compressible Euler equations to the linear advection equations. This setup is the test case for stability of EC fluxes from paper

    • Gregor J. Gassner, Magnus Svärd, Florian J. Hindenlang (2020) Stability issues of entropy-stable and/or split-form high-order schemes arXiv: 2007.09026

    with the following parameters

    • domain [-1, 1]
    • mesh = 4x4
    • polydeg = 5
    source
    Trixi.initial_condition_density_wave — Method
    initial_condition_density_wave(x, t, equations::CompressibleEulerEquations2D)

    A sine wave in the density with constant velocity and pressure; reduces the compressible Euler equations to the linear advection equations. This setup is the test case for stability of EC fluxes from paper

    • Gregor J. Gassner, Magnus Svärd, Florian J. Hindenlang (2020) Stability issues of entropy-stable and/or split-form high-order schemes arXiv: 2007.09026

    with the following parameters

    • domain [-1, 1]
    • mesh = 4x4
    • polydeg = 5
    source
    Trixi.initial_condition_eoc_test_coupled_euler_gravity — Method
    initial_condition_eoc_test_coupled_euler_gravity(x, t, equations::CompressibleEulerEquations1D)

    One dimensional variant of the setup used for convergence tests of the Euler equations with self-gravity from

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593
    Note

    There is no additional source term necessary for the manufactured solution in one spatial dimension. Thus, source_terms_eoc_test_coupled_euler_gravity is not present there.

    source
    Trixi.initial_condition_eoc_test_coupled_euler_gravity — Method
    initial_condition_eoc_test_coupled_euler_gravity(x, t, equations::CompressibleEulerEquations2D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with source_terms_eoc_test_coupled_euler_gravity or source_terms_eoc_test_euler.

    source
    Trixi.initial_condition_eoc_test_coupled_euler_gravity — Method
    initial_condition_eoc_test_coupled_euler_gravity(x, t, equations::CompressibleEulerEquations3D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with source_terms_eoc_test_coupled_euler_gravity or source_terms_eoc_test_euler.

    source
    Trixi.initial_condition_gauss — Method
    initial_condition_gauss(x, t, equations::AcousticPerturbationEquations2D)

    A Gaussian pulse in a constant mean flow. Uses the global mean values from equations.

    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerEquations1D)

    A weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerEquations2D)

    A weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerEquations3D)

    A weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerMulticomponentEquations1D)

    A for multicomponent adapted weak blast wave adapted to multicomponent and taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::CompressibleEulerMulticomponentEquations2D)

    A for multicomponent adapted weak blast wave taken from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdEquations1D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdEquations2D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdEquations3D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdMulticomponentEquations1D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::IdealGlmMhdMulticomponentEquations2D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::PolytropicEulerEquations2D)

    A weak blast wave adapted from

    • Sebastian Hennemann, Gregor J. Gassner (2020) A provably entropy stable subcell shock capturing approach for high order split form DG arXiv: 2008.12044
    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::ShallowWaterEquations1D)

    A weak blast wave discontinuity useful for testing, e.g., total energy conservation. Note for the shallow water equations to the total energy acts as a mathematical entropy function.

    source
    Trixi.initial_condition_weak_blast_wave — Method
    initial_condition_weak_blast_wave(x, t, equations::ShallowWaterEquations2D)

    A weak blast wave discontinuity useful for testing, e.g., total energy conservation. Note for the shallow water equations to the total energy acts as a mathematical entropy function.

    source
    Trixi.integrate_via_indices — Method
    integrate_via_indices(func, u_ode, semi::AbstractSemidiscretization, args...; normalize=true)

    Call func(u, i..., element, equations, solver, args...) for all nodal indices i..., element and integrate the result using a quadrature associated with the semidiscretization semi.

    If normalize is true, the result is divided by the total volume of the computational domain.

    source
    Trixi.inv_ln_mean — Method
    inv_ln_mean(x, y)

    Compute the inverse 1 / ln_mean(x, y) of the logarithmic mean ln_mean.

    This function may be used to increase performance where the inverse of the logarithmic mean is needed, by replacing a (slow) division by a (fast) multiplication.

    source
    Trixi.jacobian_ad_forward — Method
    jacobian_ad_forward(semi::AbstractSemidiscretization;
                     t0=zero(real(semi)),
-                    u0_ode=compute_coefficients(t0, semi))

    Uses the right-hand side operator of the semidiscretization semi and forward mode automatic differentiation to compute the Jacobian J of the semidiscretization semi at state u0_ode.

    source
    Trixi.jacobian_fd — Method
    jacobian_fd(semi::AbstractSemidiscretization;
+                    u0_ode=compute_coefficients(t0, semi))

    Uses the right-hand side operator of the semidiscretization semi and forward mode automatic differentiation to compute the Jacobian J of the semidiscretization semi at state u0_ode.

    source
    Trixi.jacobian_fd — Method
    jacobian_fd(semi::AbstractSemidiscretization;
             t0=zero(real(semi)),
-            u0_ode=compute_coefficients(t0, semi))

    Uses the right-hand side operator of the semidiscretization semi and simple second order finite difference to compute the Jacobian J of the semidiscretization semi at state u0_ode.

    source
    Trixi.linear_structure — Method
    linear_structure(semi::AbstractSemidiscretization;
-                 t0=zero(real(semi)))

    Wraps the right-hand side operator of the semidiscretization semi at time t0 as an affine-linear operator given by a linear operator A and a vector b.

    source
    Trixi.ln_mean — Method
    ln_mean(x, y)

    Compute the logarithmic mean

    ln_mean(x, y) = (y - x) / (log(y) - log(x)) = (y - x) / log(y / x)

    Problem: The formula above has a removable singularity at x == y. Thus, some care must be taken to implement it correctly without problems or loss of accuracy when x ≈ y. Here, we use the approach proposed by Ismail and Roe (2009). Set ξ = y / x. Then, we have

    (y - x) / log(y / x) = (x + y) / log(ξ) * (ξ - 1) / (ξ + 1)

    Set f = (ξ - 1) / (ξ + 1) = (y - x) / (x + y). Then, we use the expansion

    log(ξ) = 2 * f * (1 + f^2 / 3 + f^4 / 5 + f^6 / 7) + O(ξ^9)

    Inserting the first few terms of this expansion yields

    (y - x) / log(ξ) ≈ (x + y) * f / (2 * f * (1 + f^2 / 3 + f^4 / 5 + f^6 / 7))
+            u0_ode=compute_coefficients(t0, semi))

    Uses the right-hand side operator of the semidiscretization semi and simple second order finite difference to compute the Jacobian J of the semidiscretization semi at state u0_ode.

    source
    Trixi.linear_structure — Method
    linear_structure(semi::AbstractSemidiscretization;
+                 t0=zero(real(semi)))

    Wraps the right-hand side operator of the semidiscretization semi at time t0 as an affine-linear operator given by a linear operator A and a vector b.

    source
    Trixi.ln_mean — Method
    ln_mean(x, y)

    Compute the logarithmic mean

    ln_mean(x, y) = (y - x) / (log(y) - log(x)) = (y - x) / log(y / x)

    Problem: The formula above has a removable singularity at x == y. Thus, some care must be taken to implement it correctly without problems or loss of accuracy when x ≈ y. Here, we use the approach proposed by Ismail and Roe (2009). Set ξ = y / x. Then, we have

    (y - x) / log(y / x) = (x + y) / log(ξ) * (ξ - 1) / (ξ + 1)

    Set f = (ξ - 1) / (ξ + 1) = (y - x) / (x + y). Then, we use the expansion

    log(ξ) = 2 * f * (1 + f^2 / 3 + f^4 / 5 + f^6 / 7) + O(ξ^9)

    Inserting the first few terms of this expansion yields

    (y - x) / log(ξ) ≈ (x + y) * f / (2 * f * (1 + f^2 / 3 + f^4 / 5 + f^6 / 7))
                  = (x + y) / (2 + 2/3 * f^2 + 2/5 * f^4 + 2/7 * f^6)

    Since divisions are usually more expensive on modern hardware than multiplications (Agner Fog), we try to avoid computing two divisions. Thus, we use

    f^2 = (y - x)^2 / (x + y)^2
     = (x * (x - 2 * y) + y * y) / (x * (x + 2 * y) + y * y)

    Given ε = 1.0e-4, we use the following algorithm.

    if f^2 < ε
   # use the expansion above
 else
   # use the direct formula (y - x) / log(y / x)
-end

    References

    source
    Trixi.load_adaptive_time_integrator! — Method
    load_adaptive_time_integrator!(integrator, restart_file::AbstractString)

    Load the context information for time integrators with error-based step size control saved in a restart_file.

    source
    Trixi.load_dt — Method
    load_dt(restart_file::AbstractString)

    Load the time step size (dt in OrdinaryDiffEq.jl) saved in a restart_file.

    source
    Trixi.load_mesh — Method
    load_mesh(restart_file::AbstractString; n_cells_max)

    Load the mesh from the restart_file.

    source
    Trixi.load_time — Method
    load_time(restart_file::AbstractString)

    Load the time saved in a restart_file.

    source
    Trixi.load_timestep! — Method
    load_timestep!(integrator, restart_file::AbstractString)

    Load the time step number saved in a restart_file and assign it to both the time step number and and the number of accepted steps (iter and stats.naccept in OrdinaryDiffEq.jl, respectively) in integrator.

    source
    Trixi.load_timestep — Method
    load_timestep(restart_file::AbstractString)

    Load the time step number (iter in OrdinaryDiffEq.jl) saved in a restart_file.

    source
    Trixi.max — Method
    max(x, y, ...)

    Return the maximum of the arguments. See also the maximum function to take the maximum element from a collection.

    This version in Trixi.jl is semantically equivalent to Base.max but may be implemented differently. In particular, it may avoid potentially expensive checks necessary in the presence of NaNs (or signed zeros).

    Examples

    julia> max(2, 5, 1)
-5
    source
    Trixi.max_abs_speed_naive — Function
    max_abs_speed_naive(u_ll, u_rr, orientation::Integer,   equations)
-max_abs_speed_naive(u_ll, u_rr, normal_direction::AbstractVector, equations)

    Simple and fast estimate of the maximal wave speed of the Riemann problem with left and right states u_ll, u_rr, based only on the local wave speeds associated to u_ll and u_rr.

    For non-integer arguments normal_direction in one dimension, max_abs_speed_naive returns abs(normal_direction[1]) * max_abs_speed_naive(u_ll, u_rr, 1, equations).

    source
    Trixi.min — Method
    min(x, y, ...)

    Return the minimum of the arguments. See also the minimum function to take the minimum element from a collection.

    This version in Trixi.jl is semantically equivalent to Base.min but may be implemented differently. In particular, it may avoid potentially expensive checks necessary in the presence of NaNs (or signed zeros).

    Examples

    julia> min(2, 5, 1)
-1
    source
    Trixi.min_max_speed_davis — Function
    min_max_speed_davis(u_ll, u_rr, orientation::Integer, equations)
-min_max_speed_davis(u_ll, u_rr, normal_direction::AbstractVector, equations)

    Simple and fast estimates of the minimal and maximal wave speed of the Riemann problem with left and right states u_ll, u_rr, usually based only on the local wave speeds associated to u_ll and u_rr.

    See eq. (10.38) from

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction DOI: 10.1007/b79761

    See also FluxHLL, min_max_speed_naive, min_max_speed_einfeldt.

    source
    Trixi.min_max_speed_einfeldt — Function
    min_max_speed_einfeldt(u_ll, u_rr, orientation::Integer, equations)
-min_max_speed_einfeldt(u_ll, u_rr, normal_direction::AbstractVector, equations)

    More advanced mininmal and maximal wave speed computation based on

    originally developed for the compressible Euler equations. A compact representation can be found in this lecture notes, eq. (9.28).

    See also FluxHLL, min_max_speed_naive, min_max_speed_davis.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, normal_direction, equations::CompressibleEulerEquations2D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, normal_direction, equations::CompressibleEulerEquations3D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    Original publication:

    Compactly summarized:

    • Siddhartha Mishra, Ulrik Skre Fjordholm and Rémi Abgrall Numerical methods for conservation laws and related equations. Link
    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, orientation, equations::CompressibleEulerEquations2D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, orientation, equations::CompressibleEulerEquations3D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_naive — Function
    min_max_speed_naive(u_ll, u_rr, orientation::Integer, equations)
-min_max_speed_naive(u_ll, u_rr, normal_direction::AbstractVector, equations)

    Simple and fast estimate(!) of the minimal and maximal wave speed of the Riemann problem with left and right states u_ll, u_rr, usually based only on the local wave speeds associated to u_ll and u_rr. Slightly more diffusive than min_max_speed_davis.

    • Amiram Harten, Peter D. Lax, Bram van Leer (1983) On Upstream Differencing and Godunov-Type Schemes for Hyperbolic Conservation Laws DOI: 10.1137/1025002

    See eq. (10.37) from

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction DOI: 10.1007/b79761

    See also FluxHLL, min_max_speed_davis, min_max_speed_einfeldt.

    source
    Trixi.modify_dt_for_tstops! — Method
    modify_dt_for_tstops!(integrator::SimpleIntegratorSSP)

    Modify the time-step size to match the time stops specified in integrator.opts.tstops. To avoid adding OrdinaryDiffEq to Trixi's dependencies, this routine is a copy of https://github.com/SciML/OrdinaryDiffEq.jl/blob/d76335281c540ee5a6d1bd8bb634713e004f62ee/src/integrators/integrator_utils.jl#L38-L54

    source
    Trixi.multiply_dimensionwise — Method
    multiply_dimensionwise(matrix::AbstractMatrix, data_in::AbstractArray{<:Any, NDIMS+1})

    Multiply the array data_in by matrix in each coordinate direction, where data_in is assumed to have the first coordinate for the number of variables and the remaining coordinates are multiplied by matrix.

    source
    Trixi.n_nonconservative_terms — Function
    n_nonconservative_terms(equations)

    Number of nonconservative terms in the form local * symmetric for a particular equation. This function needs to be specialized only if equations with nonconservative terms are combined with certain solvers (e.g., subcell limiting).

    source
    Trixi.ndofs — Method
    ndofs(semi::AbstractSemidiscretization)

    Return the number of degrees of freedom associated with each scalar variable.

    source
    Trixi.negative_part — Method
    negative_part(x)

    Return x if x is negative, else zero. In other words, return (x - abs(x)) / 2 for real numbers x.

    source
    Trixi.ode_default_options — Method
    ode_default_options()

    Return the default options for OrdinaryDiffEq's solve. Pass ode_default_options()... to solve to only return the solution at the final time and enable MPI aware error-based step size control, whenever MPI is used. For example, use solve(ode, alg; ode_default_options()...).

    source
    Trixi.ode_norm — Method
    ode_norm(u, t)

    Implementation of the weighted L2 norm of Hairer and Wanner used for error-based step size control in OrdinaryDiffEq.jl. This function is aware of MPI and uses global MPI communication when running in parallel.

    You must pass this function as a keyword argument internalnorm=ode_norm to OrdinaryDiffEq.jl's solve when using error-based step size control with MPI parallel execution of Trixi.jl.

    See the "Advanced Adaptive Stepsize Control" section of the documentation.

    source
    Trixi.ode_unstable_check — Method
    ode_unstable_check(dt, u, semi, t)

    Implementation of the basic check for instability used in OrdinaryDiffEq.jl. Instead of checking something like any(isnan, u), this function just checks isnan(dt). This helps when using MPI parallelization, since no additional global communication is required and all ranks will return the same result.

    You should pass this function as a keyword argument unstable_check=ode_unstable_check to OrdinaryDiffEq.jl's solve when using error-based step size control with MPI parallel execution of Trixi.jl.

    See the "Miscellaneous" section of the documentation.

    source
    Trixi.partition! — Method
    Trixi.partition!(mesh::T8codeMesh)

    Partition a T8codeMesh in order to redistribute elements evenly among MPI ranks.

    Arguments

    • mesh::T8codeMesh: Initialized mesh object.
    source
    Trixi.partition! — Method
    partition!(mesh::ParallelTreeMesh, allow_coarsening=true)

    Partition mesh using a static domain decomposition algorithm based on leaf cell count and tree structure. If allow_coarsening is true, the algorithm will keep leaf cells together on one rank when needed for local coarsening (i.e. when all children of a cell are leaves).

    source
    Trixi.positive_part — Method
    positive_part(x)

    Return x if x is positive, else zero. In other words, return (x + abs(x)) / 2 for real numbers x.

    source
    Trixi.pressure — Method
    pressure(rho::Real, equations::LatticeBoltzmannEquations2D)
-pressure(u, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic pressure from the density rho or the particle distribution functions u.

    source
    Trixi.pressure — Method
    pressure(rho::Real, equations::LatticeBoltzmannEquations3D)
-pressure(u, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic pressure from the density rho or the particle distribution functions u.

    source
    Trixi.prim2cons — Function
    prim2cons(u, equations)

    Convert the primitive variables u to the conserved variables for a given set of equations. u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by cons2prim.

    source
    Trixi.rotate_from_x — Function
    rotate_from_x(u, normal, equations)

    Apply the rotation that maps the x-axis onto normal to the convservative variables u. This is used by FluxRotated to calculate the numerical flux of rotationally invariant equations in arbitrary normal directions.

    See also: rotate_to_x

    source
    Trixi.rotate_to_x — Function
    rotate_to_x(u, normal, equations)

    Apply the rotation that maps normal onto the x-axis to the convservative variables u. This is used by FluxRotated to calculate the numerical flux of rotationally invariant equations in arbitrary normal directions.

    See also: rotate_from_x

    source
    Trixi.load_adaptive_time_integrator! — Method
    load_adaptive_time_integrator!(integrator, restart_file::AbstractString)

    Load the context information for time integrators with error-based step size control saved in a restart_file.

    source
    Trixi.load_dt — Method
    load_dt(restart_file::AbstractString)

    Load the time step size (dt in OrdinaryDiffEq.jl) saved in a restart_file.

    source
    Trixi.load_mesh — Method
    load_mesh(restart_file::AbstractString; n_cells_max)

    Load the mesh from the restart_file.

    source
    Trixi.load_time — Method
    load_time(restart_file::AbstractString)

    Load the time saved in a restart_file.

    source
    Trixi.load_timestep! — Method
    load_timestep!(integrator, restart_file::AbstractString)

    Load the time step number saved in a restart_file and assign it to both the time step number and and the number of accepted steps (iter and stats.naccept in OrdinaryDiffEq.jl, respectively) in integrator.

    source
    Trixi.load_timestep — Method
    load_timestep(restart_file::AbstractString)

    Load the time step number (iter in OrdinaryDiffEq.jl) saved in a restart_file.

    source
    Trixi.max — Method
    max(x, y, ...)

    Return the maximum of the arguments. See also the maximum function to take the maximum element from a collection.

    This version in Trixi.jl is semantically equivalent to Base.max but may be implemented differently. In particular, it may avoid potentially expensive checks necessary in the presence of NaNs (or signed zeros).

    Examples

    julia> max(2, 5, 1)
+5
    source
    Trixi.max_abs_speed_naive — Function
    max_abs_speed_naive(u_ll, u_rr, orientation::Integer,   equations)
+max_abs_speed_naive(u_ll, u_rr, normal_direction::AbstractVector, equations)

    Simple and fast estimate of the maximal wave speed of the Riemann problem with left and right states u_ll, u_rr, based only on the local wave speeds associated to u_ll and u_rr.

    For non-integer arguments normal_direction in one dimension, max_abs_speed_naive returns abs(normal_direction[1]) * max_abs_speed_naive(u_ll, u_rr, 1, equations).

    source
    Trixi.min — Method
    min(x, y, ...)

    Return the minimum of the arguments. See also the minimum function to take the minimum element from a collection.

    This version in Trixi.jl is semantically equivalent to Base.min but may be implemented differently. In particular, it may avoid potentially expensive checks necessary in the presence of NaNs (or signed zeros).

    Examples

    julia> min(2, 5, 1)
+1
    source
    Trixi.min_max_speed_davis — Function
    min_max_speed_davis(u_ll, u_rr, orientation::Integer, equations)
+min_max_speed_davis(u_ll, u_rr, normal_direction::AbstractVector, equations)

    Simple and fast estimates of the minimal and maximal wave speed of the Riemann problem with left and right states u_ll, u_rr, usually based only on the local wave speeds associated to u_ll and u_rr.

    See eq. (10.38) from

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction DOI: 10.1007/b79761

    See also FluxHLL, min_max_speed_naive, min_max_speed_einfeldt.

    source
    Trixi.min_max_speed_einfeldt — Function
    min_max_speed_einfeldt(u_ll, u_rr, orientation::Integer, equations)
+min_max_speed_einfeldt(u_ll, u_rr, normal_direction::AbstractVector, equations)

    More advanced mininmal and maximal wave speed computation based on

    originally developed for the compressible Euler equations. A compact representation can be found in this lecture notes, eq. (9.28).

    See also FluxHLL, min_max_speed_naive, min_max_speed_davis.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, normal_direction, equations::CompressibleEulerEquations2D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, normal_direction, equations::CompressibleEulerEquations3D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, orientation, equations::CompressibleEulerEquations1D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    Original publication:

    Compactly summarized:

    • Siddhartha Mishra, Ulrik Skre Fjordholm and Rémi Abgrall Numerical methods for conservation laws and related equations. Link
    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, orientation, equations::CompressibleEulerEquations2D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_einfeldt — Method
    min_max_speed_einfeldt(u_ll, u_rr, orientation, equations::CompressibleEulerEquations3D)

    Computes the HLLE (Harten-Lax-van Leer-Einfeldt) flux for the compressible Euler equations. Special estimates of the signal velocites and linearization of the Riemann problem developed by Einfeldt to ensure that the internal energy and density remain positive during the computation of the numerical flux.

    source
    Trixi.min_max_speed_naive — Function
    min_max_speed_naive(u_ll, u_rr, orientation::Integer, equations)
+min_max_speed_naive(u_ll, u_rr, normal_direction::AbstractVector, equations)

    Simple and fast estimate(!) of the minimal and maximal wave speed of the Riemann problem with left and right states u_ll, u_rr, usually based only on the local wave speeds associated to u_ll and u_rr. Slightly more diffusive than min_max_speed_davis.

    • Amiram Harten, Peter D. Lax, Bram van Leer (1983) On Upstream Differencing and Godunov-Type Schemes for Hyperbolic Conservation Laws DOI: 10.1137/1025002

    See eq. (10.37) from

    • Eleuterio F. Toro (2009) Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction DOI: 10.1007/b79761

    See also FluxHLL, min_max_speed_davis, min_max_speed_einfeldt.

    source
    Trixi.modify_dt_for_tstops! — Method
    modify_dt_for_tstops!(integrator::SimpleIntegratorSSP)

    Modify the time-step size to match the time stops specified in integrator.opts.tstops. To avoid adding OrdinaryDiffEq to Trixi's dependencies, this routine is a copy of https://github.com/SciML/OrdinaryDiffEq.jl/blob/d76335281c540ee5a6d1bd8bb634713e004f62ee/src/integrators/integrator_utils.jl#L38-L54

    source
    Trixi.multiply_dimensionwise — Method
    multiply_dimensionwise(matrix::AbstractMatrix, data_in::AbstractArray{<:Any, NDIMS+1})

    Multiply the array data_in by matrix in each coordinate direction, where data_in is assumed to have the first coordinate for the number of variables and the remaining coordinates are multiplied by matrix.

    source
    Trixi.n_nonconservative_terms — Function
    n_nonconservative_terms(equations)

    Number of nonconservative terms in the form local * symmetric for a particular equation. This function needs to be specialized only if equations with nonconservative terms are combined with certain solvers (e.g., subcell limiting).

    source
    Trixi.ndofs — Method
    ndofs(semi::AbstractSemidiscretization)

    Return the number of degrees of freedom associated with each scalar variable.

    source
    Trixi.negative_part — Method
    negative_part(x)

    Return x if x is negative, else zero. In other words, return (x - abs(x)) / 2 for real numbers x.

    source
    Trixi.ode_default_options — Method
    ode_default_options()

    Return the default options for OrdinaryDiffEq's solve. Pass ode_default_options()... to solve to only return the solution at the final time and enable MPI aware error-based step size control, whenever MPI is used. For example, use solve(ode, alg; ode_default_options()...).

    source
    Trixi.ode_norm — Method
    ode_norm(u, t)

    Implementation of the weighted L2 norm of Hairer and Wanner used for error-based step size control in OrdinaryDiffEq.jl. This function is aware of MPI and uses global MPI communication when running in parallel.

    You must pass this function as a keyword argument internalnorm=ode_norm to OrdinaryDiffEq.jl's solve when using error-based step size control with MPI parallel execution of Trixi.jl.

    See the "Advanced Adaptive Stepsize Control" section of the documentation.

    source
    Trixi.ode_unstable_check — Method
    ode_unstable_check(dt, u, semi, t)

    Implementation of the basic check for instability used in OrdinaryDiffEq.jl. Instead of checking something like any(isnan, u), this function just checks isnan(dt). This helps when using MPI parallelization, since no additional global communication is required and all ranks will return the same result.

    You should pass this function as a keyword argument unstable_check=ode_unstable_check to OrdinaryDiffEq.jl's solve when using error-based step size control with MPI parallel execution of Trixi.jl.

    See the "Miscellaneous" section of the documentation.

    source
    Trixi.partition! — Method
    Trixi.partition!(mesh::T8codeMesh)

    Partition a T8codeMesh in order to redistribute elements evenly among MPI ranks.

    Arguments

    • mesh::T8codeMesh: Initialized mesh object.
    source
    Trixi.partition! — Method
    partition!(mesh::ParallelTreeMesh, allow_coarsening=true)

    Partition mesh using a static domain decomposition algorithm based on leaf cell count and tree structure. If allow_coarsening is true, the algorithm will keep leaf cells together on one rank when needed for local coarsening (i.e. when all children of a cell are leaves).

    source
    Trixi.positive_part — Method
    positive_part(x)

    Return x if x is positive, else zero. In other words, return (x + abs(x)) / 2 for real numbers x.

    source
    Trixi.pressure — Method
    pressure(rho::Real, equations::LatticeBoltzmannEquations2D)
+pressure(u, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic pressure from the density rho or the particle distribution functions u.

    source
    Trixi.pressure — Method
    pressure(rho::Real, equations::LatticeBoltzmannEquations3D)
+pressure(u, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic pressure from the density rho or the particle distribution functions u.

    source
    Trixi.prim2cons — Function
    prim2cons(u, equations)

    Convert the primitive variables u to the conserved variables for a given set of equations. u is a vector type of the correct length nvariables(equations). Notice the function doesn't include any error checks for the purpose of efficiency, so please make sure your input is correct. The inverse conversion is performed by cons2prim.

    source
    Trixi.rotate_from_x — Function
    rotate_from_x(u, normal, equations)

    Apply the rotation that maps the x-axis onto normal to the convservative variables u. This is used by FluxRotated to calculate the numerical flux of rotationally invariant equations in arbitrary normal directions.

    See also: rotate_to_x

    source
    Trixi.rotate_to_x — Function
    rotate_to_x(u, normal, equations)

    Apply the rotation that maps normal onto the x-axis to the convservative variables u. This is used by FluxRotated to calculate the numerical flux of rotationally invariant equations in arbitrary normal directions.

    See also: rotate_from_x

    source
    Trixi.save_plot — Method
    save_plot(plot_data, variable_names;
           show_mesh=true, plot_arguments=Dict{Symbol,Any}(),
-          time=nothing, timestep=nothing)

    Visualize the plot data object provided in plot_data and save result as a PNG file in the out directory, plotting only the variables in variable_names and, optionally, the mesh (if show_mesh is true). Additionally, plot_arguments will be unpacked and passed as keyword arguments to the Plots.plot command.

    The timestep is used in the filename. time is currently unused by this function.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    See also: VisualizationCallback, show_plot

    source
    Trixi.set_log_type — Method
    Trixi.set_log_type(type; force = true)

    Set the type of the (natural) log function to be used in Trixi.jl. The default is "sqrt_Trixi_NaN" which returns NaN for negative arguments instead of throwing an error. Alternatively, you can set type to "sqrt_Base" to use the Julia built-in sqrt function which provides a stack-trace of the error which might come in handy when debugging code.

    source
    Trixi.set_sqrt_type — Method
    Trixi.set_sqrt_type(type; force = true)

    Set the type of the square root function to be used in Trixi.jl. The default is "sqrt_Trixi_NaN" which returns NaN for negative arguments instead of throwing an error. Alternatively, you can set type to "sqrt_Base" to use the Julia built-in sqrt function which provides a stack-trace of the error which might come in handy when debugging code.

    source
    Trixi.show_plot — Method
    show_plot(plot_data, variable_names;
+          time=nothing, timestep=nothing)

    Visualize the plot data object provided in plot_data and save result as a PNG file in the out directory, plotting only the variables in variable_names and, optionally, the mesh (if show_mesh is true). Additionally, plot_arguments will be unpacked and passed as keyword arguments to the Plots.plot command.

    The timestep is used in the filename. time is currently unused by this function.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    See also: VisualizationCallback, show_plot

    source
    Trixi.set_log_type — Method
    Trixi.set_log_type(type; force = true)

    Set the type of the (natural) log function to be used in Trixi.jl. The default is "sqrt_Trixi_NaN" which returns NaN for negative arguments instead of throwing an error. Alternatively, you can set type to "sqrt_Base" to use the Julia built-in sqrt function which provides a stack-trace of the error which might come in handy when debugging code.

    source
    Trixi.set_sqrt_type — Method
    Trixi.set_sqrt_type(type; force = true)

    Set the type of the square root function to be used in Trixi.jl. The default is "sqrt_Trixi_NaN" which returns NaN for negative arguments instead of throwing an error. Alternatively, you can set type to "sqrt_Base" to use the Julia built-in sqrt function which provides a stack-trace of the error which might come in handy when debugging code.

    source
    Trixi.show_plot — Method
    show_plot(plot_data, variable_names;
           show_mesh=true, plot_arguments=Dict{Symbol,Any}(),
-          time=nothing, timestep=nothing)

    Visualize the plot data object provided in plot_data and display result, plotting only the variables in variable_names and, optionally, the mesh (if show_mesh is true). Additionally, plot_arguments will be unpacked and passed as keyword arguments to the Plots.plot command.

    This function is the default plot_creator argument for the VisualizationCallback. time and timestep are currently unused by this function.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    See also: VisualizationCallback, save_plot

    source
    Trixi.solve — Function
    solve(ode, alg; dt, callbacks, kwargs...)

    The following structures and methods provide the infrastructure for SSP Runge-Kutta methods of type SimpleAlgorithmSSP.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    source
    Trixi.source_terms_convergence_test — Method
    source_terms_convergence_test(u, x, t, equations::ShallowWaterEquations2D)

    Source terms used for convergence tests in combination with initial_condition_convergence_test (and BoundaryConditionDirichlet(initial_condition_convergence_test) in non-periodic domains).

    This manufactured solution source term is specifically designed for the bottom topography function b(x,y) = 2 + 0.5 * sin(sqrt(2)*pi*x) + 0.5 * sin(sqrt(2)*pi*y) as defined in initial_condition_convergence_test.

    source
    Trixi.source_terms_convergence_test — Method
    source_terms_convergence_test(u, x, t, equations::ShallowWaterEquationsQuasi1D)

    Source terms used for convergence tests in combination with initial_condition_convergence_test (and BoundaryConditionDirichlet(initial_condition_convergence_test) in non-periodic domains).

    This manufactured solution source term is specifically designed for the bottom topography function b(x) = 0.2 - 0.05 * sin(sqrt(2) * pi *x[1]) and channel width 'a(x)= 1 + 0.1 * cos(sqrt(2) * pi * x[1])' as defined in initial_condition_convergence_test.

    source
    Trixi.source_terms_eoc_test_coupled_euler_gravity — Method
    source_terms_eoc_test_coupled_euler_gravity(u, x, t, equations::CompressibleEulerEquations2D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with initial_condition_eoc_test_coupled_euler_gravity.

    source
    Trixi.source_terms_eoc_test_coupled_euler_gravity — Method
    source_terms_eoc_test_coupled_euler_gravity(u, x, t, equations::CompressibleEulerEquations3D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with initial_condition_eoc_test_coupled_euler_gravity.

    source
    Trixi.source_terms_eoc_test_euler — Method
    source_terms_eoc_test_euler(u, x, t, equations::CompressibleEulerEquations3D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with initial_condition_eoc_test_coupled_euler_gravity.

    Note

    This method is to be used for testing pure Euler simulations with analytic self-gravity. If you intend to do coupled Euler-gravity simulations, you need to use source_terms_eoc_test_coupled_euler_gravity instead.

    source
    Trixi.source_terms_harmonic — Method
    source_terms_harmonic(u, x, t, equations::HyperbolicDiffusionEquations1D)

    Source term that only includes the forcing from the hyperbolic diffusion system.

    source
    Trixi.source_terms_harmonic — Method
    source_terms_harmonic(u, x, t, equations::HyperbolicDiffusionEquations2D)

    Source term that only includes the forcing from the hyperbolic diffusion system.

    source
    Trixi.source_terms_harmonic — Method
    source_terms_harmonic(u, x, t, equations::HyperbolicDiffusionEquations3D)

    Source term that only includes the forcing from the hyperbolic diffusion system.

    source
    Trixi.splitting_coirier_vanleer — Method
    splitting_coirier_vanleer(u, orientation::Integer,
+          time=nothing, timestep=nothing)

    Visualize the plot data object provided in plot_data and display result, plotting only the variables in variable_names and, optionally, the mesh (if show_mesh is true). Additionally, plot_arguments will be unpacked and passed as keyword arguments to the Plots.plot command.

    This function is the default plot_creator argument for the VisualizationCallback. time and timestep are currently unused by this function.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    See also: VisualizationCallback, save_plot

    source
    Trixi.solve — Function
    solve(ode, alg; dt, callbacks, kwargs...)

    The following structures and methods provide the infrastructure for SSP Runge-Kutta methods of type SimpleAlgorithmSSP.

    Experimental implementation

    This is an experimental feature and may change in future releases.

    source
    Trixi.source_terms_convergence_test — Method
    source_terms_convergence_test(u, x, t, equations::ShallowWaterEquations2D)

    Source terms used for convergence tests in combination with initial_condition_convergence_test (and BoundaryConditionDirichlet(initial_condition_convergence_test) in non-periodic domains).

    This manufactured solution source term is specifically designed for the bottom topography function b(x,y) = 2 + 0.5 * sin(sqrt(2)*pi*x) + 0.5 * sin(sqrt(2)*pi*y) as defined in initial_condition_convergence_test.

    source
    Trixi.source_terms_convergence_test — Method
    source_terms_convergence_test(u, x, t, equations::ShallowWaterEquationsQuasi1D)

    Source terms used for convergence tests in combination with initial_condition_convergence_test (and BoundaryConditionDirichlet(initial_condition_convergence_test) in non-periodic domains).

    This manufactured solution source term is specifically designed for the bottom topography function b(x) = 0.2 - 0.05 * sin(sqrt(2) * pi *x[1]) and channel width 'a(x)= 1 + 0.1 * cos(sqrt(2) * pi * x[1])' as defined in initial_condition_convergence_test.

    source
    Trixi.source_terms_eoc_test_coupled_euler_gravity — Method
    source_terms_eoc_test_coupled_euler_gravity(u, x, t, equations::CompressibleEulerEquations2D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with initial_condition_eoc_test_coupled_euler_gravity.

    source
    Trixi.source_terms_eoc_test_coupled_euler_gravity — Method
    source_terms_eoc_test_coupled_euler_gravity(u, x, t, equations::CompressibleEulerEquations3D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with initial_condition_eoc_test_coupled_euler_gravity.

    source
    Trixi.source_terms_eoc_test_euler — Method
    source_terms_eoc_test_euler(u, x, t, equations::CompressibleEulerEquations3D)

    Setup used for convergence tests of the Euler equations with self-gravity used in

    • Michael Schlottke-Lakemper, Andrew R. Winters, Hendrik Ranocha, Gregor J. Gassner (2020) A purely hyperbolic discontinuous Galerkin approach for self-gravitating gas dynamics arXiv: 2008.10593

    in combination with initial_condition_eoc_test_coupled_euler_gravity.

    Note

    This method is to be used for testing pure Euler simulations with analytic self-gravity. If you intend to do coupled Euler-gravity simulations, you need to use source_terms_eoc_test_coupled_euler_gravity instead.

    source
    Trixi.source_terms_harmonic — Method
    source_terms_harmonic(u, x, t, equations::HyperbolicDiffusionEquations1D)

    Source term that only includes the forcing from the hyperbolic diffusion system.

    source
    Trixi.source_terms_harmonic — Method
    source_terms_harmonic(u, x, t, equations::HyperbolicDiffusionEquations2D)

    Source term that only includes the forcing from the hyperbolic diffusion system.

    source
    Trixi.source_terms_harmonic — Method
    source_terms_harmonic(u, x, t, equations::HyperbolicDiffusionEquations3D)

    Source term that only includes the forcing from the hyperbolic diffusion system.

    source
    Trixi.splitting_coirier_vanleer — Method
    splitting_coirier_vanleer(u, orientation::Integer,
                           equations::CompressibleEulerEquations1D)
 splitting_coirier_vanleer(u, which::Union{Val{:minus}, Val{:plus}}
                           orientation::Integer,
-                          equations::CompressibleEulerEquations1D)

    Splitting of the compressible Euler flux from Coirier and van Leer. The splitting has correction terms in the pressure splitting as well as the mass and energy flux components. The motivation for these corrections are to handle flows at the low Mach number limit.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • William Coirier and Bram van Leer (1991) Numerical flux formulas for the Euler and Navier-Stokes equations. II - Progress in flux-vector splitting DOI: 10.2514/6.1991-1566
    source
    Trixi.splitting_drikakis_tsangaris — Method
    splitting_drikakis_tsangaris(u, orientation_or_normal_direction,
+                          equations::CompressibleEulerEquations1D)

    Splitting of the compressible Euler flux from Coirier and van Leer. The splitting has correction terms in the pressure splitting as well as the mass and energy flux components. The motivation for these corrections are to handle flows at the low Mach number limit.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • William Coirier and Bram van Leer (1991) Numerical flux formulas for the Euler and Navier-Stokes equations. II - Progress in flux-vector splitting DOI: 10.2514/6.1991-1566
    source
    Trixi.splitting_drikakis_tsangaris — Method
    splitting_drikakis_tsangaris(u, orientation_or_normal_direction,
                              equations::CompressibleEulerEquations2D)
 splitting_drikakis_tsangaris(u, which::Union{Val{:minus}, Val{:plus}}
                              orientation_or_normal_direction,
-                             equations::CompressibleEulerEquations2D)

    Improved variant of the Steger-Warming flux vector splitting splitting_steger_warming for generalized coordinates. This splitting also reformulates the energy flux as in Hänel et al. to obtain conservation of the total temperature for inviscid flows.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • D. Drikakis and S. Tsangaris (1993) On the solution of the compressible Navier-Stokes equations using improved flux vector splitting methods DOI: 10.1016/0307-904X(93)90054-K
    • D. Hänel, R. Schwane and G. Seider (1987) On the accuracy of upwind schemes for the solution of the Navier-Stokes equations DOI: 10.2514/6.1987-1105
    source
    Trixi.splitting_lax_friedrichs — Method
    splitting_lax_friedrichs(u, orientation_or_normal_direction,
+                             equations::CompressibleEulerEquations2D)

    Improved variant of the Steger-Warming flux vector splitting splitting_steger_warming for generalized coordinates. This splitting also reformulates the energy flux as in Hänel et al. to obtain conservation of the total temperature for inviscid flows.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • D. Drikakis and S. Tsangaris (1993) On the solution of the compressible Navier-Stokes equations using improved flux vector splitting methods DOI: 10.1016/0307-904X(93)90054-K
    • D. Hänel, R. Schwane and G. Seider (1987) On the accuracy of upwind schemes for the solution of the Navier-Stokes equations DOI: 10.2514/6.1987-1105
    source
    Trixi.splitting_lax_friedrichs — Method
    splitting_lax_friedrichs(u, orientation_or_normal_direction,
                          equations::CompressibleEulerEquations2D)
 splitting_lax_friedrichs(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation_or_normal_direction,
-                         equations::CompressibleEulerEquations2D)

    Naive local Lax-Friedrichs style flux splitting of the form f⁺ = 0.5 (f + λ u) and f⁻ = 0.5 (f - λ u) similar to a flux splitting one would apply, e.g., to Burgers' equation.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    source
    Trixi.splitting_lax_friedrichs — Method
    splitting_lax_friedrichs(u, orientation::Integer,
+                         equations::CompressibleEulerEquations2D)

    Naive local Lax-Friedrichs style flux splitting of the form f⁺ = 0.5 (f + λ u) and f⁻ = 0.5 (f - λ u) similar to a flux splitting one would apply, e.g., to Burgers' equation.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    source
    Trixi.splitting_lax_friedrichs — Method
    splitting_lax_friedrichs(u, orientation::Integer,
                          equations::InviscidBurgersEquation1D)
 splitting_lax_friedrichs(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation::Integer,
-                         equations::InviscidBurgersEquation1D)

    Naive local Lax-Friedrichs style flux splitting of the form f⁺ = 0.5 (f + λ u) and f⁻ = 0.5 (f - λ u) where λ = abs(u).

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    source
    Trixi.splitting_lax_friedrichs — Method
    splitting_lax_friedrichs(u, orientation::Integer,
+                         equations::InviscidBurgersEquation1D)

    Naive local Lax-Friedrichs style flux splitting of the form f⁺ = 0.5 (f + λ u) and f⁻ = 0.5 (f - λ u) where λ = abs(u).

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    source
    Trixi.splitting_lax_friedrichs — Method
    splitting_lax_friedrichs(u, orientation::Integer,
                          equations::LinearScalarAdvectionEquation1D)
 splitting_lax_friedrichs(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation::Integer,
-                         equations::LinearScalarAdvectionEquation1D)

    Naive local Lax-Friedrichs style flux splitting of the form f⁺ = 0.5 (f + λ u) and f⁻ = 0.5 (f - λ u) where λ is the absolute value of the advection velocity.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    source
    Trixi.splitting_steger_warming — Method
    splitting_steger_warming(u, orientation::Integer,
+                         equations::LinearScalarAdvectionEquation1D)

    Naive local Lax-Friedrichs style flux splitting of the form f⁺ = 0.5 (f + λ u) and f⁻ = 0.5 (f - λ u) where λ is the absolute value of the advection velocity.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    source
    Trixi.splitting_steger_warming — Method
    splitting_steger_warming(u, orientation::Integer,
                          equations::CompressibleEulerEquations1D)
 splitting_steger_warming(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation::Integer,
-                         equations::CompressibleEulerEquations1D)

    Splitting of the compressible Euler flux of Steger and Warming.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Joseph L. Steger and R. F. Warming (1979) Flux Vector Splitting of the Inviscid Gasdynamic Equations With Application to Finite Difference Methods NASA Technical Memorandum
    source
    Trixi.splitting_steger_warming — Method
    splitting_steger_warming(u, orientation::Integer,
+                         equations::CompressibleEulerEquations1D)

    Splitting of the compressible Euler flux of Steger and Warming.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Joseph L. Steger and R. F. Warming (1979) Flux Vector Splitting of the Inviscid Gasdynamic Equations With Application to Finite Difference Methods NASA Technical Memorandum
    source
    Trixi.splitting_steger_warming — Method
    splitting_steger_warming(u, orientation::Integer,
                          equations::CompressibleEulerEquations2D)
 splitting_steger_warming(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation::Integer,
-                         equations::CompressibleEulerEquations2D)

    Splitting of the compressible Euler flux of Steger and Warming. For curvilinear coordinates use the improved Steger-Warming-type splitting splitting_drikakis_tsangaris.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Joseph L. Steger and R. F. Warming (1979) Flux Vector Splitting of the Inviscid Gasdynamic Equations With Application to Finite Difference Methods NASA Technical Memorandum
    source
    Trixi.splitting_steger_warming — Method
    splitting_steger_warming(u, orientation::Integer,
+                         equations::CompressibleEulerEquations2D)

    Splitting of the compressible Euler flux of Steger and Warming. For curvilinear coordinates use the improved Steger-Warming-type splitting splitting_drikakis_tsangaris.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Joseph L. Steger and R. F. Warming (1979) Flux Vector Splitting of the Inviscid Gasdynamic Equations With Application to Finite Difference Methods NASA Technical Memorandum
    source
    Trixi.splitting_steger_warming — Method
    splitting_steger_warming(u, orientation::Integer,
                          equations::CompressibleEulerEquations3D)
 splitting_steger_warming(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation::Integer,
-                         equations::CompressibleEulerEquations3D)

    Splitting of the compressible Euler flux of Steger and Warming.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Joseph L. Steger and R. F. Warming (1979) Flux Vector Splitting of the Inviscid Gasdynamic Equations With Application to Finite Difference Methods NASA Technical Memorandum
    source
    Trixi.splitting_vanleer_haenel — Method
    splitting_vanleer_haenel(u, orientation_or_normal_direction,
+                         equations::CompressibleEulerEquations3D)

    Splitting of the compressible Euler flux of Steger and Warming.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Joseph L. Steger and R. F. Warming (1979) Flux Vector Splitting of the Inviscid Gasdynamic Equations With Application to Finite Difference Methods NASA Technical Memorandum
    source
    Trixi.splitting_vanleer_haenel — Method
    splitting_vanleer_haenel(u, orientation_or_normal_direction,
                          equations::CompressibleEulerEquations2D)
 splitting_vanleer_haenel(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation_or_normal_direction,
-                         equations::CompressibleEulerEquations2D)

    Splitting of the compressible Euler flux from van Leer. This splitting further contains a reformulation due to Hänel et al. where the energy flux uses the enthalpy. The pressure splitting is independent from the splitting of the convective terms. As such there are many pressure splittings suggested across the literature. We implement the 'p4' variant suggested by Liou and Steffen as it proved the most robust in practice. For details on the curvilinear variant of this flux vector splitting see Anderson et al.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Bram van Leer (1982) Flux-Vector Splitting for the Euler Equation DOI: 10.1007/978-3-642-60543-7_5
    • D. Hänel, R. Schwane and G. Seider (1987) On the accuracy of upwind schemes for the solution of the Navier-Stokes equations DOI: 10.2514/6.1987-1105
    • Meng-Sing Liou and Chris J. Steffen, Jr. (1991) High-Order Polynomial Expansions (HOPE) for Flux-Vector Splitting NASA Technical Memorandum
    • W. Kyle Anderson, James L. Thomas, and Bram van Leer (1986) Comparison of Finite Volume Flux Vector Splittings for the Euler Equations DOI: 10.2514/3.9465
    source
    Trixi.splitting_vanleer_haenel — Method
    splitting_vanleer_haenel(u, orientation::Integer,
+                         equations::CompressibleEulerEquations2D)

    Splitting of the compressible Euler flux from van Leer. This splitting further contains a reformulation due to Hänel et al. where the energy flux uses the enthalpy. The pressure splitting is independent from the splitting of the convective terms. As such there are many pressure splittings suggested across the literature. We implement the 'p4' variant suggested by Liou and Steffen as it proved the most robust in practice. For details on the curvilinear variant of this flux vector splitting see Anderson et al.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    • Bram van Leer (1982) Flux-Vector Splitting for the Euler Equation DOI: 10.1007/978-3-642-60543-7_5
    • D. Hänel, R. Schwane and G. Seider (1987) On the accuracy of upwind schemes for the solution of the Navier-Stokes equations DOI: 10.2514/6.1987-1105
    • Meng-Sing Liou and Chris J. Steffen, Jr. (1991) High-Order Polynomial Expansions (HOPE) for Flux-Vector Splitting NASA Technical Memorandum
    • W. Kyle Anderson, James L. Thomas, and Bram van Leer (1986) Comparison of Finite Volume Flux Vector Splittings for the Euler Equations DOI: 10.2514/3.9465
    source
    Trixi.splitting_vanleer_haenel — Method
    splitting_vanleer_haenel(u, orientation::Integer,
                          equations::CompressibleEulerEquations1D)
 splitting_vanleer_haenel(u, which::Union{Val{:minus}, Val{:plus}}
                          orientation::Integer,
-                         equations::CompressibleEulerEquations1D)

    Splitting of the compressible Euler flux from van Leer. This splitting further contains a reformulation due to Hänel et al. where the energy flux uses the enthalpy. The pressure splitting is independent from the splitting of the convective terms. As such there are many pressure splittings suggested across the literature. We implement the 'p4' variant suggested by Liou and Steffen as it proved the most robust in practice.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    source
    Trixi.stolarsky_mean — Method
    stolarsky_mean(x, y, gamma)

    Compute an instance of a weighted Stolarsky mean of the form

    stolarsky_mean(x, y, gamma) = (gamma - 1)/gamma * (y^gamma - x^gamma) / (y^(gamma-1) - x^(gamma-1))

    where gamma > 1.

    Problem: The formula above has a removable singularity at x == y. Thus, some care must be taken to implement it correctly without problems or loss of accuracy when x ≈ y. Here, we use the approach proposed by Winters et al. (2020). Set f = (y - x) / (y + x) and g = gamma (for compact notation). Then, we use the expansions

    ((1+f)^g - (1-f)^g) / g = 2*f + (g-1)(g-2)/3 * f^3 + (g-1)(g-2)(g-3)(g-4)/60 * f^5 + O(f^7)

    and

    ((1+f)^(g-1) - (1-f)^(g-1)) / (g-1) = 2*f + (g-2)(g-3)/3 * f^3 + (g-2)(g-3)(g-4)(g-5)/60 * f^5 + O(f^7)

    Inserting the first few terms of these expansions and performing polynomial long division we find that

    stolarsky_mean(x, y, gamma) ≈ (y + x) / 2 * (1 + (g-2)/3 * f^2 - (g+1)(g-2)(g-3)/45 * f^4 + (g+1)(g-2)(g-3)(2g(g-2)-9)/945 * f^6)

    Since divisions are usually more expensive on modern hardware than multiplications (Agner Fog), we try to avoid computing two divisions. Thus, we use

    f^2 = (y - x)^2 / (x + y)^2
+                         equations::CompressibleEulerEquations1D)

    Splitting of the compressible Euler flux from van Leer. This splitting further contains a reformulation due to Hänel et al. where the energy flux uses the enthalpy. The pressure splitting is independent from the splitting of the convective terms. As such there are many pressure splittings suggested across the literature. We implement the 'p4' variant suggested by Liou and Steffen as it proved the most robust in practice.

    Returns a tuple of the fluxes "minus" (associated with waves going into the negative axis direction) and "plus" (associated with waves going into the positive axis direction). If only one of the fluxes is required, use the function signature with argument which set to Val{:minus}() or Val{:plus}().

    Experimental implementation (upwind SBP)

    This is an experimental feature and may change in future releases.

    References

    source
    Trixi.stolarsky_mean — Method
    stolarsky_mean(x, y, gamma)

    Compute an instance of a weighted Stolarsky mean of the form

    stolarsky_mean(x, y, gamma) = (gamma - 1)/gamma * (y^gamma - x^gamma) / (y^(gamma-1) - x^(gamma-1))

    where gamma > 1.

    Problem: The formula above has a removable singularity at x == y. Thus, some care must be taken to implement it correctly without problems or loss of accuracy when x ≈ y. Here, we use the approach proposed by Winters et al. (2020). Set f = (y - x) / (y + x) and g = gamma (for compact notation). Then, we use the expansions

    ((1+f)^g - (1-f)^g) / g = 2*f + (g-1)(g-2)/3 * f^3 + (g-1)(g-2)(g-3)(g-4)/60 * f^5 + O(f^7)

    and

    ((1+f)^(g-1) - (1-f)^(g-1)) / (g-1) = 2*f + (g-2)(g-3)/3 * f^3 + (g-2)(g-3)(g-4)(g-5)/60 * f^5 + O(f^7)

    Inserting the first few terms of these expansions and performing polynomial long division we find that

    stolarsky_mean(x, y, gamma) ≈ (y + x) / 2 * (1 + (g-2)/3 * f^2 - (g+1)(g-2)(g-3)/45 * f^4 + (g+1)(g-2)(g-3)(2g(g-2)-9)/945 * f^6)

    Since divisions are usually more expensive on modern hardware than multiplications (Agner Fog), we try to avoid computing two divisions. Thus, we use

    f^2 = (y - x)^2 / (x + y)^2
     = (x * (x - 2 * y) + y * y) / (x * (x + 2 * y) + y * y)

    Given ε = 1.0e-4, we use the following algorithm.

    if f^2 < ε
   # use the expansion above
 else
   # use the direct formula (gamma - 1)/gamma * (y^gamma - x^gamma) / (y^(gamma-1) - x^(gamma-1))
-end

    References

    source
    Trixi.totalgamma — Method
    totalgamma(u, equations::CompressibleEulerMulticomponentEquations1D)

    Function that calculates the total gamma out of all partial gammas using the partial density fractions as well as the partial specific heats at constant volume.

    source
    Trixi.totalgamma — Method
    totalgamma(u, equations::CompressibleEulerMulticomponentEquations2D)

    Function that calculates the total gamma out of all partial gammas using the partial density fractions as well as the partial specific heats at constant volume.

    source
    Trixi.varnames — Function
    varnames(conversion_function, equations)

    Return the list of variable names when applying conversion_function to the conserved variables associated to equations. This function is mainly used internally to determine output to screen and for IO, e.g., for the AnalysisCallback and the SaveSolutionCallback. Common choices of the conversion_function are cons2cons and cons2prim.

    source
    Trixi.velocity — Method
    velocity(u, orientation, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic velocity for the given orientation (1 -> x, 2 -> y) from the particle distribution functions u.

    source
    Trixi.velocity — Method
    velocity(u, orientation, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic velocity for the given orientation (1 -> x, 2 -> y, 3 -> z) from the particle distribution functions u.

    source
    Trixi.velocity — Method
    velocity(u, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic velocity vector from the particle distribution functions u.

    source
    Trixi.velocity — Method
    velocity(u, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic velocity vector from the particle distribution functions u.

    source
    Trixi.@autoinfiltrate — Macro
    @autoinfiltrate
-@autoinfiltrate condition::Bool

    Invoke the @infiltrate macro of the package Infiltrator.jl to create a breakpoint for ad-hoc interactive debugging in the REPL. If the optional argument condition is given, the breakpoint is only enabled if condition evaluates to true.

    As opposed to using Infiltrator.@infiltrate directly, this macro does not require Infiltrator.jl to be added as a dependency to Trixi.jl. As a bonus, the macro will also attempt to load the Infiltrator module if it has not yet been loaded manually.

    Note: For this macro to work, the Infiltrator.jl package needs to be installed in your current Julia environment stack.

    See also: Infiltrator.jl

    Internal use only

    Please note that this macro is intended for internal use only. It is not part of the public API of Trixi.jl, and it thus can altered (or be removed) at any time without it being considered a breaking change.

    source
    Trixi.@threaded — Macro
    @threaded for ... end

    Semantically the same as Threads.@threads when iterating over a AbstractUnitRange but without guarantee that the underlying implementation uses Threads.@threads or works for more general for loops. In particular, there may be an additional check whether only one thread is used to reduce the overhead of serial execution or the underlying threading capabilities might be provided by other packages such as Polyester.jl.

    Warn

    This macro does not necessarily work for general for loops. For example, it does not necessarily support general iterables such as eachline(filename).

    Some discussion can be found at https://discourse.julialang.org/t/overhead-of-threads-threads/53964 and https://discourse.julialang.org/t/threads-threads-with-one-thread-how-to-remove-the-overhead/58435.

    source
    +end

    References

    source
    Trixi.totalgamma — Method
    totalgamma(u, equations::CompressibleEulerMulticomponentEquations1D)

    Function that calculates the total gamma out of all partial gammas using the partial density fractions as well as the partial specific heats at constant volume.

    source
    Trixi.totalgamma — Method
    totalgamma(u, equations::CompressibleEulerMulticomponentEquations2D)

    Function that calculates the total gamma out of all partial gammas using the partial density fractions as well as the partial specific heats at constant volume.

    source
    Trixi.varnames — Function
    varnames(conversion_function, equations)

    Return the list of variable names when applying conversion_function to the conserved variables associated to equations. This function is mainly used internally to determine output to screen and for IO, e.g., for the AnalysisCallback and the SaveSolutionCallback. Common choices of the conversion_function are cons2cons and cons2prim.

    source
    Trixi.velocity — Method
    velocity(u, orientation, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic velocity for the given orientation (1 -> x, 2 -> y) from the particle distribution functions u.

    source
    Trixi.velocity — Method
    velocity(u, orientation, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic velocity for the given orientation (1 -> x, 2 -> y, 3 -> z) from the particle distribution functions u.

    source
    Trixi.velocity — Method
    velocity(u, equations::LatticeBoltzmannEquations2D)

    Calculate the macroscopic velocity vector from the particle distribution functions u.

    source
    Trixi.velocity — Method
    velocity(u, equations::LatticeBoltzmannEquations3D)

    Calculate the macroscopic velocity vector from the particle distribution functions u.

    source
    Trixi.@autoinfiltrate — Macro
    @autoinfiltrate
+@autoinfiltrate condition::Bool

    Invoke the @infiltrate macro of the package Infiltrator.jl to create a breakpoint for ad-hoc interactive debugging in the REPL. If the optional argument condition is given, the breakpoint is only enabled if condition evaluates to true.

    As opposed to using Infiltrator.@infiltrate directly, this macro does not require Infiltrator.jl to be added as a dependency to Trixi.jl. As a bonus, the macro will also attempt to load the Infiltrator module if it has not yet been loaded manually.

    Note: For this macro to work, the Infiltrator.jl package needs to be installed in your current Julia environment stack.

    See also: Infiltrator.jl

    Internal use only

    Please note that this macro is intended for internal use only. It is not part of the public API of Trixi.jl, and it thus can altered (or be removed) at any time without it being considered a breaking change.

    source
    Trixi.@threaded — Macro
    @threaded for ... end

    Semantically the same as Threads.@threads when iterating over a AbstractUnitRange but without guarantee that the underlying implementation uses Threads.@threads or works for more general for loops. In particular, there may be an additional check whether only one thread is used to reduce the overhead of serial execution or the underlying threading capabilities might be provided by other packages such as Polyester.jl.

    Warn

    This macro does not necessarily work for general for loops. For example, it does not necessarily support general iterables such as eachline(filename).

    Some discussion can be found at https://discourse.julialang.org/t/overhead-of-threads-threads/53964 and https://discourse.julialang.org/t/threads-threads-with-one-thread-how-to-remove-the-overhead/58435.

    source
    diff --git a/previews/PR1835/reference-trixi2vtk/index.html b/previews/PR1835/reference-trixi2vtk/index.html index 3c4b2824bfe..253f72ec286 100644 --- a/previews/PR1835/reference-trixi2vtk/index.html +++ b/previews/PR1835/reference-trixi2vtk/index.html @@ -3,4 +3,4 @@ format=:vtu, verbose=false, hide_progress=false, pvd=nothing, output_directory=".", nvisnodes=nothing, save_celldata=true, reinterpolate=true, data_is_uniform=false)

    Convert Trixi-generated output files to VTK files (VTU or VTI).

    Arguments

    Examples

    julia> trixi2vtk("out/solution_000*.h5")
-[...]
    source +[...]source diff --git a/previews/PR1835/reference-trixibase/index.html b/previews/PR1835/reference-trixibase/index.html index 617e761ccfd..cceddd66759 100644 --- a/previews/PR1835/reference-trixibase/index.html +++ b/previews/PR1835/reference-trixibase/index.html @@ -7,4 +7,4 @@ sol.t[end] end [ Info: You just called `trixi_include`. Julia may now compile the code, please be patient. -0.1source +0.1source diff --git a/previews/PR1835/restart/index.html b/previews/PR1835/restart/index.html index 8a8950f0dc8..e10812eeb55 100644 --- a/previews/PR1835/restart/index.html +++ b/previews/PR1835/restart/index.html @@ -3,4 +3,4 @@ save_final_restart=true)

    Make this part of your CallbackSet.

    An example is examples/examples/structured_2d_dgsem/elixir_advection_extended.jl.

    Perform the simulation restart

    Since all of the information about the simulation can be obtained from the last snapshot, the restart can be done with relatively few lines in an extra elixir file. However, some might prefer to keep everything in one elixir and conditionals like if restart with a boolean variable restart that is user defined.

    First we need to define from which file we want to restart, e.g.

    restart_file = "restart_000021.h5"
 restart_filename = joinpath("out", restart_file)

    Then we load the mesh file:

    mesh = load_mesh(restart_filename)

    This is then needed for the semidiscretization:

    semi = SemidiscretizationHyperbolic(mesh, equations, initial_condition, solver)

    We then define a new time span for the simulation that takes as starting time the one form the snapshot:

    tspan = (load_time(restart_filename), 2.0)

    We now also take the last dt, so that our solver does not need to first find one to fulfill the CFL condition:

    dt = load_dt(restart_filename)

    The ODE that we will pass to the solver is now:

    ode = semidiscretize(semi, tspan, restart_filename)

    You should now define a SaveSolutionCallback similar to the original simulation, but with save_initial_solution=false, otherwise our initial snapshot will be overwritten. If you are using one file for the original simulation and the restart you can reuse your SaveSolutionCallback, but need to set

    save_solution.condition.save_initial_solution = false

    Before we compute the solution using OrdinaryDiffEq.jl we need to set the integrator and its time step number, e.g.:

    integrator = init(ode, CarpenterKennedy2N54(williamson_condition=false),
                   dt=dt, save_everystep=false, callback=callbacks);
-load_timestep!(integrator, restart_filename)

    Now we can compute the solution:

    sol = solve!(integrator)

    An example is in examples/structured_2d_dgsem/elixir_advection_restart.jl.

    +load_timestep!(integrator, restart_filename)

    Now we can compute the solution:

    sol = solve!(integrator)

    An example is in examples/structured_2d_dgsem/elixir_advection_restart.jl.

    diff --git a/previews/PR1835/styleguide/index.html b/previews/PR1835/styleguide/index.html index 682f8e5cae0..98c8b49f292 100644 --- a/previews/PR1835/styleguide/index.html +++ b/previews/PR1835/styleguide/index.html @@ -1,2 +1,2 @@ -Style guide · Trixi.jl
    GitHub

    Style guide

    Coding style is an inherently personal - and thus hotly contested - issue. Since code is usually "written once, read often", it helps regular developers, new users, and reviewers if code is formatted consistently. We therefore believe in the merit of using a common coding style throughout Trixi.jl, even at the expense that not everyone can be happy with every detailed style decision. If you came here because you are furious about our code formatting rules, here is a happy little whale for you to calm you down: 🐳

    Conventions

    The following lists a few coding conventions for Trixi.jl. Note that in addition to these conventions, we apply and enforce automated source code formatting (see below for more details):

    • Modules, types, structs with CamelCase.
    • Functions, variables with lowercase snake_case.
    • Indentation with 4 spaces (never tabs!)
    • Maximum line length (strictly): 92.
    • Functions that mutate their input are named with a trailing !.
    • Functions order their parameters similar to Julia Base.
      • The main modified argument comes first. For example, if the right-hand side du is modified, it should come first. If only the cache is modified, e.g., in prolong2interfaces! and its siblings, put the cache first.
      • Otherwise, use the order mesh, equations, solver, cache.
      • If something needs to be specified in more detail for dispatch, put the additional argument before the general one that is specified in more detail. For example, we use have_nonconservative_terms(equations), equations and dg.mortar, dg.
    • Prefer for i in ... to for i = ... for better semantic clarity and greater flexibility.
    • Executable code should only use ASCII characters.
    • Docstrings and comments can and should use Unicode characters where it helps understanding.
    • Multiline expressions should be explicitly grouped by parentheses and not rely on Julia's implicit line continuation syntax.
    • When naming multiple functions of a single or similar category, prefer to put the general classification first and the specialization second. Example: Use flux_central instead of central_flux. This helps when searching for available functions on the REPL (e.g., when trying to find all flux functions).

    Automated source code formatting

    We use JuliaFormatter.jl to format the source code of Trixi.jl, which will also enforce some of the Conventions listed above (e.g., line length or indentation with 4 spaces are automatically handled, while capitalization of names is not). Our format is mostly based on the SciML-style formatting rules. For more details you can have a look at the current .JuliaFormatter.toml file that holds the configuration options we use for JuliaFormatter.jl.

    Note that we expect all contributions to Trixi.jl to be formatted with JuliaFormatter.jl before being merged to the main branch. We ensure this by running a automated check on all PRs that verify that running JuliaFormatter.jl again will not change the source code.

    To format your contributions before created a PR (or, at least, before requesting a review of your PR), you need to install JuliaFormatter.jl first by running

    julia -e 'using Pkg; Pkg.add("JuliaFormatter")'

    You can then recursively format the core Julia files in the Trixi.jl repo by executing

    julia -e 'using JuliaFormatter; format(["benchmark", "examples", "ext", "src", "test", "utils"])'

    from inside the Trixi.jl repository. For convenience, there is also a script you can directly run from your terminal shell, which will automatically install JuliaFormatter in a temporary environment and then run it:

    utils/trixi-format.jl

    You can get more information about using the convenience script by running it with the --help/-h flag.

    Checking formatting before committing

    It can be convenient to check the formatting of source code automatically before each commit. We use git-hooks for it and provide a pre-commit script in the utils folder. The script uses JuliaFormatter.jl just like formatting script that runs over the whole Trixi.jl directory. You can copy the pre-commit-script into .git/hooks/pre-commit and it will check your formatting before each commit. If errors are found the commit is aborted and you can add the corrections via

    git add -p
    +Style guide · Trixi.jl
    GitHub

    Style guide

    Coding style is an inherently personal - and thus hotly contested - issue. Since code is usually "written once, read often", it helps regular developers, new users, and reviewers if code is formatted consistently. We therefore believe in the merit of using a common coding style throughout Trixi.jl, even at the expense that not everyone can be happy with every detailed style decision. If you came here because you are furious about our code formatting rules, here is a happy little whale for you to calm you down: 🐳

    Conventions

    The following lists a few coding conventions for Trixi.jl. Note that in addition to these conventions, we apply and enforce automated source code formatting (see below for more details):

    • Modules, types, structs with CamelCase.
    • Functions, variables with lowercase snake_case.
    • Indentation with 4 spaces (never tabs!)
    • Maximum line length (strictly): 92.
    • Functions that mutate their input are named with a trailing !.
    • Functions order their parameters similar to Julia Base.
      • The main modified argument comes first. For example, if the right-hand side du is modified, it should come first. If only the cache is modified, e.g., in prolong2interfaces! and its siblings, put the cache first.
      • Otherwise, use the order mesh, equations, solver, cache.
      • If something needs to be specified in more detail for dispatch, put the additional argument before the general one that is specified in more detail. For example, we use have_nonconservative_terms(equations), equations and dg.mortar, dg.
    • Prefer for i in ... to for i = ... for better semantic clarity and greater flexibility.
    • Executable code should only use ASCII characters.
    • Docstrings and comments can and should use Unicode characters where it helps understanding.
    • Multiline expressions should be explicitly grouped by parentheses and not rely on Julia's implicit line continuation syntax.
    • When naming multiple functions of a single or similar category, prefer to put the general classification first and the specialization second. Example: Use flux_central instead of central_flux. This helps when searching for available functions on the REPL (e.g., when trying to find all flux functions).

    Automated source code formatting

    We use JuliaFormatter.jl to format the source code of Trixi.jl, which will also enforce some of the Conventions listed above (e.g., line length or indentation with 4 spaces are automatically handled, while capitalization of names is not). Our format is mostly based on the SciML-style formatting rules. For more details you can have a look at the current .JuliaFormatter.toml file that holds the configuration options we use for JuliaFormatter.jl.

    Note that we expect all contributions to Trixi.jl to be formatted with JuliaFormatter.jl before being merged to the main branch. We ensure this by running a automated check on all PRs that verify that running JuliaFormatter.jl again will not change the source code.

    To format your contributions before created a PR (or, at least, before requesting a review of your PR), you need to install JuliaFormatter.jl first by running

    julia -e 'using Pkg; Pkg.add("JuliaFormatter")'

    You can then recursively format the core Julia files in the Trixi.jl repo by executing

    julia -e 'using JuliaFormatter; format(["benchmark", "examples", "ext", "src", "test", "utils"])'

    from inside the Trixi.jl repository. For convenience, there is also a script you can directly run from your terminal shell, which will automatically install JuliaFormatter in a temporary environment and then run it:

    utils/trixi-format.jl

    You can get more information about using the convenience script by running it with the --help/-h flag.

    Checking formatting before committing

    It can be convenient to check the formatting of source code automatically before each commit. We use git-hooks for it and provide a pre-commit script in the utils folder. The script uses JuliaFormatter.jl just like formatting script that runs over the whole Trixi.jl directory. You can copy the pre-commit-script into .git/hooks/pre-commit and it will check your formatting before each commit. If errors are found the commit is aborted and you can add the corrections via

    git add -p
    diff --git a/previews/PR1835/testing/index.html b/previews/PR1835/testing/index.html index 8a0a4bf23b7..f916db4b258 100644 --- a/previews/PR1835/testing/index.html +++ b/previews/PR1835/testing/index.html @@ -3,4 +3,4 @@ include(joinpath("test", "test_p4est_2d.jl")) julia> # Run all 1D tests for the Euler equations on the TreeMesh - include(joinpath("test", "test_tree_1d_euler.jl"))

    For the automated tests with GitHub Actions, we run multiple jobs in parallel to reduce the waiting time until all tests are finished. You can see the different components that are run as jobs by looking at the TRIXI_TEST variable in test/runtests.jl.

    Adding new tests

    We use Julia's built-in unit testing capabilities to configure tests. In general, newly added code must be covered by at least one test, and all new elixirs added to the examples/ directory must be used at least once during testing. New tests should be added to the corresponding test/test_xxx.jl file, e.g., a test involving the 3D linear advection equation on the TreeMesh would go into test/test_tree_3d_advection.jl. Please study one of the existing tests and stay consistent to the current style when creating new tests.

    Since we want to test as much as possible, we have a lot of tests and frequently create new ones. Naturally, this increases the time to wait for all tests to pass with each novel feature added to Trixi.jl. Therefore, new tests should be as short as reasonably possible, i.e., without being too insensitive to pick up changes or errors in the code.

    When you add new tests, please check whether all CI jobs still take approximately the same time. If the job where you added new tests takes much longer than everything else, please consider moving some tests from one job to another (or report this incident and ask the main developers for help).

    Test duration

    As a general rule, tests should last no more than 10 seconds when run with a single thread and after compilation (i.e., excluding the first run).

    Test coverage

    In addition to ensuring that the code produces the expected results, the automated tests also record the code coverage. The resulting coverage reports, i.e., which lines of code were executed by at least one test and are thus considered "covered" by testing, are automatically uploaded to Coveralls for easy analysis. Typically, you see a number of Coveralls results at the bottom of each pull request: One for each parallel job (see Testing setup), which can usually be ignored since they only cover parts of the code by definition, and a cumulative coverage result named coverage/coveralls. The "Details" link takes you to a detailed report on which lines of code are covered by tests, which ones are missed, and especially which new lines the pull requests adds to Trixi.jl's code base that are not yet covered by testing.

    Coverage requirements

    In general, we require pull requests to not decrease the overall test coverage percentage in main, with a hard lower bound of 97%.

    + include(joinpath("test", "test_tree_1d_euler.jl"))

    For the automated tests with GitHub Actions, we run multiple jobs in parallel to reduce the waiting time until all tests are finished. You can see the different components that are run as jobs by looking at the TRIXI_TEST variable in test/runtests.jl.

    Adding new tests

    We use Julia's built-in unit testing capabilities to configure tests. In general, newly added code must be covered by at least one test, and all new elixirs added to the examples/ directory must be used at least once during testing. New tests should be added to the corresponding test/test_xxx.jl file, e.g., a test involving the 3D linear advection equation on the TreeMesh would go into test/test_tree_3d_advection.jl. Please study one of the existing tests and stay consistent to the current style when creating new tests.

    Since we want to test as much as possible, we have a lot of tests and frequently create new ones. Naturally, this increases the time to wait for all tests to pass with each novel feature added to Trixi.jl. Therefore, new tests should be as short as reasonably possible, i.e., without being too insensitive to pick up changes or errors in the code.

    When you add new tests, please check whether all CI jobs still take approximately the same time. If the job where you added new tests takes much longer than everything else, please consider moving some tests from one job to another (or report this incident and ask the main developers for help).

    Test duration

    As a general rule, tests should last no more than 10 seconds when run with a single thread and after compilation (i.e., excluding the first run).

    Test coverage

    In addition to ensuring that the code produces the expected results, the automated tests also record the code coverage. The resulting coverage reports, i.e., which lines of code were executed by at least one test and are thus considered "covered" by testing, are automatically uploaded to Coveralls for easy analysis. Typically, you see a number of Coveralls results at the bottom of each pull request: One for each parallel job (see Testing setup), which can usually be ignored since they only cover parts of the code by definition, and a cumulative coverage result named coverage/coveralls. The "Details" link takes you to a detailed report on which lines of code are covered by tests, which ones are missed, and especially which new lines the pull requests adds to Trixi.jl's code base that are not yet covered by testing.

    Coverage requirements

    In general, we require pull requests to not decrease the overall test coverage percentage in main, with a hard lower bound of 97%.

    diff --git a/previews/PR1835/time_integration/index.html b/previews/PR1835/time_integration/index.html index 26b2ad8d7af..55d60e27789 100644 --- a/previews/PR1835/time_integration/index.html +++ b/previews/PR1835/time_integration/index.html @@ -1,2 +1,2 @@ -Time integration · Trixi.jl
    GitHub

    Time integration methods

    Trixi.jl is compatible with the SciML ecosystem for ordinary differential equations. In particular, explicit Runge-Kutta methods from OrdinaryDiffEq.jl are tested extensively. Interesting classes of time integration schemes are

    Some common options for solve from OrdinaryDiffEq.jl are the following. Further documentation can be found in the SciML docs.

    • If you use a fixed time step method like CarpenterKennedy2N54, you need to pass a time step as dt=.... If you use a StepsizeCallback, the value passed as dt=... is irrelevant since it will be overwritten by the StepsizeCallback. If you want to use an adaptive time step method such as SSPRK43 or RDPK3SpFSAL49 and still want to use CFL-based step size control via the StepsizeCallback, you need to pass the keyword argument adaptive=false to solve.
    • You should usually set save_everystep=false. Otherwise, OrdinaryDiffEq.jl will (try to) save the numerical solution after every time step in RAM (until you run out of memory or start to swap).
    • You can set the maximal number of time steps via maxiters=....
    • SSP methods and many low-storage methods from OrdinaryDiffEq.jl support stage_limiter!s and step_limiter!s, e.g., PositivityPreservingLimiterZhangShu from Trixi.jl.
    • If you start Julia with multiple threads and want to use them also in the time integration method from OrdinaryDiffEq.jl, you need to pass the keyword argument thread=OrdinaryDiffEq.True() to the algorithm, e.g., RDPK3SpFSAL49(thread=OrdinaryDiffEq.True()) or CarpenterKennedy2N54(thread=OrdinaryDiffEq.True(), williamson_condition=false). For more information on using thread-based parallelism in Trixi.jl, please refer to Shared-memory parallelization with threads.
    • If you use error-based step size control (see also the section on error-based adaptive step sizes together with MPI, you need to pass internalnorm=ode_norm and you should pass unstable_check=ode_unstable_check to OrdinaryDiffEq's solve, which are both included in ode_default_options.
    Number of `rhs!` calls

    If you use explicit Runge-Kutta methods from OrdinaryDiffEq.jl, the total number of rhs! calls can be (slightly) bigger than the number of steps times the number of stages, e.g. to allow for interpolation (dense output), root-finding for continuous callbacks, and error-based time step control. In general, you often should not need to worry about this if you use Trixi.jl.

    +Time integration · Trixi.jl
    GitHub

    Time integration methods

    Trixi.jl is compatible with the SciML ecosystem for ordinary differential equations. In particular, explicit Runge-Kutta methods from OrdinaryDiffEq.jl are tested extensively. Interesting classes of time integration schemes are

    Some common options for solve from OrdinaryDiffEq.jl are the following. Further documentation can be found in the SciML docs.

    • If you use a fixed time step method like CarpenterKennedy2N54, you need to pass a time step as dt=.... If you use a StepsizeCallback, the value passed as dt=... is irrelevant since it will be overwritten by the StepsizeCallback. If you want to use an adaptive time step method such as SSPRK43 or RDPK3SpFSAL49 and still want to use CFL-based step size control via the StepsizeCallback, you need to pass the keyword argument adaptive=false to solve.
    • You should usually set save_everystep=false. Otherwise, OrdinaryDiffEq.jl will (try to) save the numerical solution after every time step in RAM (until you run out of memory or start to swap).
    • You can set the maximal number of time steps via maxiters=....
    • SSP methods and many low-storage methods from OrdinaryDiffEq.jl support stage_limiter!s and step_limiter!s, e.g., PositivityPreservingLimiterZhangShu from Trixi.jl.
    • If you start Julia with multiple threads and want to use them also in the time integration method from OrdinaryDiffEq.jl, you need to pass the keyword argument thread=OrdinaryDiffEq.True() to the algorithm, e.g., RDPK3SpFSAL49(thread=OrdinaryDiffEq.True()) or CarpenterKennedy2N54(thread=OrdinaryDiffEq.True(), williamson_condition=false). For more information on using thread-based parallelism in Trixi.jl, please refer to Shared-memory parallelization with threads.
    • If you use error-based step size control (see also the section on error-based adaptive step sizes together with MPI, you need to pass internalnorm=ode_norm and you should pass unstable_check=ode_unstable_check to OrdinaryDiffEq's solve, which are both included in ode_default_options.
    Number of `rhs!` calls

    If you use explicit Runge-Kutta methods from OrdinaryDiffEq.jl, the total number of rhs! calls can be (slightly) bigger than the number of steps times the number of stages, e.g. to allow for interpolation (dense output), root-finding for continuous callbacks, and error-based time step control. In general, you often should not need to worry about this if you use Trixi.jl.

    diff --git a/previews/PR1835/troubleshooting/index.html b/previews/PR1835/troubleshooting/index.html index b5679c4edba..b63aab1528a 100644 --- a/previews/PR1835/troubleshooting/index.html +++ b/previews/PR1835/troubleshooting/index.html @@ -44,4 +44,4 @@ set_preferences!(uuid, "PrecompileNoSpecialize" => false) set_preferences!(uuid, "PrecompileNonStiff" => true) set_preferences!(uuid, "PrecompileStiff" => false) -end

    This disables precompilation of all implicit methods. This should usually not affect the runtime latency with Trixi.jl since most setups use explicit time integration methods.

    +end

    This disables precompilation of all implicit methods. This should usually not affect the runtime latency with Trixi.jl since most setups use explicit time integration methods.

    diff --git a/previews/PR1835/tutorials/DGMulti_1/b49c8972.svg b/previews/PR1835/tutorials/DGMulti_1/1159a452.svg similarity index 90% rename from previews/PR1835/tutorials/DGMulti_1/b49c8972.svg rename to previews/PR1835/tutorials/DGMulti_1/1159a452.svg index 908d05fa005..a09292c413a 100644 --- a/previews/PR1835/tutorials/DGMulti_1/b49c8972.svg +++ b/previews/PR1835/tutorials/DGMulti_1/1159a452.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGMulti_1/a41c3abe.svg b/previews/PR1835/tutorials/DGMulti_1/165d3f48.svg similarity index 96% rename from previews/PR1835/tutorials/DGMulti_1/a41c3abe.svg rename to previews/PR1835/tutorials/DGMulti_1/165d3f48.svg index b88b70dab57..37cf694019b 100644 --- a/previews/PR1835/tutorials/DGMulti_1/a41c3abe.svg +++ b/previews/PR1835/tutorials/DGMulti_1/165d3f48.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGMulti_1/c2ebbb1c.svg b/previews/PR1835/tutorials/DGMulti_1/3d8b8e1d.svg similarity index 90% rename from previews/PR1835/tutorials/DGMulti_1/c2ebbb1c.svg rename to previews/PR1835/tutorials/DGMulti_1/3d8b8e1d.svg index 6af48f0fc85..d79a3563785 100644 --- a/previews/PR1835/tutorials/DGMulti_1/c2ebbb1c.svg +++ b/previews/PR1835/tutorials/DGMulti_1/3d8b8e1d.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGMulti_1/3042e87c.svg b/previews/PR1835/tutorials/DGMulti_1/7536ace2.svg similarity index 96% rename from previews/PR1835/tutorials/DGMulti_1/3042e87c.svg rename to previews/PR1835/tutorials/DGMulti_1/7536ace2.svg index 5b97e896c4e..ccb7303acd7 100644 --- a/previews/PR1835/tutorials/DGMulti_1/3042e87c.svg +++ b/previews/PR1835/tutorials/DGMulti_1/7536ace2.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGMulti_1/4dcdc332.svg b/previews/PR1835/tutorials/DGMulti_1/7730dd6a.svg similarity index 96% rename from previews/PR1835/tutorials/DGMulti_1/4dcdc332.svg rename to previews/PR1835/tutorials/DGMulti_1/7730dd6a.svg index db8596f24d1..a9854947908 100644 --- a/previews/PR1835/tutorials/DGMulti_1/4dcdc332.svg +++ b/previews/PR1835/tutorials/DGMulti_1/7730dd6a.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGMulti_1/4353f897.svg b/previews/PR1835/tutorials/DGMulti_1/a00a48c5.svg similarity index 89% rename from previews/PR1835/tutorials/DGMulti_1/4353f897.svg rename to previews/PR1835/tutorials/DGMulti_1/a00a48c5.svg index e15bb627fe6..86e68925904 100644 --- a/previews/PR1835/tutorials/DGMulti_1/4353f897.svg +++ b/previews/PR1835/tutorials/DGMulti_1/a00a48c5.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGMulti_1/index.html b/previews/PR1835/tutorials/DGMulti_1/index.html index dd0adcd937f..8c886577300 100644 --- a/previews/PR1835/tutorials/DGMulti_1/index.html +++ b/previews/PR1835/tutorials/DGMulti_1/index.html @@ -28,11 +28,11 @@ ──────────────────────────────────────────────────────────────────────────────────────────────────── Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3) ──────────────────────────────────────────────────────────────────────────────────────────────────── - #timesteps: 0 run time: 1.34200000e-06 s + #timesteps: 0 run time: 1.17200000e-06 s Δt: 0.00000000e+00 └── GC time: 0.00000000e+00 s (0.000%) sim. time: 0.00000000e+00 (0.000%) time/DOF/rhs!: NaN s PID: Inf s - #DOFs per field: 16384 alloc'd memory: 3139.057 MiB + #DOFs per field: 16384 alloc'd memory: 3093.037 MiB #elements: 1024 Variable: rho rho_v1 rho_v2 rho_e @@ -41,18 +41,18 @@ ∑∂S/∂U ⋅ Uₜ : -4.07691781e-17 ──────────────────────────────────────────────────────────────────────────────────────────────────── -#timesteps: 10 │ Δt: 8.7782e-03 │ sim. time: 6.2446e-02 (15.612%) │ run time: 1.6413e-01 s -#timesteps: 20 │ Δt: 1.2426e-02 │ sim. time: 1.7307e-01 (43.267%) │ run time: 3.0704e-01 s -#timesteps: 30 │ Δt: 1.3710e-02 │ sim. time: 3.0622e-01 (76.554%) │ run time: 4.5073e-01 s +#timesteps: 10 │ Δt: 8.7782e-03 │ sim. time: 6.2446e-02 (15.612%) │ run time: 1.4726e-01 s +#timesteps: 20 │ Δt: 1.2426e-02 │ sim. time: 1.7307e-01 (43.267%) │ run time: 2.8965e-01 s +#timesteps: 30 │ Δt: 1.3710e-02 │ sim. time: 3.0622e-01 (76.554%) │ run time: 4.3320e-01 s ──────────────────────────────────────────────────────────────────────────────────────────────────── Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3) ──────────────────────────────────────────────────────────────────────────────────────────────────── - #timesteps: 37 run time: 5.55476908e-01 s + #timesteps: 37 run time: 5.37119988e-01 s Δt: 9.57329122e-03 └── GC time: 0.00000000e+00 s (0.000%) - sim. time: 4.00000000e-01 (100.000%) time/DOF/rhs!: 9.31099636e-08 s - PID: 1.00204377e-07 s - #DOFs per field: 16384 alloc'd memory: 3143.919 MiB + sim. time: 4.00000000e-01 (100.000%) time/DOF/rhs!: 9.01728126e-08 s + PID: 9.70342496e-08 s + #DOFs per field: 16384 alloc'd memory: 3097.898 MiB #elements: 1024 Variable: rho rho_v1 rho_v2 rho_e @@ -65,8 +65,8 @@ Trixi.jl simulation finished. Final time: 0.4 Time steps: 37 (accepted), 37 (total) ────────────────────────────────────────────────────────────────────────────────────────────────────
    using Plots
 pd = PlotData2D(sol)
-plot(pd)
    Example block output
    plot(pd["rho"])
-plot!(getmesh(pd))
    Example block output

    This simulation is not as fast as the equivalent with TreeMesh since no special optimizations for quads (for instance tensor product structure) have been implemented. Figure 4 in "Efficient implementation of modern entropy stable and kinetic energy preserving discontinuous Galerkin methods for conservation laws" (2021) provides a nice runtime comparison between the different mesh types. On the other hand, the functions are more general and thus we have more option we can choose from.

    Simulation with Gauss nodes

    For instance, we can change the approximation type of our simulation.

    using Trixi, OrdinaryDiffEq
+plot(pd)
    Example block output
    plot(pd["rho"])
+plot!(getmesh(pd))
    Example block output

    This simulation is not as fast as the equivalent with TreeMesh since no special optimizations for quads (for instance tensor product structure) have been implemented. Figure 4 in "Efficient implementation of modern entropy stable and kinetic energy preserving discontinuous Galerkin methods for conservation laws" (2021) provides a nice runtime comparison between the different mesh types. On the other hand, the functions are more general and thus we have more option we can choose from.

    Simulation with Gauss nodes

    For instance, we can change the approximation type of our simulation.

    using Trixi, OrdinaryDiffEq
 equations = CompressibleEulerEquations2D(1.4)
 initial_condition = initial_condition_weak_blast_wave
    initial_condition_weak_blast_wave (generic function with 13 methods)

    We now use Gauss nodes instead of Gauss-Lobatto nodes which can be done for the element types Quad() and Hex(). Therefore, we set approximation_type=GaussSBP(). Alternatively, we can use a modal approach using the approximation type Polynomial().

    dg = DGMulti(polydeg = 3,
              element_type = Quad(),
@@ -95,11 +95,11 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                  0                run time:       1.26200000e-06 s
+ #timesteps:                  0                run time:       1.21200000e-06 s
  Δt:             0.00000000e+00                └── GC time:    0.00000000e+00 s (0.000%)
  sim. time:      0.00000000e+00 (0.000%)       time/DOF/rhs!:         NaN s
                                                PID:                   Inf s
- #DOFs per field:         16384                alloc'd memory:       3183.833 MiB
+ #DOFs per field:         16384                alloc'd memory:       3160.108 MiB
  #elements:                1024
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -108,19 +108,19 @@
  ∑∂S/∂U ⋅ Uₜ :  -1.01164379e-01
 ────────────────────────────────────────────────────────────────────────────────────────────────────
 
-#timesteps:     10 │ Δt: 5.0548e-03 │ sim. time: 3.3436e-02 (8.359%)   │ run time: 4.7245e-01 s
-#timesteps:     20 │ Δt: 8.8313e-03 │ sim. time: 1.0601e-01 (26.503%)  │ run time: 9.3220e-01 s
-#timesteps:     30 │ Δt: 1.0521e-02 │ sim. time: 2.0438e-01 (51.094%)  │ run time: 1.3931e+00 s
-#timesteps:     40 │ Δt: 1.1006e-02 │ sim. time: 3.1245e-01 (78.113%)  │ run time: 1.8590e+00 s
+#timesteps:     10 │ Δt: 5.0548e-03 │ sim. time: 3.3436e-02 (8.359%)   │ run time: 4.7252e-01 s
+#timesteps:     20 │ Δt: 8.8313e-03 │ sim. time: 1.0601e-01 (26.503%)  │ run time: 9.3221e-01 s
+#timesteps:     30 │ Δt: 1.0521e-02 │ sim. time: 2.0438e-01 (51.094%)  │ run time: 1.4002e+00 s
+#timesteps:     40 │ Δt: 1.1006e-02 │ sim. time: 3.1245e-01 (78.113%)  │ run time: 1.8629e+00 s
 
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                 48                run time:       2.25958288e+00 s
- Δt:             1.00192333e-02                └── GC time:    0.00000000e+00 s (0.000%)
- sim. time:      4.00000000e-01 (100.000%)     time/DOF/rhs!:  3.02281338e-07 s
-                                               PID:            3.16122676e-07 s
- #DOFs per field:         16384                alloc'd memory:       3186.203 MiB
+ #timesteps:                 48                run time:       2.27938922e+00 s
+ Δt:             1.00192333e-02                └── GC time:    2.60392470e-02 s (1.142%)
+ sim. time:      4.00000000e-01 (100.000%)     time/DOF/rhs!:  3.00442527e-07 s
+                                               PID:            3.14562162e-07 s
+ #DOFs per field:         16384                alloc'd memory:       3120.932 MiB
  #elements:                1024
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -133,7 +133,7 @@
 Trixi.jl simulation finished.  Final time: 0.4  Time steps: 48 (accepted), 48 (total)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
    using Plots
 pd = PlotData2D(sol)
-plot(pd)
    Example block output

    Simulation with triangular elements

    Also, we can set another element type. We want to use triangles now.

    using Trixi, OrdinaryDiffEq
+plot(pd)
    Example block output

    Simulation with triangular elements

    Also, we can set another element type. We want to use triangles now.

    using Trixi, OrdinaryDiffEq
 equations = CompressibleEulerEquations2D(1.4)
 initial_condition = initial_condition_weak_blast_wave
    initial_condition_weak_blast_wave (generic function with 13 methods)

    Since there is no direct equivalent to Gauss-Lobatto nodes on triangles, the approximation type SBP() now uses Gauss-Lobatto nodes on faces and special nodes in the interior of the triangular. More details can be found in the documentation of StartUpDG.jl.

    dg = DGMulti(polydeg = 3,
              element_type = Tri(),
@@ -162,11 +162,11 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                  0                run time:       1.66300000e-06 s
+ #timesteps:                  0                run time:       1.09100000e-06 s
  Δt:             0.00000000e+00                └── GC time:    0.00000000e+00 s (0.000%)
  sim. time:      0.00000000e+00 (0.000%)       time/DOF/rhs!:         NaN s
                                                PID:                   Inf s
- #DOFs per field:         30720                alloc'd memory:       3229.800 MiB
+ #DOFs per field:         30720                alloc'd memory:       3157.564 MiB
  #elements:                2048
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -175,19 +175,19 @@
  ∑∂S/∂U ⋅ Uₜ :  -6.74736856e-03
 ────────────────────────────────────────────────────────────────────────────────────────────────────
 
-#timesteps:     10 │ Δt: 6.6947e-03 │ sim. time: 4.5960e-02 (11.490%)  │ run time: 8.3880e-01 s
-#timesteps:     20 │ Δt: 1.0524e-02 │ sim. time: 1.3699e-01 (34.249%)  │ run time: 1.6435e+00 s
-#timesteps:     30 │ Δt: 1.2096e-02 │ sim. time: 2.5197e-01 (62.993%)  │ run time: 2.4581e+00 s
-#timesteps:     40 │ Δt: 1.2622e-02 │ sim. time: 3.7597e-01 (93.993%)  │ run time: 3.2961e+00 s
+#timesteps:     10 │ Δt: 6.6947e-03 │ sim. time: 4.5960e-02 (11.490%)  │ run time: 8.0745e-01 s
+#timesteps:     20 │ Δt: 1.0524e-02 │ sim. time: 1.3699e-01 (34.249%)  │ run time: 1.6019e+00 s
+#timesteps:     30 │ Δt: 1.2096e-02 │ sim. time: 2.5197e-01 (62.993%)  │ run time: 2.4084e+00 s
+#timesteps:     40 │ Δt: 1.2622e-02 │ sim. time: 3.7597e-01 (93.993%)  │ run time: 3.2388e+00 s
 
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                 42                run time:       3.47340912e+00 s
+ #timesteps:                 42                run time:       3.41331692e+00 s
  Δt:             1.13592115e-02                └── GC time:    0.00000000e+00 s (0.000%)
- sim. time:      4.00000000e-01 (100.000%)     time/DOF/rhs!:  2.87681030e-07 s
-                                               PID:            2.95732116e-07 s
- #DOFs per field:         30720                alloc'd memory:       3238.711 MiB
+ sim. time:      4.00000000e-01 (100.000%)     time/DOF/rhs!:  2.83823036e-07 s
+                                               PID:            2.90715881e-07 s
+ #DOFs per field:         30720                alloc'd memory:       3166.476 MiB
  #elements:                2048
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -200,8 +200,8 @@
 Trixi.jl simulation finished.  Final time: 0.4  Time steps: 42 (accepted), 42 (total)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
    using Plots
 pd = PlotData2D(sol)
-plot(pd)
    Example block output
    plot(pd["rho"])
-plot!(getmesh(pd))
    Example block output

    Triangular meshes on non-Cartesian domains

    To use triangular meshes on a non-Cartesian domain, Trixi.jl uses the package StartUpDG.jl. The following example is based on elixir_euler_triangulate_pkg_mesh.jl and uses a pre-defined mesh from StartUpDG.jl.

    using Trixi, OrdinaryDiffEq

    We want to simulate the smooth initial condition initial_condition_convergence_test with source terms source_terms_convergence_test for the 2D compressible Euler equations.

    equations = CompressibleEulerEquations2D(1.4)
+plot(pd)
    Example block output
    plot(pd["rho"])
+plot!(getmesh(pd))
    Example block output

    Triangular meshes on non-Cartesian domains

    To use triangular meshes on a non-Cartesian domain, Trixi.jl uses the package StartUpDG.jl. The following example is based on elixir_euler_triangulate_pkg_mesh.jl and uses a pre-defined mesh from StartUpDG.jl.

    using Trixi, OrdinaryDiffEq

    We want to simulate the smooth initial condition initial_condition_convergence_test with source terms source_terms_convergence_test for the 2D compressible Euler equations.

    equations = CompressibleEulerEquations2D(1.4)
 initial_condition = initial_condition_convergence_test
 source_terms = source_terms_convergence_test
    source_terms_convergence_test (generic function with 13 methods)

    We create the solver DGMulti with triangular elements (Tri()) as before.

    dg = DGMulti(polydeg = 3, element_type = Tri(),
              approximation_type=Polynomial(),
@@ -242,11 +242,11 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                  0                run time:       1.21300000e-06 s
+ #timesteps:                  0                run time:       1.38200000e-06 s
  Δt:             1.49245207e-03                └── GC time:    0.00000000e+00 s (0.000%)
  sim. time:      0.00000000e+00 (0.000%)       time/DOF/rhs!:         NaN s
                                                PID:                   Inf s
- #DOFs per field:          5980                alloc'd memory:       3265.068 MiB
+ #DOFs per field:          5980                alloc'd memory:       3211.341 MiB
  #elements:                 598
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -255,12 +255,12 @@
  ∑∂S/∂U ⋅ Uₜ :  -1.23444983e-02
 ────────────────────────────────────────────────────────────────────────────────────────────────────
 
-#timesteps:     20 │ Δt: 1.4925e-03 │ sim. time: 2.9849e-02 (14.925%)  │ run time: 5.3865e-01 s
-#timesteps:     40 │ Δt: 1.4925e-03 │ sim. time: 5.9698e-02 (29.849%)  │ run time: 1.0646e+00 s
-#timesteps:     60 │ Δt: 1.4925e-03 │ sim. time: 8.9547e-02 (44.774%)  │ run time: 1.5908e+00 s
-#timesteps:     80 │ Δt: 1.4925e-03 │ sim. time: 1.1940e-01 (59.698%)  │ run time: 2.1175e+00 s
-#timesteps:    100 │ Δt: 1.4925e-03 │ sim. time: 1.4925e-01 (74.623%)  │ run time: 2.6561e+00 s
-#timesteps:    120 │ Δt: 1.4925e-03 │ sim. time: 1.7909e-01 (89.547%)  │ run time: 3.1827e+00 s
+#timesteps:     20 │ Δt: 1.4925e-03 │ sim. time: 2.9849e-02 (14.925%)  │ run time: 5.4218e-01 s
+#timesteps:     40 │ Δt: 1.4925e-03 │ sim. time: 5.9698e-02 (29.849%)  │ run time: 1.0675e+00 s
+#timesteps:     60 │ Δt: 1.4925e-03 │ sim. time: 8.9547e-02 (44.774%)  │ run time: 1.5910e+00 s
+#timesteps:     80 │ Δt: 1.4925e-03 │ sim. time: 1.1940e-01 (59.698%)  │ run time: 2.1134e+00 s
+#timesteps:    100 │ Δt: 1.4925e-03 │ sim. time: 1.4925e-01 (74.623%)  │ run time: 2.6369e+00 s
+#timesteps:    120 │ Δt: 1.4925e-03 │ sim. time: 1.7909e-01 (89.547%)  │ run time: 3.1652e+00 s
 ────────────────────────────────────────────────────────────────────────────────────────────────────
 Trixi.jl simulation finished.  Final time: 0.2  Time steps: 135 (accepted), 135 (total)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
@@ -269,11 +269,11 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGMulti(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                135                run time:       3.57607922e+00 s
+ #timesteps:                135                run time:       3.56016898e+00 s
  Δt:             1.14223386e-05                └── GC time:    0.00000000e+00 s (0.000%)
- sim. time:      2.00000000e-01 (100.000%)     time/DOF/rhs!:  8.76233510e-07 s
-                                               PID:            8.83140817e-07 s
- #DOFs per field:          5980                alloc'd memory:       3265.540 MiB
+ sim. time:      2.00000000e-01 (100.000%)     time/DOF/rhs!:  8.72377851e-07 s
+                                               PID:            8.79220666e-07 s
+ #DOFs per field:          5980                alloc'd memory:       3211.813 MiB
  #elements:                 598
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -283,7 +283,7 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
    using Plots
 pd = PlotData2D(sol)
 plot(pd["rho"])
-plot!(getmesh(pd))
    Example block output

    For more information, please have a look in the StartUpDG.jl documentation.

    Package versions

    These results were obtained using the following versions.

    using InteractiveUtils
+plot!(getmesh(pd))
    Example block output

    For more information, please have a look in the StartUpDG.jl documentation.

    Package versions

    These results were obtained using the following versions.

    using InteractiveUtils
 versioninfo()
 
 using Pkg
@@ -306,4 +306,4 @@
 ⌅ [91a5bcdd] Plots v1.39.0
   [472ebc20] StartUpDG v0.17.7
   [a7f1ee26] Trixi v0.7.3-pre `~/work/Trixi.jl/Trixi.jl`
-Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`

    This page was generated using Literate.jl.

    +Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`

    This page was generated using Literate.jl.

    diff --git a/previews/PR1835/tutorials/DGMulti_2/index.html b/previews/PR1835/tutorials/DGMulti_2/index.html index a2c0455a2ca..80fe9d55cb8 100644 --- a/previews/PR1835/tutorials/DGMulti_2/index.html +++ b/previews/PR1835/tutorials/DGMulti_2/index.html @@ -33,4 +33,4 @@ Status `~/work/Trixi.jl/Trixi.jl/docs/Manifest.toml` [472ebc20] StartUpDG v0.17.7 [9f78cca6] SummationByPartsOperators v0.5.56 - [a7f1ee26] Trixi v0.7.3-pre `~/work/Trixi.jl/Trixi.jl`

    This page was generated using Literate.jl.

    + [a7f1ee26] Trixi v0.7.3-pre `~/work/Trixi.jl/Trixi.jl`

    This page was generated using Literate.jl.

    diff --git a/previews/PR1835/tutorials/DGSEM_FluxDiff/d81d7bd0.svg b/previews/PR1835/tutorials/DGSEM_FluxDiff/249f04e3.svg similarity index 95% rename from previews/PR1835/tutorials/DGSEM_FluxDiff/d81d7bd0.svg rename to previews/PR1835/tutorials/DGSEM_FluxDiff/249f04e3.svg index 8ca0d7a8e20..9627e84845c 100644 --- a/previews/PR1835/tutorials/DGSEM_FluxDiff/d81d7bd0.svg +++ b/previews/PR1835/tutorials/DGSEM_FluxDiff/249f04e3.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGSEM_FluxDiff/927838a6.svg b/previews/PR1835/tutorials/DGSEM_FluxDiff/639d223c.svg similarity index 94% rename from previews/PR1835/tutorials/DGSEM_FluxDiff/927838a6.svg rename to previews/PR1835/tutorials/DGSEM_FluxDiff/639d223c.svg index 2f5bd99e520..b195f945f30 100644 --- a/previews/PR1835/tutorials/DGSEM_FluxDiff/927838a6.svg +++ b/previews/PR1835/tutorials/DGSEM_FluxDiff/639d223c.svg @@ -1,45 +1,45 @@ - + - + - + - + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - - + + - + - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/DGSEM_FluxDiff/index.html b/previews/PR1835/tutorials/DGSEM_FluxDiff/index.html index 58451ddaa96..c14a3ccb811 100644 --- a/previews/PR1835/tutorials/DGSEM_FluxDiff/index.html +++ b/previews/PR1835/tutorials/DGSEM_FluxDiff/index.html @@ -54,11 +54,11 @@ ──────────────────────────────────────────────────────────────────────────────────────────────────── Simulation running 'CompressibleEulerEquations2D' with DGSEM(polydeg=3) ──────────────────────────────────────────────────────────────────────────────────────────────────── - #timesteps: 0 run time: 1.09200000e-06 s + #timesteps: 0 run time: 9.62000000e-07 s Δt: 0.00000000e+00 └── GC time: 0.00000000e+00 s (0.000%) sim. time: 0.00000000e+00 (0.000%) time/DOF/rhs!: NaN s PID: Inf s - #DOFs per field: 16384 alloc'd memory: 3280.459 MiB + #DOFs per field: 16384 alloc'd memory: 3226.705 MiB #elements: 1024 Variable: rho rho_v1 rho_v2 rho_e @@ -71,11 +71,11 @@ ──────────────────────────────────────────────────────────────────────────────────────────────────── Simulation running 'CompressibleEulerEquations2D' with DGSEM(polydeg=3) ──────────────────────────────────────────────────────────────────────────────────────────────────── - #timesteps: 61 run time: 9.05740855e-01 s + #timesteps: 61 run time: 8.96736539e-01 s Δt: 2.65388338e-06 └── GC time: 0.00000000e+00 s (0.000%) - sim. time: 4.00000000e-01 (100.000%) time/DOF/rhs!: 9.11295657e-08 s - PID: 9.96956489e-08 s - #DOFs per field: 16384 alloc'd memory: 3282.186 MiB + sim. time: 4.00000000e-01 (100.000%) time/DOF/rhs!: 9.08656111e-08 s + PID: 9.87062505e-08 s + #DOFs per field: 16384 alloc'd memory: 3228.433 MiB #elements: 1024 Variable: rho rho_v1 rho_v2 rho_e @@ -83,7 +83,7 @@ Linf error: 2.91149630e-01 3.21787795e-01 3.22040740e-01 1.04645370e+00 ∑∂S/∂U ⋅ Uₜ : -4.30663196e-18 ────────────────────────────────────────────────────────────────────────────────────────────────────

    A look at the change in entropy $\sum \partial S/\partial U \cdot U_t$ in the analysis callback confirms that the flux is entropy conserving since the change is about machine precision.

    We can plot the approximated solution at the time t=0.4.

    using Plots
-plot(sol)
    Example block output

    Now, we can use for instance the dissipative flux flux_lax_friedrichs as surface flux to get an entropy stable method.

    using OrdinaryDiffEq, Trixi
+plot(sol)
    Example block output

    Now, we can use for instance the dissipative flux flux_lax_friedrichs as surface flux to get an entropy stable method.

    using OrdinaryDiffEq, Trixi
 
 gamma = 1.4
 equations = CompressibleEulerEquations2D(gamma)
@@ -113,11 +113,11 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGSEM(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                  0                run time:       7.41000000e-07 s
+ #timesteps:                  0                run time:       8.11000000e-07 s
  Δt:             0.00000000e+00                └── GC time:    0.00000000e+00 s (0.000%)
  sim. time:      0.00000000e+00 (0.000%)       time/DOF/rhs!:         NaN s
                                                PID:                   Inf s
- #DOFs per field:         16384                alloc'd memory:       3280.874 MiB
+ #DOFs per field:         16384                alloc'd memory:       3227.492 MiB
  #elements:                1024
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -130,11 +130,11 @@
 ────────────────────────────────────────────────────────────────────────────────────────────────────
  Simulation running 'CompressibleEulerEquations2D' with DGSEM(polydeg=3)
 ────────────────────────────────────────────────────────────────────────────────────────────────────
- #timesteps:                 37                run time:       5.18473250e-01 s
+ #timesteps:                 37                run time:       5.25867633e-01 s
  Δt:             9.70561500e-03                └── GC time:    0.00000000e+00 s (0.000%)
- sim. time:      4.00000000e-01 (100.000%)     time/DOF/rhs!:  8.70282729e-08 s
-                                               PID:            9.34307224e-08 s
- #DOFs per field:         16384                alloc'd memory:       3282.600 MiB
+ sim. time:      4.00000000e-01 (100.000%)     time/DOF/rhs!:  8.66161754e-08 s
+                                               PID:            9.47827054e-08 s
+ #DOFs per field:         16384                alloc'd memory:       3229.218 MiB
  #elements:                1024
 
  Variable:       rho              rho_v1           rho_v2           rho_e
@@ -142,7 +142,7 @@
  Linf error:     2.61815838e-01   2.48816692e-01   2.48316760e-01   9.30972696e-01
  ∑∂S/∂U ⋅ Uₜ :  -1.40306972e-04
 ────────────────────────────────────────────────────────────────────────────────────────────────────

    The change in entropy confirms the expected entropy stability.

    using Plots
-plot(sol)
    Example block output

    Of course, you can use more than these two fluxes in Trixi. Here, we will give a short list of possible fluxes for the compressible Euler equations. For the volume flux Trixi.jl provides for example flux_ranocha, flux_shima_etal, flux_chandrashekar, flux_kennedy_gruber. As surface flux you can use all volume fluxes and additionally for instance flux_lax_friedrichs, flux_hll, flux_hllc.

    Package versions

    These results were obtained using the following versions.

    using InteractiveUtils
+plot(sol)
    Example block output

    Of course, you can use more than these two fluxes in Trixi. Here, we will give a short list of possible fluxes for the compressible Euler equations. For the volume flux Trixi.jl provides for example flux_ranocha, flux_shima_etal, flux_chandrashekar, flux_kennedy_gruber. As surface flux you can use all volume fluxes and additionally for instance flux_lax_friedrichs, flux_hll, flux_hllc.

    Package versions

    These results were obtained using the following versions.

    using InteractiveUtils
 versioninfo()
 
 using Pkg
@@ -164,4 +164,4 @@
 ⌅ [1dea7af3] OrdinaryDiffEq v6.66.0
 ⌅ [91a5bcdd] Plots v1.39.0
   [a7f1ee26] Trixi v0.7.3-pre `~/work/Trixi.jl/Trixi.jl`
-Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`

    This page was generated using Literate.jl.

    +Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`

    This page was generated using Literate.jl.

    diff --git a/previews/PR1835/tutorials/adaptive_mesh_refinement/8eb1db25.svg b/previews/PR1835/tutorials/adaptive_mesh_refinement/607e3074.svg similarity index 85% rename from previews/PR1835/tutorials/adaptive_mesh_refinement/8eb1db25.svg rename to previews/PR1835/tutorials/adaptive_mesh_refinement/607e3074.svg index 0d1511cb78a..ef1752bc712 100644 --- a/previews/PR1835/tutorials/adaptive_mesh_refinement/8eb1db25.svg +++ b/previews/PR1835/tutorials/adaptive_mesh_refinement/607e3074.svg @@ -1,35 +1,35 @@ - + - + - + - + - + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + diff --git a/previews/PR1835/tutorials/adaptive_mesh_refinement/index.html b/previews/PR1835/tutorials/adaptive_mesh_refinement/index.html index 76083bd02c1..d109782ce34 100644 --- a/previews/PR1835/tutorials/adaptive_mesh_refinement/index.html +++ b/previews/PR1835/tutorials/adaptive_mesh_refinement/index.html @@ -53,7 +53,7 @@ save_everystep=false, callback=callbacks);

    We plot the solution and add the refined mesh at the end of the simulation.

    using Plots
 pd = PlotData2D(sol)
 plot(pd)
-plot!(getmesh(pd))
    Example block output

    More examples

    Trixi.jl provides many elixirs using AMR. We want to give some examples for different mesh types:

    Animations of more interesting and complicated AMR simulations can be found below and on Trixi.jl's youtube channel "Trixi Framework".

    First, we give a purely hyperbolic simulation of a Sedov blast wave with self-gravity. This simulation uses the mesh type TreeMesh as we did and the AMR indicator IndicatorHennemannGassner.

    Trixi2Vtk

    Trixi2Vtk converts Trixi.jl's .h5 output files to VTK files, which can be read by ParaView, VisIt, and other visualization tools. It automatically interpolates solution data from the original quadrature node locations to equidistant visualization nodes at a higher resolution, to make up for the loss of accuracy from going from a high-order polynomial representation to a piecewise constant representation in VTK.

    In the Julia REPL, first load the package Trixi2Vtk

    julia> using Trixi2Vtk

    To process an HDF5 file generated by Trixi.jl, execute

    julia> trixi2vtk(joinpath("out", "solution_000000.h5"), output_directory="out")

    This will create two unstructured VTK files in the out subdirectory that can be opened with ParaView or VisIt: solution_000000.vtu contains the discontinuous Galerkin solution data while solution_000000_celldata.vtu holds any cell-based values such as the current AMR indicator or the cell refinement level.

    "solution_000000_scalar_mesh"

    This allows you to generate VTK files for solution, restart and mesh files. By default, Trixi2Vtk generates .vtu (unstructured VTK) files for both cell/element data (e.g., cell ids, element ids) and node data (e.g., solution variables). This format visualizes each cell with the same number of nodes, independent of its size. Alternatively, you can provide format=:vti as a keyword argument to trixi2vtk, which causes Trixi2Vtk to generate .vti (image data VTK) files for the solution files, while still using .vtu files for cell-/element-based data. In .vti files, a uniform resolution is used throughout the entire domain, resulting in different number of visualization nodes for each element. This can be advantageous to create publication-quality images, but increases the file size.

    If you want to convert multiple solution/restart files at once, you can just supply multiple input files as the positional arguments to trixi2vtk, e.g.,

    julia> trixi2vtk("out/solution_000000.h5", "out/solution_000040.h5")

    You may also use file globbing to select a range of files based on filename patterns, e.g.,

    julia> trixi2vtk("out/solution_*.h5")

    to convert all solution files in the out/ directory or

    julia> trixi2vtk("out/restart_00[0-9]000.h5")

    to convert every one-thousandth restart file (out/restart_000000.h5, out/restart_001000.h5 etc.).

    When multiple solution/restart files are provided, Trixi2Vtk will also generate a .pvd file, which allows ParaView to read all .vtu/.vti files at once and which uses the time attribute in solution/restart files to inform ParaView about the solution time. A comprehensive list of all possible arguments for trixi2vtk can be found in the Trixi2Vtk.jl API.

    Further information regarding the development of Trixi2Vtk can be found in the development section.

    Makie.jl [experimental]

    In addition to Plots.jl support, Trixi.jl includes visualization utilities through Makie.jl. Trixi.jl provides Makie-based visualization options both for heatmap-type plots (similar to the Plots.jl recipes) as well as for interactive surface plots. Support is currently limited to the UnstructuredMesh2D type.

    Note

    Plotting via Makie.jl is still considered an experimental feature and might change in any future releases.

    A Makie plot can be created as follows: after running a simulation with Trixi.jl in the REPL, load a Makie backend (for example, GLMakie or CairoMakie).

    julia> using GLMakie

    To visualize the solution and mesh with a heatmap-type plot, simply run

    julia> plot(sol)
    Note

    Both Makie.jl and Plots.jl export plot, so if you load both libraries, you will have to specify which plot function to call via Plots.plot or Makie.plot.

    As with Plots.jl recipes, one can view individual solution components by creating a PlotData2D object and indexing into it with the desired variable name

    julia> pd = PlotData2D(sol)
 julia> plot(pd["rho"])

    Unlike the Plots.jl recipe, mesh plotting is controlled using the keyword argument plot_mesh = false, e.g.,

    julia> plot(sol; plot_mesh=false)

    The plot command also returns figure and axis handles, which can be used to edit plot titles or labels:

    julia> fig, axes = plot(sol)
-julia> axes[1,1].title = "New title for subplot (1,1)"

    Trixi.jl also supports interactive surface plots using iplot. After executing

    julia> trixi_include(joinpath("examples", "unstructured_2d_dgsem", "elixir_euler_wall_bc.jl"))

    we can run

    julia> iplot(sol)

    This will open up an interactive visualization window:

    makie-example

    The plot can be rotated (click and hold), zoomed in and out (scroll up and down), and panned (hold right click and drag). Two toggle buttons control whether mesh lines are visible on top of and below the solution.

    Both plot and iplot use colormap = :inferno by default. A different colormap can be selected by providing an appropriate keyword argument. For example, plot(sol, colormap=:blues) and iplot(sol, colormap=:blues) produce the following figures:

    makie-plot-example makie-iplot-example

    +julia> axes[1,1].title = "New title for subplot (1,1)"

    Trixi.jl also supports interactive surface plots using iplot. After executing

    julia> trixi_include(joinpath("examples", "unstructured_2d_dgsem", "elixir_euler_wall_bc.jl"))

    we can run

    julia> iplot(sol)

    This will open up an interactive visualization window:

    makie-example

    The plot can be rotated (click and hold), zoomed in and out (scroll up and down), and panned (hold right click and drag). Two toggle buttons control whether mesh lines are visible on top of and below the solution.

    Both plot and iplot use colormap = :inferno by default. A different colormap can be selected by providing an appropriate keyword argument. For example, plot(sol, colormap=:blues) and iplot(sol, colormap=:blues) produce the following figures:

    makie-plot-example makie-iplot-example