Ingesting and coupling interface

[einola]

We need an interface between the physical model and forcing data, whether it's coming from some idealised settings, files, or a coupler. In short, what people usually do when forcing a model with reanalysis data is the following:

1. Read atmospheric state from files, e.g.
   • 10 m wind (u,v)
   • 2 m temperature
   • One of 2m dew point, mixing ratio, or specific humidity
   • mean sea level pressure
   • incoming long- and short-wave radiation at the surface
   • rain
   • snowfall
2. Use bulk formulas to calculate the total flux at the surface, sometimes along with the derivative of the total flux w.r.t. surface temperature.
3. Hand the total flux (and its derivative) to a thermodynamic routine that:
   • updates the ice surface temperature
   • calculates the temperature profile in the ice
4. Hand the imbalance in energy at ice top and/or bottom to a function of the thermodynamic model that:
   • calculates melt or growth of the ice

In many cases steps 3 and 4 are done in the same function.

Different coupling strategies with the atmosphere insert their data in different places in this routine. The ones I'm aware of (and I'm reasonably sure it's all there is):

• CNRM: The atmosphere calculates the fluxes and hands them to the ice model through the coupler. This means the data is input directly into step 3.
• CESM: The atmosphere hands the atmospheric state at the 1st model level to the ice model through the coupler. Data is input into step 2 for the ice model to calculate fluxes.
• The Winton (2000) approach. The atmosphere calculates the imbalance in energy at the ice top or bottom and sends this to the ice model via the coupler. Data is input into step 4.

We need to accommodate at a minimum reading from files and the CNRM approach in SASIP, the CESM approach should also be accomodated. The Winton (2000) approach is the most physically consistent and my favourite ... but I don't know if anyone's actually using it.

---

To accommodate at least reading from files and the CNRM and CESM approaches, I suggest that we rearrange a bit the current structure of ElementData and NextsimPhysics. I propose a basic Inputs class that inherits from BaseElementData and holds the total surface fluxes (both over ice and open water) and does the following:

• Use bulk formulas to calculate fluxes from the atmospheric state received on input
• Sum up the fluxes received as input

In addition, we would have to write different IModelStep implementations that implement the following:

1. Read in from files:
   • Receive data from XIOS (through inheritance)
   • Loop over a vector of Inputs objects, calling the routine to calculate fluxes via bulk formula
   • Loop over a modified NextsimPhysics with the vector of Inputs objects on input to calculate melt and growth
2. Couple with CNRM:
   • Receive data from OASIS (through inheritance)
   • Loop over a vector of Inputs objects, calling the routine to sum up fluxes
   • Loop over a modified NextsimPhysics with the vector of Inputs objects on input to calculate melt and growth
3. Couple with CESM:
   • Receive data from CESM coupler (through inheritance)
   • Loop over a vector of Inputs objects, calling the routine to calculate fluxes via bulk formula
   • Loop over a modified NextsimPhysics with the vector of Inputs objects on input to calculate melt and growth
4. Winton's approach:
   • We won't do this for now, but the setup is flexible enough so that it could be done if we just split the Winton model in two (as he intended).

On top of all this, we also need to accommodate different bulk formula implementations through the modules system. (but this can come later).

[einola]

Thoughts @timspainNERSC ?

[timspainNERSC]

My immediate thoughts:

This impacts heavily on the design of the existing 1D physics calculation which very much assumes it gets the data at step 1 and is doing all the calculation itself.

Using the modules could be useful here, loading different parts of the physics routines depending on which type of coupling is specified.

Are the fluxes that are coupled reasonably well standardized? Or might every model supply its own set of almost, but not entirely, different flux fields?

[einola]

There could conceivably be some variations in the flux fields. What you'd expect is to receive the following twice, once for the ice-covered portion and once for the ocean portion:

• Wind stress
• Short-wave flux
• Non-solar flux (sum of sensible, latent, and longwave)
• Snowfall
• Evaporation minus precipitation

The CNRM setup mostly follows this, but it sends evaporation and precipitation in separate fields and does something a bit odd with the wind stress that I need to figure better out. It appears that the atmosphere calculates the wind stress over the open ocean and this is sent, but in addition to the two components they also send the modulus of the wind stress vector and the 10 m wind speed. I think these extra fields are then used to calculate the wind stress over ice.

I also think the modules system is the way to go here and this is the best I came up with. The idea is that if people want to couple neXtSIM_dg to some other model(s) then writing a new module to do things in a different order or slightly differently should be easy.

And yes, it does mean changing the 1D physics design. I've been trying to understand how much, but it seems to me it's "mostly" a question of moving things around and splitting the ElementData in two (and we already have PrognosticData). But I think it's needed because we can't do everything inside a single object. I at least don't see how.

Also, the input methods we have, XIOS or the couplers, expect the traditional multiple arrays of doubles, not a single array of objects. And because they are both doing MPI in the background it's probably most efficient to get all the data in one big call, rather than querying them once per grid cell.

[einola]

Some further clarifications on the CNRM setup:

• The 10 m wind speed is "used onmpute [sic] surface gases exchanges in ice-free ocean or leads" it says in the NEMO code
• NEMO is on a C-grid and assumes stresses in the U-direction are on U-points, in the V-direction are on V-points and that the stress magnitude (modulus) is on T-points. The stress magnitude on T-points is used in the TKE vertical mixing scheme and a few other places.
• The CNRM setup assumes the wind stress over ocean and ice is the same! This is non-standard, to say the least.

[timspainNERSC]

Also, the input methods we have, XIOS or the couplers, expect the traditional multiple arrays of doubles, not a single array of objects. And because they are both doing MPI in the background it's probably most efficient to get all the data in one big call, rather than querying them once per grid cell.

The coupling is only done at the start of a TS, when the data needs to be broadcast from the dynamics arrays. If I can write an efficient broadcast/gather routine, then the overhead will be no more than that of broadcasting the data from the dynamics.

If

[einola]

Yes, that's potentially an important if :)

If you can do that, then the design of the ingester routines is cleaner, I agree (can't think of a better word than ingester). But given the different coupling strategies, I still think we should split up ElementData. So, then it's maybe not worth the effort - especially if it's difficult.

What I find more interesting is the output side of things. What I would very much like is if each module can decide what it wants to output in a self-contained way. With a good broadcast routine you could do something like this on each grid cell:

Get inputs
Do physics
Modify prognostic variables (this through PrognosticData/ElementData)
Broadcast diagnostic outputs

It would make for very clean and self-contained modules. Shall I write this up in a separate issue?

[timspainNERSC]

This is such a big part of the overall model design that I think, yes to a new issue, but we should also start a design document. Start it off as notes, like the comments above, and work towards a coherent description of how all these parts work together.

[einola]

I played a bit around with reorganising things in the current NextsimPhysics class. I'm pushing it for your reference @timspainNERSC. It mostly makes sense, but I see I may need to think a bit more about the ocean coupling side. Still, it's a start.