Thermally perfect gas as an AbstractEquationOfState

[DanielDoehring]

For high temperature flows, $c_p$ and $\gamma$ should no longer be treated as constant. In turn, they can modeled as functions of only temperature ("thermally perfect") while preserving the ideal gas relation $p = R_\text{spec} \rho T$ which makes them very attractive.
The go-to data that relates $c_p$ to $T$ is given by the NASA piecewise 9-degree polynomials.

This is an experimental implementation that implements thermally perfect gases as an equation of state.
However, I would like to not restrict this to NonIdealCompressibleEulerEquations since the original CompressibleEulerEquations could readily be extended with a non-constant gamma = gamma(T) . In fact, we already have this behaviour for the viscosity:

Trixi.jl/src/equations/compressible_navier_stokes_2d.jl

Lines 189 to 194 in 7091f3b

	# In the simplest cases, the user passed in `mu` or `mu()`
	# (which returns just a constant) but
	# more complex functions like Sutherland's law are possible.
	# `dynamic_viscosity` is a helper function that handles both cases
	# by dispatching on the type of `equations.mu`.
	mu = dynamic_viscosity(u, equations)

Trixi.jl/src/equations/compressible_navier_stokes.jl

Lines 125 to 137 in 7091f3b

	"""
	dynamic_viscosity(u, equations)
	Wrapper for the dynamic viscosity that calls
	`dynamic_viscosity(u, equations.mu, equations)`, which dispatches on the type of
	`equations.mu`.
	For constant `equations.mu`, i.e., `equations.mu` is of `Real`-type it is returned directly.
	In all other cases, `equations.mu` is assumed to be a function with arguments
	`u` and `equations` and is called with these arguments.
	"""
	dynamic_viscosity(u, equations) = dynamic_viscosity(u, equations.mu, equations)
	dynamic_viscosity(u, mu::Real, equations) = mu
	dynamic_viscosity(u, mu::T, equations) where {T} = mu(u, equations)

I also added varnames for cons2thermo (this is probably something for a different PR) to be able to save the thermal variables to get e.g. plots of temperature conveniently:

Comparison to ideal gas:
One can see that the shock is slightly further away from the cylinder compared to the real gas case.

[github-actions]

Review checklist

This checklist is meant to assist creators of PRs (to let them know what reviewers will typically look for) and reviewers (to guide them in a structured review process). Items do not need to be checked explicitly for a PR to be eligible for merging.

Purpose and scope

• The PR has a single goal that is clear from the PR title and/or description.
• All code changes represent a single set of modifications that logically belong together.
• No more than 500 lines of code are changed or there is no obvious way to split the PR into multiple PRs.

Code quality

• The code can be understood easily.
• Newly introduced names for variables etc. are self-descriptive and consistent with existing naming conventions.
• There are no redundancies that can be removed by simple modularization/refactoring.
• There are no leftover debug statements or commented code sections.
• The code adheres to our conventions and style guide, and to the Julia guidelines.

Documentation

• New functions and types are documented with a docstring or top-level comment.
• Relevant publications are referenced in docstrings (see example for formatting).
• Inline comments are used to document longer or unusual code sections.
• Comments describe intent ("why?") and not just functionality ("what?").
• If the PR introduces a significant change or new feature, it is documented in NEWS.md with its PR number.

Testing

• The PR passes all tests.
• New or modified lines of code are covered by tests.
• New or modified tests run in less then 10 seconds.

Performance

• There are no type instabilities or memory allocations in performance-critical parts.
• If the PR intent is to improve performance, before/after time measurements are posted in the PR.

Verification

• The correctness of the code was verified using appropriate tests.
• If new equations/methods are added, a convergence test has been run and the results
  are posted in the PR.

Created with ❤️ by the Trixi.jl community.

[codecov]

Codecov Report

❌ Patch coverage is 99.23664% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 96.83%. Comparing base (64faca8) to head (3282514).

Files with missing lines	Patch %	Lines
...elixir_euler_therm_perf_cylinder_bowshock_mach6.jl	97.67%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3079      +/-   ##
==========================================
+ Coverage   96.82%   96.83%   +0.01%     
==========================================
  Files         659      662       +3     
  Lines       51050    51181     +131     
==========================================
+ Hits        49429    49559     +130     
- Misses       1621     1622       +1     

Flag	Coverage Δ
unittests	96.83% <99.24%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jlchan]

This is great to see, @DanielDoehring; I was hoping to add this myself eventually.

Agreed that standard CompressibleEulerEquations could be extended with gamma(T), but the associated routines (EC fluxes, etc) may still assume gamma is constant.

What about adding type parameters to NonIdealCompressibleEulerEquations which identify whether the pressure EOS is non-ideal? This could differentiate between CPG, TPG, and fully non-ideal EOS?

[DanielDoehring]

Agreed that standard CompressibleEulerEquations could be extended with gamma(T), but the associated routines (EC fluxes, etc) may still assume gamma is constant.

I noticed since there are flux_terashima_etal and flux_terashima_etal_central this might not be required since we can reuse a lot of machinery. 👍

What about adding type parameters to NonIdealCompressibleEulerEquations which identify whether the pressure EOS is non-ideal? This could differentiate between CPG, TPG, and fully non-ideal EOS?

We could think about that, does this change something in the implementation/allow for simplifications? I did not go through the entire equation of state and nonideal Euler equations, so maybe there are some spots where things could be more efficient for an ideal gas pressure/density/temperature relation.

[jlchan]

I think of thermally perfect as modifying the internal energy/temperature relationship, while a nonideal EOS modifies the pressure equation.

Specializing on thermally perfect this way might not make too much of a difference computationally, however.

[jlchan]

@DanielDoehring can you run the formatter? Otherwise I am ready to approve

[ranocha]

Thanks! Are the new implementations tested in https://github.com/trixi-framework/Trixi.jl/blob/main/test/test_type.jl?

[ranocha]

Does this work with Float32?

[jlchan]

The other non-ideal EOS have the same issue https://github.com/trixi-framework/Trixi.jl/blob/main/src/equations/equation_of_state_peng_robinson.jl#L102-L103. May be good to open an issue to tackle them all at once?

[DanielDoehring]

I needed to convert tol to the real type at hand to make the code statically inferrable

[jlchan]

Would it make sense to set the return type of eos_newton_tol from a field of eos::ThermallyPerfectGas9PolyFit?

[ranocha]

That would be reasonable. However, we can also open an issue for now since this will likely require some more tests and fine tuning.

[DanielDoehring]

Yeah, that seems less invasive for now.

[DanielDoehring]

Thanks! Are the new implementations tested in https://github.com/trixi-framework/Trixi.jl/blob/main/test/test_type.jl?

I added tests for this as well

[ranocha]

Test failures look real, e.g., https://github.com/trixi-framework/Trixi.jl/actions/runs/28684530026/job/85074668076?pr=3079#step:7:13562

[DanielDoehring]

Test failures look real, e.g., https://github.com/trixi-framework/Trixi.jl/actions/runs/28684530026/job/85074668076?pr=3079#step:7:13562

Thanks for pointing this out, they are now fixed (I only made the tol for the new EoS datatype-dependent).

[ranocha]

Thanks a lot!