-
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
Hll 2 wave improvements #1545
Hll 2 wave improvements #1545
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1545 +/- ##
==========================================
- Coverage 96.04% 96.02% -0.03%
==========================================
Files 368 369 +1
Lines 31049 31394 +345
==========================================
+ Hits 29821 30144 +323
- Misses 1228 1250 +22
Flags with carried forward coverage won't be shown. Click here to find out more.
|
I haven't thought this through, but I'm just curious. Would something like the following work? Since function min_max_speed(u_ll, u_rr, orientation::Integer, equations::AbstractEquations)
λ_ll = eigenvalues(u_ll, orientation, equations)
λ_rr = eigenvalues(u_rr, orientation, equations)
λ_min = min(λ_ll)
λ_max = max(λ_rr)
return λ_min, λ_max
end and define for each equation a function returning the eigenvalues, e.g. function eigenvalues(u, orientation::Integer, equations::CompressibleEulerEquations1D)
rho, v1, p = cons2prim(u, equations)
c = sqrt(equations.gamma * p / rho)
return v1 - c1, v1, v1 + c1
end We probably need analogous definitions for |
So for the classical HLL 2-Wave solver you would have function min_max_speed(u_ll, u_rr, orientation::Integer, equations::AbstractEquations)
λ_ll = eigenvalues(u_ll, orientation, equations)
λ_rr = eigenvalues(u_rr, orientation, equations)
λ_min = min(min(λ_ll), min(λ_rr))
λ_max = max(max(λ_ll), max((λ_rr))
return λ_min, λ_max
end which is probably more expensive than the current implementations. |
Yes. Performance-wise you are probably right. Of course, I am totally fine if we don't implement this because of performance issues. I was just mainly curious if this would work in general. |
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 for your effort! This is quite a lot of stuff. It is helpful to break big changes like this down to several smaller PRs to speed up the review process.
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 is already in a good shape. However, it contains some breaking changes along with other implementations that can be useful right now. Thus, I would like to ask you to split this into two PRs.
- One PR can implement the purely new functionality. This will be not breaking and already a nice addition.
- Another PR can implement the breaking changes of the behavior for MHD.
When I drafted the interface of FluxHLL
originally in another package in 217 or so, my version of what we call min_max_speed_naive
in Trixi.jl was basically what you understand as min_max_speed_davis
. I agree with you that this is probably one of the first things people may expect since it easy and already quite good. Thus, I wonder whether we really need the sometimes unexpected version of min_max_speed_naive
in Trixi.jl or whether we should replace it by minmax_speed_davis
in the long run. Any thoughts about this, @trixi-framework/principal-developers?
""" | ||
min_max_speed_naive(u_ll, u_rr, orientation, equations::IdealGlmMhdEquations1D) | ||
min_max_speed_einfeldt(u_ll, u_rr, orientation::Integer, equations::IdealGlmMhdEquations1D) | ||
|
||
Calculate minimum and maximum wave speeds for HLL-type fluxes as in | ||
- Li (2005) | ||
An HLLC Riemann solver for magneto-hydrodynamics | ||
[DOI: 10.1016/j.jcp.2004.08.020](https://doi.org/10.1016/j.jcp.2004.08.020) | ||
[DOI: 10.1016/j.jcp.2004.08.020](https://doi.org/10.1016/j.jcp.2004.08.020). | ||
""" | ||
@inline function min_max_speed_naive(u_ll, u_rr, orientation::Integer, | ||
equations::IdealGlmMhdEquations1D) | ||
@inline function min_max_speed_einfeldt(u_ll, u_rr, orientation::Integer, | ||
equations::IdealGlmMhdEquations1D) | ||
rho_ll, rho_v1_ll, _ = u_ll | ||
rho_rr, rho_v1_rr, _ = u_rr |
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.
This is the part that I consider to be breaking since it changes the behavior we have so far quite a bit.
# Calculate estimates for minimum and maximum wave speeds for HLL-type fluxes | ||
@inline function min_max_speed_naive(u_ll, u_rr, orientation::Integer, | ||
equations::IdealGlmMhdEquations1D) | ||
rho_ll, rho_v1_ll, _ = u_ll | ||
rho_rr, rho_v1_rr, _ = u_rr | ||
|
||
# Calculate primitive variables | ||
v1_ll = rho_v1_ll / rho_ll | ||
v1_rr = rho_v1_rr / rho_rr | ||
|
||
λ_min = v1_ll - calc_fast_wavespeed(u_ll, orientation, equations) | ||
λ_max = v1_rr + calc_fast_wavespeed(u_rr, orientation, equations) | ||
|
||
return λ_min, λ_max | ||
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 wonder whether we really need 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.
Reason I added this is to have flux_hll
working out of the box also for MHD.
But in principle, I agree with you that the naive estimate has probably no real advantage over the Davis estimate.
# Calculate estimate for minimum and maximum wave speeds for HLL-type fluxes | ||
@inline function min_max_speed_naive(u_ll, u_rr, orientation::Integer, | ||
equations::LinearizedEulerEquations2D) | ||
min_max_speed_davis(u_ll, u_rr, orientation, equations) | ||
end | ||
|
||
@inline function min_max_speed_naive(u_ll, u_rr, normal_direction::AbstractVector, | ||
equations::LinearizedEulerEquations2D) | ||
min_max_speed_davis(u_ll, u_rr, normal_direction, equations) | ||
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.
That's what I would consider as default, too. Thus, I wonder whether we really need the current version of min_max_speed_naive
or whether we should basically deprecate it in favor of min_max_speed_davis
.
Co-authored-by: Hendrik Ranocha <[email protected]>
…rixi.jl into HLL_2_Wave_Improvements
I extraced the (hopefully) non-breaking part into #1561 and converted this to draft until we decide how we settle the naive vs davis debate. |
With the upcoming breaking release of v0.6 coming up, is this PR still considered to be merged? |
@sloede The main motivation is still there: The naming of wave-speeds is not consistent among equations, most notably for MHD things are different from SWE and CEE. |
OK. But is this PR in a shape that can be made ready to merge within the next, say, week? |
Probably its easier to start over from main branch, but this should be possible within the next week. |
OK. I'm not saying it has to be done though. But now would be the time for breaking changes 😄 |
Yes, that would be nice 👍 |
The new PR is #1708 |
This addresses #1525 by providing implementations for the standard 2-wave HLL solver for SWE, MHD, CEE as well as the improved 2-wave HLL solver by Einfeldt using Roe averages for SWE.
For completeness, the naive 2-wave HLL solver is added also for MHD.
The motivation for this pull request is
flux_hll
as one would expectFor illustration, the solution of the Sedov Blast wave is compared for the previously default
min_max_speed_naive
to the new defaultmin_max_speed
andflux_hllc
.min_max_speed_naive
min_max_speed
flux_hllc