Create minimum energy modifier

[jhp-lanl]

PR Summary

Creates a minimum energy modifier and unifies EOS behind a default behavior of returning the zero K isotherm as the minimum possible internal energy.

Some notes:

1. I duplicated @rbberger 's approach with the shifted EOS using scratch memory. Similar to populating a shift, I populate a minimum energy and then max that with the input energy to then pass to whatever function needs the internal energy.
2. I am assuming that all energies are valid when they are outputs rather than inputs. I feel this is reasonable since the EOS should be self-consistent enough to not return energies off the EOS surface. If there is an issue, it might point to badly bounded inputs (i.e. negative temperatures or densities).
3. Initially this is very rough and is guaranteed to not compile. I'll need to make tests and make sure that the Gruneisen EOS can properly call the base class version within its own version and that all the other classes can properly see both the vector and scalar overloads from the base class.

Fixes #318

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.

[jhp-lanl]

Wow it compiled first time!? The modifier isn't compiled yet, but the default minimum energy stuff should be compiling, which might mean what I wrote works?

I'd still like to make an explicit unit test something along the lines of asserting that the energy is the zero temperature energy.

[dholladay00]

Would this play nicely with the options that @annapiegra added for eospac @jhp-lanl ? It sounds similar though I don't recall the details.

I assume it matters which order an energy shift is applied so that will need to be taken into account when constructing the modifier list.

[jhp-lanl]

Would this play nicely with the options that @annapiegra added for eospac @jhp-lanl ? It sounds similar though I don't recall the details.

I assume it matters which order an energy shift is applied so that will need to be taken into account when constructing the modifier list.

This is the exact function that @annapiegra added, but when it was added it was basically disabled (would throw an error) for any EOS other than EOSPAC. This basically changes that so that every EOS will have some notion of minimum energy by default.

[Yurlungur]

Very clean how this came out. I wonder if we should make this more "monolithic" and just provide bounds on all independent variables.

[jhp-lanl]

Very clean how this came out. I wonder if we should make this more "monolithic" and just provide bounds on all independent variables.

I assume that would mean expanding this to enforce a minimum density and temperature as well? That seems pretty straight-foward and might be pretty easy to implement.

I don't know if I'd want to do anything with upper bounds though. I feel that an extrapolation approach might be a superior way to handle upper-bounds.

Speaking of extrapolation, I suppose that if a table has a non-zero lower temperature bound we might want to apply an extrapolation layer first that extends the minimum energy/temperature to 0 K first and then this would lie on top of it.

[Yurlungur]

Very clean how this came out. I wonder if we should make this more "monolithic" and just provide bounds on all independent variables.

I assume that would mean expanding this to enforce a minimum density and temperature as well? That seems pretty straight-foward and might be pretty easy to implement.

I think it might be nice to impose energy and temperature floors together, yeah. 👍

I don't know if I'd want to do anything with upper bounds though. I feel that an extrapolation approach might be a superior way to handle upper-bounds.

That's fair... but is that always going to be valid going forward? What about an EOS that is for, e.g., a single phase as @aematts is planning to use?

Speaking of extrapolation, I suppose that if a table has a non-zero lower temperature bound we might want to apply an extrapolation layer first that extends the minimum energy/temperature to 0 K first and then this would lie on top of it.

True! I actually think what you've implemented here is a nice template for that kind of thing.

[jhp-lanl]

That's fair... but is that always going to be valid going forward? What about an EOS that is for, e.g., a single phase as @aematts is planning to use?

That's a good point, but I think there's an important difference: I'm constraining the input to be on the EOS surface whereas I think @aematts is going to want to constrain the output such that it's clear when a phase EOS isn't valid.

From my limited understanding of kinetic phase transitions, you might want to set a domain of validity for a phase EOS and not constrain yourself to that domain, but instead maybe provide a flag to indicate that you're not in the range of validity anymore. For example, you could return an infinite Gibbs free energy (or equivalent) when you're outside the domain of validity (which is basically a constant extrapolation). That way the rate at which that phase is created can be set to identically zero.

Either way, I anticipate that we'll have to create additional modifiers to handle these use scenarios.

[Yurlungur]

That's fair... but is that always going to be valid going forward? What about an EOS that is for, e.g., a single phase as @aematts is planning to use?

That's a good point, but I think there's an important difference: I'm constraining the input to be on the EOS surface whereas I think @aematts is going to want to constrain the output such that it's clear when a phase EOS isn't valid.

From my limited understanding of kinetic phase transitions, you might want to set a domain of validity for a phase EOS and not constrain yourself to that domain, but instead maybe provide a flag to indicate that you're not in the range of validity anymore. For example, you could return an infinite Gibbs free energy (or equivalent) when you're outside the domain of validity (which is basically a constant extrapolation). That way the rate at which that phase is created can be set to identically zero.

Either way, I anticipate that we'll have to create additional modifiers to handle these use scenarios.

Yeah fair enough. I may be over-engineering here.

[jhp-lanl]

@Yurlungur I think this is ready for final review (sorry for the long delay)

[Yurlungur]

Non-blocking request. But overall looks good!

[Yurlungur]

There are now some more general macros that can replace these lines defined in eos_base.hpp

[jhp-lanl]

Yes! I'll change that

[jhp-lanl]

Oh and I still need to test this code. I'll try to do that here shortly.