Difference between revisions of "Talk:Air Quality/Chemistry Naming Conventions"

From Earth Science Information Partners (ESIP)
Line 1: Line 1:
Go back to [http://wiki.esipfed.org/index.php/Air_Quality/Chemistry_Naming_Conventions Start page for Atmospheric Chemistry and Aerosol Names] PLEASE DO NOT USE THE NAVIGATION BAR ON THE LEFT HAND SIDE!
+
{{CF-links}}
  
 
Go to [[Agreed_Items_Air_Quality/Chemistry_Naming_Convention|Agreed Items of Discussion on Air_Quality/Chemistry_Naming_Conventions - General ]].
 
Go to [[Agreed_Items_Air_Quality/Chemistry_Naming_Convention|Agreed Items of Discussion on Air_Quality/Chemistry_Naming_Conventions - General ]].

Revision as of 04:25, July 11, 2006

Return 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 Air_Quality/Chemistry_Naming_Conventions - General .


Martin Schultz playing the devil's advocate

Hi,

very good! It is becoming more and more clear to me that a lot of systematic thinking already went into the CF standards (and certainly Jonathan deserves a lot of credit for this). Yet, I am still a bit sceptical whether this can really get acceptance by the large community if they need to adapt so thoroughly and get rid of many old habits and custom units. Microsoft also made ist fortune by challenging the customer with small changes at a time and sacrificing the perfect system for a better chance to drag the crowd along. Translated to our problem at present, I am still wondering if it wouldn't be better to define some non-udunits "interim standards" just to keep people happy. And if they swallow the first bite and implement CF in their models and tools, one can then in a few years time work on making the system more stringent. My concern is also related to the non-existance of suitable evaluation tools which will make good use of all th enice attributes and standard names. More and more I get the impression that we are trying to model too many semantic sophistication into the definitions, which makes it practically impossible to project onto a software code as the complexity of this code must be quite large from the start. Yet another concern is my experience with improper netcdf files. Every error that can be made will be made at some point, and if we rely too much on the meaning of attributes, we are certain to get garbage results quite soon. One can of course implement some checking for consistency etc., but I see it as highly improbably that one will be able to catch all errors, and the system is becoming complex enough that it will be difficult to diagnose an error and correct it. Just two simple examples of what can easily go wrong:

(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 in the sense that the plotting software can read it and will always display the correct information for a chosen level. Yet, if you want to take advantage of the "direction" attribute, you will be mislead.

(2) assume you have a set of files with accumulated deposition fluxes ("amount" according to the new proposal). For a multi-year average of monthly values, you could for example use ncea from the NCO tools. Hardly anyone will afterwards think about a necessary adaptation of the standard name or cell_methods field (and how would you write this? "mean_of_sum"? impossible for any plotting program to"understand this!).

OK: my message is: (a) try to keep it simple, (b) avoid redundancies, (c) differentiate between tags for autmated processing and tags for human information, (d) provide very clear guidelines as to when a file is CF compliant and which standards are mandatory and which are optional (perhaps one should think about multiple "compliance levels"? level 0 would be the bony basics, level 1 would fulfill a certain set of elements necessary for standard automated processing, level 2 would include all tags amenable for automated processing, and level 3 includes correct tags for human information.

Don't misunderstand me, please! I am very much interested in seeing this happen (else I wouldnt reply at all). I am only playing the devil's advocate here.

Best regards,

Martin

Martin Schultz 4 July 2006 (EDT)


Christiane Textor's answer

Hi,

just a short answer:

1) "interim standard" cannot be called "standard" anymore, we should not create confusion.

2) we do not only ask people to do additional work, but also offer a lot of service to them when we analyse their models, this might also make them happy.

3) the non-existance of suitable evaluation tools: There are tools existing: I am in contact with people from PCMDI and will probably be able to provide some routines to map standard_names with variable names to be used in the existing analysis tools (like IDL).

4) I fully agree on the statement "Every error that can be made will be made at some point". But it is independant from the CF conventions, in contrast, CF helps to minimize errors. Of course other tools, like Automod, would do some basic checks if the data are ok (e.g. for the vertical achsis it is enought to check if the pressure is decreasing with height).

5) I agree that the averaging of "amount" variables could be a problem - but it would not help much to include the time period in the unit (e.g. kg/m2/month). A solution would be to include the averaging period in the variable name.

6) keep it simple: a very good idea. but levels of compliance do not seem very simple to me...

In summary, I think there should be only one standard. The CF names have to goal to be as clear as possible to avoid mistakes, and I feel that our virtual working group is very efficient in fulfilling these requirements: Thanks to you all.

Best regards, Christiane

Christiane Textor 4 July 2006 (EDT)


Comments of Jonathan Gregory

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

Jonathan Gregory 5 July 2006 (EDT)

Mail to Jonathan on July 10th, Christiane Textor

Dear Jonathan,

I have several questions and would be glad if you could help. Thank you very much in advance!!

IN_AIR
The mole_fraction and mass_fractions for the chemical gases in air are related to humid air. I have only defined _in_air, which from my understanding would mean 'in air what ever it contains, i.e. humid air' But it is this clear enough or do we need to have in_dry_air and in_humid_air?

EMISSIONS
I have defined surface_ and atmosphere_ emissions, e.g. surface_emission_mole_flux_of_ozone mole/m2/s atmosphere_emission_mole_flux_of_ozone mole/m3/s Is it allowed to have a flux per m3?

CMOR
You mentioned this software for the creation of CF conform netCDF files. However, I cannot download it from the PCMDI site, and Karl Taylor does not answer his emails. Can you help us?

CF-COMPLIANCE CHECKER
After discussion with HTAP people, Martin Schultz in particular, I feel that it would be nice, if the compliance checker could be more informative. It would be helpful to obtain more information on why compliance is not reached. Is this possible? In addition, the web site http://titania.badc.rl.ac.uk/cgi-bin/cf-checker.pl does not respond today, could you please have a look?

CF HOME PAGE AND DOCUMENTATION
It would be good to have a very simple and short summary of what the main objectives of CF and what CF-compliance means. The documents provided on line are not that easy to understand, and there are many of them, I found 6 relevant links, see http://wiki.esipfed.org/index.php/Air_Quality/Chemistry_Naming_Resources Would it be possible to have one simple and short version for CF-beginners? I have still some questions, for example in section 4 of the http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-current.html document, no standard_names are given, instead long_names are used. Do I misunderstand something?

NOy all_nitrogen_oxides
I have defined it as

standard_name: "atmosphere_mole_fraction_of_all_nitrogen_oxides"
explanation: " volume mixing ratio of all simulated nitrogen oxides NOy, i.e., sum of moles_fractions of all simulated oxidized nitrogen species, out of NO, NO2, HNO3, NO3aerosol, N2O5, NO3(radical), HNO4, PAN, other organic nitrates (N2O5 is only counted once!)"
unit: "1=mole/mole"

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!) Is this ok?

AMOUNT
You have anwered to Martin's mail some days ago concerning the "the averaging of "amount" variables":

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.

But a quantity with a unit of kg m-2 day-1 is a flux rather than a rate which would have kg/day? See also http://wiki.esipfed.org/index.php/CF_Standard_Names_-_Future_Atmospheric_Chemistry_and_Aerosol_Terms#Table_1:_Components_to_construct_full_CF_standard_names and there the chemical_production and chemical_production_rate...

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.

nco is essential for us! As it is not yet existing I think we should define specific variables, however, I do not know how at the moment. Could it be e.g.

surface_dry_deposition_due_to_turbulence_mole_monthly_flux_of_sulfur_dioxide
surface_dry_deposition_due_to_turbulence_mole_amount_of_sulfur_dioxide using the cell method? or what else?

And do we finally need an extra variable for the grid-box area? is nco able to understand the CF information on the grid, including the vertical axis? If not, we definitely need extra variables, or a very fast extension of nco....

This was it for today - a lot! thank you very much for your help!!

I updated the wiki page, and included most of our email discussion, I hope this is fine with you.

Best regards, Christiane