Dear All,
I don't agree with Martin and Philip.
>
> Dear Stephen, Martin, et al.
>
> I generally agree with Martin.
>
> I will say, though, that the "two table approach" (or alternatively:
> "a two orthogonal vector approach") is particularly clean for
> chemistry. In particular:
What do you mean with 'orthogonal' ?
>
> a) I cannot think of any "matrix elements" of quantity_for_species_X
> which would be undefined (although they may be negligibly small).
Please see:
http://wiki.esipfed.org/index.php/CF_Standard_Names_-_Construction_of_Atmospheric_Chemistry_and_Aerosol_Terms
by Christiane Textor, Michael Schulz and Olivier Boucher.
If you look through the 'Fluxes' list some quantities contain a X, G and
A. This looks for me that some fluxes
are only useful for gases and aerosols.
>
> b) The list of species can then be easily be extended, even for
> applications that were not originally envisioned.
>
> c) The units for the second vector (species) will all be identical.
>
> d) If a "single vector" approach for CF standard names is retained,
> then when multiple intercomparison projects submit their "two vectors"
> there will be "gaps" in the combined set. For example, if project1
> submits the matrix formed by the sets {quantities1} and {species1},
That was not my idea. The project has to submit the quantities. The
species1 could be any of SMILES, IUPAC or CAS lists.
The IUPAC_system... should be proposed as a standard name to make the
naming of the species unique. CF could build up a
list see Christane's list above but the others should be used too.
example:
dimensions:
lat=72;
lon=124;
maxlen=30;
float quantity(lat,lon,height,time) ;
quantity:standard_name = "mass_fraction_of_constituent_in_air" ;
quantity:units = "1" ;
quantity:coordinates = "constituent" ;
char constituent(maxlen);
constituent:standard_name='IUPAC_system';
data:
constituent='ozone';
> and project2 submits the matrix formed by {quantities2} and
> {species2}, then there will be names that are undefined in the matrix
> formed by {quantities1 UNION quantities2} and {species1 UNION
> species2}. Thus, with a "single vector" approach, subsequent projects
> will have to search the full standard name list for every "matrix
> element" to see whether it is defined, even if the quantity and specie
> are already recognized, and then submit those orphan names to the CF
> list.
>
> e) The two vector approach will significantly reduce the burden of
> dealing with new standard name requests to this list (based on the
> arguments above).
>
This could not happen. See example. The quantities and species are
independent.
> In summary, I understand the desirability of maintaining a single
> "flat" list. I also understand that allowing multiple attributes would
> cause a lot of problems in general (as Martin indicated).
>
> However, is there a middle way, in which limited exceptions can be
> made in cases where the good strongly outweighs bad, eg could a
> limited exception be made for chemical names?
I think the middle way is to go on as yet but to build up a new system
as soon as possible.
>
> Yours truly,
>
> Philip
>
> On Tue, 14 Oct 2008, Schultz, Martin wrote:
>
>> Dear Stephen (Pascoe) and all,
>>
>> thanks for your comment. You are certainly right that no one wants to
>> push 4500*physical parameters standard names. BUT: I am concerned
>> that your proposal to adopt CF (the "climate and forecasting"
>> convention) to the kinetics community might really cross a border. It
>> is my understanding that CF is tailored to Earth System Models, and
>> they will unlikely ever see 4500 chemical compounds (we are lucky if
>> they include more than 4 at this stage).
I am not specialist but the estimations are between 4 and 4500. If I
look at Martina's and Christiane's list
4 seems not to be realistic. If I look in our database we have for
example the hammoz model.
http://www.mpimet.mpg.de/en/wissenschaft/modelle/mpiom/mpiom-description.html
There are more than 4 species.
>> Of course it might be an advantage if a potential standard in the
>> kinetics community would share many concepts and terms with CF, but I
>> don't think that CF itself is the right place for this.
>>
>> It seems to me like the real issue at hand is the decision whether or
>> not to include the compound name explicitely in the standard name or
>> not. Frankly, from my perspective, it would be the opposite from
>> Stephen's: if we have to go to other attributes, I fear that things
>> become so complicated that no one will use CF.
I like to say it in Jonathan's words:
"We decided on the CF approach because it is more general and it reduces the
size of the standard name table by "factorising" the information. We could
have taken this approach further and made the standard name table more
hierarchical. The approach we have followed is a middle way, I think, which
splits off specifications of the values of continuously variable parameters
(such as height), and attributes which could be combined with *any* standard
name (such as the indication of a time-mean)."
and
"* Make the program cleverer which reads the data. I would guess it is
not very
hard to offer the user a menu of quantities defined as bundles of metadata
specifications such as tas or Heinke's indices, and then search for these
combinations. It would also not be difficult to scan a dataset against the
definitions of the bundles in order to display its contents in these terms."
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001654.html
I agree with Jonathan.
We have had the splitting discussion with the 2 meter air temperature.
The users want this in one term. We were working on a solution in track #24.
I hope that the 'common concept' will help us to be more user friendly.
>> Then again, there is some virtue in the "two table approach" that
>> Martin Suttie has brought into the GRIB2 proposal. BUT, as things
>> have developed in CF I fear this is a fundamentally different
>> approach. Why should there be two atributes for chemistry but not for
>> other quantities?
I gave an example in my email:
"The splitting could be done like the area_fraction with a coordinate
variable or scalar coordinate variable."
>> Shouldn't the concept of "change_of_X_due_to_Y" then also apply to,
>> say temperature, salinity and others?
No, see example above only if they are in the list for example:
'IUPAC_system
>>
>> Best regards,
>>
>> Martin Schultz
>>
>> < Dr. Martin G. Schultz, ICG-2, Forschungszentrum J?lich >
>> < D-52425 J?lich, Germany >
>> < ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131 >
>> < email: m.schultz at fz-juelich.de >
>> < web: http:// www. fz-juelich.de/icg/icg-2/m_schultz >
>>
>>
>> -------------------------------------------------------------------
>> -------------------------------------------------------------------
>> Forschungszentrum J?lich GmbH
>> 52425 J?lich
>>
>> Sitz der Gesellschaft: J?lich
>> Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498
>> Vorsitzende des Aufsichtsrats: MinDir'in B?rbel Brumme-Bothe
>> Gesch?ftsf?hrung: Prof. Dr. Achim Bachem (Vorsitzender),
>> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
>> Dr. Sebastian M. Schmidt
>> -------------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
> ------------------------------------------------------------------------
> Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division
> pjc at llnl.gov Lawrence Livermore National Laboratory
> +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Best regards
Heinke
Received on Mon Oct 20 2008 - 02:51:37 BST
