MARBL Design Document

Very Rough Draft!

Split into routines: sflux, interior, init

---

Intent(in) [every time step]

1. GCM State
2. Tracers
3. Forcing
4. Domain / vertical grid (may be time-varying, option for static?)

Intent(out) [every time step]

1. Surface Fluxes
2. Tracer Tendencies
3. Saved State
4. Diagnostics

Intent(inout) [initialization]

1. Namelist / Configuration
   1. High level config: Option A vs B vs C (turning on / off ciso)
   2. Low level config: saturation constants / other parameters
   3. Is passing namelist string across API acceptable?
2. Metadata
   1. MARBL needs to know what the intent(in) data represents
   2. GCM needs to know where to intent(out) data represents

The top two categories are clear, I think the current hang-up is how to handle initialization (POP is happy letting MARBL set everything up, MPAS needs a way to tell MARBL how things are already set up). Alternative: MARBL makes decisions, but GCM confirms handshake (make sure everything lines up)

Configuration Requirements

1. MARBL's BGC configuration can be changed without modifying the GCM driver interface
   1. One way to do this is for MARBL to be solely responsible for its configuration (for instance, parsing namelist input)
2. MARBL will provide routines to allow the GCM [read / maybe write?] access to parameters used in a particular run