taylor13
commented
6 years ago Here I record an offline discussion of this:
Martin J.:
Karl and others have suggested that we introduce am "olevhalf" dimension for ocean model half
levels, similar to the "alevhalf" dimension which was used in CMIP5 for atmosphere half levels.
This new dimension would be used for zhalfo (the geometric height of ocean half-levels). Tim
Graham has suggested that it should also be used for vertical velocity and mass flux, wo and
wmo. This makes sense, but the data hasn't been explicitly requested on half levels.
I've reviewed what was done in CMIP5 -- from the 36 models that we have CMIP5 historical data
at CEDA for wmo and uo, 13 models used the same vertical levels for both variables, the other 23
appear to have used half-levels for wmo. As far as the horizontal location of the data point goes,
we have requested that variables be interpolated to cell centres, even if the variable is held on a
cell vertex in the model itself.
Do you have a preference for wo and wmo in CMIP6? Should we specify data on half levels, leave
it up to the modelling groups or specify full levels?Steve G.
Interesting thought. I must admit having considered the olevhalf as the standard for mapping wo
and wmo, since that is the proper depth to have wo and wmo be
computed via continuity from umo and vmo. Sorry not to have thought beforehand to define this
more clearly in so far as the depth levels for the diagnostic. At GFDL, we follow this approach
with the olevhalf. I was unaware that others did not follow that approach.
So bottomline is I think we should recommend olevhalf be the levels on which wo and wmo are
placed.
Having said that, are we perhaps going to be too late for those who pursue the alternative? Balaji:
I think it is too late, certainly for GFDL (not that we would need to reprocess, but, just saying, our
workflow is now frozen). I think we can add a recommendation to the output grid guidance, but I
wouldn't be surprised if we ended up with a similar mix again. Karl T.:
I agree that we can't insist at this point that vertical velocity and fluxes be provided on half-levels.
However, as Steve says, it would be desirable to avoid interpolation from half levels to full levels,
and many groups I think will really want to provide the vertical fluxes on half levels.
I need to confirm this, but I think CMOR could handle both options (allowing either half-level or
full-level). The only difference in the CMOR tables is that full-level data normally requires cell
bounds (i.e., the vertical extent of a grid cell must be recorded in the output file), but half-level
data does not.
The options for changing the data request to allow flexibility for the vertical levels are:
1) Do nothing, but then users reporting data on half-levels, rather than full levels would also be
*required* to make up and store some cell bounds.
2) Modify the data request, changing "cell_bounds_required" from "yes" to "no" for *all* ocean
level data. User could still include bounds for the full-level fields (the bounds are "allowed", but
*not* required). CMOR, however, would fail to warn users if they forgot to include the bounds
when they should have really included them.
3) Modify the data request by defining a new vertical coordinate (e.g., "olev") that would indicate
data could be reported either on model levels or on half-levels. The vertical velocity and vertical
fluxes would be defined as functions of "olev" (rather than the current "olevel"). For "olev",
"cell_bounds_required" would be set to "no". In this case all the other ocean model level data
would require bounds and CMOR would notice when the user forgot them.
I don't like option 2 because lots of models might omit the bounds, which are needed to compute
volume integrals.
Option 1 doesn't sit well with me because the bounds would be required but are meaningless.
Option 3 would be my choice if we were deciding this several months ago (and we didn't want to
*require* the vertical velocity and fluxes be put on half levels). I'm a little worried, however, that
there might be unanticipated consequences of adding a new coordinate now.
I guess on balance I'd vote for option 1. I'm not sure, however, how a user would know which
variables can be reported on half-levels.Tim G.
Thanks for clarifying this. Like Steve it didn’t really cross my mind early on that variables such as
wo or wmo could be expected on full levels so I’m glad to hear Steve confirm this is his thinking
as well. As far as I know all of the NEMO model users will be outputting these variables on
half-levels.Martin J.
After reading that discussion I've checked what was done in CMIP5: for all but one of the models
the cell bounds were provided for both full levels and half levels. For one model (BNU-ESM) the
bounds were omitted for both full levels and half levels -- which is clearly non-compliant with the
requirements.
For vertical fluxes: at CEDA we only have vertical fluxes on ocean levels from two groups, GFDL
and UKMO. I've looked at expc (Sinking particulate organic carbon flux). In both cases this flux is
stored on full model levels, even though these groups have both opted to put their wmo data on
half levels. In the CMIP5 archive as a whole a few more groups produced such vertical fluxes, but
not many. Having vertical fluxes on full levels and vertical velocities on half levels doesn't look
desirable to me .. so perhaps we should make a clear revision to discourage this.
Karl's option (3) could be implemented as a recommendation .. which would not affect the validity
of data produced under the current request.
If we follow option (1), and add a guidance note, we are unlikely to get much consistency in the
choice of levels, as some groups are likely to assume that all variables requested with "olevel"
should be handled the same.
However, I am concerned about making the change for all vertical fluxes (principally . The list of
variables on ocean model levels with "Flux" in the long name is:
exparag, expc, expcalc, expfe, expn, expp, expsi, fg14co2abio, fgco2abio, fgco2nat, ficeberg,
hfibthermds, hfrunoffds, hfsifrazil, hfsnthermds. Is this a complete list? (Some of these are
requested as surface fields by OMIP, but on model levels by C4MIP/PMIP ... I need to check those
requests).
martinjuckes
Some of the ocean variables are defined at the interface between the ocean grid cells (e.g. zhalfo, wo, wmo). Would it make more sense to have an olevel_half dimension analogous to alevel_half. I realise it may now be too late to implement this.