-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DGMulti
support for curved meshes and parabolic terms
#1400
DGMulti
support for curved meshes and parabolic terms
#1400
Conversation
- it's not necessary for coercivity (BR1 is coercive with any penalty parameter > 0; a factor of 1/h is only necessary for IPDG) - simplifies the implementation for curved meshes - it's not in CI tests yet (should be added soon)
Codecov Report
@@ Coverage Diff @@
## main #1400 +/- ##
==========================================
- Coverage 95.97% 91.19% -4.78%
==========================================
Files 351 353 +2
Lines 29122 29337 +215
==========================================
- Hits 27949 26752 -1197
- Misses 1173 2585 +1412
Flags with carried forward coverage won't be shown. Click here to find out more.
|
the call isn't that complex, and it's easier for me to debug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for working on this, @jlchan! Please find below some comments after an initial review. It would be great to get some additional eyes on this.
- p * rho * rho_yy ) * mu_ ) | ||
|
||
return SVector(du1, du2, du3, du4) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just assume you copied this setup and did not review it properly (same in 3D).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this referring to the type-unstable (indexing) comment above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No - to the actual formulas of the manufactured solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the exact same as the setup for elixir_navierstokes_convergence.jl
. I can add a comment mentioning this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, I could just run elixir_navierstokes_convergence.jl
and pass a new mesh through trixi_include
instead of creating new elixirs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, using trixi_include
didn't work. I added some comments noting the origin of the manufactured solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively... shouldn't we add the NSE convergence test to the CompressibleNSEDiffusionXD
types? IIRC, we do have a similar function for most other equation systems. Or was there an issue with that why this didn't work/why this is super awkward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine from my side to keep it as it is - I just wanted to say that I didn't want to read it 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sloede we could. The only potential issue I see is that the source and initial condition require functions mu()
and prandtl_number()
to be defined (see https://github.com/jlchan/Trixi.jl/blob/a8c0933bd0077c45372c3937c40fce772e348886/examples/dgmulti_2d/elixir_navierstokes_convergence.jl#L56-L57). These functions are necessary due to the fact that initial conditions cannot specialize on only one equation type, since they are called both with equations::CompressibleEulerEquations2D
and equations::CompressibleNavierStokesDiffusion2D
in different places.
To me, moving the NSE convergence test functions out of the elixir makes these implicit requirements even less clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Let's keep them as they are, please.
@ranocha any idea why Invalidations.yml keeps failing? |
Invalidations CI run fails because of aviatesk/JET.jl#499. That's not critical right now. |
Co-authored-by: Hendrik Ranocha <[email protected]>
this makes it so this PR is no longer a breaking change
This reverts commit adc0fde.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot! This looks good to me.
This PR adds support for curved parabolic terms. The previous approach taken for parabolic terms was to
du
Here, we switch to the following workflow
du
This is mathematically equivalent to the former approach, but ensures that the resulting scheme is symmetric and entropy/energy dissipative even on curved meshes. It should also be slightly more efficient (fewer multiplications by interpolation matrices).
Unfortunately, because this involved rewriting much of the parabolic framework, it is a somewhat large PR - apologies in advance.