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.

[Yurlungur]

We may wish to compute t of emin or something for rho e based EOS's. Not sure that's worth thinking about here though.

[jhp-lanl]

Are you talking about maxing the input temperature before outputting the energy?

I think more generally though if the energy output here violates the minimum given by the MinInternalEnergyFromDensity() function, then it's a reflection of an unphysical EOS (i.e. a negative heat capacity). As a result, I'm not sure we want to guard against this.

That said, it's certainly possible to have a negative heat capacity in some fringe cases, but I'm not sure if this is the appropriate way to guard against this. But then again, maybe it's better to guarantee that the output is always bounded by the minimum.

[Yurlungur]

Are you talking about maxing the input temperature before outputting the energy?

That was what I was thinking but actually it probably makes more sense to max it after. Either way it may not be worth worrying about here.

[jhp-lanl]

I'm open to renaming this if someone has a more descriptive name

[Yurlungur]

Maybe FlooredEnergy or something?

[jhp-lanl]

I like that better. I'll change it when I get back

[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.