-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify behavior of DensityEnergyFromPressureTemperature #199
Comments
@Yurlungur from the mattermost chat, we have also brought up that this function is mainly useful for initialization from a pressure-temperature state where the desired density is the solid density. I still support deleting the EOS-specific versions and maybe instead using the same strategy we use for the PTE solvers where we try to find ambient density based off of the density at the pressure minimum. This could be a generic behavior that could live in the CRTP base class. We may not get as nice of values for analytic EOS, but I think it would still be acceptable for initialization. |
Ah good point. I like the CRTP idea. |
In #233 we discussed the fact that different EOS have different behaviors for this function. For example, the Davis EOS use the ambient density as an initial guess in the root find while JWL allows specification of an initial guess through the density and spiner allows the initial guess through the lambda parameter. For analytic EOS, this behavior can probably be unified in the base class. It may also be worthwhile to provide this functionality for EOSPAC as well since the EOSPAC P-T lookup can sometimes produce strange values for some EOS and may benefit from an external root find in rho-T space. |
I return to the thought that maybe we should delete this function---perhaps the preferred path here is to use the PTE machinery... or to provide external root-finding capability specifically for this that has a clearer API. |
The PTE machinery is not built for this; the PTE machinery recieves a density and energy and returns a pressure and temperature. I will argue that it is imperative that we provide some functionality that produces the energy and density at a given pressure and temperature. I'd like to hear your ideas on why it shouldn't live in the EOS itself though. From my perspective it seems natural to have this in the EOS, but we need to decide on the appropriate procedure for providing a guess or ensuring predictable behavior though. |
This function is unused and just for convenience. It also may hinder future development for multiphase and we should remove it.
The text was updated successfully, but these errors were encountered: