Adding Global Biogeochemical Hindcast to Copernicus.jl

[vtamsitt]

I'd like to add the Copernicus 1/4 degree NEMO-PISCES Global Biogeochemical Hindcast to the DataWrangling tools to use for restoring boundary conditions. It could make sense to fold this into the existing Copernicus.jl module, but I wanted to check if that makes sense and if there are any considerations for this, or if it's better to make a separate module.

[glwagner]

I think it probably makes sense to add to Copernicus.jl! Let's look at the details. Here's some python code that the web interface generated for downloading a few variables:

import copernicusmarine

copernicusmarine.subset(
  dataset_id="cmems_mod_glo_bgc_my_0.25deg_P1D-m",
  variables=["chl", "no3", "nppv", "o2", "po4", "si"],
  minimum_longitude=-180,
  maximum_longitude=179.75,
  minimum_latitude=-80,
  maximum_latitude=90,
  start_datetime="2022-12-31T00:00:00",
  end_datetime="2022-12-31T00:00:00",
  minimum_depth=0.5057600140571594,
  maximum_depth=0.5057600140571594,
)

[glwagner]

This has a different dataset_id, since GLORYSDaily is

ClimaOcean.jl/src/DataWrangling/Copernicus/Copernicus.jl

Line 53 in f559d7e

copernicusmarine_dataset_id(::GLORYSDaily) = "cmems_mod_glo_phy_my_0.083deg_P1D-m"

So I think you need a new dataset type, eg the equivalent of

ClimaOcean.jl/src/DataWrangling/Copernicus/Copernicus.jl

Line 41 in f559d7e

struct GLORYSDaily <: CopernicusDataset end

Something like

 struct GLORYSBGCDaily <: CopernicusDataset end 
copernicusmarine_dataset_id(::GLORYSBGCDaily) = "cmems_mod_glo_bgc_my_0.25deg_P1D-m"

you also need all_dates:

ClimaOcean.jl/src/DataWrangling/Copernicus/Copernicus.jl

Line 49 in f559d7e

all_dates(::GLORYSDaily, var) = range(DateTime("1993-01-01"), stop=DateTime("2021-06-30"), step=Day(1))

and dataset_name

ClimaOcean.jl/src/DataWrangling/Copernicus/Copernicus.jl

Line 45 in f559d7e

dataset_name(::GLORYSDaily) = "GLORYSDaily"

[glwagner]

Might as well add GLORYSBGCMonthly while you're at it.

[vtamsitt]

Great, thanks!

[vtamsitt]

Hmm ok this is practically straightforward but there is more complexity to the utility of this for forcing BGC.

1. the daily and monthly Copernicus BGC products don't have the same variables, the daily doesn't include the iron, phytoplankton, and carbonate system variables but they are included in the monthly files.
2. The carbonate system tracers saved in the monthly product are ph and spCO2, whereas explicit tracers in OceanBioME.jl biogeochemistry are DIC and Alk. DIC and Alk can easily be derived from ph and spCO2, but I'm not sure if that conversion makes sense to build in here or elsewhere in OceanBioME.jl. Also more generally, different BGC models in OceanBioME.jl (NPZD, Lobster, PISCES) have different sets of tracers, so there isn't a really clean way to set all boundary/initial conditions from a single product as there is for the model physical state. I still think including this product in here is very useful for simplifying forcing set up though.

[glwagner]

On the first point --- I don't think this is an issue, as the variable name is a user input. The only task is to define the mapping between "our" names (we prefer more verbose names generally speaking...)

https://github.com/CliMA/ClimaOcean.jl/blob/f559d7ed764e103e0a8fa5d7e72f342ef6729f80/src/DataWrangling/Copernicus/Copernicus.jl#L68C1-L79C2

(There is only an issue if Copernicus uses different names for variables in different data products. But I don't think this is the case, right?)

I think the second point is an issue of the user interface to OceanBioME, because I don't see how this can be solved in a generic way that doesn't depend on both 1) Copernicus bgc models and 2) the bgc models in OceanBioME (which depends on Oceananigans, rather than the other way around). For example, we can't compute DIC and Alk from any tracers without some specific bgc model.

Here's a suggestion: it could make sense to implement helper functions in OceanBioME for converting between bgc states, or for converting from common bgc states to the ones that are supported by a particular model.

[vtamsitt]

Yes you're right the first is a non-issue for this as the naming convention is consistent within Copernicus products, it just means the utility of the daily averaged product is much lower as it doesn't include key variables.

On the second point, yes helper function in OceanBioME make sense here, I'll take this step over there and just add the bgc products to Copernicus.jl as is for now.