Data container cleanup

[dustinswales]

Description

As part of adapting contiguous data structures within the ufsatm, and in preparation for the inclusion of MPAS, these sub-fields could be combined into a single type and partitioned into dycore-specific and dycore-agnostic sections, possibly isolating diagnostics into their own type.

Descriptions of existing GFS data containers.

GFS_init_type - Dynamical core specific. Contains grid-specification and domain decomposition information. Additional dynamical cores will need their own container for this information. To accommodate, we suggest changing the name GFS_init_type to FV3_init_type

GFS_statein_type - Dynamical core specific. Contains the input prognostic state from the dynamical core. Additional dynamical cores will need their own container for this information. To accommodate, we suggest changing the name GFS_statein_type to FV3_statein_type

GFS_stateout_type - Dynamical core specific. Contains prognostic state from the physics to the dynamical core. Additional dynamical cores will need their own container for this information. To accommodate, we suggest changing the name GFS_stateout_type to FV3_stateout_type

GFS_sfcprop_type - Dynamical core agnostic. Contains interstitial physics variables relating to the surface. The surface is handled in the physics, so this data could be shared across dynamical cores that use the same physics codebase.

GFS_coupling_type - Dynamical core specific, but could be partitioned into specific/agnostic pieces. Contains interstitials related to physics coupling with other ESM components, topography, cellular automata, and stochastic physics. To clearly distinguish the FV3 coupling, we suggest creating a common coupling type, and dynamical core specific coupling types. The dynamical core specific coupling types would contain interstitials related to 3D physics (i.e CA and Stochastic physics) and topography, which is grid/dycore specific. For example, a common GFS_coupling_type with dynamical-core specific FV3_coupling_type and MPAS_coupling_type types.

GFS_control_type - Dynamical core specific, but could be partitioned into specific/agnostic pieces. Contains model control parameters. There are pieces that relate specifically to the physics configuration/setting, which is common across dynamical-cores, and pieces which are dycore specific. We suggest partitioning this type into agnostic/specific parts. GFS_physics_control_type, GFS_FV3_control_type and GFS_MPAS_control_type.

GFS_grid_type - Dynamical core agnostic. MPAS may have more fields, but all interpolation data is common.

GFS_tbd_type - Dynamical core specific. Fields that don’t fit in the aforementioned data containers live here. This includes some dycore agnostic fields, but also dycore-specifc fields related to stochastic-physics and CA. We suggest to initially create new TBD data containers for any new dynamical core. To accommodate, we suggest changing the name GFS_tbd_type to FV3_tbd_type

GFS_cldprop_type - Dynamical core agnostic. Fields needed by the radiation Group from the physics Group.

GFS_radtend_type - Dynamical core agnostic. The Radiation Group is called less frequently than the Physics Group, which requires an update step for these radiation fields at the beginning of the Physics Group. This type holds the radiation fields needed by the Physics Group for this update.

GFS_diag_type - Dynamical core agnostic. Contains diagnostics related to the physics parameterizations.

Solution

1. Combine existing DDTs into dycore specific/agnsostic DDTs, and diagnostic DDT.
2. Flat fields in a module. Reliant on completing Transition to use contiguous data arrays #2521.