Difference between revisions of "Talk:CF Standard Names - Discussed Atmospheric Chemistry and Aerosol Terms"

From Earth Science Information Partners (ESIP)
Line 9: Line 9:
 
<br>
 
<br>
 
=NOy=
 
=NOy=
'''Vincent-Henri PEUCH VHP - CT - Jonathan Gregory JG - Frank Dentener FD, June/July 2006'''
+
'''Vincent-Henri PEUCH VHP - CT - Jonathan Gregory JG - Frank Dentener FD - David Stevenson DS, June/July 2006'''
 
:* there is always the problem that "NOy" has no fully agreed definition in the literature... It is perhaps unwise to use it in the name? Could we use "total_nitrogen_oxides" instead?  
 
:* there is always the problem that "NOy" has no fully agreed definition in the literature... It is perhaps unwise to use it in the name? Could we use "total_nitrogen_oxides" instead?  
 
::''(JG))I think it's a good idea to avoid the word "total" if we can, as it is not always obvious what aspect is being totalled! total_nitrogen_oxides is probably clear enough, but maybe all_nitrogen_oxides might be better?  
 
::''(JG))I think it's a good idea to avoid the word "total" if we can, as it is not always obvious what aspect is being totalled! total_nitrogen_oxides is probably clear enough, but maybe all_nitrogen_oxides might be better?  
Line 18: Line 18:
 
::explanation: volume mixing ratio of nitrogen oxides NOy, i.e., sum of moles_fractions of all simulated oxidized nitrogen species, (NO, NO2, HNO3, NO3aerosol, N2O5, NO3(radical), HNO4, PAN, other organic nitrates) (N2O5 is only counted once!)
 
::explanation: volume mixing ratio of nitrogen oxides NOy, i.e., sum of moles_fractions of all simulated oxidized nitrogen species, (NO, NO2, HNO3, NO3aerosol, N2O5, NO3(radical), HNO4, PAN, other organic nitrates) (N2O5 is only counted once!)
 
:''(CT) Another difficulty arises from N2O5, that contains to N atmos. Frank wrote 2*N2O5 in his definition, but if we count in mole or kg - not kgN!, this is not correct. Therefore, I have added (N2O5 is only counted once!)
 
:''(CT) Another difficulty arises from N2O5, that contains to N atmos. Frank wrote 2*N2O5 in his definition, but if we count in mole or kg - not kgN!, this is not correct. Therefore, I have added (N2O5 is only counted once!)
 +
:''(DS) Follow Frank's definition, this is widely used. This is valid for all species expressed as mole fractions (or volume mixing ratios). This is the most common usage in atmospheric chemistry.
  
 
=Tropopause definition - tropospheric column of gas phase species=
 
=Tropopause definition - tropospheric column of gas phase species=

Revision as of 08:23, July 10, 2006

Go back to Start page for Atmospheric Chemistry and Aerosol Names PLEASE DO NOT USE THE NAVIGATION BAR ON THE LEFT HAND SIDE!

Go to Agreed Items of Discussion on Proposed Atmospheric Chemistry and Aerosol Terms.

---

Important issues are marked in RED , please COMMENT!


NOy

Vincent-Henri PEUCH VHP - CT - Jonathan Gregory JG - Frank Dentener FD - David Stevenson DS, June/July 2006

  • there is always the problem that "NOy" has no fully agreed definition in the literature... It is perhaps unwise to use it in the name? Could we use "total_nitrogen_oxides" instead?
(JG))I think it's a good idea to avoid the word "total" if we can, as it is not always obvious what aspect is being totalled! total_nitrogen_oxides is probably clear enough, but maybe all_nitrogen_oxides might be better?
(CT) But what does 'all' include? anyway, I changed it.
(FD) NOy it is a matter of defining accurately. Total Nitrogen is a very confusing term, in biological applications it may mean something completely different. NOy=NO+NO2+HNO3+NO3aerosol+2 N2O5 + NO3(radical) + HNO4 + PAN + other organic nitrates.
(CT) some models might not have all these species, I define it now as:
standard_name: atmosphere_mole_fraction_of_all_nitrogen_oxides
explanation: volume mixing ratio of nitrogen oxides NOy, i.e., sum of moles_fractions of all simulated oxidized nitrogen species, (NO, NO2, HNO3, NO3aerosol, N2O5, NO3(radical), HNO4, PAN, other organic nitrates) (N2O5 is only counted once!)
(CT) Another difficulty arises from N2O5, that contains to N atmos. Frank wrote 2*N2O5 in his definition, but if we count in mole or kg - not kgN!, this is not correct. Therefore, I have added (N2O5 is only counted once!)
(DS) Follow Frank's definition, this is widely used. This is valid for all species expressed as mole fractions (or volume mixing ratios). This is the most common usage in atmospheric chemistry.

Tropopause definition - tropospheric column of gas phase species

Christiane Textor CT - Jonathan Gregory JG, June/July 2006

  • JG: You have a number of names of the form up_to_chemical_tropopause_content_of_X_in_air. This order is rather unnatural, I'd say. Also in_air probably isn't right, as here you mean a large-scale quantity. I know that we discussed whether "atmosphere" goes at the start or the end, and I remarked it usually was at the start, but a complete phrase is more awkward at the start. Would you consider X_content_of_chemical_troposphere or X_content_of_atmosphere_below_chemical_tropopause?
CT: I have put in_air because satellites only see the fraction in the gas phase, so atmosphere is not correct. below_chemical_tropopause sounds good. This would lead to X_mole_content_below_chemical_tropopause_in_air or X_mole_content_in_air_below_chemical_tropopause. What do you think?
JG: X_mole_content_in_air_below_chemical_tropopause is fine
CT: tropopause not yet defined!

VHP: troposphere_content

Vincent-Henri PEUCH VHP - CT, June/July 2006

The description of the "troposphere_content*" variables is not enough detailed because it is indeed verticaly integrated, but up to the tropopause only. We can specify in the explanation "up to the tropopause level", but we probably also have to specify the tropopause definition to be used (2PVU,380K ?) as the value is quite sensitive to the specific criterion used (for species with strong vertical gradients at the tropopause like ozone). A drawback of specifying is that any other type of hypotheses (other "tropopause" definition : 150 ppb of ozone, 100 hPa,...) or other ways of computation (specific tracer in the model) would then no longer fit with the name. I don't know the solution...
CT: The 150ppb O3 isosurface is a good measure for atmospheric chemsitry problems and has been used in ACCENT/PHOTOCOMP.

CT: Several tropopause definitions exist

CT, June/July 2006

- chemical tropopause (150 ppb O3 isosurface)
- lapse rate tropopause (the lowest level at which the lapse rate decreases to 2 °C/km or less,
provided that the average lapse rate between this level and all higher levels within 2 km does not exceed 2 °C/km. WMO definition of Tropopause)
- potential vorticity (PVU2 (at the 2 PVU surface) or PVU1.5 (at the 1.5 PVU surface))
- potential temperature surface

JG: tropopause_defined_by_...

JG- CT, June/July 2006

If you need to distinguish different definitions of the tropopause, this could be done by defining different standard names. This issue is rather like the definition of the ocean mixed layer, for which we have several standard names:
ocean_mixed_layer_thickness_defined_by_mixing_scheme
ocean_mixed_layer_thickness_defined_by_sigma_t
ocean_mixed_layer_thickness_defined_by_sigma_theta
ocean_mixed_layer_thickness_defined_by_temperature
If there are particular numbers which are needed for the definition (like your 150 ppb O3) they could be specified as standard name parameters (but we still haven't agreed the mechanism for this!).
CT: This would then give X_mole_content_in_air_below_tropopause_defined_by_150ppv_O3_iso_surface.
JG: For X_mole_content_in_air_below_tropopause_defined_by_150ppv_O3_iso_surface: I was thinking it is better avoid putting "parameter" like 150 ppb in the name. When it is necessary to record such parameters to define a standard name, we should use some other attribute. This has come up before and I refer to them as "standard name parameters" but we have not decided how it should be done! For instance, it could be a new attribute, or it could be a scalar coordinate variable. This needs to be debated. I think a generic name such as X_mole_content_in_air_below_tropopause_defined_by_ozone_mole_fraction would be all right, and we could mention the 150 ppb in the definition (for the moment).
CT: X_mole_content_in_air_below_tropopause_defined_by_ozone_mole_fraction is the new name so far, but the tropopause definition is still not agreed on, it could be:
tropopause_defined_by_ozone_mole_fraction
tropopause_defined_by_temperature_lapse_rate
tropopause_defined_by_potential_vorticity
tropopause_defined_by_potential_temperature

VHP: mole_fraction_of_ozone_from_stratosphere_in troposphere

VHP-JG, June/July 2006

The variable "mole_fraction_of_ozone_from_stratosphere_in troposphere" is a modeler's concept, with no chance of being measured. The way it is implemented in a model has an impact on the actual values, due to non linearities etc... I would not be in favor of including it as a standard variable. What do you think?
JG "The variable mole_fraction_of_ozone_from_stratosphere_in troposphere is a modeler's concept." Yes, that is true, but if modellers want to store this quantity, and compare it among models, then it should be given a standard name. There are many quantities like this, which aren't really observable. To begin with CF was designed for models, rather than the real world!

Construction of deposition flux names

Jonathan Gregory - Christiane Textor (CT), June/July 2006

  • I would suggest that due_to_turbulence comes after of_X, because there could be a quantity dry_deposition_flux_of_X, of which dry_deposition_flux_of_X_due_to_turbulence is a part.
(CT) It is :dry_deposition_mole_flux_of_X=dry_deposition_mole_flux_of_X_due_to_turbulence+dry_deposition_mole_flux_of_X_due_to_sedimentation, so I would rather like to leave the due_to_turbulence and due_to_sedimentation close to deposition, so I would like to change it to dry_deposition_mole_flux_of_X=dry_deposition_due_to_turbulence_mole_flux_of_X+dry_deposition_due_to_sedimentation_mole_flux_of_X, ok?

Grid box area

Jonathan Gregory JG - Christiane Textor CT - Martin Schultz MS,June/July 2006

JG: Do you have a data variable containing area? If the only purpose of this is to provide weights, you can use cell_measures to supply the area variable (CF 7.2). However if you do have them as data variables, I agree you need a standard name. I'd suggest surface_area. I think this is really the quantity, isn't it. It is analogous to sea_ice_area (m2), for example. These are extensive quantities in space; they implicitly depend on the size of the grid box.

CT: I reread the CF documentation yesterday and realized the possibility of using the cell methods for the grid information, sorry for that. We do not need an additional standard_name.

MS: I am not convinced that this is a good decision. In atmospheric chemistry, the term "surface area" is much more common for "surface_area_of_leaves" (i.e. for calculating biogenic emissions), or "aerosol_surface_area" (i.e. for computing heterogeneous reaction rates). I think that the term gridbox_area is much more clear in describing what the variable contains. A really detailed standard name might be "gridbox_surface_area".

total atmospheric columns

VHP - CT, June/July 2006

VHP: we could add, for ozone at least, "total_atmosphere_content_of_*_in_air" (in Dobson units for ozone, mol/m2 for others if needed).

CT: I have added "atmosphere_content_of_*_in_air" in mole/m2. total_ is not necessary, this is already included in atmospere if there is no other specification. Dobson units are not possible within the concept of CF which is based on UDUNITS, see also the discussion on units.


lasjdflaksd;lkmadfslkj Dear Christiane and Martin

I agree with Christiane's comments.


>> 3) the non-existance of suitable evaluation tools: >> There are tools existing

In particular there is the CF-checker, which verifies conformance to the standard in a "syntactic" sense, as specified by the conformance document http://www.cgd.ucar.edu/cms/eaton/cf-metadata/conformance-req.html There is also the CMOR F90 library written by PCMDI to help people write CF-compliant netCDF more easily.


>> 5) I agree that the averaging of "amount" variables could be a problem -

This problem comes up with other amount variables too, like precipitation. One solution could be to recognise that if you are averaging them, you are maybe treating them as a rate, not an amount. Hence the standard name should be the one of rate, not amount. The unit does not have to be kg m-2 s-1. It could be kg m-2 day-1, for instance. Although udunits allows "month" we don't recommend it because its definition is not a calendar month but a particular (constant) number of seconds - probably not what you want. But the time bounds of the variable should always indicate the meaning period.

With both rates and amounts, climatological time bounds may help as well, with which you can record that it is (for instance) the January mean over a number of years (see CF 7.4). I hope that tools such as nco may be extended to produce the cell_methods attribute to describe this, since CF is becoming quite important; in fact we could request such an extension.


>> (1) a certain software tool requires the ordering of levels from top to >> bottom, and thus you need a small program to reverse the order of the >> hybrid coefficients and all model fields. Since you are under pressure >> to deliver results, you will not worry about the attributes, and >> immediately your "direction:up" will be wrong. The file is still a >> "good" file

positive is not affected by the ordering of the coordinates. It indicates only whether larger or smaller values mean up or down.


>> (a) try to keep it simple, (b) avoid redundancies

Both of these are principles of CF. See http://www.cgd.ucar.edu/cms/eaton/cf-metadata/clivar_article.pdf

>> (c) differentiate between tags for autmated processing and >> tags for human information

We try to provide both at once i.e. metadata which is precise for programs but also intelligible to humans. This minimises redundancy.


>> (d) provide very clear guidelines as to when >> a file is CF compliant and which standards are mandatory and which are >> optional

There is only kind of compliance defined at present, because most features of CF (beyond COARDS) are optional, for backward compatibility. But in a particular application or project you could of course insist on certain features or choices within the standard.

Thanks for your comments. Best wishes

Jonathan