Talk:CF Standard Names - Discussed Atmospheric Chemistry and Aerosol Terms
Go back to Start page for Atmospheric Chemistry and Aerosol Names PLEASE DO NOT USE THE NAVIGATION BAR ON THE LEFT HAND SIDE!
Important issues are marked in RED , please COMMENT!
Vincent-Henri PEUCH VHP - CT - Jonathan Gregory JG - Frank Dentener FD, 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!)
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!
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- 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:
- 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:
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 - Christiane Textor (CT),June/July 2006
- 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.
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