[IMPORTANT] Possible repository name change

[simone-silvestri]

Hello ClimaOcean community!

The package is growing, and with its growth, its scope is also amplifying.
The initial ClimaOcean prototype was little more than a wrapper over Oceananigans to simplify setting up realistic ocean configurations. However, during these years of development, we realized that ClimaOcean can be much more than just a home for realistic ocean setups; it can also serve as a powerful Julia framework for coupling different components and models.

As it stands right now, this repository holds data wrangling, but also interface parameterizations between different components (surface fluxes) and a powerful abstraction (currently named OceanSeaIceModel), which is the prototype for a complete Earth system model including all prognostic components.

The vision for this "coupled model" is to be able to swap in and out new atmosphere / ocean / sea ice models within a flexible and easy-to-use framework, but also the ability to run individual prognostic model components (not just the ocean!) coupled with prescribed data. Examples are the current coupling of an Oceananigans simulation with SpeedyWeather (#463), the possibility to couple an atmosphere with a Python model (#602), and plans to couple with the non-hydrostatic atmospheric model Breeze.jl, in addition to the original (still planned) scope of coupling to ClimaAtmos.jl. Therefore, the long-term plan is to remove the current centrality of the ocean model.

For this reason, the name ClimaOcean may no longer accurately represent or describe the scope of the repository anymore. We already had discussions about name changes with @glwagner and @navidcy, so I think it is the right time to officially open this issue to gauge the developers' interest in maintaining the current name or transitioning to something else.

After some brainstorming, we came up with some names that could better capture the scope and the plans for the future of this package. The idea is that the name needs to communicate that the package is "all things earth system modeling". Some proposals include

• NumTerra.jl (numerical earth modeling)
• EarthLike.jl
• Planetology.jl
• Ryujin.jl (japanese god for tides and weather)

Note that if we change the name, the package will need to be registered anew.
Interested to know what you are all thinking and, if you agree with a name change, what name you would propose (I am not sure if I should tag all the contributors here)

[glwagner]

I think this is a good idea @simone-silvestri ! The name "ClimaOcean" has confused many and is overly ocean-centric for the current future scope of this package.

I think you said everything well, but I just wanted to add that the EarthSystemModel (which I think we should rename OceanSeaIceModel to) resembles "couplers" in other software systems, but strives to be a bit more. This abstraction does contain a representation of the interface state between components (eg fluxes, as well as state variables like temperature, momentum, etc). But it also conceives of the "coupled system" as an entity in and of itself (rather than merely coupling entities together). Thus run!(Simulation(earth_system_model)), etc.

In the medium term, we hope to use this package for coupled atmosphere + ocean + land + sea-ice simulations with a variety of different packages (SpeedyWeather, Breeze, ClimaAtmos, Oceananigans, veros, Terrarium, ClimaLand, ClimaSeaIce). And more. Originally it was just for ocean and sea ice simulations, but we realized it is simple to swap PrescribedAtmosphere for a prognostic one. I think that reflects the clean, modular design of EarthSystemModel.

Maybe this explanation can help guide us into finding a good name. Eg I think a good name would probably effectively be an evocative, exciting translation of "EarthSystemModels.jl"

[ali-ramadhan]

Big +1 to a name change! I always find it super hard to name packages but out of the suggestions so far I like NumTerra.jl the most.

[rafferrari]

Renaming the package is a reasonable idea. However the name should convey the point that this is at heart a coupler, not a full monolithic ESM model. Calling it ESM.jl conveys the opposite message. Something along the lines of EarthSystemLink may be more appropriate.

[xkykai]

In the spirit of conveying the notion of a coupler there is perhaps no better candidate than something related to Hermes -- think HermESM.jl (which is probably a bad name). Unfortunately Hermes.jl has already been taken. Along the same lines MercuryEarth.jl or Iris.jl?

Upon looking it up Ryujin is a nice candidate, but could be potentially obscure, also not to be confused with Ryujin the Korean rapper.

I also chanced upon the idea of a World Tree which connects all realms, like the Yggdrasil in Norse Mythology. But I think Yggdrasil is a mouthful. Along the lines I found out about Fusang, which is a similar idea in Chinese mythology. So maybe something like Fusang.jl? Don't think it rings well though.

Seems like I do like the gods and legends direction.

[ali-ramadhan]

I know there's been a tiny bit of discussion on Slack around not naming packages after gods but I'm curious what people think: https://numericalearth.slack.com/archives/C09568HMH0W/p1757048551686339

And just to add to @xkykai's links: Yggrasil is a taken name in the Julia ecosystem: https://github.com/JuliaPackaging/Yggdrasil

[glwagner]

Renaming the package is a reasonable idea. However the name should convey the point that this is at heart a coupler, not a full monolithic ESM model. Calling it ESM.jl conveys the opposite message. Something along the lines of EarthSystemLink may be more appropriate.

The key concept is that, like Oceananigans is a library for building ocean models, this package is a library for building EarthSystemModels. Therefore it does not provide a single implementation of an ESM, but rather a framework for building them.

I think it's very important to understand the tool that we have built as much more than a "coupler" -- for example, it instantiates its own, independent prognostic state, and has a design that permits whole-system diagnostics. The abstraction acts just like an ocean model in Oceananigans because it has time_step!(coupled_model, coupled_dt), it can be put into Simulation and we can call run!(coupled_simluation), it can have its own grid, output, checkpointer, and diagnostics, etc. It has many parameters that are independent of the parameters appearing in component models.

[milankl]

Yay 🎉 was waiting for this moment! What about EarthSystemMeridian.jl or simply Meridian.jl or similar? Meridian or meridian line means midday so conveys the message of being central but the meridians are also the lines that flow together at the poles, connecting ocean, land, ice etc across the globe?

Meridian.jl also isn't taken in the general registry, but for uniqueness/ findability one could also combine this with ESMs (plural to highlight it's not just one) like MeridianESMs.jl -- for brevity one may say "Meridian" but for urls etc the "ESMs" makes it unique

[glwagner]

I like Meridian.jl quite a bit! A similar concept could be Horizon.jl --- where ocean, land, and sky meet. (But "Horizons.jl" with an "s" is taken, so Meridian might be better). Acronyms are discouraged I believe, so I would leave off "ESM".

[milankl]

Would you eventually move this to its own organization? Then github.com/MeridianESMs/Meridian.jl could fly? Google searches would therefore also be easier ...

[simone-silvestri]

I very much like names like Meridian and Horizon, evocative yet easy to understand (and to pronounce 😅 )

[tomchor]

Meridian.jl and Horizon.jl are at the top of my list right now! Honestly I prefer Horizon.jl though, since it's more tangible and has a more direct meaning. I don't think it's a problem that HORIZONS.jl already exists. It doesn't seem to be very active and it's written in all-caps, so I doubt it'll be a source of confusion.

[simone-silvestri]

All exciting takes! I will convert this issue to a discussion so we can initiate a poll to vote on a possible new name for this repository!