Skip to content
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

Add HLL numerical flux #648

Merged
merged 50 commits into from
May 13, 2022
Merged

Add HLL numerical flux #648

merged 50 commits into from
May 13, 2022

Conversation

MTCam
Copy link
Member

@MTCam MTCam commented Apr 27, 2022

This change set:

  • adds Harten-Lax-van Leer (HLL) numerical flux routines implemented by @anderson2981,
  • and adds/refactors numerical flux interfaces supporting user-specified numerical flux routines
    • euler.py, inviscid.py, flux.py, viscous.py, boundary.py
  • adds a suite of tests and extends some existing tests for the new fluxes
    • test_bc.py, test_inviscid.py, test_flux.py
  • adds Toro reference on approximate Riemann solvers and sharpens the documentation on BCs and numerical fluxes
    • misc.rst, discretization.rst

majosm review checklist:

  • Is the scope and purpose of the PR clear?
    • The PR should have a description.
    • The PR should have a guide if needed (e.g., an ordering).
  • Is every top-level method and class documented? Are things that should be documented actually so?
  • Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
  • Does the implementation do what the docstring claims?
  • Is everything that is implemented covered by tests?
  • Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

anderson2981 review checklist:

  • Is the scope and purpose of the PR clear?
    • The PR should have a description.
    • The PR should have a guide if needed (e.g., an ordering).
  • Is every top-level method and class documented? Are things that should be documented actually so?
  • Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
  • Does the implementation do what the docstring claims?
  • Is everything that is implemented covered by tests?
  • Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

@MTCam MTCam changed the base branch from ns-update to main April 27, 2022 15:48
@MTCam MTCam mentioned this pull request Apr 27, 2022
8 tasks
@MTCam MTCam changed the title Stab wildly at extricating HLL out of NS. Add HLL numerical flux Apr 27, 2022
@MTCam MTCam marked this pull request as ready for review April 27, 2022 21:15
@MTCam MTCam added enhancement New feature or request Production Feeder Feeds the production branch labels Apr 28, 2022
Copy link
Collaborator

@majosm majosm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made a couple of passes, mostly looking at code clarity and documentation. Hopefully @anderson2981 can look more closely at the math.

mirgecom/flux.py Outdated
Comment on lines 60 to 70
f_minus_normal
Normal component of physical flux interior to (left of) interface

f_plus_normal
Normal component of physical flux exterior to (right of) interface

q_minus
Physical state on interior of interface

q_plus
Physical state on exterior of interface
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use TracePairs instead of separate minus/plus arguments?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well we wanted this interface to be numerical quantities only with no grudgy data structures down here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come? I don't see allowing TracePair as being too egregious... and then you get to use tpair.avg, tpair.diff, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the time they were written, it allowed just sending numbers or numpy arrays to the low-level flux routines in such a way that we could just copy tests right out of the book. The extra baggage of needing TracePairs data structure to call and test the numerical flux function.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, OK. I guess that's fair.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unresolving to say: Add a comment justifying the choice to supply different variables.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a stab. How's it looking now?

mirgecom/flux.py Outdated Show resolved Hide resolved
mirgecom/inviscid.py Outdated Show resolved Hide resolved
mirgecom/inviscid.py Outdated Show resolved Hide resolved
mirgecom/inviscid.py Outdated Show resolved Hide resolved
mirgecom/viscous.py Outdated Show resolved Hide resolved
mirgecom/viscous.py Outdated Show resolved Hide resolved
mirgecom/flux.py Outdated Show resolved Hide resolved
mirgecom/inviscid.py Show resolved Hide resolved
mirgecom/inviscid.py Outdated Show resolved Hide resolved

# choose the correct f contribution based on the wave speeds
f_check_minus = \
actx.np.greater_equal(s_minus, 0*s_minus)*(0*f_minus_normal + 1.0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actx.zeros_like(s_minus) or so?

Disclaimer: Doesn't totally work yet: inducer/arraycontext#161

mirgecom/inviscid.py Outdated Show resolved Hide resolved
$\b{h}^*_e$ is equal to the (interior; - side) pressure contribution of
$\b{F}^I(\b{Q}_{bc})\cdot\b{n}$
(since $\b{V}\cdot\b{n} = 0$).
Adiabtic slip wall
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Read to here


.. image:: figures/ElementBoundary.png
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Track down the source file?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Track down the source file?

I have it, if it is useful. PPTX

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mirgecom/viscous.py Outdated Show resolved Hide resolved
discr, gas_model, boundaries, interior_state_pairs,
domain_boundary_states, grad_cv, interior_grad_cv_pairs,
grad_t, interior_grad_t_pairs, quadrature_tag=None,
numerical_flux_func=viscous_divergence_flux, time=0.0):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
numerical_flux_func=viscous_divergence_flux, time=0.0):
numerical_flux_func=viscous_divergence_flux):

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't figure out how to pass time down through the operator to the boundary without this argument.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can make it a little more obvious that this is just a passthrough to the BCs (e.g. by passing something like a boundary_kwargs argument instead of passing time etc. explicitly), but I suspect this is best saved for another PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we stash time somewhere in the fluid state? That'd be great? 🤔

def viscous_flux_on_element_boundary(
discr, gas_model, boundaries, interior_state_pairs,
domain_boundary_states, grad_cv, interior_grad_cv_pairs,
grad_t, interior_grad_t_pairs, quadrature_tag=None,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
grad_t, interior_grad_t_pairs, quadrature_tag=None,
grad_t, interior_grad_t_pairs, discretization_tag=None,

(here and elsewhere)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bump to issue? Document to be a discretization tag?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made an issue, but eager to tackle it here if we can.

Copy link
Collaborator

@majosm majosm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made another pass through and found some stuff (mostly doc fixes).

doc/discretization.rst Outdated Show resolved Hide resolved
doc/discretization.rst Outdated Show resolved Hide resolved
doc/discretization.rst Show resolved Hide resolved
doc/discretization.rst Outdated Show resolved Hide resolved
doc/discretization.rst Outdated Show resolved Hide resolved
mirgecom/flux.py Outdated Show resolved Hide resolved
mirgecom/flux.py Outdated Show resolved Hide resolved
mirgecom/viscous.py Outdated Show resolved Hide resolved
mirgecom/viscous.py Outdated Show resolved Hide resolved
mirgecom/viscous.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@majosm majosm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Github made me split this into 3 suggestions, ugh sorry.

doc/discretization.rst Outdated Show resolved Hide resolved
doc/discretization.rst Outdated Show resolved Hide resolved
doc/discretization.rst Outdated Show resolved Hide resolved
Co-authored-by: Matt Smith <[email protected]>
Copy link
Collaborator

@majosm majosm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just had another pass through; looks good on my end. Left a couple of optional thoughts.


.. image:: figures/ElementBoundary.png
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text renders a little blurry when scaled down to fit in the doc page. Maybe see how it looks without the shadows?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, we intend to replace this outright with tikz.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +179 to +218
# calculate left/right wavespeeds
actx = state_pair.int.array_context
ones = 0.*state_pair.int.mass_density + 1.

# note for me, treat the interior state as left and the exterior state as right
# pressure estimate
p_int = state_pair.int.pressure
p_ext = state_pair.ext.pressure
u_int = np.dot(state_pair.int.velocity, normal)
u_ext = np.dot(state_pair.ext.velocity, normal)
rho_int = state_pair.int.mass_density
rho_ext = state_pair.ext.mass_density
c_int = state_pair.int.speed_of_sound
c_ext = state_pair.ext.speed_of_sound

p_star = (0.5*(p_int + p_ext) + (1./8.)*(u_int - u_ext)
* (rho_int + rho_ext) * (c_int + c_ext))

gamma_int = gas_model.eos.gamma(state_pair.int.cv, state_pair.int.temperature)
gamma_ext = gas_model.eos.gamma(state_pair.ext.cv, state_pair.ext.temperature)

q_int = 1 + (gamma_int + 1)/(2*gamma_int)*(p_star/p_int - 1)
q_ext = 1 + (gamma_ext + 1)/(2*gamma_ext)*(p_star/p_ext - 1)

pres_check_int = actx.np.greater(p_star, p_int)
pres_check_ext = actx.np.greater(p_star, p_ext)

q_int_rt = actx.np.sqrt(actx.np.where(pres_check_int, q_int, ones))
q_ext_rt = actx.np.sqrt(actx.np.where(pres_check_ext, q_ext, ones))

# left (internal), and right (external) wave speed estimates
# can alternatively use the roe estimated states to find the wave speeds
s_minus = u_int - c_int*q_int_rt
s_plus = u_ext + c_ext*q_ext_rt

f_minus_normal = inviscid_flux(state_pair.int)@normal
f_plus_normal = inviscid_flux(state_pair.ext)@normal

q_minus = state_pair.int.cv
q_plus = state_pair.ext.cv
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be documenting anything here about how the wave speeds are computed? Or should that be obvious to someone with domain knowledge?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These Riemann-solver-based flux routines are well known and documented in detail by Toro, which is linked in the documentation. That said, I don't think it would hurt the pepper in some comments in the implementations where there might be subtle points about our implementation. @anderson2981 wrote this routine - so I suspect he already has comments where he thought he needed them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those expressions follow almost verbatim from Toro. I'm not sure we need extra comments here.

@MTCam
Copy link
Member Author

MTCam commented May 12, 2022

Anything preventing merge here from your perspective, @inducer?

Copy link
Contributor

@anderson2981 anderson2981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This passes all the tests I setup initially to verify its implementation from a physics perspective. I don't see any changes that would impeded its proper operation. And the tests are still passing.

@MTCam MTCam merged commit 52a6e26 into main May 13, 2022
@MTCam MTCam deleted the add-hll-flux branch May 13, 2022 16:41
@MTCam
Copy link
Member Author

MTCam commented May 24, 2022

Resolved part of #509

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Production Feeder Feeds the production branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants