ClimFlows is an ongoing effort to develop an ecosystem of composable and extensible packages:

• from which one can compose a variety of climate-relevant numerical models, especially for oceanic and atmospheric circulation, from toy models to realistic solvers
• from which one can cherry-pick specific functionality without having to install the whole ClimFlows ecosystem
• which works on laptops as well as HPC clusters
• whose performance is competitive on CPUs and GPUs, enabling meaningful comparisons
• whose composability builds upon state-of-the-art understanding of the mathematical and physical structure of geophysical models

Building an ecosystem means that thought and effort is put not only in the contents of each package, but also in the way they interact via their respective interfaces (APIs). We expect that arriving at the 'right' APIs will be a trial-and-error process.

See our Gallery which is sampled from ClimFlowsExamples.

See all pull requests, issues and code coverage.

Since each independent package deliberately focuses on a limited task, the progress of the ecosystem towards usefulness is demonstrated by achieving milestones where existing packages are composed into a 'useful product'. Achieved milestones are:

• a hydrostatic, global atmospheric solver with arbitrary thermodynamics and competitive performance on CPU and GPU

Our next milestones are:

• a differentiable dry, hydrostatic, global atmospheric solver. Possibly based on spherical harmonics.
• a dry atmospheric general circulation solver with arbitrary thermodynamics and simplistic but physically-consistent models (parameterizations) for radiation, turbulence and convection.
• an implicit-LES Boussinesq/anelastic solver in logically-Cartesian domains

For the time being ClimFlows is mostly Julia-based. Choosing a single computing language makes development easier, but it fractions the already small community of climate-relevant model developers. Ultimately, we would like to find ways to make ClimFlows a polyglot project, with a focus firstly on robust language-agnostic APIs based on sound concepts and abstractions, and secondly on implementations in different languages with different limitations.

We consider implementing the most promising APIs in (modern) Fortran when sensible. Contributors comfortable with other languages, especially C++, PyTorch and JAX, are welcome.

• Physics: ClimFlowsTestCases, ClimFluids, CFPlanets, CFShallowWaters, CFHydrostatics
• Maths: CFTimeSchemes, SHTnsSpheres, CFDomains, CFTransport, CFMultiGrid
• Performance: ManagedLoops, LoopManagers, SIMDMathFunctions
• Convenience: MutatingOrNot, MemberFunctions, CookBooks
• Other: ClimFlowsPlots, ClimFlowsData

ClimFlows Julia packages that are not sufficiently general-purpose and mature to be registered in the General Julia registry are registered in JuliaRegistry.

The call graph of a typical main program, here VoronoiHPE.jl from ClimFlowsExamples, looks like:

graph TD;
    VoronoiHPE-->CFDomains*;
    CFDomains*-->ClimFlowsData;
    ClimFlowsData-->NetCDF;
    CFHydrostatics*-->CFPlanets;
    CFHydrostatics*-->CFTestCases;
    VoronoiHPE-->CFTransport;
    CFTransport --> ManagedLoops;
    VoronoiHPE-->CFTimeSchemes;
    VoronoiHPE-->CFHydrostatics*;
    CFTimeSchemes-->CFHydrostatics;
    CFHydrostatics-->ManagedLoops;
    CFHydrostatics-->CFDomains;
    CFHydrostatics-->ClimFluids;
    ManagedLoops-->LoopManagers;
    LoopManagers-->KernelAbstractions;
    KernelAbstractions-->CUDA;

where a star indicates a call made when initializing the model.

However a deep call graph does not necessarily imply a deep dependency graph among packages. The key to a shallow ecosystem dependency graph is dependency inversion, whereby a package implements a function whose interface (API) is defined in another package. In this example, CFHydrostatics implements functions whose API is defined in CFTimeSchemes. These functions are called by CFTimeSchemes during time integration. Similarly LoopManagers implements functions whose API is defined in ManagedLoops. To do so, it uses KernelAbstractions and CUDA, a relatively big package from the wider Julia ecosystem. Performance-critical routines from CFHydrostatics are passed to ManagedLoops, LoopManagers, KernelAbstractions and ultimately to CUDA to be executed on a GPU. Similarly the function NetCDF.ncread is passed by the main program to ClimFlowsData then CFDomains, which does not have to depend on NetCDF to read the mesh description from disk.

As a result, the dependency graph of ClimFlows packages so far is essentially:

graph TD;
    LoopManagers==>ManagedLoops;
    CFDomains --> SHTnsSpheres
    CFHydrostatics-->ManagedLoops;
    CFTransport --> ManagedLoops;
    CFMultiGrid --> ManagedLoops;
    CFHydrostatics-->ClimFluids;
    CFHydrostatics-->CFPlanets;
    CFHydrostatics-->CFDomains;
    CFHydrostatics==>CFTimeSchemes;
    CFShallowWaters-->CFDomains;
    CFShallowWaters==>CFTimeSchemes;

Independent packages are omitted, as wel as tiny packages such as MutatingOrNot. Plain arrows represent a call from one package to another, while bold arrows represent a reverse dependency. These arrows make it possible to buy into only a fraction of ClimFlows. For instance it would be entirely possible to use a package from the Julia ecosystem to perform time integration, instead of using CFTimeSchemes. In line with the open-closed principle, new packages can extend existing packages by implementing their API, without modifying the original package or deepening the dependency graph.

While Julia is designed for composability, many other languages, including some considered as legacy, support dependency inversion. For instance, in Fortran 2003, dependency inversion can be achieved by means of procedures (with a fully typed interface) passed as arguments and/or abstract types with deferred bindings.