areacell naming

[taylor13]

The long-planned approach (initiated more than 3 years ago) to making the variable register for CMIP7 serve multiple projects without undue, duplicative inflation of the register's contents requires that it be independent of reporting interval ("frequency"), region, and grid. The plan, therefore, has been to remove frequency, region, and grid-specific information from the variable definitions in the register. This has already been implemented for frequency and region, and this should be done for "grid" by removing the distinction between the variable names "areacella" and "areacello", replacing these simply with "areacell".

Although the distinction in the names "areacella" and "areacello" superficially seem to be useful in determining which grid a variable should be reported on, it is not true. Even for a single model, a variable may be reported on multiple grids (e.g., on a very high resolution native grid of complex description and on a more manageable, lower resolution regular latitude x longitude grid). So knowing the name of the areacell variable in CMIP6 (whether it be areacella or areacello) did not provide a user with the definitive information needed to obtain the area cells they should use to analyze CMIP variables of interest.

For CMIP7 it became clear that we should register each grid used to report model output and assign it a unique grid label. That plan is being implemented. Some of the more recent discussion of this (initiated in May of this year) can be found here: WCRP-CMIP/CMIP7-CVs#202 . This grid label will appear as part of the filename uniquely identifying data and it will also be record as a global attribute in every file. This means that when users download a variable that they want to analyze, they can definitively learn (from either the filename or from the grid_label global attribute) which of the areacell variables in the archive they should obtain in conjunction with the file of interest. There is absolutely no need to assign different names for the cell areas that might usually be associated with an atmospheric grid or usually associated with an ocean grid. (The same grid may, in fact, be used to report both atmospheric and ocean variables.)

I have spent countless hours trying to come up with a use-case where it would be important to filter datasets based on the name of areacell (i.e., whether it was areacella or areacello). I have been unsuccessful, and no one has provided a use-case requiring the use of different names.

So, I think there should be no reason to continue to give different names to the areacell variable based on whether it might happen to be used to report atmospheric variables or ocean variables . (When both atmospheric and ocean variables are reported on a common grid, then we face a dilemma. Should we assign the name "areacella" or "areacello"? In fact we would have to report the same cell areas twice but using two different names; otherwise the cell_measures would point to a non-existent variable.)

Somewhat tangentially, It should be noted that the current plan for the data request is to include a grid directive, which would indicate to modeling groups what grid a variable is requested on. The options will include: the native atmospheric grid, the native ocean grid, a preferred atmospheric grid (i.e., a grid that a modeling group chooses to regrid its data to) , and a preferred ocean grid (similar to the atmospheric case). In the latest release of the data request a modeling group must infer this information from the cell_measures and by reading the "processing notes". Inclusion of explicit "requested grid" information will ensure that modeling groups are aware of which grid they should report their data on. (The "requested grid" is, of course, simply a "request" and not a requirement.)

Apparently, objections were raised just a few days ago to the above well-reasoned plan by one or two members of the Data Request Task Team (no one has publicly raised any objections). I'm pretty sure their objections arose from an unawareness of how grids were to be uniquely identified in CMIP7. Whether or not that's the case, I would request that they publicly provide a use-case indicating why it is important to create two different variable names to identify the area of a grid cell.

Time is of the essence now, so I hope any objections identifying the variable containing cell areas by the name "areacell" will be made known within the next day or two. I am told that some groups plan to start writing model output in the next week or so, and they need to know how cell_measures should be recorded.

Please provide any feedback on this by responding to the corresponding github issue:
(The issue has been raised on the "WCRP-CMIP/Variable Registry" repository (https://github.com/WCRP-CMIP/Variable-Registry) because this register cannot be implemented as originally conceived without correcting this problem; it should be noted, however that there are also important implications for the CV repository (https://github.com/WCRP-CMIPCV) and the data request's airtables.)

Please share this issue with anyone you think might have an interest.

[mpmoine]

Hi Karl and all,

Thank you for the detailed and well-reasoned argument. It really helps clarify the situation, in addition to the GitHub issue WCRP-CMIP/CMIP7-CVs#202, which we carefully reviewed in full.

To clarify, our concern was not about the o/a suffixes, but rather about no longer mentioning areacell/thkcell/volcell in a variable’s cell_measures attribute and therefore (as required by the CF convention) in the global attribute external_variables.

We fully agree that the Variable Registry must remain agnostic to region, frequency, and grid. We now better understand the rationale for simplification and the logic behind the “new” grid_label. The registered grid labels defined by modeling groups identify the grids of each model component on which variables for a given experiment are written. This allows users to distinguish whether a grid is atmospheric or oceanic, simple or complex, etc.

Our first concern was from a user’s perspective. This new grid_label implicitly means there must be a link between the grid label itself and the corresponding weight file (e.g., areacell or equivalent). From our understanding, that link will only exist at the CV level, where each modeling group will document, through the EMD, the grid identifiers they use. Thus, the identification of the correct weight file relies on the grid label, but only indirectly and outside of the netCDF file itself. So the disappearance of cell_measures and external_variables is not necessarily a regression. However, it may increase the need for user support, especially for those unfamiliar with CMIP, who will ask where to find the appropriate mesh weight files for their analysis. In CMIP6, even with the presence of cell_measures and external_variables in netCDF files, which were already insufficient to uniquely identify the grid, this was already one of the most common questions we received.

From a producer’s standpoint, we worried about the risk that only a limited number of modeling groups will actually provide the mesh weight files. But after carefully check in DR 1.2.2.1, physical parameters such as areacella, areacello, and thkcello are defined and requested by the “BCV: Baseline Climate Variables” opportunity (thkcello being requested as fixed field or time series in case of variable-volume ocean grid) which is fine.

However, there are also cases where the preferred grid for a given variable is not the component’s native grid. In other words, producers must know in advance which grid the data is expected on (if not native) in order to regrid as necessary and provide the mesh weight file of the target grid. In CMIP6, this was partially handled through cell_measures, which helped deduce the expected grid from the DR. For CMIP7, since cell_measures is no longer used, the proposed solution is to include an explicit requested_grid in the DR. This works for us, but it requires integration into DR 1.2.3 and corresponding adaptations to downstream workflows. In practice, the DR will not know all the grid labels registered by modeling groups and cannot directly point to a specific “preferred” grid label for each GCM/variable. Inevitably, this translation step between the DR’s requested_grid value and the corresponding grid_label will fall to the modeling groups.

In conclusion, we support the proposed strategy around grid_label, which allows us to move beyond unsufficient cell_measures and external_variables attributes. However, this strategy has technical consequences and user-facing implications. At a minimum, clear communication is needed:

1. To producers: to emphasize that they must systematically provide weight files for all declared grids in the EMD (ensured if they always support the BCV opportunity), and to let them know the grid_label naming rules and management
2. To users: to clarify the now implicit rule that weight files are always the areacell/thkcell/volcell variables matching the grid_label of the analyzed netCDF file.

Finally, our apologies if it seemed that we were questioning a carefully considered decision at the last minute. In reality, there was a breakdown in communication, as we only became aware of these elements last Thursday, and it was not easy to fully weigh all the implications during the meeting itself.

Marie-Pierre, Guillaume, Gaëlle and Laurent.

[taylor13]

Hi Marie-Pierre, Guillaume, Gaëlle, Laurent and others,

Thanks very much for spending precious time reviewing the discussion concerning areacella, areacello, and related issues. And apologies that only now have you become aware of how we planned to specify grids in CMIP7. The plan was discussed by a group of us long ago.

Our first concern was from a user’s perspective. This new grid_label implicitly means there must be a link between the grid label itself and the corresponding weight file (e.g., areacell or equivalent). From our understanding, that link will only exist at the CV level, where each modeling group will document, through the EMD, the grid identifiers they use. Thus, the identification of the correct weight file relies on the grid label, but only indirectly and outside of the netCDF file itself.

If I’ve followed what you’ve said, I think there is a misunderstanding. When analyzing data stored in a CMIP7 file, the user can easily find the reporting grid since its label will appear both in the filename and be stored as a global attribute. With this grid label in hand, the user will consult the list of available areacell files and select the one that includes the identical label (both in its filename and stored as a global attribute). To perform the analysis, there is no reason to consult the CVs unless one wants to learn about the grid characteristics (e.g., its resolution). [Under our method, it will be easier to find the correct area weights than under the CMIP6 system where users had to obtain the source_id, the grid_label, and the name of the areacell* variable in cell_measures. Then search all the files with the same areacell* name to find the one that was produced by the specified model and had the same grid_label.]

Inevitably, this translation step between the DR’s "requested grid" value and the corresponding grid_label will fall to the modeling groups.

Yes, this has always been the case. The job of the data request is to indicate if groups of variables should be reported on a common grid. In CMIP6 (and in CMIP7 v1.2.1.1), this is usually done by specifying in cell_measures different names to identify 4 different groups of variables: "areacella" indicates that the variable belongs to an “atmosphere” group, “areacello” an “ocean” group, “areacellr” a river group, and “areacellg” a “glacial ice sheet group”. For these there are no grids specified, but within each group all variables should share a common grid. In addition, sometimes the “processing notes” will indicate the variable be reported on the “native” grid on which the variable was calculated.

We can simplify inference of the requested grid, by simply adding to the data request a descriptor identifying the “requested grid”. As noted above, we would need grid_labels possibly named native, ocean, atmosphere, river, and ice-sheet. With the “requested grid” explicitly included in the data request, there will be no need for data producers to consult the processing notes or cell_measures for this information (and of course cell_measures for area would be simply areacell, independent of medium, so the information would not be available there).

At a minimum, clear communication is needed:

Yes, I agree with both your points regarding producers and users. Thanks for making that explicit here.

Proceeding in this way will remove the somewhat disruptive change in how the global attribute external_variables and the variable attribute cell_measures are treated in this new CMIP phase, since they could no longer be required if we proceeded with a distinction between the names of different cell areas. If we don't uniformly require all models to provide cell_measures and external_variables, we introduce an unnecessary non-uniformity in the data reported by different groups, and we would make it more difficult to QA-check whether these attributes have been recorded correctly when they are included.

By the way, no need to apologize for questioning the approach; that’s how we arrive at a solution that will hopefully satisfy everyone. And thanks again for carefully considering the arguments and forging an acceptable way forward that will be consistent with what the data request needs to communicate and is consistent with the data register approach and essential downstream software. Building a consensus has always been the CMIP way, and it would be great if the data request folks would confirm that they have no substantive objections to proceeding as outlined above. I noted that I thought their objections were probably along some of the lines that initially concerned you and that now with a better understanding of the grid_label approach, they will no longer object to implementing the changes in the v1.2.3 release planned soon.

Karl

[JamesAnstey]

Here's an attempt to summarize implications of the two options for naming cell area variables:

Option 1: use "areacell" as the root name for all cell area variables

• cell_measures = "area: areacell" appears in VR and CMOR tables (which are keyed by branded variable name), and in the DR. (VR = Variable Register, DR = Data Request)
• "areacell" is used in filenames, hence the variable name doesn't indicate if the grid is used by data producers to report atmosphere, ocean, river or ice sheet variables.
• DR variables require a "requested grid" attribute to specify if modellers should provide the variable on the atmosphere, ocean, etc grid, because cell_measures no longer gives this info (since "areacell" is the variable name used for any of those grids).

Option 2: use "areacella/o/r/g" as the root name for cell area variables

• cell_measures = "area: areacella", cell_measures = "area: areacello", etc, appear in the DR, specifying if modellers should provide the variable on their chosen atmosphere, ocean, etc, grid.
• cell_measures = "area: areacella" etc don't appear in the VR and CMOR tables (which are keyed by branded variable name, excluding grid information). For CMOR users an additional CMOR function call is needed to add cell_measures, which is specified in the DR, as a variable attribute.
• "areacella", etc, is used in filenames; hence the variable name indicates if the grid is used for atmosphere, ocean, river or ice sheet variables.
• DR variables don't strictly require a "requested grid" attribute since cell_measures in most cases provides this information, though arguably it would be useful to add for clarity (e.g., not all variables specify cell_measures).

For both options:

• grid_label appears in filenames and as a global attribute, indicating the unique registered grid on which the file's data is reported. Details of implementing grid_label are discussed here.
• cell_measures is an optional netcdf variable attribute, as specified by CF
• If cell_measures is included as a netcdf variable attribute, external_variables will specify the appropriate variable name (CMOR does this automatically, tested in 3.12.0).

Option 2 is what's used in DR v1.2.2.2 (latest), v1.2.2, and previous DR releases.

Others please correct me if the above technical info is mistaken or important aspects are missing.

Then for an additional $0.02, a couple follow-on questions:

• Is it valuable for users to be able to search ESGF for atmosphere, ocean, etc cell area variables based on a distinct variable name? (areacella/o/etc)
• If users rely solely on grid_label to search for the cell area variables they need, will the grid_label implementation imply these cell areas are exactly the ones needed for their grid? (as I believe it would if grid_label is designed to facilitate automatic regridding)

[martinjuckes]

There are a number of important aspects missing from the discussion above.

(1) We have had previous assurances that we would not be making ongoing changes to the content except where needed to correct technical errors. There is no technical error here. As this is not a technical issue, but about choice of names, it does not fall within the remit of the WIP. There does appear to be some conflict with a very specific and arbitrary choice of one element of registry design, but that is easily avoidable. The fact that the distinction is not needed (referred to in Karl's first paragraph) does not imply that the distinction, which is well established, needs to be removed.

(2) The use of "o" and "a" in variable names to distinguish between ocean and atmosphere quantities is widespread in the data request. For example, there are variables such as ua/uo, va/vo, tas/tos. This is a valuable shorthand. If we want a consistent approach, this usage should be maintained.

(3) The variable names are used widely in the scientific community and no effort has been made to establish the impact of this late and disruptive change. In a parallel discussion about a proposal to rename bothsiconco and siconca as siconc there was some consultation with the community and very clear feedback that such a change would be unwelcome.

(4) We don't have a full view of how the variable names are used across the CMIP user community, which spans thousands of organisations and tens or hundreds of thousands of users. These variables are among the most widely used variables. Changing their names without consultation seems to me to be hugely irresponsible and risky. It is important to realise that these names have usage far beyond ESGF. As Karl notes, the o and a don't specify which grid a variable is on .. but they do convey important information.

(5) We have told modelling centres that there will be limited changes to the data request. This is an extensive change. There are many modelling centres which are not included in this discussion.

I really am quite shocked that a change of this scale is being made at such a late stage of a long process in which we have gone to great lengths to consult with the community.

[taylor13]

@JamesAnstey asked:

If users rely solely on grid_label to search for the cell area variables they need, will the grid_label implementation imply these cell areas are exactly the ones needed for their grid? (as I believe it would if grid_label is designed to facilitate automatic regridding)

Yes, each grid label is uniquely associated with a single grid (i.e. a single set of grid-cell locations), so if, for example, a variable is reported on the grid labeled “g42”, then with option 1, the cell area file with variable root name “areacell” and grid_label “g42” will contain the needed cell areas. The user will know what grid the variable being analyzed is reported on because its grid_label will be recorded by the global attribute grid_label in the file, and the label also is invariably included in each filename.

[martinjuckes]

I feel that we are still missing any credible explanation of why this change needs to be discussed. Karl, in the first paragraph above, says that he wishes to remove "frequency, region, and grid-specific information" from the variable registry. There is then a leap to suggesting removing the "o", "a", etc from the areacella etc variables. There is surely something missing here, because, the "o", "a" etc, as discussed above, are not providing frequency, region, or grid-specific information. (@JamesAnstey : can we make sure that the final vote text does not refer to removing grid information, but refers to realm information instead?)

"o", "a" do provide, for these variables and a great many others, information about realm. Removing realm specific information from variable names would be impossible at this stage (equivalent variables for different realms often have different standard names when they refer to physical properties rather than grid properties; hence uo and ua must have different entries). Why is there a need to remove realm information from these variables? The confusion between grid and realm runs through the above discussion and makes for a lot of ambiguity. (@JamesAnstey : can we make sure that the final vote text does not refer to removing grid information, but refers to realm information instead?)

I find it very hard to believe that we lack the technical competence to create a variable registry which supports the inclusion of the variables as defined in v1.2 of the data request. I have seen reference to the view that it is a problem to have multiple entries in the variable registry which have the same branded variable identifier. It is very unclear where this requirement comes from. It is a very odd and obscure constraint to have in a registry which is supposed to be supporting a broad community in and open and transparent process. Having different entries with different names should be trivial from a technical perspective.

While it was agreed that there should be a variable registry, it was also agreed that the registry should take and maintain variable definitions provided by the data request engagement process.

Karl notes that he has spent several hours trying to think whether this change might cause problems for users. This let me reflect that perhaps people are not aware of the background work that has created the request. Rather than trying to imagine what the community might or might not work, we engaged representatives of relevant WCRP activities and MIPs, and worked with them over a period of months to devise an approach based on broadening engagement by empowering people to take part in the request. The process was discussed openly with the panels and welcomed by the community. We found people from dozens of institutions, many different career stages, different domains of science, working in multiple time zones, and all respecting the challenging time line. The only exception has been the CV task team which has found it necessary to work outside the time line. This now leaves us in a position of not being able to consult with the people who gave their time in good faith to discuss these issues. It may well have been that the CV TT was not ready to engage on the time scale that all other parts of the extensive community. If that is the case, a little more humility about the implications of arriving late with difficult demands would be welcome. The intention in all this was to dual: firstly, to get reliable decisions across the board by asking people who are in touch with different parts of the community (the author teams that were appointed all signed up to the idea of representing the views of their communities and networks rather than sharing their own judgements). Secondly, to empower people. Making extensive changes after the conclusion of that consultation is undermining the process.

As for use cases: areacella and areacello have been used in multiple rounds of CMIP. Consistency in naming makes it easier to make comparisons across CMIP cycles (we had strong feedback from many parts of the community to avoid unnecessary changes, and this change looks very unnecessary). However, I want to emphasise that the outcome of our consultation last year strongly emphasised that we cannot reliably judge the impact of decisions through committee brainstorming. For the changes being suggested, the degree of consideration given to downstream impact is disturbingly superficial. I know that Karl sees this as a technical change, but names are important to people.

[davidhassell]

Hello, I need to ask a question, as I get my head around this:
In the event that an external cell measures file is provided, is it mandatory or optional to provide a cell_measure and external_variables attributes that point to it?

[davidhassell]

(having a bad typing time - here it is again, slight edited)

Hello, I need to ask a question, as I get my head around this:

• In the event that an external cell measures file is provided, is it mandatory or optional to provide cell_measure and external_variables attributes that point to it?

Thanks,
David

[JamesAnstey]

• In the event that an external cell measures file is provided, is it mandatory or optional to provide cell_measure and external_variables attributes that point to it?

@davidhassell according to CF, I believe it's optional - the convention (latest release, v1.12) states:

To indicate extra information about the spatial properties of a variable’s grid cells, a cell_measures attribute may be defined for a variable.

and re. external_variables, the same section (7.2) goes on to say:

A variable referenced by cell_measures is not required to be present in the file containing the data variable. If the cell_measures variable is located in another file (an "external file"), rather than in the file where it is referenced, it must be listed in the external_variables attribute of the referencing file (Section 2.6.3).

So it seems to me that CF says 1) cell_measures is optional, and 2) if cell_measures is included and the variable it refers to isn't in the same file, then including external_variables in the file is mandatory.

[davidhassell]

Thanks, @JamesAnstey - that's very useful.

So, is it right that it's allowed for a modelling group to provide an external cell area file, but to not reference it in any way from the data variable files?

External variables were created as a space-saving device to allow CMIP6 to not repeat the cell area metadata arrays in every single file. To not state in the data files that cell areas are available externally when in fact are, would indeed not a be CF compliance issue, but it is akin to not providing cell bounds, say - allowed, but not helpful!

From a CF perspective, a referenced external file contains metadata, an unreferenced external file contains not-self-describing data - and some tooling will respect that difference.

I'm not expressing an opinion yet, but this distinction (either way) seems important to me when trying to understand the issues at stake.

[JamesAnstey]

So, is it right that it's allowed for a modelling group to provide an external cell area file, but to not reference it in any way from the data variable files?

AFAIK, CF is ok with this.

External variables were created as a space-saving device to allow CMIP6 to not repeat the cell area metadata arrays in every single file. To not state in the data files that cell areas are available externally when in fact are, would indeed not a be CF compliance issue, but it is akin to not providing cell bounds, say - allowed, but not helpful!

I agree - it seems to me that CF says can, but we're more concerned here with should - i.e., with what is most helpful to users. Since cell_measures has been previously included in CMIP netcdf files, I would presume it's useful and expected and that downstream tools may depend on it.

With grid_label uniquely identifying a grid (i.e., a given grid_label corresponds uniquely to an array of cell areas) then users can find the right cell areas as long as they know to look for a variable whose name starts with "areacell". It seems to me that providing both entry points would be helpful to users: explaining this in the guidance docs, and including cell_measures in the file.

[taylor13]

[The following text was written before seeing the 3 most recent comments, but I think it provides some background and an easy option for proceeding if we want to make cell_measures required.]

My understanding is that under either of the 2 options, cell_measures could be included at the discretion of the data provider, but would not be required for any variable. Only if cell_measures is in a file would external_variables be included (as required for CF compliance).

I think these (less than ideal) options have resulted from the fact that

1. Under option 1 (the areacell only option), modeling groups relying on CMOR (i.e., most groups) will seamlessly connect to the CMIP7 CMOR tables to generate output files fully consistent with the CMIP7 requirements. However, the remaining few groups relying on the data request alone for generating a cell_measures attribute would have to modify the information they get from the current release of the data request (DR). This would marginally complicate their writing of output files that include the cell_measures attribute. Thus, it was suggested that we should make this attribute entirely optional. Note that data providers must already include a step in ingesting the DR's cell measures information where they translate it into a cell_measures attribute because currently there are dozens of variables in the DR for which non-CF-compliant text appears in its "cell measures" text. For example there are cases where the DR's "cell measures" is specified as "::MODEL" and cases where "cell measures" is specified as "::OPT". Because of this, in preparing model output, the data provider will need to include coding that effectively includes "if statements" and translates this cell measure information into a correct and compliant cell_measures attribute.
   If option 1 is adopted and we want to eliminate the translation step entirely, a straight-forward edit of the DR airtables would transform the DR's current cell measures information into the actual cell_measures text. All that is required is to globally replace all occurrences of "areacell*" with "areacell" and "::MODEL" with "area: areacell", and finally to replace the 6 occurrences of "::OPT" with "". By doing this, the DR would be brought into full conformance with the CF conventions and in harmony with the variable register, and we could make cell_measures required. Up to now, the DR team prefers not to make this change, although others with permission to alter airtables do not see any practical obstacles to doing so.
2. Under option 2 (areacella, areacello, etc.), the groups relying on CMOR (i.e., most groups) could no longer rely on CMOR to automatically include cell_measures. In particular there would be no way to automatically build cmor tables that distinguish between the names of cell areas (because those names will not be included in the variable register for reasons discussed elsewhere). Groups relying on CMOR could write code to work around this problem, but the value and popularity of CMOR is that errors in writing CMIP output in conformance with the CMIP requirements can be minimized. Requiring work arounds will not only burden modeling groups with implementing new code into their post-processing streams, but increase the chance of errors, which I think we all would like to avoid. Thus, as in option 1, the cell_measures would be optional and it is likely that the majority of modeling groups would omit it.

In summary, to make it easy for both types of users (those relying on CMOR and those on the DR), we could adopt option 1 and we could execute the global replacements described above in the DR's cell measures information. We could then insist that the cell_measures and external_variables attributes be included in files. This seems to me to be the simplest and most straight forward path for everyone and would result in all data being fully self-describing in a standard way under the CF conventions.

[davidhassell]

Hi,

I strongly recommend that when an external cell measures variable exists, it is a requirement for it to be referenced with external_variables and cell_measures attributes from all data variable files to which it applies.

CF itself does not require us to provide cell measures, but when they do exist, why wouldn't you include the simple CF mechanism for saying "there are cell some cell measures for this data"? The purpose of CF is to connect metadata to data, and the absence of a connection gives no information as to whether that item of metadata exists but wasn't connected, or if it doesn't exist at all. Imagine if CF didn't have external variables, meaning that cell measures always had to be in the same file as the data variable, we wouldn't omit the cell_measures attribute in this case, so we shouldn't in the 100% logically equivalent case of the cell measures being allowed to exist in a different file.

As @JamesAnstey pointed out, this is the case for previous phases of CMIP, and will be useful to downstream tools for the lifetime (decades) of the files.

It has always seemed to me, in this context, that the name of a metadata variable is not in the same class as the name of an actual data variable, and hence the reason for asking my original question about optional/mandatory cell measures attributes. The ease of intercomparison is much less affected by a change to cross-referenced metadata variable name than it would be by a change in a data variable name.

Now that I've made a lot of vague and general comments, I'd like to express support for Karl's option 1, which seems to be a simplifying and unifying approach (under the assumption of mandatory cell_measures).

I've been thinking about the grid/realm question that Martin raised. I don't think it's that clear cut. The "a" in ta refers to a medium (air) that has a property (temperature). The "a" in areacella refers to a cell areas for a grid that is being used for variables defined for the atmosphere ... and possibly other realms/media. The grid itself is abstract and independent of any medium or realm. So I think it's fairly loosely defined, and losing those cell area suffixes would be no great information loss.

(Please note, that I'm sure we're all struggling with "known unknowns" on this debate, which may affect what we say. Facts, re-stated or newly presented, are always gratefully received :-))

Thanks,
David

[taylor13]

We are beginning to write "guidance" pages for data providers and users. Under option 1, I think we can provide rather simple guidance (along the lines of):

Analysis of a CMIP gridded variable often requires that the area of grid cells also be known. Commonly, for example, regridding of data must preserve the area-mean of a variable, which requires cell weights be computed from cell areas. For CMIP7, all cell areas will be named "areacell". Every CMIP file will include a unique "grid label" like "g42" (in the filename and stored as a global attribute) which will enable users to find the cell area file of interest, because the areacell files will also include the grid label.

We could also possibly indicate how this handling of cell areas differs from the CMIP6 approach (along the lines):

In CMIP6, finding the cell areas corresponding to a file of interest was more difficult. Not only was the "grid label" needed (which was unique only for output generated by a single model, not across the archive) but also the name of the model and the name of the cell area variable. All three of these had to be matched in order to obtain the cell areas of interest. With truly unique grid labels defined in CMIP7 and the use of a single variable name ("areacell") replacing the four CMIP6 names (which were "areacella", "areacello", "areacellr", and "areacellg"), we have made it easier for users to obtain the cell areas needed for their analysis.