Developing and sharing custom bathymetries

[taimoorsohail]

Hi,

As I embark on a long-term ClimaOcean run with distributed GPUs, I am running into an issue that I think is worth discussing here.

Namely, the bathymetry file needs to be manually tweaked to open and close various major and minor basins. Specifically, the Black Sea, Caspian Sea and Baltic are often closed or open depending on the major_basins and interpolation flags in the regrid_bathymetry function.

It is fairly straightforward to define a polygon and mask these basins (or open channels) for the grid. In a distributed run, it is a bit more challenging due to the geographical partitioning, but still doable.

However, it occurred to me that this manual tweaking of bathymetries is part of model development. For instance, closing small basins that experience T/S extrema, or trigger velocity instabilities. I am realising it may be worth considering developing plug-and-play bathymetry files for each resolution that people can use. For example, I am running a 1/6th-degree simulation, so any bathymetry file I adjust to avoid instabilities and open relevant basins can then be shared and may become standard for ClimaOcean 1/6th degree runs. Same for 1/8th and 1/12th runs, which I think @simone-silvestri is working on. I realise this may not be a very general solution. But I also realise that if everyone starts with ETOPO, there will be a fair bit of repeated efforts in tweaking bathymetries.

Maybe there is a general masking function we can build into Bathymetry.jl, but I guess that still puts the onus on the user to find and quell any bathymetry-related gremlins at their resolution. What do we all think?

[glwagner]

I would advocate for sharing functions that produce custom bathymetries (which can be embedded in the source code) rather than sharing the bathymetry files themselves.

The reason is that the function encodes a workflow which can be reproduced, and changed via PRs.

The common practice of sharing bathymetry files does not produce this; they cannot be further edited, and the process by which they are developed is not visible.

The function will have to take in the vertical grid, which can also be changed arbitrarily, right? But a given function will correspond to a fixed horizontal discretization (eg quarter_degree_tripolar_grid or whatever).