GENIE:Design doc

=Introduction=

One of the key facets of GENIE is that the overall model is comprised of sub-models which, broadly speaking, can be swapped in or out. These permutations give rise to the various 'flavours' of the overall GENIE model.

This glorious modularity has a rub, however. If all the sub-models are independent of each other, swapping sub-models in and out is easy, but getting overall consistency of common parameters--e.g. the length of a year etc.--is hard.

This tension hasn't been resolved thus far, and is the bane of many an experimenter's life. The situation has prompted the adoption of a broad brush design principle illustrated in the figures below. The principle is as follows:


 * Parameters common to more than one sub-model should reside in the calling-context for that sub-model. For GENIE, this calling context are variables in genie-main which have, ideally, been read-in from a namelist file.  If an experimenter wishes to run a sub-model in isolation, they will need a bespoke calling-context to feed the sub-model in question with all the parameters it expects to receive from outside.  If the sub-model were to be included in yet another climate model, then the new model becomes the calling-context.  Makes sense, right?





=Standardised I/O=

Writing to the Screen
Several categories:
 * Record of State
 * Actions
 * Chronological

In more detail:


 * Record of State
 * Global verbosity (0: silent running, 1: basic, 2: chatty, 3: debug)
 * Per module verbosity?
 * which modules selected in flavour
 * time-stepping ratios
 * global constants
 * Actions
 * open/close, read/write files
 * Chronological
 * Setup
 * Can use "write (6, NML-NAME)" to print runtime params to screen
 * Each timestep
 * e.g. model 'date'

Style: indicate which module a message is coming from? line & file?