Create minimum energy modifier #375

jhp-lanl · 2024-05-11T02:35:18Z

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:

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

…orks)

jhp-lanl · 2024-05-11T02:45:07Z

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.

…ergyBound

dholladay00 · 2024-05-14T16:35:28Z

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 · 2024-05-14T16:40:54Z

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 · 2024-05-14T00:38:25Z

singularity-eos/eos/eos_base.hpp

+  // Default MinInternalEnergyFromDensity behavior is to just return the zero-K isotherm.
+  // This should be fine for all thermodynamically consistent EOS, but could cause issues
+  // with EOS that aren't thermodynamically consistent.


I think as far as default behavior this is just fine.

Yurlungur · 2024-05-14T22:21:15Z

singularity-eos/eos/modifiers/minimum_energy.hpp

+  template <typename Indexer_t = Real *>
+  PORTABLE_FUNCTION Real InternalEnergyFromDensityTemperature(
+      const Real rho, const Real temperature, Indexer_t &&lambda = nullptr) const {
+    return t_.InternalEnergyFromDensityTemperature(rho, temperature, lambda);
+  }


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.

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.

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 · 2024-05-14T23:40:26Z

singularity-eos/eos/modifiers/minimum_energy.hpp

+using namespace eos_base;
+
+template <typename T>
+class MinimumEnergy : public EosBase<MinimumEnergy<T>> {


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

Maybe FlooredEnergy or something?

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

jhp-lanl · 2024-05-14T23:56:44Z

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 · 2024-05-15T01:36:34Z

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 · 2024-05-15T02:22:46Z

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 · 2024-05-15T02:58:57Z

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 added 5 commits May 10, 2024 20:07

Create default MinInternalEnergyFromDensity behavior

355cf71

Add minimum energy modifier

2eda134

Add minimum energy modifier

1c29d51

Rely on default minimum energy functionality in base class (if this w…

c6ed8dc

…orks)

Clang format

4da0d99

jhp-lanl marked this pull request as draft May 11, 2024 02:35

jhp-lanl changed the title ~~WIP: Create minimum energy modifier~~ Create minimum energy modifier May 11, 2024

jhp-lanl requested review from Yurlungur and dholladay00 May 11, 2024 02:57

Merge branch 'main' of github.com:lanl/singularity-eos into jhp/MinEn…

21510e6

…ergyBound

Yurlungur reviewed May 14, 2024

View reviewed changes

jhp-lanl commented May 14, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create minimum energy modifier #375

Create minimum energy modifier #375

jhp-lanl commented May 11, 2024

jhp-lanl commented May 11, 2024

dholladay00 commented May 14, 2024

jhp-lanl commented May 14, 2024

Yurlungur left a comment

Yurlungur May 14, 2024

Yurlungur May 14, 2024

jhp-lanl May 14, 2024

Yurlungur May 15, 2024

jhp-lanl May 14, 2024

Yurlungur May 15, 2024

jhp-lanl May 15, 2024

jhp-lanl commented May 14, 2024

Yurlungur commented May 15, 2024

jhp-lanl commented May 15, 2024

Yurlungur commented May 15, 2024

Create minimum energy modifier #375

Are you sure you want to change the base?

Create minimum energy modifier #375

Conversation

jhp-lanl commented May 11, 2024

PR Summary

PR Checklist

jhp-lanl commented May 11, 2024

dholladay00 commented May 14, 2024

jhp-lanl commented May 14, 2024

Yurlungur left a comment

Choose a reason for hiding this comment

Yurlungur May 14, 2024

Choose a reason for hiding this comment

Yurlungur May 14, 2024

Choose a reason for hiding this comment

jhp-lanl May 14, 2024

Choose a reason for hiding this comment

Yurlungur May 15, 2024

Choose a reason for hiding this comment

jhp-lanl May 14, 2024

Choose a reason for hiding this comment

Yurlungur May 15, 2024

Choose a reason for hiding this comment

jhp-lanl May 15, 2024

Choose a reason for hiding this comment

jhp-lanl commented May 14, 2024

Yurlungur commented May 15, 2024

jhp-lanl commented May 15, 2024

Yurlungur commented May 15, 2024