Open mpmoine opened 5 years ago
davidhassell
commented
5 years ago ES-DOC are collecting couplings between "realms" separately in the coupling spreadsheet. Any coupling within realms should be described with a property in that realm. This is the case here,with the coupled_to_land property in the river routing process (9.1.1.10)
mpmoine
commented
5 years ago Thanks for the precision.
In fact, we find hard to follow this guideline because technically, in a coupled model, the coupler handles coupling between executables. And there is no bijectivity between a realm and an executable.
An executable corresponds to a model component, covering possibly several realms (e.g. our atmosphere executable includes atmosphere and land realms), or, on the opposite, this executable can have no associated realm (its is the case for "river routing" in our model).
Moreover, its is not possible to describe all the couplings, in the broad sense of the word, that includes all arguments passing between the main routines of 2 realms.
davidhassell
commented
5 years ago I think that the aim of the coupling description is to transcend, to a large extent, the organisation of the code (in terms of compiled modules) and focus more on which coupled variables are of interest, rather than aiming to describe every combination that exists.
Within-realm couplings for quantities of common interest require specific questions in the spreadsheets, and we are happy to add these if they are missing.
if I have not quite understood your points - please let me know!
When defining the Source and Target of a coupling, we are limited to a choice among the 8 realms. However, this does not necessarily matches the reality of the coupling. For instance, there is no “river routing” realm but in our climate model, land-surface and river-routing model components exchange coupling fields.