Skip to content

Adding Clima Thermodynamics#112

Open
olivierbonte wants to merge 18 commits intomainfrom
ob/feature_clima_thermodyn
Open

Adding Clima Thermodynamics#112
olivierbonte wants to merge 18 commits intomainfrom
ob/feature_clima_thermodyn

Conversation

@olivierbonte
Copy link
Copy Markdown
Collaborator

As previously mentioned in #108, I thought Thermodynamics.jl could be a nice way to avoid reimplementation of a lot of the thermodynamics. This PR is an attempt at replacing some utilities by functions from Thermodynamics.jl.

To avoid the use of ClimaParams.jl, PhysicalConstants is defined as a subtype of AbstractThermodynamicsParameters. This approach is inspired by the use of Thermodynamics.jl in NumericalEarth.jl for the atmospheric thermodynamics (see here).

This PR also introduces specific heat capacity and air density as functions, not constants, consistent with the use in Thermodynamics.jl

olivierbonte and others added 18 commits April 28, 2026 11:36
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
@olivierbonte olivierbonte requested a review from bgroenks96 April 30, 2026 15:04
@olivierbonte
Copy link
Copy Markdown
Collaborator Author

I now also see that there is an issue on the use of abbreviations in physical constants #111. Is this something to fix in this PR or not @bgroenks96 ?

@bgroenks96
Copy link
Copy Markdown
Collaborator

Hey @olivierbonte, I think this PR would be a good opportunity to resolve #111!

I had also considered splitting up PhysicalConstants into separate types for thermodynamic vs material and hydraulic constants. What do you think about this?

@olivierbonte
Copy link
Copy Markdown
Collaborator Author

Alright! I'll try to address this soon

I agree that splitting up the constants in categories makes sense, otherwise this one struct will get very large I think. Given the current set of properties, thermodynamic vs material makes sense to me. Any preferences for the naming of these structs?

Copy link
Copy Markdown
Collaborator

@bgroenks96 bgroenks96 left a comment

Choose a reason for hiding this comment

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

Looks really great! Thanks a lot!

@inline cp_v(c::PhysicalConstants) = c.cp_v
@inline LH_v0(c::PhysicalConstants) = c.Llg
@inline LH_s0(c::PhysicalConstants) = c.Lsg
@inline T_0(c::PhysicalConstants) = c.T_ref
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.

Why is this T_0 and not T_ref? I guess you can also address this when updating the names to be fully spelled out.

@inline saturation_vapor_pressure(T, a₁, a₂, a₃) = a₁ * exp(a₂ * T / (T + a₃))
@inline function saturation_vapor_pressure(c::PhysicalConstants, T::NF) where {NF}
T_K = celsius_to_kelvin(c, T)
return if T <= zero(T)
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.

I know this also isn't what the old code did, but maybe we should use ifelse here just to be safe (for Enzyme/GPU)?

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