Create a multi-EOS framework #526

jhp-lanl · 2025-07-23T03:34:55Z

PR Summary

This MR creates a new modifier called MultiEOS that can construct an EOS object that effectively combines multiple materials together via our PTE closure models. This is useful for reactive flows where a single material is described by two or more equations of state. Notably, the equation of state models must be known at compile time (e.g. Davis reactants and products) and cannot be dynamically selected.

~~There's still left to do with the class, but I've started with the basic structure and left placeholders for all the member functions I have yet to define.~~Most of them should be able to leverage the four member functions, GetStatesFromDensityEnergy(), GetStatesFromDensityTemperature(), GetStatesFromDensityPressure(), and GetStatesFromPressureTemperature(). The overall strategy is to store the EOS models in a tuple, use fold expressions where possible, and then convert the model tuple into an array that can be used with the PTE solver.

The new Type-based indexing for the lambda variable is required for this class in order to extract the mass fractions. However, I'm not quite sure how to handle individual EOS lambda parameters (e.g. LogDensity for spiner and maybe any of the 3T parameters) when there are multiple EOS. @Yurlungur any thoughts here would be helpful.

Also note that I inject a functor to average the bulk modulus. I do this because there are many ways to average the bulk modulus depending on what the desired behavior is. From a thermodynamic perspective, a harmonic average can be easily derived (which is why I use it), but this has drawbacks. For example, when a stiff material is combined with a soft material, the soft material will preferentially compress and dominate the bulk modulus even if the average density is more characteristic of the stiff material. In this case, the mixture sound speed is much smaller than the contributions of the individual materials. Instead, there are formula that can be derived from the PTE assumption and the eigenvalues of the Euler equations, and it may be better to use these. Either way, I wanted to expose this as a customization point, but default to a given choice.

I also add a ~~helper function~~ CTAD for constructing the MultiEOS object since the type will be ~~pretty gross~~ a bit complex to explicitly write out. I anticipate that we could just decltype the result when defining a Variant.

~~Note that this is very much a draft, but I'm putting it up for early review.~~

PR Checklist

Adds a test for any bugs fixed. Adds tests for new features.
Format your changes by using the make format command after configuring with cmake.
Document any new features, update documentation for changes made.
Make sure the copyright notice on any files you modified is up to date.
After creating a pull request, note it in the CHANGELOG.md file.
LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

Update the version in cmake.
Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
Ensure that any when='@main' dependencies are updated to the release version in the package.py

…y-eos into jhp/two_eos

…to jhp/two_eos

…p/two_eos

jhp-lanl · 2025-07-23T03:37:38Z

@Yurlungur I'd appreciate your high-level input when you get a chance. I won't be working on this next week, so there's no rush.

Yurlungur · 2025-07-23T13:57:58Z

Excited to see this @jhp-lanl ! Probably won't get to it today but looking forward to looking through it.

jhp-lanl · 2025-07-23T18:50:37Z

Tagging @chadmeyer since this is something I talked with him about a long time ago.

And always @mauneyc-LANL , your input on C++ design is always valued if you want to review some of this in your infinite spare time 😉

dholladay00 · 2025-08-20T21:56:34Z

Assuming we have a countable (and hopefully) small combination of 2eos things then it could be added to the variant, but note that all possible combinations of Eos's will need to be enumerated at compile time if you want to access this via the variant.

jhp-lanl · 2025-08-21T18:25:59Z

Assuming we have a countable (and hopefully) small combination of 2eos things then it could be added to the variant, but note that all possible combinations of Eos's will need to be enumerated at compile time if you want to access this via the variant.

Agreed. This is intended for explicitly identified EOS pairs (e.g. Davis Reactants + Davis Products). I did not intend to add more to our combinatorics in the Variant typelist ;-)

Remove static lib asan

jhp-lanl · 2025-10-09T23:36:25Z

Alright, to summarize the recent progress, I haven't been able to successfully debug the EOSPAC memory issue I'm running into. I'm going to comment out the test and add a comment to the code indicating that the feature is broken. I'll also create an issue and add that to the documentation.

I'm going to try to wrap this up here shortly.

jhp-lanl · 2025-10-10T17:18:35Z

@jonahm-LANL @Yurlungur I think this is ready for final review

Yurlungur

Some minor nitpicks below, but I consider them non-blocking. Nice work pulling this through, @jhp-lanl !

doc/sphinx/src/models.rst