Hi all,
A little more background about C-LAMP. C-LAMP output is being written
(rewritten?) through CMOR, so netCDF files are being produced that are
to some extent compliant with CF. I think the main problem is that
certain "standard_names" have not yet been defined, and there are some
standard_names that are incorrect. I have copied an email I sent to the
C-LAMP folks a week or two ago. It lists some of the problems I found.
(Some of you have found and commented on these same problems.)
Best regards,
Karl
Dear Forrest,
I have quickly looked over the list of your standard output fields for
C-LAMP and have a few questions/comments/suggestions:
1) You should submit your proposed new standard names to the following
CF discussion list: cf-metadata at cgd.ucar.edu. After consideration by a
broader group of individuals, the names will be approved or suggestions
for modifications will be made. I suggest, however, first that you
consider 2-6 below:
2) Different components of water vapor flux are requested as "rates" (in
units of m s-1), which is admissible, but does involve some
approximation concerning the density of water (which isn't constant).
Fluxes (expressible as kg m-2 s-1, for example) are the primitive
quantity (used by the model), and with some assumption about water
density can be converted to a rate. I recommend that such quantities as
subsurface drainage, surface runoff, rainfall, snowfall,
evapotranspiration, etc. all be expressed as fluxes. You will be able
to use available CF "standard names" and avoid petitioning for new
names. This would save both you and the "standard name" committee some
time and also make your units exact and for some of these quantities
consistent with the units required for the CMIP3 (IPCC AR4) archive at
PCMDI.
3) To avoid misunderstanding concerning the meaning of several
quantities appearing in your list of standard output, it would be good
to add notes concerning the definitions (following the example of the
CMIP3 archive; see notes in the table at:
http://www-pcmdi.llnl.gov/ipcc/standard_output.html). In particular it
will be important to specify whether quantities such as "snow depth"
(surface_snow_thickness) are the thickness averaged over 1) the entire
grid cell, 2) the land-portion of the grid cell, or 3) only the portion
of the grid cell covered by snow. For the CMIP3 standard output, we
described monthly-mean surface_snow_thickness as follows:
"this thickness when multiplied by the average area of the grid cell
covered by snow yields the time-mean snow volume. Thus, for time means,
compute as the weighted sum of thickness (averaged over the snow-covered
portion of the grid cell) divided by the sum of the weights, with the
weights equal to the area covered by snow; report as 0.0 in snow-free
regions."
Similarly, monthly mean soil_moisture_content was described as:
"water in all phases summed over all soil layers, and averaged over the
land portion of the grid cell (i.e., compute by dividing the total mass
of water contained in the soil layer of the grid cell by the land area
in the grid cell); report as "missing" or 0.0 where the land fraction is 0."
Note, that if the land fraction is either 0. or 100%, then the ambiguity
for this variable vanishes (i.e., dividing by the land area or the grid
cell area would give the same result).
4) For several variables, you request surface values, but at least in
the case of atmospheric specific humidity (SPEC_HUM or QBOT) I wonder if
that is a 2-meter quantity or a value right at the surface. You also
request SPEC_HUM_2M (Q2M) which clearly states at 2M. As I understand
it models produce the 2M value just to compare with observations, and
they use the lowest model level specific humidity to calculate latent
heat fluxes. What is SPEC_HUM (QBOT) used for?
5) To be consistent with the CF conventions, all variables evaluated at
2-meters above the surface should not include this location within the
CF convention "standard_name" (i.e, the standard_name for 2m air
temperature should be simply "temperature", not
"surface_air_temperature_at_2m"). The quantity measured is temperature
and the location should be stored in CF as a "scalar coordinate" using
the "coordinates attribute" (see:
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html#scalar_coords)
Note that CMOR can be made to automatically store this information
consistent with the CF conventions.
6) You should double check your standard names for consistency with:
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/standard_name.html
Note, for example, that for "GROUND" you list the standard name,
"downward_heat_flux_in_soil", but I think you want
"downward_heat_flux_at_ground_level_in_soil".
Please let me know if you have questions or if I can help out. One can
only hope that you will be rewarded by the avoidance of future problems
if you continue to pay attention to these seemingly endless details.
regards,
Karl
Curtis Covey wrote:
> Dear CF Metadata Discussion Group,
>
> The CCSM Biogeochemistry Working Group
> (www.ccsm.ucar.edu/working_groups/Biogeo) invites your comments on the
> conventions we've developed for the new Carbon-LAnd Model
> intercomparison Project (C-LAMP). To see these conventions, go to the
> C-LAMP Web site at climate.ornl.gov/bgcmip, then click on the link
> "Developing a Common Set of Output Fields for the CCSM C-LAMP."
>
> Note that C-LAMP presently involves just two or three versions of a
> single model (the CCSM). As Pierre Friedlingstein has remarked, for some
> purposes it might be considered a pilot project for the next phase of
> the larger Coupled Climate and Carbon Cycle Model Intercomparison
> Project (C4MIP). Accordingly, we do not intend to wait for a formal
> endorsement by the CF group before releasing C-LAMP output to the
> Working Group.
>
> At the same time, we welcome your suggestions on how the C-LAMP data
> conventions could be improved. I have copied this message to other
> interested parties who may not belong to the CF Metadata Discussion
> Group. Please forward to others I've missed.
>
> We looking forward to hearing from you.
>
> - Curt Covey for the CCSM BGC Working Group
>
Received on Mon Apr 30 2007 - 14:58:07 BST
