How best to include code for coupled applications

[Whyborn]

I would like to work out how exactly we want to include code intended for coupled applications. At the moment, we use all 3 possible methods in different places:

• Preprocessor directives e.g. science/casa-cnp/bgcdriver.F90, science/misc/cable_climate.F90. Also note that UM_CBL is the only preprocessor directive that's active at the moment- ESM15 and UM_BUILD are not defined.
• Namelist options e.g. science/roughness/cable_roughness.F90, science/gw_hydro/cable_gw_hydro.F90
• Inclusion of files via CMakeLists.txt

My opinion is that the best approach in the long term is to cut the preprocessor directives entirely, and rely on namelist options and inclusion/exclusion of files via CMake to get the desired application-dependent behaviour. The removal of preprocessor directives wouldn't happen particularly soon, but it might influence the way I work on the library for AM3. I think we have discussed this before, but I couldn't find anything written down. Thoughts @ccarouge @JhanSrbinovsky @har917 @rml599gh?

[JhanSrbinovsky]

Sounds like what we want. And what we have with code in place. i.e. only offline builds include offline/. only AM3 builds include coupled/AM3/. The ifdef ESM15 should be gone I thought. The UM_CBL is trickier and we've put this into the too hard basket for a while. cable_user switches were intended for selecting configs - although morphed into something else. cable_runtime switches are all set to FALSE. cable_runtime%explicit for e.g. is flicked to TRUE when it passes through cable_explicit_main. We did have a ubiquitous cable_cbm and spaghettidifed with IF cable_runtime%explicit, IF cable_runtime%implicit, IF cable_runtime%um ELSE. Earliy on when we were particularly worried about what gets (re)set when, it was painful to read given the 3 different time stepping in ESM1.6, AM3, offline so I seperated them all BUT they could be put back together. So per timestep cbm calls the same model, or same library in all apps. How we call cbm and what switches we turn on to prior to calling it can be in each application interface. The UM_CBL preprocessor couldn't be easily fit in with runtime switches. The brute force way could be to use interfaces I suppose

  INTERFACE eg
    MODULE PROCEDURE eg_offline, eg_um
  END INTERFACE eg

[har917]

Morning all - my preference on this is similar but with one layer of complication (actually 2), i.e.

1. no preprocessor directives (that includes UM_CBL)
2. combinations of namelist options and Makelist
3. create/use stubs for those parts of the code that can only be activate in certain applications (e.g. POP) or need to be different across different applications* but that need to be there for compilation.
4. Be much more pedantic around directory structure - any file that we find needs stubbifying gets placed into and across different directories*.

I think this will end up being similar in approach to where JaC lands TBH (i.e. stubs for tech/science in JULES to keep the coupling/i-o secure and then ACCESS builds from the library).

I suppose that an INTERFACE could work but I've always found these to be less that intuitive and we'd need to do roughly the same amount of sorting/shuffling anyway.

e.g. for POP and climate create stubs (basically simple dummy TYPEs and singleton instances) that we can carry around which (in combination with some IF cable_user% conditions would get rid of the the need for UM_CBL. Place the different POP and climate definitions in easily identified directories (ie. not in the common science directory - so likely would require some modularisation/code restructure) - so that in the unlikely event we end up changing stuff it's obvious that partner changes may be needed in the other stubs - then use the Makelists to pull things together at compilation/build.