River model grid area ... and optional values of cell_measures

[martinjuckes]

This relates to https://github.com/WCRP-CMIP/CMIP6_CVs/issues/312 and https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/85. People want to provide river flow information on the grid of the river model which may be different from that of the atmosphere model. I've taken the first step towards supporting this by adding an areacellr variable to the request. It follows that there are a number of variables which may have either cell_measures: "area: areacella" or cell_measures: "area: areacellr" How should this be indicated in the data request? For example, I could put area: areacella --OR areacellr in the cell_measures entries for these variables? Would CMOR and PrePARE be able to deal with that?

[martinjuckes]

You might be in agreement, but I disagree with you. I've no idea what you mean by "we agree" or where you get this idea from. Your comment above is not the current definition of areacellg and never has been. It is defined in the data request. I can change it to bring it into line with what you are suggesting, but I want agreement first. i.e agreement between us, not just you agreeing with yourself (a potential area of confusion which, I confess, I hadn't given serious thought to before now).

[taylor13]

I'm pretty sure I wasn't misinterpreting areacelli and areacellg following your https://github.com/PCMDI/cmor/issues/220#issuecomment-319763133 that "areacelli should be the area of the ice model grid, not the grid that the data is requested on." This was reinforced in your https://github.com/PCMDI/cmor/issues/220#issuecomment-319895376 that "areacelli was added after discussion with the ISMIP6 chair, Sophie Nowicki. It is there to provide information about the spatial structure and spatially varying resolution of the ice model grid."

You pointed out that areacelli is distinct from areacellg, which you defined in https://github.com/PCMDI/cmor/issues/220#issuecomment-326615796 as follows: "We currently have a variable areacellg for the cell area of interpolation target grids." The only time areacellg is used in the current data request is for ice-sheet model variables interpolated to special grids over Antarctica and Greenland; it is not used for atmospheric or ocean data.

Recently you proposed new areacell definitions in https://github.com/PCMDI/cmor/issues/220#issuecomment-334915071:

For areacelli:
comment = "Cell areas any grid used to report ice sheet variables. 
These cell areas should be defined to enable exact calculation of area 
integrals (e.g., of vertical fluxes of energy at the surface and top of 
the atmosphere)."

and

modelAreaCelli:
long_name = "The cell area of the ice sheet model. When interpolated 
to a regular grid, it should be interpolated (not summed) with a 
conservative scheme to preserve total area".

I think your new definition of areacelli is the definition that you originally assigned to areacellg in https://github.com/PCMDI/cmor/issues/220#issuecomment-326615796 , and modelAreaCelli is what you originally named areacelli, consistent with https://github.com/PCMDI/cmor/issues/220#issuecomment-319763133 and https://github.com/PCMDI/cmor/issues/220#issuecomment-319895376 .

So as not to change the data request in this respect at this late date, we only need to replace "areacelli" with "areacellg" in the definition above (copied from https://github.com/PCMDI/cmor/issues/220#issuecomment-334915071). Then none of the cell_measures currently containing "areacellg" will have to be changed. [The renaming of the original areacelli as modelAreaCelli is a change we could also avoid but since it doesn't appear in cell_measures, it won't be as disruptive to change at this point.]

[martinjuckes]

I see, you are classing some changes as changes and other changes as "not changes", complete nonsense, but with some kind of internal consistency. I'll make the "non-changes" that are needed, and we can move on.

[taylor13]

If CMOR can handle areacellr the same way as areacella, areacello, and areacellg, then I think this issue can be closed.