Allow for pairwise exchange grids

[bgroenks96]

While trying to understand how the component interfaces work, I noticed that ComponentInterfaces seems to assume the existence of a single exchange_grid,

https://github.com/NumericalEarth/NumericalEarth.jl/blob/main/src/EarthSystemModels/InterfaceComputations/component_interfaces.jl#L297

I think this will be problematic when adding land into the mix (#36), at least for some model configurations. More specifically, in the case where we have an Oceananigans-SpeedyWeather-Terrarium EarthSystemModel, it would make very little sense to exchange fluxes between the atmosphere and land using the ocean grid (currently the default for exchange_grid) since Speedy and Terrarium already operate on the same underlying grid structure (just using different Field types).

Of course, for Oceananigans-Breeze-Terrarium configurations this wouldn't be an issue since Terrarium could just use the same Oceananigans grid.

Nevertheless, I am wondering whether it would be a good idea to consider allowing for more than one exchange grid, at least one for atmosphere-ocean and atmosphere-land.

[glwagner]

exchange_grid is where fluxes are computed. Each component regrids to the exchange_grid, fluxes are computed, and then remapped back to the grids of the component models.

I'm not sure I understand the issue with this pattern, can you explain further?

[bgroenks96]

The issue is that Terrarium currently unrolls a RingGrid into the x dimension of a RectilinearGrid (actually we just create a grid that has x dimension matching the shape of the RingGrid). This means that we do not need to do any regridding at all when interfacing with a Speedy atmosphere; we can just copy Fields directly. I wouldn't want to add a regridding step for no reason.

[bgroenks96]

but obviously that wouldn't work for the ocean component because it isn't column-based and has its own Oceananigans grid.

[glwagner]

I think if you want to run speedy-terrarium simulations, you should use that grid as the exchange_grid. Moreover, I do not think we want to support situations in which ocean-atmosphere and ocean-land fluxes are computed on different grids?

It does seem like there is a case for ocean-sea-ice fluxes though, since sea ice is "inside" the ocean by definition.

cc @simone-silvestri

[bgroenks96]

Moreover, I do not think we want to support situations in which ocean-atmosphere and ocean-land fluxes are computed on different grids?

Why not though? Is there a good reason to preclude Speedy-Terrarium coupled with NumericalEarth ocean + sea ice?

[bgroenks96]

or would you suggest that we support that but just accept the overhead from doing the unnecessary regridding step between Speedy and Terrarium?

[glwagner]

Moreover, I do not think we want to support situations in which ocean-atmosphere and ocean-land fluxes are computed on different grids?

Why not though? Is there a good reason to preclude Speedy-Terrarium coupled with NumericalEarth ocean + sea ice?

How would speedy communicate with the ocean and sea ice in this situation? What exchange grid would they use?

[glwagner]

or would you suggest that we support that but just accept the overhead from doing the unnecessary regridding step between Speedy and Terrarium?

If the exchange grid is a grid that is common to speedy and terrarium then there is no need to regrid. In that case only the ocean/sea-ice must regrid.

[glwagner]

I think we could generalize exchange_grid, find a good name and then in the case that its "one grid", we implement the algrithm in which all fields are regridded to that common grid. in the case that it is a different type like PairwiseExchangeGrids we can support all the combinations which are something like

atmosphere_land
atmosphere_sea_ice
atmosphere_ocean
ocean_sea_ice

there are also land_ocean fluxes but I don't think these require a grid (it is just a one-way passing of fluxes from land to ocean)

[simone-silvestri]

I agree that in the case of Speedy + Terrarium + Oceananigans we can generalize the exchange grid to use SpeedyWeather RingGrids (should probably not be too difficult), so that we can keep only one exhange grid.