Adcroft, Chassignet, Danabasoglu, Doney, Hallberg, Griffies, Hill, McGillicuddy,

McWilliams, Schepetkin, Wallcraft, Zadeh

Objectives for proto-HOME Explore and demonstrate the possibilities

for sharing software within the ocean modeling community. (Ocean modeling includes BGC)

Propose a path forward to achieve community models and shared software. Jargon: “Environment”, meaning anything but

think of it as libraries (e.g. netcdf) Such an environment would enable mixing

and matching of ocean model building blocks

Two levels

High level (or coarse grain ← jargon for lots of code) How to swap in another models scheme? Example we proposed was to implement a “common”

interface for BGC models Low level (or fine grain ← jargon for smallish

subroutine) Envision library of well-used common, simple

operationse.g. advection, E.O.S., solvers,

parameterizations, ... We identified lateral advection as do-able

(and learned a lot about what really is do-able)

Coordinating software at a high level

BGC modules at GFDL re-written Same interface Works with two fundamentally different

ocean models (different in coding structure) One uses conventional arrays and “use”

statements One uses pointers ← jargon for something

that isn’t a pointer Has enabled two ESMs at GFDL GFDL considers this a success (we all

agree) Significant skepticism about whether it

could be pulled off at community scale (even with major funding)

Developing libraries (low level) Set of lateral advective flux routines

developed independent of model Developed a recipe to write kernels ← jargon for

subroutines Works for different staggered grids, indexing

conventions, etc… Implementation in GOLD, MOM, MITgcm shows no

performance hit Significantly extends the abilities of each model by

providing new schemes

GOLD

MITgcm MOM4.1

POP

The future? We will tell NSF it can be done but needs

real funding Is the community really motivated enough

to commit resources to an activity like this? Who would own/support it long-term? High-level interoperability is desirable

We want the latest KPP (v9.2)… We believe kernelizing physics internally is

very do-able (i.e. fine grain ← jargon, sorry) e.g. kernelizing KPP means a kernel for

Richardson number calculation, non-local transport, etc.

would deliver inter-operability from the bottom up

Other fields? Sea-ice? …