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.

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.

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.

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.

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.

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.

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.