Skip to content

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

Open
buechlerm wants to merge 4 commits intomainfrom
buechler/spiner_constructor
Open

Add a SpinerEosDependsRhoSie constructor that uses an existing eos object to generate a spiner eos#632
buechlerm wants to merge 4 commits intomainfrom
buechler/spiner_constructor

Conversation

@buechlerm
Copy link
Copy Markdown
Collaborator

PR Summary

This is currently very DRAFy. Almost completely generated by AI and I haven't fully reviewed the work myself, so if you don't have time to look at it right now, that's fine.

I had asked it to emulate sesame2spiner in terms of parameters for grid generation. Seems somewhat heavyweight, but there are defaults.

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 buechlerm self-assigned this Apr 9, 2026
dependsRhoSie_.P(j, i) = P;

// Bulk modulus will be computed by calcBMod_() after derivatives are populated
dependsRhoSie_.bMod(j, i) = robust::EPS();
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

modulo thermodynamic consistency...

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@jhp-lanl jhp-lanl Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 buechlerm force-pushed the buechler/spiner_constructor branch from 608002d to 522f37e Compare April 13, 2026 14:12
@buechlerm buechlerm force-pushed the buechler/spiner_constructor branch from 522f37e to cc4ee8f Compare April 13, 2026 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants