Inconsistency in dependency rule? #4

Activity

1. haakon-e commented on May 28, 2026

   

   haakon-e

   on May 28, 2026

   Member

   More actions

   Pete, I wrote the initial draft for this. Having discussed aspects of this with @imreddyTeja in-person, and now seeing your question here, I see the text may come across as a bit too prescriptive, when it was mostly intended to be informative. Of course, there are technical reasons some packages cannot depend on some other (e.g. circular dependencies), but that's not your question.

   Conceptually, I view discretization (time and space, i.e. CC.jl) as separated from physics. In reality of course, we carefully implement the parameterizations to be stable with the given discretization¹, and may do so within the physics libraries.

   I think your question shows

   1. some clear limitations with the single-parent graph structure
   2. that while CC.jl is "L1", Oceananigans (which arguably serves a similar purpose to CC.jl) is "L2"
   3. that the dependency graph may be a greater source of confusion than help

   I could see a few options to make this section more useful to folks:

   1. Remove it entirely and summarize our zoo of packages in some other way
   2. Reword the rule on permitted dependencies between the layers to clarify "desired" behavior (in general, physics should not depend on discretization details)
   3. make a multiple-parent graph (Teja has a visualization of the dependencies among individual packages in slack, I think that could become useful as a summary tool if we group together multiple packages before drawing arrows)

   Footnotes

   1. I could link many PRs here, but some recent ones that come to mind include moisture fixers, linearized averaged microphysics tendencies ↩
2. imreddyTeja commented on May 28, 2026

   

   imreddyTeja

   on May 28, 2026

   Member

   More actions

   This is a good point... perhaps this is more confusing than helpful.

   I think physics libraries should not (and currently do not) depend on ClimaCore. I'll think about this some more, but feel free to modify or delete the table
3. petebachant commented on May 29, 2026

   

   petebachant

   on May 29, 2026

   MemberAuthor

   More actions

   I don't think this is some urgent problem to solve; it's definitely helpful to kickstart understanding of the architecture. It could be as simple as adding the word "typically" or noting the special case.

   make a multiple-parent graph (Teja has a visualization of the dependencies among individual packages in slack, I think that could become useful as a summary tool if we group together multiple packages before drawing arrows)

   That sounds pretty great. And TIL you can put footnotes in GitHub comments 😎