pt derivatives from preferred

[Yurlungur]

PR Summary

This MR resolves #598 by adding @jhp-lanl 's suggested function PTDerivativesFromPreferred, which I think does make sense. To robustly test, and provide a sensible fallback for methods that don't implement the function, I also implement a finite differences approach.

This MR isn't finished (and we can't merge until our internal CI is back up anyway), but I believe it is ready for feedback. The major todos at this point are:

• Thread the derivatives calculation through EOSPAC
• Thread derivatives calculation through SpinerEOS. I might put this in a second, later MR because it requires changing sesame2spiner. There's a missing derivative table.
• Test more robustly.

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

[Yurlungur]

The main thing missing now is the spiner EOS and tests for the EOSPAC eos. The former I will add in a later PR. The latter I will add once the CI is working again.

[jhp-lanl]

I'll try to review this today or tomorrow

[Yurlungur]

I'll try to review this today or tomorrow

Thanks @jhp-lanl ! I'm also still debugging.

[jhp-lanl]

Minor comments. Looks good! I think this will be really useful for computing multimaterial mixture derivatives.

[jhp-lanl]

Suggested change

	dedP_T *= robust::ratio(press_unit_, temp_unit_);
	dedP_T *= robust::ratio(press_unit_, energy_unit_);

[jhp-lanl]

There are actually a few ways to skin this cat. Whichever you choose, I'd want a justification for why that's the method of choice. For example, I can think of two other ways that have significant advantages:

1. Compute $e(\rho, T)$ and $P(\rho, T)$ and use the resulting derivatives in thermodynamic identities to compute the desired P-T derivatives.
2. Ask EOSPAC for derivative quantities that are close to what you want. E.g. you could use the following (check my math):
   • EOS_BTt_DT gets you the isothermal bulk modulus that can be converted into drdP_T
   • EOS_ALPHAt_DT gets you the thermal expansion coefficient, which can be converted to drdT_P
   • Use EOS_CPt_DT and EOS_ALPHAt_DT with $(\partial e/ \partial T)_P = C_P - PV\alpha$
   • Use EOS_BTt_DT and EOS_ALPHAt_DT with $(\partial e/ \partial P)_T = TV\alpha - PV / B_T$

The first method is likely the fastest with only two lookups, but I would suspect that the second could be the most accurate, but will be at least twice as expensive (four lookups). Both are subject to the assumption of thermodynamic consistency of course. I would assume that the lookups in (2) are doing thermo identities under the hood, so it may actually not be more accurate if errors compound as EOSPAC does thermo identities and then you use those in a different relation to get different quantities. I'd lean towards the first method I present here, but I could be convinced that your method is superior (although it does involve a root find).

[jhp-lanl]

Suggested change

	or temperature fixed. Density, energy, pressure, and temperature, must
	all be passed into this function, to maximize the ability for the
	underlying EOS to perform this calculation performantly. The intended
	or temperature fixed. Each EOS model expects consistent density,
	energy, pressure and temperature values to be provided so that it
	can perform this calculation performantly. The intended

I think it's important to emphasize that all four must be valid even if you know that a certain EOS doesn't have two as preferred inputs.

[jhp-lanl]

My second approach for EOSPAC could actually be the preferred method for spiner. Either that or you can fall back on the Menikoff and Plohr relations that rely on the derivatives that spiner already tabulates.

[jhp-lanl]

Maybe in the future? In my head, I'd pair a vectorized version of this call with a vectorized PTE solver.

[jhp-lanl]

Nice!