Add a SpinerEosDependsRhoSie constructor that uses an existing eos object to generate a spiner eos

[buechlerm]

PR Summary

Much of this was generated by AI. I had asked it to emulate sesame2spiner in terms of parameters for grid generation. Seems somewhat heavyweight, but there are defaults. Ultimately, if somebody proposes a different way of parameterizing the grids, I'd accept that.

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 ML was used, make sure to add a disclaimer at the top of a file indicating ML was used to assist in generating the file.
• If Agentic AI was used, have the AI generate a "proposed changes" markdown file and store it in the plan_histories folder, with a filename the same as the MR number.

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.
• Maintainers: ensure spackages are up to date:
  • LANL-internal team, update XCAP spackages
  • Current maintainer of upstream spackages, submit MR to spack

[buechlerm]

We can check that the eos provides an isentropic bulk modulus. Probably should use that. If it provides Ks, gamma and Cv should we derive the derivatives from those? Probably.

[jhp-lanl]

modulo thermodynamic consistency...

[buechlerm]

Are you suggesting that you prefer finite difference for derivatives and then evaluation of the properties from those? The real question I am thinking about right now, is what is the minimum we expect in the source_eos. I'm inclined to allow (for the dependsRhoSIE case) the source_eos to provide as little as PofRE and TofRE to fill in the tables, taking advantage of ks, gruneisen, and cv it it also has those methods.

[jhp-lanl]

Honestly, I'm not sure. The advantage of finite differences is that they are guaranteed to be robust to thermodynamic consistency issues. The disadvantage is that they are never that accurate.

The worst possible scenario is using finite differences and then trying to use them in thermodynamic derivatives to compute something else. I ran into this in #526 where I didn't have a good mechanism to get P-T derivatives (hence #598). The finite differences there when combined into quantities we want (like a sound speed) could result in pretty large errors.

Some of the formulas from Menikoff and Plohr using these quantities are pretty complex. I'm not sure anybody has looked at the effects of thermodynamic inconsistencies on the accuracy of quantities computed from these quantities. I'd naively think that $\Gamma$ could be the most susceptible since it relates the pressure and energy tables; I think that can be a source of inconsistency in older tables where a change was made to one without propagating the change to the other.

If I had to pick, I think I'd agree with you on using $C_V$, $\Gamma$, and $B_S$ to compute everything else. But I think it's always worth remembering that those formulas are predicated on thermodynamic consistency, and using them without that consistency could lead to strange results.

[buechlerm]

Ok, this is effectively feature complete. I've made choices on what is the prefered path from an incomplete eos to the tables, but I'm not dead set on them, so if somebody has a very strong preference, I can change it. @adamdempsey90 was also working on some sesame2spiner changes and if he wants a different way of defining the table grids, I'm open to that as well. Finally, I said feature complete, but a future feature that is probably required is writing an sp5 file (for restarts at minimum). I'm putting that off till later.

[buechlerm]

There are actually a few more features we would want (I just don't need them for my Ristra work). Here, I punted on split-eos and mass fractions. We definitely want to optionally support those as well. Again, punting on those, till later, unless somebody sees something atrocious about this MR that'll make adding those features difficult, later.