search

ESCOMP / CTSM

Community Terrestrial Systems Model (includes the Community Land Model of CESM)
http://www.cesm.ucar.edu/models/cesm2.0/land/
Other
308 stars 311 forks source link

Prototype analysis scripts using landunit_mask metadata to create regional / global averages #1345

Open billsacks opened 3 years ago

billsacks commented 3 years ago

We'd like to start playing around with tools that use the landunit_mask metadata (on history fields for which it is already available) together with PCT_LANDUNIT to create correct regional / global averages. Part of the purpose of this prototyping is to see if the current metadata format works well enough for this purpose.

wwieder commented 3 years ago

I also assigned @negin513 to this. Although it's unlikely to come up in NEON analyses, it may come into larger analysis efforts.

billsacks commented 3 years ago

@klindsay28 made the following comment in #1297

Have you considered using the CF convention attribute cell_measures?

In the hypothetical example of

Consider a grid cell that is 1/2 natural veg and 1/2 lake, and a diagnostic field that is only calculated over vegetated columns. If the value of this variable is 10 in the vegetated column, what should its grid cell average be: 10? 5?

could you average only over the vegetated area, and provide a cell_measures attribute that points to a variable that contains vegetated area?

There is a admittedly a chicken and egg problem of using this attribute in output and updating analysis workflows to take this into account.

I think it would be best to consider that comment in the context of this issue: The people working on writing prototype analysis scripts are in the best position to weigh in on how exactly the metadata should be represented in the model. So I'd like to task the assignees of this issue with coming up with a recommendation for attribute and variable names giving these metadata. It should be pretty easy to then change the CTSM code to implement these recommendations (as long as they aren't too different from what we're currently doing).

It would be relatively easy, for example, to output a set of named variables in place of the current PCT_LANDUNIT array (PCT_NATVEG, PCT_CROP, etc.) – and actually, that could be more useful in general. @klindsay28's suggestion goes further than that, if I understand it correctly, and what I'm not sure of is whether we want to go all the way there: I think that using the cell_measures attribute would probably entail having a field for each possible landunit_mask giving the total area of each grid cell represented by that mask. For example, for landunit_mask='veg', I think we'd want a field giving area*landfrac*(%natveg + %crop)/(100%). This would require adding some new, derived fields to output files on at least an annual time step.