Re: [CF-metadata] CF region_names

[Schultz, Martin]

Dear all,

 what is this thing about region_names? I only now saw this popping up and 
must say that I strongly object to adopt these as a standard. Region 
definitions are so manifold and depend very much on individual applications 
that I don't see any value in adopting one set of names (here GCMD) and call 
them "CF region names". In my view this runs completely against what I conceive 
as the CF philosophy which is trying to be broad and encompass many application 
areas.

Not only are the names of the regions under dispute, but even more so any 
definition of their boundaries. For example: for a lake area such as 
"caspian_sea", do you follow the lake boundaries (and if so in which year?) or 
do you mean the catchment area including all rivers running into it, or are you 
referring to a lon/lat rectangle?

I have no problem with a concept that is called "gcmd_regions", for 
example, if it is detailed somewhere where these definitions come from and how 
the boundaries are defined. Note that there are indeed various other 
"prominent" region definitions, for example 6(+1) world regions by WMO, see 
https://www.wmo.int/pages/members/index_en.html, or the WMO code table 0161 
specifying oceanic areas. But even then, I don't think that this belongs in the 
CF domain, but instead should be dealt with elsewhere. What CF can do in my 
opinion is to define suitable attributes how a region (code) and its underlying 
definition can be provided.

Best regards,

Martin





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] provisional status for changes to the convention

[Schultz, Martin]

John,

   indeed I would consider it as "RFC" version, i.e. a non-released 
specification. People can try to build datasets/services with this new 
specification and report problems back, but it would be clear that the 
pre-release might still change and some software might have to be adapted again 
after final release. I don't see a reason why this modern software approach 
shouldn't work for a text document that deals with a data convention.

Cheers,

Martin


Message: 3
Date: Wed, 4 Feb 2015 11:48:12 -0800
From: John Graybeal 
To: CF Metadata List 
Subject: Re: [CF-metadata] provisional status for changes to the
convention  (Jonathan Gregory)
Message-ID: <3f21050a-5f12-4699-beb9-dca93c7b3...@mindspring.com>
Content-Type: text/plain; charset=us-ascii

Jonathan, thank you for your considered update. If we 'deprecate' a released 
version that has an error, presumably this just means it is no longer 
recommended for use? I assume data sets released with the flawed version 
shouldn't have to be re-released, if the flaw did not affect them.

And I'm assuming any time a new CF version is released, it is considered the 
recommended version, and all CF users are encouraged to use it as they write 
new data sets. But I don't know that I've read that anywhere.

Martin, can you be specific about how reverting changes is less confusing when 
those changes are in provisional versions, than when they are in plain old 
released versions?  Given your variants, perhaps we interpret 'provisional' 
differently? I understand it to be a released specification, usable but somehow 
not fully final/reliable. Perhaps your model would define it as an unreleased 
specification, versioned but not yet approved for use, which I agree is 
consistent with modern software practices.

John





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] provisional status for changes to the convention (Jonathan Gregory)

[Schultz, Martin]

Dear Jonathan, all,

we have had this discussion about provisional status earlier, and I 
remember having received quite a bit of support for a proposal to have a 
provisional status with a fixed lifetime. I still believe this would be better 
than having to revert changes and create confusing new document versions. I 
don't know what can be implemented (easily) in GitHub, but I think there are 
various ways which don't differ too much in what they accomplish, and one of 
them is hopefully both acceptable and easy to implement:
Variant A) introduce a fixed publication cycle for the convention, e.g. every 6 
or 12 months with a "moratorium period" of, say 3 months, before publication. 
This means that changes are only accepted up to 3 months prior to the next 
publication, so there is a 3 months period for testing and commenting/reverting 
changes. New changes would go into the next cycle only. This scheme is adopted 
from software releases ("release candidate").
Variant B) add date label to all changes and automatically accept them after a 
fixed period (say 6 months) unless these changes were edited/reverted again in 
the meantime (then, the date label should be changed to the last modification).
Variant C) establish a "review panel" to go over modifications on a 
semi-regular cycle and accept everything that has not been questioned recently. 
This may sound more personnel-intensive than the other two options, but I would 
guess that in reality the difference will be marginal if the review panel is 
kept small.

Best regards,

Martin


In reply to:
Date: Wed, 4 Feb 2015 14:11:33 +
From: Jonathan Gregory 
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] provisional status for changes to the
convention
Message-ID: <20150204141133.ga5...@met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii

Dear John

Thanks for your posting. I have changed the subject so as not to mix it up
with the discussion about the format for maintaining the document.

The rules expect that a test file is provided to accompany a change to the
conventions, but this has rarely or never been done in practice. We could
improve the procedure by insisting on this, when it's relevant.

I agree with you that provisional status has a cost in complication and has
not given a benefit. The idea of provisional status is that it should be easy
to reverse provisional changes, I suppose, but we have not written down how
this would be done in practice, because we've not needed to. Therefore I would
be happy if we abolished provisional status. That means if a change is found
to be wrong, it would have to be reversed by opening a new ticket.

Perhaps we could make a new procedure to help with this, should it ever be
needed. If a ticket is agreed to reverse a previous change which was found
to be wrong, it could mean that a new version of the convention is released
straight away, with the error corrected, so that it doesn't have to wait to
go live, and that the current and any other versions of the convention which
contain the erroneous change would then be deprecated.

Best wishes

Jonathan





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] HTAP2 last revisions

[Schultz, Martin]

Dear Alison,

 great overview! Thanks very much for this. I am happy with all of your 
suggestions, so you can count my vote if needed.

Concerning the "resistance" terminology: This refers to a resistance model 
approach for which a paper by Wesely, 1989 (Atmos. Env., 23/6) is widely 
referred to. This paper talks about "surface resistances" and explicitly 
mentions "aerodynamic resistance", "quasilaminar sublayer resistance", and 
"bulk surface resistance", the latter being composed of various terms, among 
them a term for "stomatal resistance". Explicit reference is made to Ohm's law 
as analogy, and this concept is widely known in the community. I would hence 
argue in favour of keeping the word resistance in these terms.

With best regards,

Martin


Message: 2
Date: Fri, 21 Nov 2014 12:18:34 +
From: 
To: 
Cc: frank.dente...@jrc.ec.europa.eu, michael.sch...@lsce.ipsl.fr
Subject: Re: [CF-metadata] HTAP2 last revisions
Message-ID:
<014539ac4976be4490a360410a8c2017792a8...@exchmbx03.fed.cclrc.ac.uk>
Content-Type: text/plain; charset="us-ascii"

Dear Brigitte,  Markus and Martin,

I have reviewed the discussion of all the HTAP names proposed by Brigitte at 
the beginning of this year. This is in preparation for making an update to the 
standard name table. I am also in the process of reviewing Markus Fiebig's own 
proposals (see 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056946.html and follow 
up posts) as the discussions of the two sets of names overlap. I will post 
later today about Markus' names.

[...]

Two  new proposals were added at the end of the discussion: (see 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014/057372.html).

canopy_resistance_to_ozone_dry_deposition (m-1 s) " The "canopy_resistance" is 
the resistance of a compound to uptake by the vegetation canopy. It varies both 
with the surface and the chemical species or physical state (gas or particle)."

aerodynamic_resistance (m-1 s)
"The "aerodynamic_resistance" is the resistance to mixing  through the boundary 
layer toward the surface by means of the dominant process, turbulent transport."

I am not very familiar with either of these quantities and no comments have 
been received on these proposals. A quick internet search suggests that both 
terms are in wide use in the literature.

My (brief) research revealed that aerodynamic_resistance is sometimes termed 
"aerodynamic drag" which is more similar to existing standard names for heat, 
momentum and gravity wave drag. Perhaps "aerodynamic_drag" would therefore be 
more appropriate for this name? (I don't have a strong opinion either way). If 
it is a resistance to downward turbulent transport, then presumably that refers 
to transport of aerosol particles? Perhaps we should also put that in the name 
to make it more self explanatory, e.g., 
aerodynamic_drag_on_turbulent_deposition_of_aerosol_particles or 
resistance_to_turbulent_deposition_of_aerosol_particles_due_to_aerodynamic_drag.
 These are just suggestions and I'd welcome other opinions. Regarding the 
definition, it appears that there are a number of different formulae for this 
quantity (see for example the first paragraph of  
http://agsys.cra-cin.it/tools/evapotranspiration/help/Aerodynamic_resistance.html).
 Does this proposal relate to any particular form
 ulation? If so, we should provide a reference in the definition.

Regarding the canopy resistance name, could it be reworded  to 
canopy_resistance_to_downward_flux_of_ozone_due_to_dry_deposition? Perhaps this 
more clearly relates the quantity to other atmospheric names? I don't know if 
that is useful and again it is just a suggestion. Also, if there is a 
particular formula or reference for this quantity we should include it in the 
definition.

That concludes my somewhat lengthy comments! If we can agree any of the "under 
discussion" names over the next two or three working days then they can also be 
accepted in time for inclusion in the upcoming standard name table update.

Best wishes,
Alison

--
Alison Pamment  Tel: +44 1235 778065
NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt

---

Re: [CF-metadata] string valued coordinates

[Schultz, Martin]

Dear Jonathan,

 Deprecating the units attribute for string and char variables (perhaps 
int, too?) sounds like a good idea. Yet, I would still second Marc to at least 
allow for a "None" value in the units attribute - as far as I understand this 
wouldn't break the compatibility.

But, in my view even more important, is the  issue of making the units 
attribute mandatory in CF-2. We had this discussion earlier, and I sensed some 
support for the general idea of "cleaning" CF in the sense that our 
applications can rely on certain things to be there, because this clearly 
enhances the resilience of interoperable systems. If people submit their test 
files to a CF check and get a message back that they are supposed to add a 
units attribute, they may do so. If the CF checker doesn't tell them this 
(because it is valid CF to have variables without a units attribute), then they 
will most certainly not do so. Of course, in light of the new discussion, we 
would have to carefully draft the rules for when the units attribute is indeed 
mandatory.

Best regards,

Martin

--

Message: 2
Date: Thu, 6 Nov 2014 17:38:38 +
From: Jonathan Gregory 
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata]  string valued coordinates
Message-ID: <20141106173838.ga9...@met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii

One further thought: we could deprecate the units attribute for variables of 
string and char type, or having a flag_values att. These conditions can be 
detected automatically, so the CF_checker would give a warning, for instance.
Jonathan

[...]





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates (unitless quantities)

[Schultz, Martin]

Dear Mark and all,

 thanks for this discussion and the motion to approach udunits to advance 
this issue. Reading through the posts on this, I have two comments, one 
question, and one afterthought:

1. Why "no_unit" and not simply "none"? "no_unit" could also be "no_units" (in 
fact the attribute name is unit*s*, so the missing "s" in "no_unit" may be 
confusing). Being a Python fan, I like Python's concept of None as a value that 
indicates that there is no value; just what we want here.

2. When you revise the respective section of the CF convention: in light of the 
"CF 2" discussions we should think about making the units attribute mandatory. 
Alternatively, I would suggest that a missing units attribute should mean 
"none" rather than "1" and/or the units attribute should become mandatory for 
numerical fields (a string array, for example of station names, may indeed not 
require a units attribute).

3. Would you regard "" (empty string) as a valid alternative to "none"?   [I 
may have overlooked this in the previous discussions but wasn't sure if there 
was a consensus view]

4. Coming back to the old "kg/kg" or "mole/mole" discussion: I guess it would 
help if udunits would accept "terms that evaluate as '1' " with the 
understanding that they ae equivalent to "1" as unit. Many (most) atmospheric 
chemistry modelers are still operating in the grey zone with units attributes 
of "nmole mole-1" which are a lot more readable than "1.e-9" and make a lot of 
sense to them. Only if you enforce a CF checker on them they will abide, but 
keep grunting. If one doesn't want to be too generic here, at least "kg/kg" and 
"mole/mole" should be added to the udunits collection.

Best regards,

Martin





-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
cf-metadata-requ...@cgd.ucar.edu
Sent: Tuesday, November 04, 2014 5:38 PM
To: cf-metadata@cgd.ucar.edu
Subject: CF-metadata Digest, Vol 139, Issue 4

Send CF-metadata mailing list submissions to
cf-metadata@cgd.ucar.edu



Message: 2
Date: Tue, 4 Nov 2014 16:38:12 +
From: "Hedley, Mark" 
To: Jim Biard , "cf-metadata@cgd.ucar.edu"

Subject: Re: [CF-metadata] string valued coordinates
Message-ID:

<7819c496f4e10e47bcefbe74551aac9606f40...@exxcmpd1dag3.cmpd1.metoffice.gov.uk>

Content-Type: text/plain; charset="windows-1252"

Hello Jim

> A variable with no units attribute at all is also pretty unambiguously a 
> marker for something that isn't intended to be a even a pure number.

If only this were the case.  CF conventions state that:
Units are not required for dimensionless quantities. A variable with no units 
attribute is assumed to be dimensionless. However, a units attribute specifying 
a dimensionless unit may optionally be included.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units

Thus, the absence of a unit is to be interpreted identically to a statement 
that units = '1'

This is the current situation and it is likely that there is lots of data like 
this around.

> Do we really need something more than a disambiguation of units = '1' vs no 
> units attribute present?

Yes, I think we do: this situation is not ambiguous in CF, they are the same 
thing.

What I believe we require is a udunits entity which is clearly 'there is no 
unit of measure here, this is not dimensioned and not dimensionless'

The udunits value
''
delivers this functionality (I think), but it does not read very well, hence my 
suggestion that we ask for a new entry in udunits, 'no_unit'
which is hopefully clear in its meaning and interpretation and which behaves 
the same as '' : failing all udunits processing attempts and operating as 'not 
a unit'

all the best
mark


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 31 October 2014 15:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates

Mark,

I'm not clear on what you are suggesting that udunits do with 'no_unit' or '?'.

I had thought that the desire was to be able to differentiate between a pure 
number (as you mention below) and a value (whether a string or a bit pattern) 
that should not be interpreted as any number at all.

As the situation stands, a units value of '1' is pretty unambiguously a marker 
for a pure number. We may need to modify docs to make this clearer, but I don't 
think that poses a problem. A variable with no units attribute at all is also 
pretty unambiguously a marker for something that isn't intended to be a even a 
pure number. Again, we may need to modify docs to make this clearer. Because 
these two concepts are somewhat conflated in the current documentation and 
usage (area_type being an example), there is the issue of other places where 
cleanup would be good going forward, but even if you have a units value of '1' 
on a non-number, it doesn't hurt anyt

Re: [CF-metadata] mole_concentration_of_air_in_air? (alison.pamm...@stfc.ac.uk)

[Schultz, Martin]

Dear all,

  I like the term "number_concentration_of_molecules_in_air" (m-3). Thanks, 
Alison!

Best regards,

Martin

> Message: 5
> Date: Wed, 2 Jul 2014 11:40:04 +
> From: 
> To: 
> Subject: Re: [CF-metadata] mole_concentration_of_air_in_air?
> Message-ID:
>   <014539ac4976be4490a360410a8c201779243...@exchmbx03.fed.c
> clrc.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Andreas,
>
> This might sound like a silly question, but what do you mean by "air"? Do you
> mean just the mixture of gases or do you mean everything that might
> be found in a random sample of air, including aerosol particles and
> precipitation?
>
> If you mean strictly the gases, then I would suggest
> mole_concentration_of_gas_molecules_in_air  which would have
> canonicalunits of mol m-3
> or if you want to express it as a simple number per unit volume we could
> have
> number_concentration_of_gas_molecules_in_air (m-3).
>
> If you want to include all constituents of the air parcel, then you would need
> something like
> mole_concentration_of_molecules_in_air
> or perhaps even better
> mole_concentration_of_air
> both of which would have canonical units of mol m-3.
> The name number_concentration_of_air doesn't sound very meaningful in
> English, but you could have
> number_concentration_of_molecules_in_air (m-3).
>
> Best wishes,
> Alison
>
> --
> Alison Pamment  Tel: +44 1235 778065
> NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
> >-Original Message-
> > From: Andreas Hilboll [mailto:li...@hilboll.de]
> > Sent: 02 July 2014 10:46
> > To: cf-metadata@cgd.ucar.edu
>  > Subject: [CF-metadata] mole_concentration_of_air_in_air?
> >
> > Hi guys,
> >
> > I'm wondering how to express the air number density, i.e., the number of
> > air molecules per unit volumne (in mole cm-3), in terms of CF standard
> > names?
> >
> > -- Andreas.




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Convention document on Github

[Schultz, Martin]

Dear all,

 sorry of this has been asked/commented before: I admit I didn't follow all 
the Github posts that came in lately. Firstly, let me say that I like the 
Github look&feel - let's hope this will soon be fully functional. I just tried 
to get the latest (1.6) conventions document (pdf) and was amazed that I see it 
posted as "executable file", and "Open" redirects me to some place where I can 
install some Github software. Being happy to experiment, I then tried "raw", 
and this actually worked, and I can open the document in my preferred pdf 
reader. If possible, this should be cleaned so that an "open" on a pdf document 
actually opens it.

Thanks and best regards,

Martin


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Classification of a "trajectory" with asynchronous time coordinates (Mike Godin)

[Schultz, Martin]

Dear Mike,

 what you describe sounds to me like a textbook example of what the netcdf4 
groups could accomplish without any quirks. Since you do have a separate time 
axis for each variable, it doesn't make much sense in my view to force them to 
co-exist in one file at one "level". As far as I understand CF, this would 
require to define a "master time axis", which would serve as the time 
"coordinate". Or else, all time axes would be auxiliary coordinate variables, 
which also doesn't make much sense in a discovery framework. We did have a 
discussion on "group-aware CF" a while ago - maybe this is the time to 
resurrect this?

Best regards,

Martin


==
PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831



> Date: Tue, 18 Mar 2014 12:10:44 -0700 (PDT)
> From: Mike Godin 
> To: "CF-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] Classification of a "trajectory" with
>   asynchronoustime coordinates
> Message-ID:
>   <1395169844.32180.yahoomail...@web141004.mail.bf1.yahoo.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> I am considering a file from a sampling system that follows a trajectory, but
> which collects each variable independently of each other. It would have with
> a header that looks like the following (adapted from "Example H.13. A single
> trajectory recording atmospheric composition."):
>
> ? ?dimensions:
> ? ? ? time_lon = 42;
> ? ? ? time_lat = 55;
> ? ? ? time_z = 435;
> ? ? ? time_O3 = 335;
> ? ? ? time_NO3 = 5357;
>
> ? ?variables:
> ? ? ? double time_lon(time_lon) ;?
> ? ? ? ? ? time_lon:standard_name = "time";
> ? ? ? ? ? time_lon:long_name = "time_lon" ;
> ? ? ? ? ? time_lon:units = "days since 1970-01-01 00:00:00" ;
> ? ? ? float lon(time_lon) ;?
> ? ? ? ? ? lon:standard_name = "longitude";
> ? ? ? ? ? lon:long_name = "longitude" ;
> ? ? ? ? ? lon:units = "degrees_east" ;
> ? ? ? double time_lat(time_lat) ;?
> ? ? ? ? ? time_lat:standard_name = "time";
> ? ? ? ? ? time_lat:long_name = "time_lat" ;
> ? ? ? ? ? time_lat:units = "days since 1970-01-01 00:00:00" ;
> ? ? ? float lat(time_lat) ;?
> ? ? ? ? ? lat:standard_name = "latitude";
> ? ? ? ? ? lat:long_name = "latitude" ;
> ? ? ? ? ? lat:units = "degrees_north" ;
> ? ? ? double time_z(time_z) ;?
> ? ? ? ? ? time_z:standard_name = "time";
> ? ? ? ? ? time_z:long_name = "time_z" ;
> ? ? ? ? ? time_z:units = "days since 1970-01-01 00:00:00" ;
> ? ? ? float z(time_z) ;?
> ? ? ? ? ? z:standard_name = ?altitude?;
> ? ? ? ? ? z:long_name = "height above mean sea level" ;
> ? ? ? ? ? z:units = "km" ;
> ? ? ? ? ? z:positive = "up" ;?
> ? ? ? ? ? ?z:axis = "Z" ;?
> ? ? ? ? ? ?
> ? ? ?double time_O3(time_O3) ;?
> ? ? ? ? ? time_O3:standard_name = "time";
> ? ? ? ? ? time_O3:long_name = "time_O3" ;
> ? ? ? ? ? time_O3:units = "days since 1970-01-01 00:00:00" ;
> ? ? ? float O3(time_O3) ;?
> ? ? ? ? ? O3:standard_name = ?mass_fraction_of_ozone_in_air?;
> ? ? ? ? ? O3:long_name = "ozone concentration" ;
> ? ? ? ? ? O3:units = "1e-9" ;
> ? ? ? ? ? O3:coordinates = "time_O3 lon lat z" ;
>
> ? ? ?double time_NO3(time_NO3) ;?
> ? ? ? ? ? time_NO3:standard_name = "time";
> ? ? ? ? ? time_NO3:long_name = "time_NO3" ;
> ? ? ? ? ? time_NO3:units = "days since 1970-01-01 00:00:00" ;
> ? ? ? float O3(time_NO3) ;?
> ? ? ? ? ? NO3:standard_name = ?mass_fraction_of_nitrate_radical_in_air?;
> ? ? ? ? ? NO3:long_name = "NO3 concentration" ;
> ? ? ? ? ? NO3:units = "1e-9" ;
> ? ? ? ? ? NO3:coordinates = "time_NO3 lon lat z" ;
>
> ? ?attributes:
> ? ? ? :featureType = "";
>
> The data points could be sampled to generate a header exactly like the
> example from the standard, but in doing so, one would lose information
> about the timing of each variable's values, and would either end up with data
> loss, or a much larger file. ?So I'm wondering: is this a valid "H.4.2. Single
> trajectory"? ?If not, is it something that can be annotated as a valid CF
> metadata file without altering the measured data?
>
> Thanks, Mike Godin
> -- next part --
> An HTML attachment was scrubbed...
> URL:  metadata/attachments/20140318/6625043f/attachment.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> --
>
> End of CF-metadata Digest, Vol 131, Issue 1
> ***




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung:

Re: [CF-metadata] Editing/publishing workflow (Hattersley, Richard)

[Schultz, Martin]

> Message: 2
> Date: Tue, 18 Mar 2014 09:05:36 +
> From: "Hattersley, Richard" 
> To: "Gregory, Jonathan" ,
>   "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Editing/publishing workflow
> Message-ID:
>   <21A2C87797FA6042B162A8A0A11A15DB06F60FCE@EXXCMPD1DAG2
> .cmpd1.metoffice.gov.uk>
>
> Content-Type: text/plain; charset="us-ascii"
>
> > I'd like to propose changing the rules. That's something the conventions
> committee can agree, I believe. I would suggest the simplest possibility, if 
> we
> wish to retain provisional status, is to specify a time. We could say that, 
> after
> one year from acceptance or when the next version of the conventions
> document is published, whichever is later, a change becomes permanent.
> What do you think?
>
> The more I consider the concept of "provisional status" the more it concerns
> me. What does it actually mean for a netCDF file to use a particular
> "Conventions" attribute value? How can one tell what is still in provisional
> status? What version should data writers be using? I've checked back
> through 1.3, 1.4, 1.5, and 1.6 and they all still contain sections marked as
> provisional. Using the analogy to software versions that has been raised
> elsewhere, the CF convention versions are essentially pre-release versions,
> e.g. 1.6-beta, and are not suitable for production use.
>
> [...]

Dear all,

 taking up Richard's comment: wouldn't it make most sense to change the 
release cycle as with any software product? Instead of immediately releasing 
"1.7", there would be a, say six months period where we have "1.6" as official 
version and "1.7-beta" as test candidate for the next release. This would allow 
everyone to develop, test and comment, while it remains fully clear which 
version is the latest operational one. CF checking tools could then even issue 
a warning if they find an outdated "*-beta" version in the Conventions 
attribute, and production datasets should simply refrain from using beta 
versions.

Best regards,

Martin


===
PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831







Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Editing/publishing workflow (Jonathan Gregory)

[Schultz, Martin]

Dear Jonathan et all,

   I sympathize with this change of rules. However, I would propose to 
couple this to a "final review alert" or whatever you want to call it. A 
deadline can pass unnoticed, and it would be good to either set a fixed yearly 
date for accepting changes as final (the "CF spring cleaning date"), or to "set 
a timer" and then send a message to the CF community about 1 month prior to the 
end of the provisional period (of course one can also do both). We are all very 
busy and these measures could at least give us a chance to take another 
dedicated look at provisional items and map own experiences with the proposed 
changes. In order to prevent this from eternal perpetuation, one should 
probably also say that any further comments on the provisional changes will not 
lead to an extension of the deadline unless there is a strong view that this is 
needed (how to measure "strong view"? Perhaps by requiring at least 3 
supporters?). In practice I would expect few occasions where issues are
  actually re-discussed, but of course this can happen.

Best regards,

Martin



> Message: 3
> Date: Thu, 13 Mar 2014 17:23:31 +
> From: Jonathan Gregory 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Editing/publishing workflow
> Message-ID: <20140313172331.gh32...@met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Jeff
>
> [...]
> Yes, this is a issue. As Richard said, it doesn't matter how it is marked. The
> problem is that all changes, however old, are still marked as provisional, as
> you said. This is (a) a bit silly and (b) a nuisance as regards legibility
> of the doc. The aim of provisional status was to allow time for people to try
> out the change, in case a logical flaw was discovered which hadn't been fore-
> seen at the time of the proposal. This was because of the concern that many
> or
> most proposals concern data which has not yet been written, so the
> metadata
> being proposed can't have been thoroughly tested. It was supposed that
> some
> tests, using specified software, would be used to demonstrate the new
> feature
> was "working", but no-one had time to work out the details for this.
>
> I'd like to propose changing the rules. That's something the conventions
> committee can agree, I believe. I would suggest the simplest possibility, if
> we wish to retain provisional status, is to specify a time. We could say that,
> after one year from acceptance or when the next version of the conventions
> document is published, whichever is later, a change becomes permanent.
> What
> do you think?
>
> Cheers
>
> Jonathan




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] HTAP2 Final proposal = 102 CF Standard Names

[Schultz, Martin]

Dear Brigitte and all,

 please find below a few comments -- I only copied those names on which I 
made a comment.

Thanks again for this effort!

Martin

> -Ursprüngliche Nachricht-
> Von: Brigitte Koffi Lefeivre [mailto:brigitte.koffi-lefei...@jrc.ec.europa.eu]
> Gesendet: Dienstag, 21. Januar 2014 09:20


> 1. EMISSIONS
> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_pm10_dry_aerosol_due_to_emission
> Unit: kg m-2 s-1
There is an issue with "PM10 emissions" in that this term is somewhat ambiguous 
and obviously a diagnostic, because models will generally emit BC, OC, SO4, 
etc. rather than PM10. I would argue that this standard_name is nevertheless 
useful, but the definition should make this diagnostic aspect clear.

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_pm2p5_dry_aerosol_due_to_emission
> Unit: kg m-2 s-1
Same as above

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_pm10_seasalt_dry_aerosol_due_to_emission
> Unit: kg m-2 s-1
Same as above

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_pm10_dust_dry_aerosol_due_to_emission
> Unit: kg m-2 s-1
Same as above

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_pm2p5_seasalt_dry_aerosol_due_to_emission
> Unit: kg m-2 s-1
Same as above

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_pm2p5_dust_dry_aerosol_due_to_emission
> Unit: kg m-2 s-1
Same as above

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_nmvoc_expressed_as_carbon_due_to_emission
> Unit: kg m-2 s-1
The definition string should contain a clear recommendation to add a comment 
attribute that details which VOC are contained in "nmvoc" for this model

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_nmvoc_due_to_emission*
> Unit: kg m-2 s-1
The definition string should contain a clear recommendation to add a comment 
attribute that details which VOC are contained in "nmvoc" for this model

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_alkanes_due_to_emission
> Unit: kg m-2 s-1
The definition string should contain a clear recommendation to add a comment 
attribute that details which VOC are contained in "alkanes" for this model

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_alkenes_due_to_emission
> Unit: kg m-2 s-1
The definition string should contain a clear recommendation to add a comment 
attribute that details which VOC are contained in "alkenes" for this model

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_aromatic_compounds_due_to_emission
> Unit: kg m-2 s-1
The definition string should contain a clear recommendation to add a comment 
attribute that details which VOC are contained in "aromatic_compounds" for this 
model. Maybe it would be better to say "aromatic_voc" (if oxygenated compounds 
can be included) or "aromatic_hydrocarbon" (if you consider only C-H molecules)

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_biogenic_nmvoc_expressed_as_carbon_due_to_emission
> Unit: kg m-2 s-1
The definition string should contain a clear recommendation to add a comment 
attribute that details which VOC are contained in "biogenic_voc" for this model

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_secondary_particulate_organic_matter_dry_aerosol_due_to_pseudo_emission.
> Unit: kg m-2 s-1
> Definition: pseudo_emission means that the model does not calculate the
> particulate organic matter formed within the atmosphere from gaseous
> precursors but uses a pseudo emission instead.
Hmmm. Does it really make sense to come up with a new term "pseudo_emission" 
here? I guess for the model (i.e. mathematically) this is an emission. In the 
physical world this doesn't happen, but is this pertinent here? I would suggest 
to rename to "..._due_to_emission" and state in the definition that secondary 
organic aerosol are (of course) not directly emitted, but that emissions can be 
defined as a model concept.

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_monoterpenes_due_to_emission
> Unit: kg m-2 s-1
> Definition: Monoterpenes are a class of terpenes that consist of two
> isoprene units and have the molecular formula C10H16.
The definition should at least recommend to include a comment attribute 
detailing which monoterpenes are considered in the model

> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_sesquiterpenes_due_to_emission
> Unit: kg m-2 s-1
> Definition: Sesquiterpenes are a class of terpenes that consist of three
> isoprene units and have the molecular formula C15H24.
The definition should recommend to include a comment attribute detailing which 
sesquiterpenes are considered in the model


> 2. DEPOSITIONS
> Proposed new standard name:
> tendency_of_atmosphere_mass_content_of_organic_nitrates_due_to_dry_deposition
> Unit: kg m-2 s-1

Re: [CF-metadata] new standard names: fire area, fire, temperature, fire

[Schultz, Martin]

Hi Charlie,

this could be a future extension. Right now, I believe that most products 
will not make this distinction - hence we need names for these. A natural 
extension would then be the "due_to" construct:
"fire_area_due_to_smoldering_fires". However, these names should only be 
proposed when someone really needs them.

Cheers,

Martin

> Date: Wed, 27 Nov 2013 15:29:55 -0800
> From: Charlie Zender 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] new standard names: fire area, fire,
>   temperature, fire radiative power
> Message-ID: <52968073.9070...@uci.edu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> My qualm about these names
>
> Standard Name: fire_area
> Standard_Name: fire_temperature
> Standard_Name: fire_radiative_power
>
> is there potential ambiguity as to fire type.
> Researchers now separately detect and/or estimate
> both "active" and "smouldering" fires.
> Is it worth breaking-out your names by fire type?
>
> cz
> --




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard names: fire area, fire temperature, fire radiative power

[Schultz, Martin]

> Date: Tue, 26 Nov 2013 14:36:48 -0500
> From: Gary Meehan 
> Subject: Re: [CF-metadata] new standard names: fire area, fire
>   temperature, fire radiative power
> Message-ID: <5294f850.5070...@aer.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Dear CF Community,
>
> This is a follow-up email to my note of 18 November in which I proposed
> standard names to fire area, fire temperature, and
> fire radiative power. Are there any opinions to what I have proposed below?
>
> Sincerely,
>
> Gary Meehan
>
> > Standard Name: fire_area
> > Standard_Name: fire_temperature
> > Standard_Name: fire_radiative_power

Dear Gary,

these names (and their definitions) look fine. Thanks for proposing these.

Best regards,

Martin



PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF-checker as a script

[Schultz, Martin]

Dear Petra,

 we developed such a script at Forschungszentrum Juelich: 
http://redmine.iek.fz-juelich.de/projects/cfchecker. My colleague Michael 
Decker (m.dec...@fz-juelich.de) will be happy to assist you if you have 
questions. The tool has been developed in python.

Best regards,

Martin Schultz

> Date: Tue, 24 Sep 2013 08:05:55 +
> From: Fuchs Petra 
> To: "'cf-metadata@cgd.ucar.edu'" 
> Subject: [CF-metadata] CF checker as script
> Message-ID:
>   <9298739FB413E644A0A1DA64DA4B37F0337614AD@OFWEXC21.win2
> 003.dwd.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear members of the CF mailing list,
>
> We generate climate data records based on satellite data  in netcdf cf
> standard format as output. As we are dealing with a  large number of files
> we are interested in using the netcdf cf checker offline and running a script
> (for LINUX/UNIX) to check the files in our processing environment. Do you
> have such a script available for users?
>
> Thank you in advance,
> Best regards,
> Petra




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 
bis 17:00 Uhr: http://www.tagderneugier.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Are ensembles a compelling use case for "group-aware" metadata? (CZ)

[Schultz, Martin]

Hi Charlie,

very good and extensive explanation of the potential use for groups and 
group-aware metadata. Yet, I have a few remarks (which may in part reveal that 
I should probably read the preamble of the CF convention again ;-):

> Point 1: How does the user know she has all the realizations?

Is this question best addressed with metadata in a (series of) file(s)? In a 
modern, interoperable architecture, I would think that this belongs into the 
realm of data discovery, which would be done via web catalogues using metadata 
facets. File-based metadata IMHO may be more prone to failure. Just imagine, 
ECMWF had first generated two ensemble members, and their metadata would say so 
(your "page 2/2" analogy). Now they run another two: do you really expect the 
metadata from the old files to be updated? A web catalogue would provide a more 
robust solution to this question, I believe.

This doesn't mean that it may not be useful to have such information in a file! 
However, to come back to the suitcases: this can only be a packing list for the 
current trip and not an inventory of all the socks you may possibly own. Of 
course your young aspiring researcher may wish to express her knowledge about 
other ensemble members she found on the web but didn't include in the file (the 
suitcase). But will her supervisor or colleague on the other side of the world 
understand what she is talking about? I think, if you intend to go beyond the 
packing list, you open too many cans with too many worms.

> Point 2: Multiple and/or Non-numeric Ensemble axes

Here, you have a  valid point, although - again - I would not connect this to 
knowing " that she has all the models". Yet, within the packed file (the 
suitcase) you want to know which hierarchy model (packing order) was applied in 
order to be able to aggregate things (for example by computing ensemble 
averages). See also my use-case on aircraft data introduced below. Question: 
what happens to this kind of information when the files are flattened and 
re-packaged? It might well become meaningless, which would indicate that these 
are "temporary" metadata, and thus probably out of scope for CF. This actually 
reminds me a bit of my experiences with the history attribute when I use ncks 
-A. This command will preserve the history of one file, but discard the history 
of the other file, which is certainly not the behavior you would like to see in 
ungrouping/re-grouping software.

> Point 3: Weights and intentional reproducibility of MME statistics

In my view this is actually just another viewing angle on your point #2.

--

Your use-case does however highlight the "convenience" of grouping data which 
somehow belong to each other into one file. In a world of flat files, one must 
check coordinates each time when you want to perform some sort of (ensemble) 
averaging operation. A hierarchical file will tell you that it is OK to average 
by placing the common coordinates on the upper level. IMPORTANT: again, this 
doesn't mean that this is the only or best way to do the grouping - yet, it 
seems a compelling advantage to have this coordinate-consistency problem 
eliminated somewhere along your processing steps. As others said already: there 
are reasons for why people use suitcases.

--

Now, here is another use case, which we haven't implemented yet - partly 
because we didn't see how it can be done in a CF consistent way:
While there has been a definition of a standard file layout for data from 
multiple stations (a contribution from Ben Domenico and Stefano Nativi if I am 
not mistaken), this concept cannot be applied to multiple aircraft flight data. 
The station data can be packaged together with help of a non-geophysical 
"station" coordinate, because all stations share the same time axis. With 
aircraft flights, the time axes often don't overlap, and forcing all data onto 
the superset of time would be a tremendous waste of space. Groups would seem as 
 the natural solution to this problem! Why not flat files? Because you might 
wish to retrieve all the aircraft data which were sampled in a given region 
during a specific period (a natural use case for a catalogue query it seems) in 
one entity, and not in N entities, where you cannot even predict N.

I would think the same applies to "granules" of satellite data which share a 
common calibration, for example.

--

As Nan said, we should try to come back to define what is really at stake for 
CF and what exactly shall be proposed. Now this is where my failure to re-read 
the convention preamble may show ;-). The main question is: is CF about files 
or about interoperability?  Unfortunately, my view on this is not entirely 
clear, because it seems to be a bit of both. The standard_names clearly have a 
bearing in the interoperable world, and this shows through various links to the 
CF standard_names in web catalogues or controlled vocabulary collections (e.g. 
SeaDataNet). The conventions themselves seem

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups

[Schultz, Martin]

Dear all,

 maybe we should rephrase the question behind this discussion: How can 
hierarchies and/or groups be implemented without breaking CF? More 
specifically, it seems that we should care about not breaking CF when the 
suitcases are packed or unpacked. It would be a nightmare if anyone or any 
interoperable application would have to re-build CF compliance every time the 
hierarchies are introduced or flattened out. Unless I am mistaken here this 
would mean that CF should be "group aware" without necessarily having to 
support hierarchies or groups as a concept. Would this be a compromise to work 
on?

Cheers,

Martin

> Thus far all that have been put on display seem to be counter-examples(*): 
> [...]




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 
bis 17:00 Uhr: http://www.tagderneugier.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups

[Schultz, Martin]

Hi again,

I fully support Jim's view! Let's not get hung up on whether 
groups/hierarchies are good or bad. Instead we should consider them a reality 
and an option rather than a must. They are a bit like a suitcase which you can 
pack and unpack to carry things around or store them in your basement until you 
need them again. In your closet (i.e. on your harddrive) you may prefer to have 
flat access to your shirts and socks, while on travel (distributing datasets to 
students, for example) you may prefer some sort of packaging. And don't tell me 
there would be a unique way how to pack your suitcase!

>  treat groups as files
There should probably be two ways for converting group files to flat files:
a) flatten everything into one file with "." separated name spaces
b) flatten groups into individual files (tools like NCO could then use the name 
space as part of the file names to be generated)
Conversely, one may want to define rules for aggregating flat files into a 
hierarchy - allowing for different "models" for how data should be structured
[this is probably beyond CF but related as far as attributes are concerned]

> allow for the concept of inheritance of dimensions (which is native to 
> netCDF-4)
I may be naïve, but this seems relatively straightforward to me as long as we 
stay clear of multiple or circular hierarchies. We should be aware of the 
consequences, though: not all HDF5 files may fit into the new CF framework 
then! It would actually be good to get a view from the HDF5 experts as to how 
widespread the multiple ancestor or circular "features" of HDF5 are exploited 
in real datasets (what would we miss if we adhere to the netcdf4 concept?).

> ... and attributes (which would be a CF convention)



> -Ursprüngliche Nachricht-
> Von: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] Im Auftrag
> von cf-metadata-requ...@cgd.ucar.edu
> Gesendet: Dienstag, 17. September 2013 07:52
> An: cf-metadata@cgd.ucar.edu
> Betreff: CF-metadata Digest, Vol 125, Issue 6
>
> Send CF-metadata mailing list submissions to
>   cf-metadata@cgd.ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> or, via email, send a message with subject or body 'help' to
>   cf-metadata-requ...@cgd.ucar.edu
>
> You can reach the person managing the list at
>   cf-metadata-ow...@cgd.ucar.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CF-metadata digest..."
>
>
> Today's Topics:
>
>1. Re: Towards recognizing and exploiting hierarchical groups
>   (Jim Biard)
>
>
> --
>
> Message: 1
> Date: Tue, 17 Sep 2013 09:51:51 -0400
> From: Jim Biard 
> To: "cf-metadata@cgd.ucar.edu List" 
> Subject: Re: [CF-metadata] Towards recognizing and exploiting
>   hierarchicalgroups
> Message-ID: <0b9e777c-c317-4ce9-acea-cfdf93c2c...@noaa.gov>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi.
>
> I strongly support the idea of adding groups to CF.  As a data producer and
> consumer, I vastly prefer to have collections of similar items grouped
> together rather than laying about in a single large bin.  (I also make 
> extensive
> use of folders on my computer!)  I am currently building netCDF-4 files that
> use groups, which allows me to produce single files instead of groups of 35
> files.  As attractive as the thought of "containerless data" (clouds of fully 
> self-
> described, individual variables floating in cyberspace) is, I find that a
> significant database system is required to make that functional.   When such
> a system is available, variables can be as easily presented from files
> containing groups as from files that don't.  When such as system isn't
> available, groups help unaided human brains grasp the organization of the
> data.  That's why the hierarchical file system has been such a success.  (And 
> I
> admit, this is colored by my own particular biases.  I like to sort my email 
> in
>  to folders, even sub-folders.  I use search when I need to, but I find it 
> much
> quicker to go to the folder where I am more likely to find what I'm looking
> for.)
>
> I also agree that we should take a gradualist approach.  If we conceptually
> treat groups as files, allow for the concept of inheritance of dimensions
> (which is native to netCDF-4) and attributes (which would be a CF
> convention), and stop there for now, I think we can then wrestle with more
> complex topics as they come along.
>
> Grace and peace,
>
> Jim
>
> Visit us on
> Facebook  Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jim.bi...@noaa.gov
> o: +1 828 271 4900
>
>
>
> On Sep 17, 2013, at 7:56 AM,  wrote:
>
> > Bryan has beaten me to the points I would

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups (Charlie Zender - Steve Hankin - Richard Signell)

[Schultz, Martin]

Dear all,

I very much welcome the initiative by Charlie, Ted and Peter on 
hierarchical data structures. Without wanting to offend anyone, the arguments 
against this brought forward by Steve and Richard sound to me a bit cowardly - 
but of course they do have a point in trying to ensure backward compatibility. 
I don't believe that we should pinpoint CF for all eternity to netcdf 3 files, 
because this inevitably means to render it meaningless at some point in time. 
And, as Charlie "threatened", there may be (are?) other groups defining 
conventions which would certainly step in. We did have a couple of discussions 
already which probably could have been solved easier if there were a group 
concept in CF. Specifically, I remember a discussion on the data model about 
inheritance of "global" attributes when data from different files were merged. 
In a group concept, you could simply define the content of each file as one 
group and re-define the global attributes from all files as group attri
 butes. Just as Charlie discussed in the paragraph about "scope". So, I am 
definitively all for at least this aspect of hierarchical structures. And, as 
long as we are only concerned about scoping, it doesn't sound to be overly 
complicated to map hierarchical structures onto flat files (break groups apart 
into individual files), so that interoperable applications could flexibly deal 
with one or the other.

   The real issue is indeed the definition of some sort of relation between or 
among the groups. Then again, this problem seems to be the same as defining 
relations between/among files if you intend to somehow connect them (may this 
be concatenating, (ensemble) averaging, or whatever). From a practical point of 
view, I would think that following the concept of the NCOs could be a useful 
starting point. By this I mean let's first worry about frequently used 
operations such as those that have been implemented as NCO operators. As this 
appears a limited set of relations, it should be possible to map those onto CF 
(any may be this would indeed be the time to think about CF 2.0?). 
Nevertheless, a little bit of "philosophical" discussion up front may also not 
hurt in order to see where possible limitations may be hidden. In fact, as 
indicated above, I believe that such a discussion could also help the CF 
datamodel become robust for future extensions, and it may provide some insight
 s for good implementations of the data model - because hierarchies are a 
reality.

On a somewhat different note, I would just like to point out that 
hierarchies also cause tremendous problems in the linking of data catalogues. 
Who says what goes on top and what follows next? Unfortunately, at some point, 
this structure (hierarchy) needs to be models in an XML, attribute, or whatever 
structure, and then it becomes quite complicated to translate it into another 
hierarchy in order to harmonize finding and accessing datasets from multiple 
sources. Some would argue that this is what conventions are made for. However, 
my response to this would be that you will then see as many conventions as 
(practical) hierarchies sprouting up. So, perhaps we need to think even beyond 
HDF and netcdf4 ??

Best regards,

Martin

> --
>
> Message: 3
> Date: Mon, 16 Sep 2013 13:52:50 -0400
> From: "Signell, Richard" 
> To: Steve Hankin 
> Cc: CF Metadata Mail List 
> Subject: Re: [CF-metadata] Towards recognizing and exploiting
>   hierarchicalgroups
> Message-ID:
>mail.gmail.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> Charlie & Co,
>
> Also, regardless of whether these hierarchical structures are stored
> in NetCDF4 or flattened NetCDF3, we get a big boost in
> interoperability when we write datasets with known featureTypes
> (profile, time series collection, swath, etc), because then workflows
> that have performed a
> catalog search and returned dataset endpoints knows what to do.   If
> the dataset endpoints contain ad hoc heirarchies it will be a lot more
> difficult.
>
> So if we create hierarchical datasets, I hope we create known
> featureTypes to accompany them (like gridEnsembleStructure).
>
> Thanks,
> Rich
>
> On Mon, Sep 16, 2013 at 12:53 PM, Steve Hankin
>  wrote:
> > Hi Charlie,
> >
> > Great that you have opened the door onto this discussion topic. Total
> > agreement from my pov that "group-awareness" in CF is an area that is
> crying
> > to be explored and solved.   Your analysis of technical details -- e.g.
> > attribute scope and inheritance by group descendents, etc. -- sounds
> natural
> > and sensible.
> >
> > The principle barrier to moving forward along this path lies in the fact
> > that CF is heavily committed to interoperability.  Arguably interoperability
> > is the raison d'?tre of CF.   The style of "backwards compatibility" that
> > one gets through a headlong switch from the netCDF3 API into the
> > group-oriented elements of the netCDF4 API i

Re: [CF-metadata] Request for a new standard_name: barometric_altitude

[Schultz, Martin]

Dear Jonathan (and John who replied offline),

"* Would it be acceptable and useful to follow some other kinds of standard 
name and call this air_pressure_expressed_as_altitude?"

Actually, I think not. The goal of this quantity is really to describe 
altitude, not pressure. This is different from a 
"mole_fraction..._expressed_as...", because there it is really the same thing 
with a simple conversion factor. So, I would still prefer "barometric_altitude".

Concerning the second name, I see that we need to define this better. Actually, 
it doesn't seem as straightforward as I thought...  We will take your comments 
into account when rephrasing the proposal for the second name.

Best regards,

Martin

From: Jonathan Gregory 
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Request for a new standard_name:
barometric_altitude
Message-ID: <20130705165717.ga32...@met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii

Dear Martin

Obviously these quantities are useful. I have two suggestions for your
consideration, hoping I have understood the idea.

* Would it be acceptable and useful to follow some other kinds of standard name
and call this air_pressure_expressed_as_altitude?

* above_ground doesn't seem specific enough to me, because you don't mean the
local ground, which we would usually call "surface" in standard names (i.e. the
bottom of the atmosphere). To be more precise, we could use something longer
such as wrt_surface_at_flight_origin. It refers to a particular time and place.

Best wishes

Jonathan





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 
bis 17:00 Uhr: http://www.tagderneugier.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Request for a new standard_name: barometric_altitude

[Schultz, Martin]

Dear all,

for the standardisation of metadata from aircraft measurements I would like 
to propose on behalf of the IGAS project team two new standard names for 
altitude:


1.   "barometric_altitude"

"Barometric altitude is the altitude determined by a pressure measurement which 
is converted to altitude through interpolation of the International Standard 
Atmosphere (ICAO, 1976).  A mean sea level pressure of 1013.25 hPa is used for 
the surface pressure."

Units: m


2.   "barometric_altitude_above_ground"

"Barometric altitude is the altitude determined by a pressure measurement which 
is converted to altitude through interpolation of the International Standard 
Atmosphere (ICAO, 1976).  The reference pressure is derived from the surface 
pressure measurement at take-off of the aircraft."

Units: m


Thanks for considering these and best regards,

Martin

PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 
bis 17:00 Uhr: http://www.tagderneugier.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] use of _FillValue vs valid_range, and minimum and maximum

[Schultz, Martin]

> >...  but computing min & max on the fly can also be very expensive.
> >We have aggregated model output datasets where each variable is more
> >than 1TB!

> Sure, I can see that that's useful metadata about the dataset, and that
> there's value in caching it somewhere.  I just don't think it belongs with
> the metadata inside the netcdf file. What's the use case for storing it
> there?

Dear all,

  that may be an issue of "style", or more technically speaking the way you 
set-up your system(s). I do think there is use for this as soon as you take a 
file out of an interoperable context. However, it's a very good and valid point 
to say that this information can (very) easily get corrupted. Thus it may be 
good to define some way of marking "fragile" metadata (i.e. metadata that can 
be corrupted by slicing or aggregating data from a file -- maybe even from 
several files). In fact this is related to the issue of tracking metadata 
information in the data model -- that has been brought up in the track ticket 
but was referred to the implementation...

Cheers,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] 4. Re: New Standard Names for Satellite Data

[Schultz, Martin]

Dear Aleksandar,

 nice job! Putting your proposal on 
http://wiki.esipfed.org/index.php/Standard_Names_For_Satellite_Observations#Proposal_.232
 like this makes it easily tractable.

Sorry if I may be a little late, but upon reading through I have some minor 
concerns about:

"relative_platform_azimuth_angle" and "relative_platform_azimuth_angle": in my 
understanding "relative" denotes a (percent) fraction rather than a difference. 
Therefore, I think this term could be misleading. Wouldn't 
"platform_azimuth_angle_difference" be more precise?

Out of curiosity: isn't there a need to describe several other 
platform/sensor/solar/viewing angles? It might help to refer to some figure 
(e.g. on a web site) which illustrates the various geometrical aspects needed. 
For example, I am wondering if "sensor zenith angle" and "sensor look angle" 
aren't the same, only shifted by 180 degrees. It might still be ok to have two 
different standard names for them (because they are different quantities), but 
in this case a sentence should be added to the definition such as "Note that 
zenith_angle and look_angle are related by zenith_angle = (look_angle + 180) 
mod 360".

And, please excuse my ignorance, but 
"covariance_between_constant_and_linear_terms_of_radiance_per_unit_wavenumber_correction_due_to_intercalibration"
 does sound rather specific and incomprehensible to me, even if I read through 
the definitions of 
constant_term_of_radiance_per_unit_wavenumber_correction_due_to_intercalibration
 and 
linear_term_of_radiance_per_unit_wavenumber_correction_due_to_intercalibration. 
Is this a general concept, or are these variables needed for one specific 
satellite sensor? Do we run the "danger" to see many more such proposals with 
other (inter)calibration concepts? I think, these definitions require a far 
more extensive description (i.e. definition), again, for example pointing to a 
web reference where the sensor concept and/or viewing geometry is described. It 
may thus be better from the standard_name perspective to try and find a 
somewhat more generalized term (if this is indeed sensor specific) and 
require/request a comment attribute which would then detail the exact procedure 
used. As an extreme (and perhaps unrealistic) suggestion, one could think about 
"covariance_between_correction_terms_due_to_intercalibration". The comment 
attribute would then have to specify that these are corrections of 
"radiance_per_unit_wavenumber", and that the covariance refers to "constant and 
linear terms".

Best regards,

Martin



PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard name: datetime_iso8601 (Seth McGinnis)

[Schultz, Martin]

Dear Seth,

I believe your concerns nicely confirm Michael's and my viewpoint that the 
real issue is a "lack of functionality" in the underlying netcdf library. If 
done properly, the datetime representation in the file would of course be 
numerical (python and certainly most other languages will do this also). Tools 
like ncdump or ncgen (and of course the library APIs) would then be used to 
obtain the string representation.

Best regards,

Martin


>Message: 2
>Date: Fri, 22 Mar 2013 14:31:47 -0600
>From: "Seth McGinnis" 
>To: 
>Subject: Re: [CF-metadata] New standard name: datetime_iso8601
>Message-ID: 
>Content-Type: text/plain;charset=utf-8
>
>
>Hi all,
>
>I'm a bit late to the discussion, but I just want to go on the record as being 
>(fairly strongly)
> opposed to allowing *anything* to be expressed as a string if there's a 
> reasonable numeric
> representation we can use instead.
>
> Maybe I'll change my mind after the community has made the jump to netcdf4, 
> but dealing
> with string data as arrays of chars under netcdf classic is a gigantic pain, 
> and I want to minimize
> the amount of data that I might ever have to interact with that does that.
>
> And with regard to coordinate variables in particular, if I'm writing a 
> script to analyze some
> data, I'll often want to do something (e.g., select data) that involves 
> dealing with the
> coordinate as a numeric value.  And in most of the processing environments I 
> can think of,
> parsing a string to convert it into a number is a lot more effort than 
> printing a date string
> based on a numeric representation.  I'd much prefer only needing to do the 
> latter.
>
> Cheers,
>
> --Seth





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard name: datetime_iso8601

[Schultz, Martin]

Dear all,

 as I am the "at least one other person" to whom Nan refered, let me 
clarify my position:

1) I would strongly argue against adding another way of formatting time through 
the backdoor via a standard_name.

2) I do see quite a bit of sense in re-modeling the date and time handling in 
netcdf-CF, because the current exclusive "something since ..." does have its 
drawbacks and makes things sometimes more complicated than they would need to 
be. I would just like to point out the discussions about climatological time 
axes, paleo dates, etc. Furthermore, interoperable services typically rely on 
ISO metadata and handle ISO 8601 time stamps. Thus, in order to translate back 
and forth to and from netcdf-CF one always needs to convert. Yes! There are 
libraries that can do this, but in the life of a scientist, these libraries are 
not always readily at hand, or it takes time to find out how they work, and 
your favorite programmer is on vacation.

3) Alexandar has rightly pointed out that there seems no easy consensus on this 
list to add ISO 8601 to the convention. Well, one reason for this is that a 
convention change must be discussed in a track ticket (see 
http://cf-pcmdi.llnl.gov/discussion/about-the-cf-trac-ticket-system). The other 
reason (more important) is (as has been pointed out by others) that this is 
actually an issue that goes beyond the CF realm and affects the netcdf library 
itself. I found it very interesting to see that the Unidata CDM has been 
expanded to allow for ISO-like datetime values. Indeed the question is: when 
will this be fully supported by the netcdf library and the ncdump/ncgen tools? 
As soon as this is the case, I would in fact advocate strongly that we open a 
track ticket and let the convention follow what is done in netcdf and the CDM.

There is some interesting reading at 
http://www.dwd.de/bvbw/generator/DWDWWW/Content/Oeffentlichkeit/TI/TI1/Informationstechnik/Software/UniDart/downloads/2__XML__Datatypes__download,templateId=raw,property=publicationFile.pdf/2_XML_Datatypes_download.pdf
 -- specifically this document declares datatypes such as gYear, gYearMonth, 
gMonthDay for recurring dates (remember this climatology issue and the ban on 
using "month" as period interval?).

So, I clearly see a future here - but it's first in the hands of Unidata, and 
then probably more for CF 1.7.

Best regards,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard name: datetime_iso8601 [John Graybeal et al.]

[Schultz, Martin]

Dear all,

 interesting discussion. From the point of view of an outsider (not dealing 
with ocean data ;-) there are two issues which still aren't entirely clear to 
me:

1) as Steve Hankin wrote, this variable has a potential to deflect from the 
actual physical quantity, which is expressed in the "time" dimension variable. 
This is no harm as such, but I am wondering if we shouldn't make this relation 
clearer, for example by defining the standard_name as 
"time_expressed_as_iso8601", or perhaps more precisely 
"datetime_expressed_as_iso8601". (Yes, Jonathan, I can see that this could open 
a backdoor towards replacing the numerical time construct by a string variable 
eventually...).

2) I agree with a few others that human readability should not be a criterion 
as such. If you think this through, then we would have to go back to ascii for 
everything (then I will look for a new job). I do, however, appreciate the need 
for documenting, i.e. preserving original datetime labels as they may have been 
sent for example from buoys. But in this sense, this variable only serves as a 
label and could in principle be some different entity such as a UUID or a 
random number. This has a very important consequence, because it implies that 
this datetime information should never be used by any software for processing 
(date)time information.

I hope you have detected that 1 and 2 are almost orthogonal to each other. I 
have a feeling that you lean towards 2 with your standard_name proposal, but 
that you have a secret wish to actually use datetime_iso8601 as a "real" time 
variable. This makes me slightly worried, unless there is a formal discussion 
to extend the convention via a track ticket.

Another issue is the default time zone. I couldn't quite follow whether the 
default will be "local" or "UT" in the end. If "UT" which makes a lot more 
sense in terms of "CF interoperability", this would break the ISO standard. 
This can of course be overcome by a community profile, but then there should 
also be a clear reference to this standard (a namespace attribute?).

Best regards,

Martin



PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard_names for emissions data

[Schultz, Martin]

Dear Alison,



   thank you for your email and sorry for the late reply. Yes - you are 
perfectly right: all of these names are suggested additions, and we would like 
to see them appear in the standard_name table.



Best regards,



Martin





> -Original Message-

> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf

> Of alison.pamm...@stfc.ac.uk

> Sent: 28 January 2013 12:24

> To: cf-metadata@cgd.ucar.edu

> Subject: Re: [CF-metadata] Proposal for new standard_names for biomass

> burning emissions

>

> Dear Martin and Angelika,

>

> ...

> Regarding the discussion of nitrogen dioxide and nitrogen monoxide

> names, I would like to check my understanding of exactly what is now

> being proposed. There seems to be agreement that it is fine to have

> nox_expressed_as_nitrogen_monoxide names, so are you in fact proposing

> that we should add the following eleven names?

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_savanna_and_grassland_fires

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_forest_fires

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_agricultural_production

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_agricultural_waste_burning

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_industrial_processes_and_combustion

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_energy_production_and_distribution

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_land_transport

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_maritime_transport

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_waste_treatment_and_disposal

> tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_

> monoxide_due_to_emission_from_residential_and_commercial_combustio

> n

> units: kg m-2 s-1

>

> tendency_of_mass_concentration_of_nox_expressed_as_nitrogen_monoxi

> de_in_air_due_to_emission_from_aviation

> units: kg m-3 s-1

>

> Are these in addition to the recently added nitrogen_monoxide emission

> names (i.e. I assume you are not intending the existing names to

> become aliases of these more recent proposals)?

>

> For nitrogen dioxide I think you are currently sticking with your

> original two proposals of:

> tendency_of_atmosphere_mass_content_of_nitrogen_dioxide_due_to_emi

> ssion_from_savanna_and_grassland_fires

> tendency_of_atmosphere_mass_content_of_nitrogen_dioxide_due_to_emi

> ssion_from_forest_fires.

> Is that correct?

>

> Best wishes,

> Alison

>

> --

> Alison Pamment  Tel: +44 1235 778065

> NCAS/British Atmospheric Data CentreEmail: 
> alison.pamm...@stfc.ac.uk

> STFC Rutherford Appleton Laboratory

> R25, 2.22

> Harwell Oxford, Didcot, OX11 0QX, U.K.

>



PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Usage of the 'Conventions' attribute (Phil Bentley)

[Schultz, Martin]

Hi Phil,

 while I agree with you that the only clean solution would have to be 
defined in the netcdf API itself (not in CF), I don't think that groups are 
what we are looking for here. This namespace thing is entirely related to 
attributes, while groups are a variable concept. What would help were 
"hierarchical attributes", so that one could define metadata "groups" just as 
in an XML file. Possibly something like

float myvar(dim1, dim2)
  cf_attributes:
standard_name: "..."
units: "..."
 OSD_attributes:
measurement_principle: "..."

etc.pp. -- only this would make reading netcdf files a wee bit more complicated 
;-(


Best regards,

Martin

>Perhaps the only solution lies in using netCDF-4's existing namespacing
>mechanism, namely groups (which idea has been proposed before). I
>suspect this too will have it's adherents and detractors!





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Usage of the 'Conventions' attribute (Nan Galbraith)

[Schultz, Martin]

Dear all,

I fully agree with Jonathan's view that it would not be a good idea to call 
this new thing "Convention". On the other hand, I don't really like the term 
"flag_convention_name" either, because it doesn't tell me anything. If I 
understand correctly, then your desire is different from defining a pointer to 
controlled vocabulary. Should it be a similar idea, then I suggest we should 
try to follow the ideas and namings of ISO19115 (without being able to tell you 
right away what the appropriate term would be). If it's cf specific and indeed 
refers to the version of a cf document (or annex or whatever), shouldn't the 
attribute then have a name that starts with "cf_"? E.g. cf_attribute_convention 
?

Cheers,

Martin


Message: 4
Date: Thu, 24 Jan 2013 12:23:33 +1100
From: Jonathan Gregory 
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata]  Usage of the 'Conventions' attribute
Message-ID: <20130124012333.gc22...@met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii

Dear Roy

I understand the need but I tend to think this would not be an appropriate
use of the Conventions attribute, which is a general netCDF attribute, not
specific to CF, and refers to files. I do appreciate the logical similarity
but I would have thought it better to define something more specific in CF
for this purpose.

If this is a need which several users have and is required for exchange of
data, then it is reasonable to propose to add something to CF. Since it's
an extra piece of information referring to flags, maybe an attribute such as
flag_convention_name would work? We could make it a requirement that this
attribute was allowed only if the variable had flag_meanings as well, to
prevent its being used as a substitute for spelling out what the flags mean
(as is necessary for the file to be self-describing).

Best wishes

Jonathan





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Proposal for new standard_names for biomass burning

[Schultz, Martin]

Dear Jonathan, Philip,

 good point! In practice, I think that "expressed_as" means something more 
general than "contained in" so that the "NOx_expressed_as_NO2" case is a 
perfectly valid one. Indeed, that would be the standard_name that would be used 
if "official" inventories were to adopt CF for their data (the US EPA uses 
"short tons of NO2", for example). As Philip says, in our research context we 
usually deal with "expressed_as_NO". Hence, I would advocate to leave things as 
they are now and rework the definition only when needed.

Cheers,

Martin

>Message: 5
>Date: Sat, 5 Jan 2013 14:16:26 +
>From: Jonathan Gregory 
>To: "Cameron-smith, Philip" 
>Cc: "cf-metadata@cgd.ucar.edu" 
>Subject: Re: [CF-metadata] Proposal for new standard_names for biomass
>   burning emissions
>Message-ID: <20130105141626.ga16...@met.reading.ac.uk>
>Content-Type: text/plain; charset=us-ascii

>Dear Philip

>> Jonathan: we already have std_names without a fixed ratio, although it isn't 
>> explicit in the descriptions (eg, 
>> >>atmosphere_mass_content_of_anthropogenic_nmvoc_expressed_as_carbon).  
>> Indeed, this is one of the main
>>reasons people use the 'expressed_as' concept.
>>
>> I did note the tiniest inconsistency for the future.   As proposed, 
>> NOx_expressed_as_NO is consistent with the
>>current description "The phrase 'expressed_as' is used in the construction 
>>A_expressed_as_B, where B is a
>>chemical constituent of A. It means that the quantity indicated by the 
>>standard name is calculated solely
>>with respect to the B contained in A, neglecting all other chemical 
>>constituents of A."
>>
>> However, in the future someone may want NOx_expressed_as_NO2, and NO2 is not 
>> entirely contained in
>>NOx.   To put it another way, the mass of the emission expressed as NO2 is 
>>larger than the mass of the actual
>>NOx emission.
>
>I think your point is similar to what I was trying to say, but it might be 
>that I don't understand this properly.
>I think nmvoc_expressed_as_carbon is fine. It just means we count up the C, 
>never mind what compounds
>actually contain the C. I assume that nox_expressed_as_no means that we 
>pretend all the N in the NOx is
>actually present as NO. Is that right? If so, I think it is well- defined, but 
>it's a bit different from previous
>situations, where B is truly contained in A. C is truly contained in nmvoc.




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Proposal for new standard_names for biomass burning emissions

[Schultz, Martin]

Dear all,

 as per the general CF philosophy to add terms when needed, we propose the 
addition of the following standard_names for emissions from biomass burning. 
These follow the syntax of existing names and merely add three chemical 
species, namely nitrogen_dioxide, molecular_hydrogen, and dimethyl_sulfide (aka 
"DMS"):


tendency_of_atmosphere_mass_content_of_nitrogen_dioxide_due_to_emission_from_savanna_and_grassland_fires

tendency_of_atmosphere_mass_content_of_nitrogen_dioxide_due_to_emission_from_forest_fires

tendency_of_atmosphere_mass_content_of_molecular_hydrogen_due_to_emission_from_savanna_and_grassland_fires

tendency_of_atmosphere_mass_content_of_molecular_hydrogen_due_to_emission_from_forest_fires

tendency_of_atmosphere_mass_content_of_dimethyl_sulfide_due_to_emission_from_savanna_and_grassland_fires

tendency_of_atmosphere_mass_content_of_dimethyl_sulfide_due_to_emission_from_forest_fires

units: kg m-2 s-1

Note, that the definition of emissions for nitrogen_dioxide is tricky: most 
inventories only give emissions for "NOx" (the sum of NO and NO2), and 
sometimes it is not even clear to an uninformed user if these are 
"expressed_as" nitrogen_monoxide or nitrogen_dioxide, or even nitrogen. The 
ratio of emitted NO to emitted NO2 varies by source category, and this is now 
sometimes taken into account in models. Therefore it becomes necessary to 
define emissions specifically for nitrogen_monoxide (already defined as 
standard_name) and nitrogen_dioxide (new proposal).

We should perhaps amend the definition terms for nitrogen_monoxide (and 
nitrogen_dioxide) emissions as follows:
"[...] In some inventories, emissions of nitrogen_monoxide include the fraction 
of nitrogen_oxide emissions that is released in the form of nitrogen_dioxide. 
If this is the case, a comment attribute should be added for clarification."

An even better and clean solution would be the addition of the species name 
"NOx" as follows:

"nox_expressed_as_nitrogen_monoxide":

"NOx" means a combination of two radical species containing nitrogen and 
oxygen: NO+NO2. The phrase 'expressed_as' is used in the construction 
A_expressed_as_B, where B is a chemical constituent of A. It means that the 
quantity indicated by the standard name is calculated solely with respect to 
the B contained in A, neglecting all other chemical constituents of A.

This would entail the definition of the new standard_names (based on 
existing terms):

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_savanna_and_grassland_fires

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_forest_fires

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_agricultural_production

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_agricultural_waste_burning

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_industrial_processes_and_combustion

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_energy_production_and_distribution

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_land_transport

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_maritime_transport

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_waste_treatment_and_disposal

tendency_of_atmosphere_mass_content_of_nox_expressed_as_nitrogen_monoxide_due_to_emission_from_residential_and_commercial_combustion

units: kg m-2 s-1



tendency_of_mass_concentration_of_nox_expressed_as_nitrogen_monoxide_in_air_due_to_emission_from_aviation

units: kg m-3 s-1


Best regards,

Martin and Angelika


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] correction of an emissions-related standard_name

[Schultz, Martin]

Dear all,

 while re-processing the ACCMIP emission data set, we found an error in one 
of the recent standard_name additions for emission mass fluxes:


Due to a typo in the source categories in the original sector definition which 
we once submitted, there is now an error in the sector definition of 
industrial_processes_and_combustion:

The current definition reads: [...] "Industrial processes and combustion" is 
the term used in standard names to describe a collection of emission sources. A 
variable which has this value for the standard_name attribute should be 
accompanied by a comment attribute which lists the source categories and 
provides a reference to the categorization scheme, for example, "IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A2, 2A, 2B, 2C, 
2D and 2E as defined in the 2006 IPCC guidelines for national greenhouse gas 
inventories".


Please replace 2E by 2G (second line from bottom).

2E corresponds to "Production of halocarbons SF6", which is wrong

2G corresponds to "Non-energy use of lubricants/waxes (CO2)", which is correct

There are 22 standard_names 
"tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion"
 affected.

Best regards,

Martin and Angelika


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard names for column amounts (atmospheric chemistry)

[Schultz, Martin]

Hi Andreas,

> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf
> Of Andreas Hilboll
> Sent: Wednesday, December 19, 2012 2:53 AM
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] standard names for column amounts
> (atmospheric
> chemistry)
>

   in addition to what Philip said, let me try to guide you a little more 
specifically concerning some of your questions. Don't feel frightened about the 
discussions that are going to come up. Eventually, there will be an agreement, 
and in the end it's usually a wise decision if you look at it from a little 
distance later. The following comments may help you to identify the potential 
areas for discussion - the better your proposal will address these points "in 
the spirit" of existing CF names, the easier it will be to get the proposal 
accepted smoothly.

> * The canonical way to specify tropospheric NO2 columns in
>   molecules cm^-2 would be to use the standard name
>   "mole_content_of_nitrogen_dioxide_in_troposphere_layer", or rather
>   "troposphere_mole_content_of_nitrogen_dioxide",
>   together with a units attribute of "molecules cm^-2"?

I agree with Philip here, that "troposphere_mole_content..." seems the more 
natural choice. Obviously, this can easily be extended to 
"stratosphere_mole_content..." if you provide a clear definition of what 
"stratosphere" means (in fact I just saw that "troposphere" is also not defined 
very well, it only says "in this layer of the atmosphere"!). We should probably 
change this definition to something more specific, such as "the layer of the 
atmosphere between the earth surface and the tropopause. Generally, the 
tropopause will be defined via the reversal of the temperature gradient with 
altitude as specified by WMO. Other definitions of tropopause are possible, and 
if one of these is used, it should be explained in a comment attribute." -- In 
analogy, the "stratosphere" should be defined as the layer between the 
tropopause and the stratopause.


>
> * What can I do for
> "atmosphere_mole_content_of_nitrogen_dioxide_between_surface_and_XhPa
> ",
> where X is 500?

Here, my suggestion would be to go for the general term "atmosphere_layer" and 
request either a generic comment attribute or a more specific attribute 
(something like "layer_extent" ?) where the exact specification of "between ... 
and ..." should be provided. I don't believe that it would be possible to agree 
on a small confined set of numbers, and since a standard_name is static and 
cannot contain variable elements, one would have to define thouands of  
standard names in order to be able to distinguish any layer between X and Y.

>
> * What about
> "atmosphere_mole_content_of_nitrogen_dioxide_between_XhPa_and_tropopa
> use",
> where X is 500?

Here again, we should try to find a general solution with an additional 
attribute. In fact this discussion could/should be broader than for atmospheric 
composition only, because similar problems might be present for soil variables 
(soil layer between X and Y), and in the ocean as well. In fact you can look 
into the definition of "frozen_water_content_of_soil_layer" as an example. This 
is formulated rather vaguely, I think. So, perhaps this could be a starting 
point for a more general discussion on how to uniformly express "layers" in the 
CF model.

... I just saw your folow-up email. That is a good start!

Best regards,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF calendars (was: problem with times in PSD dataset)

[Schultz, Martin]

Dear Chris,

>> I think a solution shouldn't break current files which followed what had 
>> been a standard for a long time (however ill-advised the standard was).[...]

while I fully support your pledge for backward compatibility, we should also 
avoid stagnation because of too many old hassles that need to be supported. 
Isn't this situation exactly why we need different CF versions? The existing 
files you talk about will carry a CF attribute <= 1.5. If the rules become 
stricter in CF 1.6 (and "1-1-1" will no longer be allowed, for example), there 
shouldn't be any issue with backward compatibility, because any software that 
claims it can read CF-1.5 data will have to allow for "1-1-1" dates and should 
interpret these correctly. In this case, the backward compatibility issue will 
only apply for data files that are newly created, and this is exactly the 
situation where we would like to get away from "1-1-1", isn't it? The other 
potential conflict could arise if someone decides to "clean" an old file and 
bring it to the CF-1.6 standard. Well, in this case, cleaning of the date 
values and attributes would have to be part of the cleanup process.

Cheers,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] new standard name proposal for total ozone in DU

[Schultz, Martin]

Dear all,

  I would also like to support this proposal. And I thank Philip for his 
careful thinking.

>> If these were the only aspects to consider then I would be against the new 
>> std_name.  However, there
>> are many more species than ozone, and ozone is the only one that I see 
>> expressed as equivalent thickness.
>> This means that we will surely end up wanting atmosphere_mole_content for 
>> other species, so it makes
>> sense to have it for ozone too.  For me, this tips the balance in favor of 
>> accepting the proposed std_name.

 Wouldn't this even call for recommending the use of 
atmosphere_mole_content as preferred option? Since both quantities are 
essentially the same and both are reported in DU, it will be merely a naming 
thing in practice. The advantage being that it will be easier for outsiders to 
understand that an atmosphere_mole_content of ozone is the same concept as an 
atmosphere_mole_content of some other species, whereas this gets lost if the 
default for ozone is equivalent_thickness_at_stp_of_atmosphere_ozone_content 
while all other compounds use atmosphere_mole_content.

Should we even go as far as to deprecate the use of 
equivalent_thickness_at_stp_of_atmosphere_ozone_content?

Philip also raises a good point with respect to alias names: has it been 
stated clearly that they must refer to "exactly the same quantity"? I believe 
they should, because if we allow "trivial" unit conversions to count as 
aliases, then even "wavelength" and "frequency" could be considered of aliases, 
which surely no one would want.

Best regards,

Martin


Date: Thu, 6 Dec 2012 23:41:16 +
From: "Cameron-smith, Philip" 
To: "alison.pamm...@stfc.ac.uk" ,
"christophe.le...@aeronomie.be" 
Cc: "victoria.benn...@stfc.ac.uk" ,
"cf-metadata@cgd.ucar.edu" 
Subject: Re: [CF-metadata] new standard name proposal for total ozone
in DU
Message-ID:
<298f51abd432da4288ce6b8c469a2afc338...@prdexmbx-04.the-lab.llnl.gov>
Content-Type: text/plain; charset="us-ascii"

Hi All,

After considerable thought, I do support addition of this std_name, but 
recommend that we add a comment to the description (as described below).

The problem is that

atmosphere_mole_content_of_ozone (proposed, units = moles/m2, typically 
expressed in DU)

and

equivalent_thickness_at_stp_of_atmosphere_ozone_content (already in CF, units = 
m, typically expressed in DU)

are essentially the same. Although they have nominally different units, the 
usual unit used in both cases is Dobson Units (DU).  1 DU was originally 
defined as 10 micrometers of ozone at STP (ie a unit of distance), but can 
equivalently defined as 446.2... micromoles/m2 (ie, related to 'moles/m2'), see 
http://en.wikipedia.org/wiki/Dobson_unit.  The conversion is trivially done 
through the ideal gas law.

A user putting ozone column data into CF is just as likely to use one std_name 
as the other, and use DU for the units in either case.  It would be appropriate 
to compare the data directly (with no unit conversion if both are put in as DU).

Hence, different datasets may contain the same data using different std_names, 
which isn't ideal.

On the other hand, the official units are different, and we have a related 
issue where we have separate std_names for quantities in 'moles' and 'mass', 
which are often trivial to convert between in many cases.

If these were the only aspects to consider then I would be against the new 
std_name.  However, there are many more species than ozone, and ozone is the 
only one that I see expressed as equivalent thickness.  This means that we will 
surely end up wanting atmosphere_mole_content for other species, so it makes 
sense to have it for ozone too.  For me, this tips the balance in favor of 
accepting the proposed std_name.

Unfortunately, I don't think we can mitigate the problems using an alias 
because the std_names have different official units.

Hence, I propose that we simply add a note at the end of the descriptions for 
atmosphere_mole_content_of_ozone and 
equivalent_thickness_at_stp_of_atmosphere_ozone_content alerting users to the 
existence of the other std_name:

"Note: Ozone columns can be stored in either 
equivalent_thickness_at_stp_of_atmosphere_ozone_content or 
atmosphere_mole_content_of_ozone."

Best wishes,

 Philip

---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Pr

Re: [CF-metadata] Extensions to the Standard Name table

[Schultz, Martin]

Great! Looking forward to test this!

Cheers,

Martin

-Ursprüngliche Nachricht-
Von: Leadbetter, Adam [mailto:al...@bodc.ac.uk] 
Gesendet: Montag, 22. Oktober 2012 14:45
An: Lowry, Roy K.; Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: RE: [CF-metadata] Extensions to the Standard Name table

Hi Martin

I'll aim to have the small demonstrator with mappings in place towards the end 
of this week, or early next week.

Thanks

Adam

From: Lowry, Roy K.
Sent: 21 October 2012 17:17
To: Schultz, Martin; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Subject: RE: [CF-metadata] Extensions to the Standard Name table

OK Martin,

I'm on leave for the next 2 weeks, but will try and get a demonstration mapping 
with 4 or 5 contaminants mapped the week after I get back (unless Adam can do 
something in the mean time).

Cheers, Roy.

____
From: Schultz, Martin [m.schu...@fz-juelich.de]
Sent: 21 October 2012 15:00
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Subject: AW: [CF-metadata] Extensions to the Standard Name table

Hello Roy,

 this sounds indeed convincing. If there is indeed some funding to 
establish this by January, and if we can then somehow ensure continuity 
(someone would have to update the mapping whenever there are changes to the 
standard_name table, and we should be in a position to add more rows to the 
table even after funding will have ended), then this sounds like a good plan.

Cheers,

Martin


Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Gesendet: Sonntag, 21. Oktober 2012 10:21
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Betreff: RE: [CF-metadata] Extensions to the Standard Name table

Hello Marin,

I'm not sure what would be possible using the string-matching SPARQL approach. 
It would be perfectly possible to do that from a relational database using SQL 
(which I do know) and so it may be possible.  I'll see if Adam can come up with 
anything (I've yet to learn the language).

However, I am certain that if we installed a mapping (maybe a day's work) then 
it could be done - all the query would have to do is identify whether or not 
there is a mapping from the Standard Name reference to the EEA vocabulary and 
match on it if it exists.

Installing a mapping in NVS fulfils exactly the same function as adding a link 
to the Standard Name table.  The difference is that the former process simply 
involves population of operational technological infrastructure (a mapping is a 
row in an Oracle table) with some funding support if the work is done before 
the end of January, whereas the latter would require infrastructure development 
in addition to population.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 20 October 2012 11:43
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Extensions to the Standard Name table Dear Roy,

 thanks a lot for this nice example of true interoperability. Yet, two 
questions remain: 1) what I would be even more interested in is the inverse 
problem, i.e. given a standard_name, I would like to know which compound it 
contains. 2) I expect that this is more difficult, in particular if we don't 
know a priori that the given standard_name does contain a compound name. 
Generally, this is where I see the difficulty with your brokered approach: how 
do you find out which controlled vocabulary list(s) have to be applied in order 
to identify the components of a standard_name? Think of 
"tendency_of_X_due_to_emissions_from_Y" where you want to link both the 
compound and the emission sector to the respecitve controlled vocabulary table. 
Then, in another standard_name you will find some marine bacteria or so which 
relate to yet another vocabulary list, and so on. Unless I miss the point here, 
I would still argue that it will be more efficient and less ambiguous if the 
link would be provided in the standard_name table itself.

What do you think?

Cheers,

Martin




Date: Fri, 19 Oct 2012 12:30:42 +0100

From: "Lowry, Roy K." mailto:r...@bodc.ac.uk>>

To: "cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>" 
mailto:cf-metadata@cgd.ucar.edu>>

Subject: [CF-metadata] Extensions to the Standard Name table

Message-ID:


<40829b0e077c1145a6de44d39b3830a921f5722...@nerckwmb1.ad.nerc.ac.uk<mailto:40829b0e077c1145a6de44d39b3830a921f5722...@nerckwmb1.ad.nerc.ac.uk>>

Content-Type: text/plain; charset="us-ascii"



Dear All,



Martin Schultz was proposing an extension to the Standard Name table to provide 
a means of easily identifying the Standard Names associated with a given 
atmospheric contaminant.  What follows provides an alternative way to address 
his use case

Re: [CF-metadata] Extensions to the Standard Name table

[Schultz, Martin]

Hello Roy,

 this sounds indeed convincing. If there is indeed some funding to 
establish this by January, and if we can then somehow ensure continuity 
(someone would have to update the mapping whenever there are changes to the 
standard_name table, and we should be in a position to add more rows to the 
table even after funding will have ended), then this sounds like a good plan.

Cheers,

Martin


Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Gesendet: Sonntag, 21. Oktober 2012 10:21
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Cc: Leadbetter, Adam
Betreff: RE: [CF-metadata] Extensions to the Standard Name table

Hello Marin,

I'm not sure what would be possible using the string-matching SPARQL approach. 
It would be perfectly possible to do that from a relational database using SQL 
(which I do know) and so it may be possible.  I'll see if Adam can come up with 
anything (I've yet to learn the language).

However, I am certain that if we installed a mapping (maybe a day's work) then 
it could be done - all the query would have to do is identify whether or not 
there is a mapping from the Standard Name reference to the EEA vocabulary and 
match on it if it exists.

Installing a mapping in NVS fulfils exactly the same function as adding a link 
to the Standard Name table.  The difference is that the former process simply 
involves population of operational technological infrastructure (a mapping is a 
row in an Oracle table) with some funding support if the work is done before 
the end of January, whereas the latter would require infrastructure development 
in addition to population.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 20 October 2012 11:43
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Extensions to the Standard Name table
Dear Roy,

 thanks a lot for this nice example of true interoperability. Yet, two 
questions remain: 1) what I would be even more interested in is the inverse 
problem, i.e. given a standard_name, I would like to know which compound it 
contains. 2) I expect that this is more difficult, in particular if we don't 
know a priori that the given standard_name does contain a compound name. 
Generally, this is where I see the difficulty with your brokered approach: how 
do you find out which controlled vocabulary list(s) have to be applied in order 
to identify the components of a standard_name? Think of 
"tendency_of_X_due_to_emissions_from_Y" where you want to link both the 
compound and the emission sector to the respecitve controlled vocabulary table. 
Then, in another standard_name you will find some marine bacteria or so which 
relate to yet another vocabulary list, and so on. Unless I miss the point here, 
I would still argue that it will be more efficient and less ambiguous if the 
link would be provided in the standard_name table itself.

What do you think?

Cheers,

Martin




Date: Fri, 19 Oct 2012 12:30:42 +0100

From: "Lowry, Roy K." mailto:r...@bodc.ac.uk>>

To: "cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>" 
mailto:cf-metadata@cgd.ucar.edu>>

Subject: [CF-metadata] Extensions to the Standard Name table

Message-ID:


<40829b0e077c1145a6de44d39b3830a921f5722...@nerckwmb1.ad.nerc.ac.uk<mailto:40829b0e077c1145a6de44d39b3830a921f5722...@nerckwmb1.ad.nerc.ac.uk>>

Content-Type: text/plain; charset="us-ascii"



Dear All,



Martin Schultz was proposing an extension to the Standard Name table to provide 
a means of easily identifying the Standard Names associated with a given 
atmospheric contaminant.  What follows provides an alternative way to address 
his use case.  Go to the URL http://vocab.nerc.ac.uk/sparql/ and copy the 
SPARQL query at the end of this message into the box, choose your output format 
and press 'Get Results'. If you don't want 'carbon monoxide' simply replace 
'Carbon monoxide' by another valid EEA contaminant name.



For the techies on the list, this is done by a federated SPARQL query involving 
SPARQL endpoints on vocabulary servers at BODC and the EEA. This is based on 
string matching, but could be made more robust by implementing an EEA/Standard 
Names mapping in NVS should this be requested by the CF community.



Cheers, Roy.





PREFIX skos: 
<http://www.w3.org/2004/02/skos/core#<http://www.w3.org/2004/02/skos/core>>

PREFIX j.0: <http://rdfdata.eionet.europa.eu/airbase/schema/>

PREFIX rdfs: 
<http://www.w3.org/2000/01/rdf-schema#<http://www.w3.org/2000/01/rdf-schema>>

SELECT ?urie ?labele ?urin ?labeln WHERE {

  BIND("Carbon monoxide" AS ?pollutant)

  SERVICE<http://cr.eionet.europa.eu/sparql>

  {

?urie skos:inScheme 
<http://rdfdata.eionet.europa.e

Re: [CF-metadata] Extensions to the Standard Name table

[Schultz, Martin]

Dear Roy,

 thanks a lot for this nice example of true interoperability. Yet, two 
questions remain: 1) what I would be even more interested in is the inverse 
problem, i.e. given a standard_name, I would like to know which compound it 
contains. 2) I expect that this is more difficult, in particular if we don't 
know a priori that the given standard_name does contain a compound name. 
Generally, this is where I see the difficulty with your brokered approach: how 
do you find out which controlled vocabulary list(s) have to be applied in order 
to identify the components of a standard_name? Think of 
"tendency_of_X_due_to_emissions_from_Y" where you want to link both the 
compound and the emission sector to the respecitve controlled vocabulary table. 
Then, in another standard_name you will find some marine bacteria or so which 
relate to yet another vocabulary list, and so on. Unless I miss the point here, 
I would still argue that it will be more efficient and less ambiguous if the 
link would be provided in the standard_name table itself.

What do you think?

Cheers,

Martin




Date: Fri, 19 Oct 2012 12:30:42 +0100

From: "Lowry, Roy K." mailto:r...@bodc.ac.uk>>

To: "cf-metadata@cgd.ucar.edu" 
mailto:cf-metadata@cgd.ucar.edu>>

Subject: [CF-metadata] Extensions to the Standard Name table

Message-ID:


<40829b0e077c1145a6de44d39b3830a921f5722...@nerckwmb1.ad.nerc.ac.uk>

Content-Type: text/plain; charset="us-ascii"



Dear All,



Martin Schultz was proposing an extension to the Standard Name table to provide 
a means of easily identifying the Standard Names associated with a given 
atmospheric contaminant.  What follows provides an alternative way to address 
his use case.  Go to the URL http://vocab.nerc.ac.uk/sparql/ and copy the 
SPARQL query at the end of this message into the box, choose your output format 
and press 'Get Results'. If you don't want 'carbon monoxide' simply replace 
'Carbon monoxide' by another valid EEA contaminant name.



For the techies on the list, this is done by a federated SPARQL query involving 
SPARQL endpoints on vocabulary servers at BODC and the EEA. This is based on 
string matching, but could be made more robust by implementing an EEA/Standard 
Names mapping in NVS should this be requested by the CF community.



Cheers, Roy.





PREFIX skos: 

PREFIX j.0: 

PREFIX rdfs: 

SELECT ?urie ?labele ?urin ?labeln WHERE {

  BIND("Carbon monoxide" AS ?pollutant)

  SERVICE

  {

?urie skos:inScheme 
.

?urie skos:prefLabel ?labele.

?urie j.0:pollutant ?pollutant.

  }.

   skos:member ?urin.

  ?urin skos:prefLabel ?labeln.

  ?urin skos:definition ?defn.

  FILTER CONTAINS (str(lcase(?defn)),str(lcase(?pollutant)))

}





PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Schultz, Martin]

Hi Roy,

 exactly!Just how can we get there?

Cheers,

Martin

-Ursprüngliche Nachricht-
Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk] 
Gesendet: Samstag, 22. September 2012 18:24
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: RE: [CF-metadata] Another potentially useful extension to the 
standard_name table

Hello Martin,

I understand exactly what you want - or at least I thing I do.  I think that 
you would like to enter a URL representing the concept 'carbon monoxide' and 
get back a document giving you all the Standard Names pertaining to carbon 
monoxide.  Am I right?

My vision - which I'm pretty sure John Graybeal shares - is of a grammar in 
which each element is populated from a controlled vocabulary comprising 
concepts that are included in a thesaurus or more likely a full-blown ontology.

Does that sound like what you need?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
 tags (specifically ). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it "parseable" in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for "air_temperature" would be "temperature_of_air" in 
order to identify the relation of, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use "air_temperature" 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is "temperature" and the medium is "air".

Of course, I am not in charge if creating a new standard_name table (and I 
am sure no one would like me to be in charge ;-), but I hope this illustrates 
the problem we have with the current table. Sad as it seems, I really see only 
two options: A) if most people agree that a grammar-based approach is the way 
to go, then we need to start overhauling the standard_name table (track ticket 
#91) and slowly transform it into something that "makes sense" (please don't 
misunderstand this phrase!). Option B): we leave things as they are, but then 
we would indeed have to further discuss the  idea, because this 
would provide a way of interpreting standard_names without having to parse them 
(which, as I hope to have made clear, is impossible at present).


  I agree with the precautions that were raised in that the s 
pose some danger of becoming uncontrolled and simply too many. However, perhaps 
it is not so bad, because the standard_names usually consist of no more than 6 
lexical tokens, and if we could agree that there should be not more than one 
 per lexical token (and these would anyhow be optional), then it 
appears manageable and finite.

With somewhat Quichotte'sque feelings,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: 

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Schultz, Martin]

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
 tags (specifically ). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it "parseable" in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for "air_temperature" would be "temperature_of_air" in 
order to identify the relation of, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use "air_temperature" 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is "temperature" and the medium is "air".

Of course, I am not in charge if creating a new standard_name table (and I 
am sure no one would like me to be in charge ;-), but I hope this illustrates 
the problem we have with the current table. Sad as it seems, I really see only 
two options: A) if most people agree that a grammar-based approach is the way 
to go, then we need to start overhauling the standard_name table (track ticket 
#91) and slowly transform it into something that "makes sense" (please don't 
misunderstand this phrase!). Option B): we leave things as they are, but then 
we would indeed have to further discuss the  idea, because this 
would provide a way of interpreting standard_names without having to parse them 
(which, as I hope to have made clear, is impossible at present).

  I agree with the precautions that were raised in that the s 
pose some danger of becoming uncontrolled and simply too many. However, perhaps 
it is not so bad, because the standard_names usually consist of no more than 6 
lexical tokens, and if we could agree that there should be not more than one 
 per lexical token (and these would anyhow be optional), then it 
appears manageable and finite.

With somewhat Quichotte'sque feelings,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Another potentially useful extension to the standard_name table: OFFLINE RESPONSE

[Schultz, Martin]

Hi Robert,

 very good points! I like this idea of hierarchical 
... and ... structures. I just 
don't speak XML well enough myself yet ;-)  Only for the canonical_units things 
are set in stone already, all other things are just beginning to be defined.

   Just one question/comment, though: if we plan on further extending this 
concept beyond , wouldn't it then make sense to generalize this 
further? Example:

trimethylbenzene
   ...

etc. ?  Or would this make it again more difficult to parse?

Cheers,

Martin

Von: Robert Muetzelfeldt [mailto:r.muetzelfe...@ed.ac.uk]
Gesendet: Donnerstag, 13. September 2012 21:50
An: Schultz, Martin
Betreff: Fwd: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table: OFFLINE RESPONSE

Hi Martin,

I sent the following response to your email to the list this morning, but it 
has not yet appeared (being moderated? - but I've posted OK before).   So I 
thought I would send you the reply directly, so you can be thinking about it.  
If it's wrong/irrelevant/unworkable (given existing constraints in the XML 
Schema or tools for handling these documents), then do feel free to say so when 
my email eventually appears on the list.  I won't be upset.

Cheers,
Robert


 Original Message 
Subject:

Re: [CF-metadata] Another potentially useful extension to the standard_name 
table

Date:

Thu, 13 Sep 2012 10:21:13 +0100

From:

Robert Muetzelfeldt <mailto:r.muetzelfe...@ed.ac.uk>

To:

cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>



Hi Martin,

Is there some reason why the  element must have a flat set of 
sub-elements, as in your example below?It seems to me that from an XML 
data-design point-of-view, a neater data model would be:

...See note [1] below
...
 ... see note [2] below ...
...








This design is:
- more in keeping with conventional XML designs;
- allows for additional forms of 'status' without changing the DTD/Schema;
- facilitates processing (you are parsing *only* XML; you don't need separate 
code to parse
  the text string for each of your 3 original elements).

It is a matter of taste as to whether you prefer the above design of the 
 element (i.e. with two (XML) attributes), or whether you would 
prefer to have 'status' and 'name' as two sub-elements of .

The following notes are not directly relevant to your suggestion, but I might 
as well make the points now:

Note [1]
A similar argument as the above applies to the two  elements, 
which would I think be better represented as:

or

...
...

But it may be that this decision is already fixed in stone.

Note [2]
A similar argument applies to , except here I think the 
principled approach would be to use the W3C Units in MathML ( 
http://www.w3.org/TR/mathml-units/) or UnitsML ( http://unitsml.nist.gov/), 
since both represent a concerted effort to develop a standard for representing 
units in a machine-processable format.I can think of several reasons why 
people might object vigourously to either solution: the current design is also 
already fixed in stone; it is harder to write my hand; it is harder for humans 
to read; it is much more verbose; and possibly quite simply that  may 
have to have a flat list of sub-elements (as per the first sentence of this 
email).   However, these standards exist for a good reason, and  we should have 
a good reason for not adopting them.

Cheers,
Robert



On 13/09/12 08:09, Schultz, Martin wrote:
Dear all,

 during the recent discussion on "compound_name" as additional tag in the 
standard_names.xml file and in relation to track ticket #90 it occurred to me 
that another useful addition could be to express the "need" of certain variable 
attributes in this table as well. This refers to the attempt of creating a 
"CF-1.6-strict" standard which would have more things mandatory in order to 
better support interoperable applications.

 One example (related to the new emission standard_names) could be:


-
   Alcohols
   
http://rdfdata.eionet.europa.eu/airquality/components/??http://rdfdata.eionet.europa.eu/airquality/components/??%3c/compound_codelist>>
 # ??
kg m-2 s-1
   "..." 
   None
   emission_sector, emission_sector_reference, 
compound_group_members
   comments


The idea is that "optional" refers to "could" in the description, "recommended" 
to "should", and "required" to "shall".

Best regards,

Martin


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszent

[CF-metadata] Another potentially useful extension to the standard_name table

[Schultz, Martin]

Dear all,

 during the recent discussion on "compound_name" as additional tag in the 
standard_names.xml file and in relation to track ticket #90 it occurred to me 
that another useful addition could be to express the "need" of certain variable 
attributes in this table as well. This refers to the attempt of creating a 
"CF-1.6-strict" standard which would have more things mandatory in order to 
better support interoperable applications.

 One example (related to the new emission standard_names) could be:


-
   Alcohols
   
http://rdfdata.eionet.europa.eu/airquality/components/??http://rdfdata.eionet.europa.eu/airquality/components/??%3c/compound_codelist>>
 # ??
kg m-2 s-1
   "..." 
   None
   emission_sector, emission_sector_reference, 
compound_group_members
   comments


The idea is that "optional" refers to "could" in the description, "recommended" 
to "should", and "required" to "shall".

Best regards,

Martin


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Expanding the standard_name metadata

[Schultz, Martin]

Hi John,

 sounds we are converging here. So, perhaps I should re-consider the 
"compound_name" attribute and generalize it. We all agree that the URL is the 
definitive reference from where the term should be obtained. Now, there are two 
cases which we (i.e. eventually some interoperable application) should be able 
to handle:

case 1: one of the 27 namespace servers from all the different communities 
involved happens to be down when the application needs to access it in order to 
find out the compound_name. One can argue that it's the responsibility of the 
application to provide a fallback solution in this event (which would be some 
cached version of the vocabulary list retrieved earlier), but we could also say 
that this fallback solution would be provided within the standard_name table 
via the "resolved" compound_name tag - or more generally, if X_codelist fails, 
then X_name will be the "value to the best of our knowledge". Technically, one 
could for example establish a procedure where all X_names would be 
automatically resolved upon creating a new standard_name table, i.e. at each 
release.

case 2: some community re-thinks their controlled vocabulary, and what was 
always called "hydrocarbonoclastic_bacteria" would now be called something 
else. In this case we would of course get an inconsistency between a 
standard_name term and the component that is controlled by the external list. 
Yes, there is a procedure: we can request a standard_name change and move the 
old name to the alias section. Should we then allow X_codelist also for aliases 
(given that the old name is still available)? We can hope that this case 
doesn't happen very often. If it would then we may need to rethink the way how 
standard_names are adopted (in the case of change requests). But we could end 
up with an inconsistency between the standard_name and its component, at least 
temporarily.

While I can see that the explicit addition of the X_name tag could potentially 
lead to yet another level of inconsistency, I would argue that it might help 
identify problems of nature #2, and that the risk of inconsistencies is small 
if we adopt the approach suggested in #1, i.e. automatic re-harvesting in the 
event of a standard_name table update.

I can see that this almost conceptual change to the standard_names table could 
lead to a number of issues we will only find out if we try. Perhaps it would be 
best to create a test version of the current table (version 20) including a 
couple of these X_name and X_codelist pairs and see how it can actually be used 
and what kind of problems we encounter. Then, after some testing we could 
probably come up with a more robust description of what exactly should be done 
and how it should be done. If you agree I could make a start and post a 
modified table somewhere so that you (or someone else) could add some more 
codelist/name tags from their field.

Best regards,

Martin







Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Expanding the standard_name metadata (Jonathan Gregory)

[Schultz, Martin]

Dear Jonathan,

  thanks for your encouraging mail and the specific questions. Please find 
my reply below:

* What if there is more than one compound involved in a standard name? This 
could be the case with the existing construction using expressed_as, and you 
can probably imagine better than me other situations where standard_names might 
want to name more than one species.

   According to my understanding, these names will still refer to one 
particular "compound" (or "species" if you like). 
"Nitrogen_dioxide_expresses_as_nitrogen" is still the same as 
"nitrogen_dioxide", only that the mass units are given relative to "N" rather 
than "NO2". I cannot think of a good example where you will indeed find more 
than one compound name in the standard_name and where you actually aim at 
pointing to more than one compound at the same time. An example like 
"photolysis_frequency_of_nitrogen_trioxide_decomposing_into_nitrogen_dioxide_and_atomic_oxygen"
 (hypothetical example at present) lists 3 compounds, but it is not the 
compound that is at the center here, but rather the rate (or "frequency"), so 
in this case I would argue not to include a "compound_name" tag.

* Is it specifically only compounds that you want to identify, that is, 
excluding elements, lumped groups of components, ions or other chemical 
species? In my draft lexicon, I have a category "species". This includes all 
chemical species, but also biological species and some other things such as 
aerosol and grapel. That's because they appear in similarly patterened 
standard_names. Do we need to draw a semantic distinction? That would increase 
the number of standard_name patterns.

This is indeed a tough decision. Without having thought through this in all 
detail, my gut feeling tells me that it might be more useful to distinguish 
between fields or applications here and adopt a rather cautious approach when 
adding such tags. Otherwise we will soon end up in a similar situation where 
the tags are so broad that they cannot be parsed automatically, and we will 
invent yet another level of classification. What I have in mind would be an 
application that would lexically parse the standard_name table and then can use 
such information to offer "informed choices" to the user. For example, you 
create a plot of ozone concentrations (sorry, that is 
"mole_fraction_of_ozone_in_air"), and the program would then tell you which 
other variables about ozone are in the dataset (or available from some web 
service). So far, this should also work if, for example, marine biological 
species were labeled by the same token. But if you want to make the relations 
one level bigger a
 nd get suggestions for "other relevant atmospheric chemical compounds", then 
the marine bacteriae, algae, fish and mammals would literally flood the system.

 As to "aerosol" and "graupel", this will require some more discussion, 
because aerosol is seen by some also as a medium, rather than a compound. I am 
not sure at present which concept would be more meaningful for these.

Best regards,

Martin





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Expanding the standard_name metadata

[Schultz, Martin]

Hi John,

the problem is that the compound name is obvious for a human, but very hard 
to extract for a machine, because we don't have a strict set of grammar rules. 
What you are suggesting sounds almost like you wanted to replace the 
standard_names by some other mechanism of controlled vocabulary, a collection 
of URIs from different fields and different servers which would point to the 
actual reference term in each case? Perhaps I got you wrong here, but I would 
feel rather uneasy about going too far in this direction at present. We were 
very happy to find out in Dublin that the community (of atmospheric chemists) 
is beginning (!) to recognize standard_names as a valuable resource enabling 
them to speak about the same thing with the same words (even though sometimes a 
bit clumsy), and to have one "master list" of terms seems much simpler and more 
resilient to me at present. Yet, it may be good to reflect within the 
standard_name list what is often brought up in the list discussions anyhow, 
that is that some communities have established controlled vocabulary for their 
field, and - as far as I follow the discussions - this is usually a good 
argument for accepting a standard_name proposal, unless it is in conflict with 
other rules.

The specific situation in atmospheric chemistry (maybe not so specific but 
at least very prominent) is that the "variable name space" is not 
1-dimensional, but multi-dimensional, i.e. for each (new) compound we can 
easily add a dozen or more new terms (= standard_names) which describe the 
molar fraction or mass content in the atmosphere, emission or deposition fluxes 
(due to a myriad individual processes if need be), chemical reaction rates or 
turnover rates, etc. My proposal to add the compound_name and a URI/URL to the 
accepted standard vocabulary list for compounds merely aims at making sure we 
can link the various compound properties together, so that an application can 
understand that "mole_fraction_of_trimethylbenzene_in_air" is linked to 
"tendency_of_atmosphere_mass_content_of_trimethylbenzene_in_air_due_to_emissions_from_traffic",
 for example. If you show me a parser that can extract all compound names from 
the standard_name table and which would work for all future versions of the 
standard_name table, then we might not need this (although the reference to a 
controlled vocabulary list might still be useful and take a little 
responsibility away from CF).

Cheers,

Martin



Von: John Graybeal [mailto:jgrayb...@ucsd.edu]
Gesendet: Montag, 10. September 2012 18:28
An: Schultz, Martin
Cc: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Betreff: Re: [CF-metadata] Expanding the standard_name metadata

Congratulations on your great meeting!

Concur that when the name is derivable fairly obviously from the other matter, 
it should not be required. In this case the CF name is supposed to be clear 
enough that the compound name should be within it already. Suggest this be 
available as an option if you value it highly (it is perhaps as much the label, 
as the unique identifier?).

We are bootstrapping best semantic practices for a long lifetime of their use 
(hopefully), and so having a URL (well, URI/IRI; yours works) is the principal 
computational reference. (How does the computer know with some confidence what 
the thing is?) Yes, definitely a web 2.0 kind of answer. Although a particular 
unique identifier may no longer be maintained in 10 or 20 years, it is likely 
enough of a 'standard reference' that it has been mapped to its replacement, or 
even forward linked from the old URL. Absolute worst case, a web search should 
find traces of it.

To generalize this (for creatures, phenomena, etc.), could we call it not 
"compound_codelist", but "object_codelist" or "object_IRI", as the compound is 
the direct object of the prepositional phrase?  OK, that's pretty 
grammar-centric and therefore obscure, but I see the names quickly described 
via their mapped components (a great thing!). This is very much the first step 
of that.

John

On Sep 10, 2012, at 02:35, Schultz, Martin wrote:


Hi Roy,

 thanks for supporting this idea. Why include the "compound_name"? I didn't 
really think about this, but only copied what is common practice in ISO 
metadata files. They usually pair a name with the link to the controlled 
vocabulary list. It could have to do with resilience. What do you do if the 
controlled vocabulary server doesn't work at the time when you need it? 
Actually, I would tend to think that the "compound_name" tag is the more 
important one, and I would see the URL more in the sense of a bibliographic 
reference. In a sense, this bibliographic reference lends some weight to the 
name. But perhaps I am still living too much in the web 1.0 world?

Cheers,

Martin


Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk]<mailto:[

Re: [CF-metadata] Expanding the standard_name metadata

[Schultz, Martin]

Hi Roy,

 thanks for supporting this idea. Why include the "compound_name"? I didn't 
really think about this, but only copied what is common practice in ISO 
metadata files. They usually pair a name with the link to the controlled 
vocabulary list. It could have to do with resilience. What do you do if the 
controlled vocabulary server doesn't work at the time when you need it? 
Actually, I would tend to think that the "compound_name" tag is the more 
important one, and I would see the URL more in the sense of a bibliographic 
reference. In a sense, this bibliographic reference lends some weight to the 
name. But perhaps I am still living too much in the web 1.0 world?

Cheers,

Martin


Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
Gesendet: Montag, 10. September 2012 11:03
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: RE: Expanding the standard_name metadata

Hello Martin,

I really like the idea of linking the Standard Name to a resolveable URL for 
the compound, but would question the need for adding the compound name to the 
standard name table as well as the URL.  The plaintext compound name has to be 
included in the Standard Name and is available through resolution of the URL.  
Why introduce a further duplicate of the information with the inherent risk of 
discrepencies creeping in?

In a similar vein, should Standard Names get deeper into biological parameters 
it would be good to include a link to the World Register for Marine Species 
(WoRMS) for the taxon.

Cheers, Roy.

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 10 September 2012 09:33
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Expanding the standard_name metadata
Dear all,

 last week, we had a rather successful workshop on "Metadata for air 
quality and atmospheric composition" in Dublin. It was nice to see that the 
community (i.e. those present) seemed to agree without much discussion, that 
ISO 19115 (-1) is the way to go for discovery metadata, while CF is the way 
forward for descriptive metadata to be stored in (usually) netcdf data files. 
The main discussions at the workshop centered around ISO issues, but there was 
one interesting point that came up with respect to CF standard_names and their 
relation to controlled vocabulary:

We did have discussions on this list earlier about a more grammar-oriented 
approach, and this was also brought up at our workshop again, mainly in light 
of the "threat" that the atmospheric composition group will soon begin to flood 
this email list with hundreds of new names in order to add additional chemical 
compounds. As we have seen with the problem of standard_names for emissions, 
this is stretching the limits of the current ways to operate and publish new 
standard_names. I don't want to argue against the concept of one "flat" master 
list (we have been through this and there are good reasons for sticking to this 
concept), but I would like to stipulate a discussion about adding more 
"metadata" to the standard_name table in order to better link it to other 
controlled vocabulary lists and avoid confusing inconsistencies, for example in 
the naming of chemical compounds. Specifically, I would like to propose two 
"conditional" tags compound_name and compound_codelist in the standard_name 
list which shall appear for all standard_names having to do with chemical 
compounds. Example:

-
   Carbon monoxide
   
http://rdfdata.eionet.europa.eu/airquality/components/10
kg m-2
   "Content" indicates a quantity per unit area. The "atmosphere 
content" of a quantity refers to the vertical integral from the surface to the 
top of the atmosphere. For the content between specified levels in the 
atmosphere, standard names including content_of_atmosphere_layer are used. The 
chemical formula of carbon monoxide is CO.


In a way, this may be seen as duplication of information, but it would 
really help to tie ends together, because it is practically impossible to parse 
the standard_names in order to extract such information (due to the lack of a 
strict grammar). There may be other tags which could be useful to add, and one 
will have to decide about the pros and cons in each case. However, for compound 
names I would see a clear need arising now.

Best regards,

Martin


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
G

[CF-metadata] Expanding the standard_name metadata

[Schultz, Martin]

Dear all,

 last week, we had a rather successful workshop on "Metadata for air 
quality and atmospheric composition" in Dublin. It was nice to see that the 
community (i.e. those present) seemed to agree without much discussion, that 
ISO 19115 (-1) is the way to go for discovery metadata, while CF is the way 
forward for descriptive metadata to be stored in (usually) netcdf data files. 
The main discussions at the workshop centered around ISO issues, but there was 
one interesting point that came up with respect to CF standard_names and their 
relation to controlled vocabulary:

We did have discussions on this list earlier about a more grammar-oriented 
approach, and this was also brought up at our workshop again, mainly in light 
of the "threat" that the atmospheric composition group will soon begin to flood 
this email list with hundreds of new names in order to add additional chemical 
compounds. As we have seen with the problem of standard_names for emissions, 
this is stretching the limits of the current ways to operate and publish new 
standard_names. I don't want to argue against the concept of one "flat" master 
list (we have been through this and there are good reasons for sticking to this 
concept), but I would like to stipulate a discussion about adding more 
"metadata" to the standard_name table in order to better link it to other 
controlled vocabulary lists and avoid confusing inconsistencies, for example in 
the naming of chemical compounds. Specifically, I would like to propose two 
"conditional" tags compound_name and compound_codelist in the standard_name 
list which shall appear for all standard_names having to do with chemical 
compounds. Example:

-
   Carbon monoxide
   
http://rdfdata.eionet.europa.eu/airquality/components/10
kg m-2
   "Content" indicates a quantity per unit area. The "atmosphere 
content" of a quantity refers to the vertical integral from the surface to the 
top of the atmosphere. For the content between specified levels in the 
atmosphere, standard names including content_of_atmosphere_layer are used. The 
chemical formula of carbon monoxide is CO.


In a way, this may be seen as duplication of information, but it would 
really help to tie ends together, because it is practically impossible to parse 
the standard_names in order to extract such information (due to the lack of a 
strict grammar). There may be other tags which could be useful to add, and one 
will have to decide about the pros and cons in each case. However, for compound 
names I would see a clear need arising now.

Best regards,

Martin


PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] GEO AQ CoP Workshop Dublin: Registration deadline approaching!

[Schultz, Martin]

Dear CF mailing list,
 We would like to draw your attention to the approaching deadline for 
registration to the workshop on "Metadata for air quality and atmospheric 
composition" in Dublin, Sept 5-7, 2012. Registration will close on Friday, 31 
Aug., end of business. If you intend to participate in the workshop and have 
not registered yet, please do so urgently by filling the form at 
http://cop.nilu.no/Registration/tabid/10710/language/nb-NO/Default.aspx.
 In the meantime we have published an updated draft agenda and a couple of 
metadata templates on 
http://wiki.esipfed.org/index.php/Air_Quality_Metadata_Workshop_Dublin_2012. 
Please also consult the "Background material" page at 
http://wiki.esipfed.org/index.php/ADN_Standards .
Looking forward to meet you in Dublin! (... and don't forget to bring 60 
Euros in cash ...)
Best regards,
Martin Schultz and Leonor Tarrason

PS: ** THIS IS THE LAST MAIL YOU RECEIVE ABOUT THIS WORKSHOP! IF YOU WOULD LIKE 
TO RECEIVE FURTHER ANNOUNCEMENTS OR INFORMATION ABOUT THE WORKSHOP OUTCOMES, 
PLEASE REGISTER AT THE geo_aq_...@fz-juelich.de MAILING LIST!  **





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] emission names?

[Schultz, Martin]

Dear Alison,

many thanks for your efforts and the thorough review of the definitions. 
Below I copy and answer only to the points that need attention.

1. general remark concerning the suggested definition text:

> suggested explanation for 'mass'.  For example, the full definition
> for the first proposed name,
> tendency_of_atmosphere_mass_content_of_carbon_monoxide_due_to_emission
> _ from_energy_production_and_distribution, would read:
>
> ' "tendency_of_X" means derivative of X with respect to time. [...]
> 'The "energy production and distribution" sector comprises fuel
> combustion activities related
>   to energy industries and fugitive emissions from fuels. It may also
> include any not-classified or "other" combustion, which is commonly
> included in energy-related inventory data. "Energy production and
> distribution" is the term used in standard names to describe a
> collection of emission sources.** If clarification of the emission
> sources is useful or necessary, it could be given in the comment
> attribute. The comment attribute could be a list of sources or a
> reference such as "IPCC (Intergovernmental Panel on Climate Change)
> source categories 1A1 and 1B as defined in the 2006 IPCC guidelines
> for national greenhouse gas inventories". **'

   I would advocate a somewhat more rigid formulation here. According to 
Jonathan, CF uses either "shall" or "should", and in my understanding "could" 
is even weaker. In fact, I would argue that clarification of the sectors is 
always useful (and probably almost always necessary). Hence, I suggest to 
change the part between "**" and "**" to:
'A variable containing this standard_name attribute should be accompanied by a 
comment attribute which lists the source categories and provides a reference to 
the categorization scheme. Example: "IPCC (Intergovernmental Panel on Climate 
Change) source categories 1A1 and 1B as defined in the 2006 IPCC guidelines for 
national greenhouse gas inventories".'

2. industrial_processes_and_combustion:
> [...] a reference such as "IPCC (Intergovernmental Panel on Climate Change)
> source categories 1A2, 2A, 2B, 2C, 2D and 2E as defined in the 2006
> IPCC guidelines for national greenhouse gas inventories". '
>
> **Does the suggested text for the comment attribute contain the
> correct list of categories? The original definition provided by Martin
> refers to "1A2, 2A, 2B, 2C, 2D and 2E" in the first sentence but later
> refers to "non-energy use of lubricants/waxes (2G)" which isn't in the
> first list. Is this just a typo?

Your text is correct. There may be a place for some "2G" emissions in this 
category, but since we should advocate the use of a comment attribute to define 
the actual sector list, limiting the standard name definition to "1A2, 2A, 2B, 
2C, 2D and 2E" is fine.


3. ** The definitions of both "forest_fires" and  "savanna_and_grassland_fires" 
refer to IPCC source category 5; is that correct?

Yes. Category 5 is for "other". The 2006 guidelines state "Only use this 
category exceptionally, for any categories than cannot be accommodated in the 
categories described above. Include a reference to where a detailed explanation 
of the category can be found." Neither forest nor savanna fires fall under the 
reporting obligations.

4. ** I assume that the phrase in parenthesis "(natural and human induced)" 
refers to the fires, not the land use type; is that correct?

Yes. This is correct.

5. ** Do we need any additional qualifying text about "alcohols" being a
> group chemical name, e.g., 'In standard names "alcohols" is the term
> used to describe the group of chemical species that are represented
> within a given model. The list of individual species that are included
> in a quantity having a group chemical standard name can vary between
> models. Where possible, the data variable should be accompanied by a
> complete description of the species represented, for example, by using
> a comment attribute.' ?

As this is common practice elsewhere, I agree. This implies that we would like 
to see two things described in the comments attribute: the emission source 
categories and the species which make up for the compound group. In order to 
not delay the process any further, I suggest to take this route for now, but 
perhaps we should open a new discussion (track ticket) then on adding more 
specific attributes for chemistry variables. If Philip follows this, he may 
wish to comment?

An initial suggestion could be:
 source_categories:"1A1, 1B"
 source_category_reference:"IPCC Emission guidelines 2006; 
http://www.ipcc-nggip.iges.or.jp/public/2006gl/index.html";
 group_compounds:"CH3OH, C2H5OH, ..."
Of course, the application of these would be limited to emission variables and 
chemical compound groups, respectively.

Best regards,

Martin





--

Re: [CF-metadata] Warming up old stuff - 4 (emissions)

[Schultz, Martin]

Dear Alison,

 fine on both accounts. I suggest to use the comment attribute as you 
suggested and give the appropriate hint in the definition text. I also second 
the addition of Philip concerning the specification of the units. This later 
topic may come up again -- if I recall correctly there was an older discussion 
on such "atom-based" mass units, which are quite commonly used. For now, we 
should assume that mass is mass of compound, and when the need arises, we will 
have to introduces a couple of "clones" with the "_expressed_as" addition to 
the standard_names.

Best regards,

Martin

-Ursprüngliche Nachricht-
Von: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] Im Auftrag von 
cf-metadata-requ...@cgd.ucar.edu
Gesendet: Montag, 9. Juli 2012 09:58
An: cf-metadata@cgd.ucar.edu
Betreff: CF-metadata Digest, Vol 111, Issue 8

Send CF-metadata mailing list submissions to
cf-metadata@cgd.ucar.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
or, via email, send a message with subject or body 'help' to
cf-metadata-requ...@cgd.ucar.edu

You can reach the person managing the list at
cf-metadata-ow...@cgd.ucar.edu

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of CF-metadata digest..."


Today's Topics:

   1. Re: Standard names for sea level change (Cameron-smith, Philip)
   2. Re: Standard names for sea level change (Cameron-smith, Philip)
   3. Re: [CF Metadata] #90: Collection of CF enhancements for
  interoperable applications (Heiko Klein)
   4. Re: Warming up old stuff - 4 (emissions)
  (alison.pamm...@stfc.ac.uk)
   5. Re: Warming up old stuff - 4 (emissions)
  (alison.pamm...@stfc.ac.uk)


--

Message: 1
Date: Fri, 6 Jul 2012 10:25:15 -0700
From: "Cameron-smith, Philip" 
To: Jonathan Gregory ,
"cf-metadata@cgd.ucar.edu"  
Subject: Re: [CF-metadata] Standard names for sea level change
Message-ID:



Content-Type: text/plain; charset="us-ascii"

Hi Jonathan, et al.,

We do have a number of other cases where we effectively specify 
integrals/averages within std_names.  For example, we have 
atmosphere_moles_of_X as a global integral.  We also have 
atmosphere_mass_content_of_X as a column integral.

I know there are advantages and disadvantages.  Personally, I believe the bar 
should be high to be included as a separate standard name, but there are cases 
such as these which pass over the bar.  I am personally happy to leave these 
global_average_sea_level names as they are.

Best wishes,

   Philip

---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---



> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf
> Of Jonathan Gregory
> Sent: Friday, July 06, 2012 4:50 AM
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Standard names for sea level change
>
> Dear all
>
> Regarding the existing standard_name global_average_sea_level_change
> and the corresponding ones for steric and thermosteric:
>
> It is anomalous to have "global" and "average" in a standard name
> because, as Philip says, we usually put these kinds of thing in
> cell_methods. The reason for having them in the standard name in these
> cases is that these global quantities are commonly referred to without
> being regarded as the global average of something. You can imagine
> other quantities which refer to the whole world; for example we might
> have a standard name for the age of the Earth.
>
> Although it's a fuzzy distinction, it's not quite like global average
> air temperature change, for example. We do not have a standard name
> for that, because people do regard it as the global average of local
> air temperature change. That is how it is computed. Global average sea
> level change, before satellite altimetry began, is estimated from
> sparse measurements by various methods.
>
> However, we could change to using more systematic names, although it
> would be a bit more obscure. global_average_sea_level_change could be
> described by a standard_name of change_in_ocean_thickness with
> cell_methods of "area: mean over sea" for the whole world.
> global_average_thermosteric_sea_level_change
> could be change_in_ocean_thickness_due_to_thermosteric_change. Should
> we make that change (with aliases)?
>
> Cheers
>
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--

Message: 2
Date: Fri, 6 Jul 2012 10:37:59 -0700
From: "Cameron-smith, Philip" 
To: Jonathan Gregory ,
"cf-metadata@cgd.ucar.edu"  
Su

[CF-metadata] GEO AQ CoP meeting "Metadata for Atmospheric Composition and Air Quality", Dublin, 5-7 Sept. 2012 -- Registration open

[Schultz, Martin]

Dear colleague,

   with some delay, we are happy to announce that you can now register for 
the GEO Air Quality Community of Practice meeting on “Metadata for Atmospheric 
Composition and Air Quality” in Dublin (Morrison hotel), 5-7 September 2012. 
The registration web page is at 
http://cop.nilu.no/Registration/tabid/10710/language/nb-NO/Default.aspx . The 
registration fee will be 60 €, to be paid in cash at the venue. Registration 
will be open until August 31st, or when we reach the limit of 80 participants.
 Further information about the workshop can be found at 
http://wiki.esipfed.org/index.php/Air_Quality_Metadata_Workshop_Dublin_2012 . 
Right now, this page contains the text of the first announcement, but we plan 
to post some extra material over the coming weeks.
  Finally, we encourage you to register for the geo_aq_cop mailing list in 
order to streamline the information process. Simply go to 
http://lists.fz-juelich.de/mailman/listinfo/geo_aq_cop and register yourself 
with your email address.

Thanks very much – looking forward to meet you in Dublin,

Martin Schultz and Leonor Tarrason

PS: if you don’t want to receive further email concerning this workshop or the 
activities of the GEO AQ CoP, please send a short message to 
m.schu...@fz-juelich.de





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unseren neuen Film? http://www.fz-juelich.de/film
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Warming up old stuff - 4 (emissions)

[Schultz, Martin]

Dear Alison, all,

thanks for bringing this to a conclusion, and thank you also for your 
thoughtful comment. I like your idea of broadening the definitions somewhat to 
allow for a little more flexibility in the practical use without having to 
invent new standard_names for every new combination of sectors. I am only 
wondering (but this should be a discussion under a different thread), whether 
"comment" is the right attribute for such things. Without having checked the 
standard_name table for this, I assume that there are some other occasions 
where additional clarification is at least useful if not mandatory. "Comment" 
is rather general and optional. For the sake of improving CF to become better 
suited for interoperability purposes, it may be a good idea to either formalize 
the way the "comment" attribute shall be used (the standard_name table could 
indicate if there should be a comment attribute available for any given 
standard_name), or, alternatively, to extend the syntax of standard_names to 
add "mandatory" or "recommended" comments right there (for example 
"tendency_of_atmosphere_mass_content_of_carbon_monoxide_due_to_emission_from_energy_production_and_distribution:
 IPCC source categories 1A1 and 1B as defined in the 2006 IPCC guidelines for 
national greenhouse gas inventories".)

With this, I hope that we can close the discussion on the emission names soon 
and let them see the light of the next table.

Best regards,

Martin



-Ursprüngliche Nachricht-
Von: alison.pamm...@stfc.ac.uk [mailto:alison.pamm...@stfc.ac.uk]
Gesendet: Freitag, 6. Juli 2012 12:01
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: Re: [CF-metadata] Warming up old stuff - 4 (emissions)

Dear Martin, All,

Martin Schultz proposed a set of emission names about 12 months ago and there 
has been some sporadic discussion since. I would like to draw this discussion 
to a conclusion so that we are in a position to include these quantities, which 
are clearly of fundamental importance to the climate community, in the standard 
name table.

To summarize the situation so far: [...]





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unseren neuen Film? http://www.fz-juelich.de/film
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Workshop on Air Quality and Atmospheric Composition Metadata, Dublin, 5-7 Sept. 2012

[Schultz, Martin]

First Announcement





Dear colleague,



The GEO AQ CoP is a self-organized voluntary group that fosters the application 
of Earth observations to air quality management and science. Its participants 
and its main beneficiaries are members of national and international science 
teams, data portals and decision support activities. CoP activities include 
sharing tools and best practices and facilitation of standards-based networking 
of air quality data systems using GEOSS data sharing principles.



The collection, management and access to atmospheric composition and air 
quality data are undergoing rapid changes towards web-based, interoperable data 
services. Although significant efforts are presently dedicated to facilitate 
access to these type of information, severe limitations for linking information 
from different platforms, programs, data centers and research fields arise from 
inadequate definitions of metadata. In order to enhance the connectivity of the 
global network on air quality and atmospheric composition data, the community 
of researchers and practitioners needs to articulate their needs, identify the 
most relevant facets of metadata, and try to reach consensus on terminology and 
structure.



The next meeting of the GEO AQ CoP is organized together with the 
preoperational GMES Atmospheric Service (MACC-II) and links to the GISC 
activities under the European Environment Agency. It invites emissions experts, 
air quality modellers, satellite data users, in-situ observation experts to 
express their views on the description of air quality and atmospheric 
composition data and to help advance the standardisation of metadata in these 
fields. The GEO Air Quality CoP- MACC-II workshop in Dublin main goals are:



*   to review the international metadata standards in terms of their 
applicability to air quality and atmospheric composition needs,



*   to establish a community consensus on the metadata structure and 
terminology for air quality and atmospheric composition,



*   to identify interconnections among different geographic and thematic areas 
from emissions to observations and model results on atmospheric composition, and



*   to provide recommendations on possible ways to implement the consensus 
metadata structure and terminology.



The workshop will consist of plenary sessions and a full day of discussions in 
thematic and cross-cutting working groups. The facilities in Dublin can 
accommodate approximately 80 attendees.





Preliminary agenda: see 
http://wiki.esipfed.org/index.php/Air_Quality_Metadata_Workshop_Dublin_2012



Venue: Morrison hotel, Lower Ormond Quay, Dublin 1, Ireland 
(http://www.morrisonhotel.ie/).



Registration: to be opened in June 2012



Financial support: We cannot offer any travel support, but we aim at keeping 
the registration fee below 100 Euros





The organizing committee: Martin Schultz (FZ Juelich), Leonor Tarason (NILU), 
Colin O'Dowd (U. Galway)





PS: if you would like to obtain further information, please 
mailto:m.schu...@fz-juelich.de (do not reply to this mail)


PPS: please forward this announcement to interested colleagues!





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unseren neuen Film? http://www.fz-juelich.de/film
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Juelich checker

[Schultz, Martin]

Dear all,

we appreciate the recognition of our Juelich CF checker and I can confirm 
that we will maintain this tool during the coming years. There are certainly 
pros and cons for merging the code bases:
PRO: less work for each team, higher chances to catch errors, (if definition 
process is well defined) chances to catch ambiguities and other "features" 
before release of a new version
CON: as Dave states, independent developments can occasionally lead to 
"diverging oppinions" which can then be resolved

Let me briefly point out two main factors that had prompted our CF checker 
development (and which we would like to preserve):
1) possibility to include this tool in interoperable web applications (see 
http://ogc-interface.icg.kfa-juelich.de:50080/upload)
2) automated test suite using python's unittest module

We are currently leaning towards the proposal of merging code bases, mainly 
to save personnel resources, but also in the hope that independent eyes during 
the development lead to a better software. If we want to pursue this, it should 
be decided, however, how changes in the standard and new rules will be 
implemented and who takes responsibility for which parts of the code. We are 
currently investigating the possibility to set-up a Redmine system here in 
Juelich, which would allow easy access to a version control system, bug and 
feature tracking system and wiki for documentation. With such a tool, a joint 
development seems possible and would hopefully be transparent enough to satisfy 
user demands as expressed by Dave.

Perhaps it would be most efficient if Rosalyn and Michael could have a 
little discussion about the virtues of each system and their own plans for 
further development. If this can be formulated in a consensus view (mini "white 
paper"), we would have a much better basis to decide on the way forward.

Best regards,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] new track ticket to propose extension of cell_methods

[Schultz, Martin]

Dear all,

as there is yet no mechanism to alert everyone on new track tickets, this 
is just to inform you that I have added a new ticket (#82) to propose enhancing 
the cell_methods attribute so that it can cope with more complex averaging 
procedures (see thread on "8-hour maximum" concentrations from last year). Some 
time has gone by since the original discussion, so I wonder if my proposal 
captures all the problems we debated.

Best regards,

Martin


---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] repost warming up old stuff - part 4: emissions (hit send too early)

[Schultz, Martin]

Dear Heiko,

 you are of course right that this cannot be the end of it. Yet, I think it 
is very important to get these standard names into the list soon, because there 
are already large data sets with these categories (the "ACCMIP" emissions 
produced for chemistry calculations to support IPCC AR5, and "MACCity" 
emissions which are employed in the quasi-operational MACC forecasts and 
reanalyses). The issue of sector definitions had been discussed and in the end 
the majority view was that we should follow the practical approach and adopt 
what is already in use. Nevertheless, the emissions community should indeed 
follow up on this and create a more comprehensive vocabulary. A good 
opportunity to carry this forward might be the next GEIA conference in Toulouse 
in mid June.

Best regards,

Martin


> -Original Message-
> From: Heiko Klein [mailto:heiko.kl...@met.no]
> Sent: Wednesday, March 07, 2012 9:52 AM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] repost warming up old stuff - part 4: emissions
> (hit send too early)
>
> Hi Martin,
>
> I guess you are referring to your emails from
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/027072.html .
> I agree that the CF-standard names haven't been updated in quite a while
> (since July?).
>
> But it seems like there are still some open issues concerning the
> sectors. I think the selection of the IPCC sectors is quite arbitrary
> and very much related to greenhouse gases. It seems like the IPCC
> sectors have been derived from the UNECE/CLRTAP NFR sectors
> (http://www.unece.org/env/documents/2002/eb/ge1/eb.air.ge.1.2002.7.e.
> pdf
> pp 21)which again have been derived from the Corinair/SNAP sectors
> combined with the IPCC2000 sectors.
>
> Since CF should not only serve IPCC, I would rather like to see a
> general list of human activity sectors, and then request standard-names
> for those as a whole. There is even an additional problem with these
> sectors: They are very hierarchical, and I would like to see these
> hierarchies at one point or another. As Jonathan suggested, I think this
> human activity sector list should be handled separately and then
> included in the standard_names.
>
> I don't like to use the 'due to' keyword either. This is for processes,
> like 'convection', and I don't consider 'emission from energy
> production' a process. I'd like a new standard_name extension like
> 'caused by' better. Otherwise, we might have a physical process and a
> human process compete for a standard name, like
> xxx_due_to_convection_due_to_emission
>
>
> I'm not sure about the correct procedure for requesting new standard
> names, but shouldn't they appear in 'trac' at one point or another? I
> couldn't find a trac-ticket for your request.
>
> Heiko
>
>
>
>
> On 2012-03-06 15:26, Schultz, Martin wrote:
> > Dear all,
> >
> >  this is my final attempt to propose these new emission standard names.
> The proposal dates back to June 8th, 2011 and has never been implemented.
> Here, I provide the list of specific standard_name attributes we would like to
> see in the list. The old emails detail the concept and explain how these
> names were derived.
> >
> > I request addition to the standard_name table within 1 month.
> >
> > Martin
> >
> >
> > Group:
> tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_e
> nergy_production_and_distribution
> > Units: kg m-2 s-1
> > Definition: The 'energy production and distribution' sector refers to the
> IPCC (Intergovernmental Panel on Climate Change) source categories 1A1
> and 1B as defined in the 2006 IPCC guidelines for national greenhouse gas
> inventories. It comprises fuel combustion activities related to energy
> industries (1A1) and fugitive emissions from fuels (1B). It may also include
> any not-classified or "other" combustion, which is commonly included in
> energy-related inventory data.
> > Standard_names:
> >
> tendency_of_atmosphere_mass_content_of_carbon_monoxide_due_to_e
> mission_from_energy_production_and_distribution
> >
> tendency_of_atmosphere_mass_content_of_methane_due_to_emission_f
> rom_energy_production_and_distribution
> >
> tendency_of_atmosphere_mass_content_of_ammonia_due_to_emission_
> from_energy_production_and_distribution
> >
> tendency_of_atmosphere_mass_content_of_nitrogen_monoxide_due_to_
> emission_from_energy_production_and_distribution
> >
> tendency_of_atmosphere_mass_content_of_sulfur_dioxide_due_to_emiss
&g

Re: [CF-metadata] warming up old stuff - part 1: aerosol mie scattering

[Schultz, Martin]

Dear Markus,

 good to hear that you are taking this up as a GAW initiative. Personally I 
wouldn't have a problem with your suggestion, but I'd like to refer this 
discussion to the more aerosol-oriented community. Small change (lowercase 
"mie"). Hence your name would read
"volume_scattering_coefficient_in_air_due_to_ambient_aerosol_assuming_mie_scattering"
  

Cheers,

Martin

PS: I think it would be appreciated if you can also suggest a definition term 
(basically summarizing your thoughts from the last email). 


> -Original Message-
> From: Markus Fiebig [mailto:markus.fie...@nilu.no]
> Sent: Wednesday, March 07, 2012 12:24 PM
> To: Schultz, Martin; cf-metadata@cgd.ucar.edu
> Cc: Shankar, Uma (ushan...@unc.edu)
> Subject: RE: warming up old stuff - part 1: aerosol mie scattering
> 
> Dear Martin,
> 
> thanks for filling me in on the background of this discussion! This must have
> happened before I joined the mailing list, and I do need to admit it's a 
> hassle
> to read through the whole archive.
> 
> I do see your point, i.e. that you describe a modelled variable, but I still 
> think
> it is self-contradicting to call the variable extinction coefficient, and then
> confine this to aerosol scattering within one and the same variable name. I
> actually wouldn't be so concerned if the syntax philosophy didn't conflict 
> with
> the variable names I'm about to propose on behalf of the WMO Global
> Atmosphere Watch (GAW) aerosol programme. The names are going to be
> of the type "volume_scattering_coefficient_in_air_due_to_dry_aerosol",
> which in fact isn't defined yet.
> 
> How about calling your variable
> 
> "volume_scattering_coefficient_in_air_due_to_ambient_aerosol_assuming
> _Mie_scattering"  ?
> 
> That would avoid the self-contradiction, it would fit into the syntax
> philosophy used so far, and it would still express clearly that it is a model
> output variable with an underlying assumption.
> 
> Best regards,
> Markus
> 
> ___
> Dr. Markus Fiebig
> 
> Dept. Atmospheric and Climate Research (ATMOS) Norwegian Institute for
> Air Research (NILU) P.O. Box 100
> N-2027 Kjeller
> Norway
> 
> Tel.: +47 6389-8235
> Fax : +47 6389-8050
> e-mail: markus.fie...@nilu.no
> skype: markus.fiebig
> 
> 
> -Original Message-
> From: Schultz, Martin [mailto:m.schu...@fz-juelich.de]
> Sent: Mittwoch, 7. März 2012 11:16
> To: Markus Fiebig; cf-metadata@cgd.ucar.edu
> Cc: Shankar, Uma (ushan...@unc.edu)
> Subject: RE: warming up old stuff - part 1: aerosol mie scattering
> 
> Dear Markus,
> 
>thanks for the thoughtful response. I cc this to Uma Shankar who had
> sent me the RSIG (http://badger.epa.gov/rsig/) CMAQ variable list from
> where this suggestion originated. CMAQ is of course a model. I don't think it
> would hurt to have also standard_names for pure model quantities, but I
> agree with you that one may have to phrase and define this more clearly.
> The name you propose is already in the list, and the suggestion was to
> include a more specific term to denote the specific contribution from Mie
> scattering.
> 
> Best regards,
> 
> Martin
> 
> PS: original proposal was
> "* How can we get more specific about the "extinction coefficient"? In
> particular, we would like to express something like
> "..._due_to_Mie_scattering". But does this work with "
> volume_extinction_coefficient_in_air_due_to_ambient_aerosol". The new
> name would then become
> "volume_extinction_coefficient_in_air_due_to_Mie_scattering_of_ambient
> _aerosol" ? (and would "Mie" be spelled with "M" or "m"?)"
> 
> > -Original Message-
> > From: Markus Fiebig [mailto:markus.fie...@nilu.no]
> > Sent: Wednesday, March 07, 2012 9:31 AM
> > To: Schultz, Martin; cf-metadata@cgd.ucar.edu
> > Subject: RE: warming up old stuff - part 1: aerosol mie scattering
> >
> > Dear all,
> >
> > please excuse if I come in late into this discussion, but I would like
> > to make a few comments about the proposed variable name
> >
> >
> "volume_extinction_coefficient_in_air_due_to_mie_scattering_of_ambient
> > _aerosol"
> >
> > As it is written above, the name is self-contradicting. The aerosol
> > extinction coefficient is defined to include both, particle scattering
> > and absorption. The part of the aerosol extinction coefficient that is
> > due to particle scattering is commonly referred to as aerosol
> > scattering coefficient. Also, I need to apologis

Re: [CF-metadata] warming up old stuff - part 1: aerosol mie scattering

[Schultz, Martin]

Dear Markus,

   thanks for the thoughtful response. I cc this to Uma Shankar who had 
sent me the RSIG (http://badger.epa.gov/rsig/) CMAQ variable list from where 
this suggestion originated. CMAQ is of course a model. I don't think it would 
hurt to have also standard_names for pure model quantities, but I agree with 
you that one may have to phrase and define this more clearly. The name you 
propose is already in the list, and the suggestion was to include a more 
specific term to denote the specific contribution from Mie scattering.

Best regards,

Martin

PS: original proposal was
"* How can we get more specific about the "extinction coefficient"? In 
particular, we would like to express something like 
"..._due_to_Mie_scattering". But does this work with " 
volume_extinction_coefficient_in_air_due_to_ambient_aerosol". The new name 
would then become 
"volume_extinction_coefficient_in_air_due_to_Mie_scattering_of_ambient_aerosol" 
? (and would "Mie" be spelled with "M" or "m"?)"

> -Original Message-
> From: Markus Fiebig [mailto:markus.fie...@nilu.no]
> Sent: Wednesday, March 07, 2012 9:31 AM
> To: Schultz, Martin; cf-metadata@cgd.ucar.edu
> Subject: RE: warming up old stuff - part 1: aerosol mie scattering
>
> Dear all,
>
> please excuse if I come in late into this discussion, but I would like to 
> make a
> few comments about the proposed variable name
>
> "volume_extinction_coefficient_in_air_due_to_mie_scattering_of_ambient
> _aerosol"
>
> As it is written above, the name is self-contradicting. The aerosol extinction
> coefficient is defined to include both, particle scattering and absorption. 
> The
> part of the aerosol extinction coefficient that is due to particle scattering 
> is
> commonly referred to as aerosol scattering coefficient. Also, I need to
> apologise for not having followed the discussion concerning the use of the
> term "mie", but it appears rather to confuse than to clarify in the context
> here. Even though the term Mie-particle is colloquially used for a spherical,
> internally well mixed aerosol particle, such a particle exists only in theory 
> or in
> some numerical model. If the variable name is also to be used for an
> observed quantity, which I think it should, the term "Mie" should be avoided.
>
> How about putting this much simpler, and name the property:
>
> "volume_scattering_coefficient_in_air_due_to_ambient_aerosol"
>
> or, to avoid even more confusion:
>
> "volume_scattering_coefficient_at_stp_in_air_due_to_ambient_aerosol"
>
> Regards,
> Markus
>
>
>
> ___
> Dr. Markus Fiebig
>
> Dept. Atmospheric and Climate Research (ATMOS)
> Norwegian Institute for Air Research (NILU)
> P.O. Box 100
> N-2027 Kjeller
> Norway
>
> Tel.: +47 6389-8235
> Fax : +47 6389-8050
> e-mail: markus.fie...@nilu.no
> skype: markus.fiebig
>

---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Warming up old stuff - 4 (emissions)

[Schultz, Martin]

Dear Alison (cc Hugo, Steve, Greg),

> Looking back to the original proposal,
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/027071.html, you
> have provided definitions of the emissions sectors in terms of 2006 IPCC
> source categories. I have found the following document: http://www.ipcc-
> nggip.iges.or.jp/public/2006gl/pdf/1_Volume1/V1_8_Ch8_Reporting_Guida
> nce.pdf (section 8.5) which appears to contain the categories to which you
> refer. Please can you confirm whether this is the best reference to use as I
> think it will be important to include it in the definitions? Steve has 
> supported
> your sector definitions and they are clearly in wide use. There have been no
> other comments regarding the categories.

 This appears to be the right document. To make sure, I ask Hugo, Greg and 
Steve to confirm. I guess the official reference web site is 
http://unfccc.int/national_reports/annex_i_ghg_inventories/items/2715.php, but 
that doesn't seem to offer the information in a single pdf file format.

> When the carbon_dioxide emission names were introduced there was some
> discussion as to whether to use
> 'tendency_of_atmosphere_mass_content_of_X_due_to_emission' or
> 'surface_upward_mass_flux_of_X_due_to_emission'. The units would be
> the same in either case (kg m-2 s-1) and the distinction is really one of 
> where
> the emission takes place. The surface_upward_flux names apply only to
> emission at the surface itself and are therefore 2D fields. The tendency
> due_to_emission names refer to emission anywhere in the atmosphere,
> including the surface, and are 3D fields. Obviously your aviation emissions
> would be 3D, but is that also true of the others? I am happy to use either
> form of words in these names, whichever you feel is the most appropriate.

Back then we had decided on the 'tendency_of_atmosphere_mass_content...' 
terms, because there are various other sectors for which "surface" is not fully 
appropriate, such as smoke stacks from power plants and industrial facilities, 
and even ship emissions (where the chimney is typically at ~30 m altitude and 
therefore often falls into the second or even third model grid box above the 
surface. The term "surface_flux" suggests that these emissions are indeed 
formulated as a surface flux boundary condition (i.e. technically they are 
introduced into the diffusion equation), and this is not always the case. The 
change in atmospheric mass content is the ultimate result and the term is more 
universal and easily covers all "strange" 3D emissions as well. But of course 
it is a bit unfortunate that carbon emissions are then named different from 
other species. Where this makes sense, we could perhaps define alias names for 
the carbon fluxes?

Best regards,

Martin



---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] repost warming up old stuff - part 4: emissions (hit send too early)

[Schultz, Martin]

Dear all,

this is my final attempt to propose these new emission standard names. The 
proposal dates back to June 8th, 2011 and has never been implemented. Here, I 
provide the list of specific standard_name attributes we would like to see in 
the list. The old emails detail the concept and explain how these names were 
derived.

I request addition to the standard_name table within 1 month.

Martin


Group: 
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
Units: kg m-2 s-1
Definition: The 'energy production and distribution' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A1 and 1B as 
defined in the 2006 IPCC guidelines for national greenhouse gas inventories. It 
comprises fuel combustion activities related to energy industries (1A1) and 
fugitive emissions from fuels (1B). It may also include any not-classified or 
"other" combustion, which is commonly included in energy-related inventory data.
Standard_names:
tendency_of_atmosphere_mass_content_of_carbon_monoxide_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_methane_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ammonia_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_nitrogen_monoxide_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_sulfur_dioxide_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_black_carbon_dry_aerosol_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ 
particulate_organic_matter_dry_aerosol_expressed_as_carbon 
_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_nmvoc_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_alcohols_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ethane_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_propane_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_butane_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ethene_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_propene_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ethyne_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_benzene_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_toluene_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_xylene_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ 
trimethylbenzene_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_formaldehyde_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_ketones_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_organic_acids_due_to_emission_from_energy_production_and_distribution


Group: 
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
Units: kg m-2 s-1
Definition: The 'industrial processes and combustion' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A2, 2A, 2B, 2C, 
2D and 2E as defined in the 2006 IPCC guidelines for national greenhouse gas 
inventories. It comprises fuel combustion activities related to manufacturing 
industries and construction (1A2) and industrial processes related to the 
mineral products (2A), the chemical industry (2B), the metal production (2C), 
the pulp, paper, food and drink production (2D), and non-energy use of 
lubricants/waxes (2G). It may also include any not-classified or "other" 
combustion, which is commonly included in industry-related inventory data.
Standard_names:
tendency_of_atmosphere_mass_content_of_carbon_monoxide_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_methane_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_ammonia_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_nitrogen_monoxide_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_sulfur_dioxide_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_black_carbon_dry_aerosol_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_particulate_organic_matter_dry_aerosol_expressed_as_carbo

[CF-metadata] warming up old stuff - part 3: mole_fractions and mass concentrations of additional chemical compounds

[Schultz, Martin]

Dear all,

on Oct. 3 the following proposals were made and - if you take Philip's 
endorsement as that - accepted. Yet, these names never made it anywhere on the 
list:

*   "mole_fraction_of_hydrogen_sulfite_in_air", units "1" (meaning "mole 
mole-1")
Definition: Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. Hydrogen sulfide is the molecule with 
the chemical formula H2S.

*   "mole_fraction_of_alkanes_in_air", units "1" (meaning "mole mole-1")
Definition:  Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y.  Alkanes are saturated hydrocarbons, 
i.e. they do not contain any chemical double bonds. Alkanes contain only 
hydrogen and carbon combined in the general proportions C(n)H(2n+2); "alkanes" 
is the term used in standard names to describe the group of chemical species 
having this common structure that are represented within a given model. The 
list of individual species that are included in a quantity having a group 
chemical standard name can vary between models. Where possible, the data 
variable should be accompanied by a complete description of the species 
represented, for example, by using a comment attribute. Standard names exist 
for some individual alkane species, e.g., methane and ethane.

*   " mass_concentration_of_coarse_mode_ambient_aerosol_in_air", units "kg 
m-3"
Definition: Mass concentration means mass per unit volume and is used in the 
construction mass_concentration_of_X_in_Y, where X is a material constituent of 
Y. A chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. "Aerosol" means the 
suspended liquid or solid particles in air (except cloud droplets). "Ambient 
aerosol" is aerosol that has taken up ambient water through hygroscopic growth. 
The extent of hygroscopic growth depends on the relative humidity and the 
composition of the aerosol. Coarse mode aerosol is aerosol having a diameter of 
more than 1 micrometer.

*   "mole_fraction_of_aldehydes_in_air", units "1" (meaning "mole mole-1")
Definition: Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y.  Aldehydes are organic compounds with a 
CHO group; "aldehydes" is the term used in standard names to describe the group 
of chemical species having this common structure that are represented within a 
given model. The list of individual species that are included in a quantity 
having a group chemical standard name can vary between models. Where possible, 
the data variable should be accompanied by a complete description of the 
species represented, for example, by using a comment attribute. Standard names 
exist for formaldehyde as the simplest member of the aldehydes group.

*   " mole_fraction_of_dichlorine_in_air", units "1" (meaning "mole mole-1")
Definition: Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y.  Dichlorine is the molecular form of 
elemental chlorine with the chemical formula Cl2.

*   "mole_fraction_of_methlyglyoxal_in_air", units "1" (meaning "mole 
mole-1")
Definition: Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y.  Methylglyoxal is an organic molecule 
with the chemical formula CH3COCHO. It is also called pyruvaldehyde or 
2-oxopropanal.


I request addition to the standard_name table within 1 month.

Martin


---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] warming up old stuff - part 2: pm mass concentrations

[Schultz, Martin]

Dear all,

 on Oct. 3, 2011, the following standard_names were proposed. Despite 
absence of any critical comments they appear neither on the standard_name list 
nor in the current proposals list:

*   " mass_concentration_of_pm2p5_ambient_aerosol_in_air", units "kg m-3"
Definition: Mass concentration means mass per unit volume and is used in the 
construction mass_concentration_of_X_in_Y, where X is a material constituent of 
Y. A chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. "Aerosol" means the 
suspended liquid or solid particles in air (except cloud droplets). "Ambient 
aerosol" is aerosol that has taken up ambient water through hygroscopic growth. 
The extent of hygroscopic growth depends on the relative humidity and the 
composition of the aerosol. "Pm2p5 aerosol" is an air pollutant with an 
aerodynamic diameter of less than or equal to 2.5 micrometers. To specify the 
relative humidity and temperature at which the particle size applies, provide 
scalar coordinate variables with the standard names of, respectively, 
"relative_humidity" and "air_temperature".

*   " mass_concentration_of_pm1_ambient_aerosol_in_air", units "kg m-3"
Definition: Mass concentration means mass per unit volume and is used in the 
construction mass_concentration_of_X_in_Y, where X is a material constituent of 
Y. A chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. "Aerosol" means the 
suspended liquid or solid particles in air (except cloud droplets). "Ambient 
aerosol" is aerosol that has taken up ambient water through hygroscopic growth. 
The extent of hygroscopic growth depends on the relative humidity and the 
composition of the aerosol. "Pm1 aerosol" is an air pollutant with an 
aerodynamic diameter of less than or equal to 1 micrometer. To specify the 
relative humidity and temperature at which the particle size applies, provide 
scalar coordinate variables with the standard names of, respectively, 
"relative_humidity" and "air_temperature". [Note that pm1 actually coincides 
with the current definition of "coarse_mode" - it may be helpful to allow b
 oth terms as aliases]

*   " mass_concentration_of_pm10_ambient_aerosol_in_air", units "kg m-3"
Definition: Mass concentration means mass per unit volume and is used in the 
construction mass_concentration_of_X_in_Y, where X is a material constituent of 
Y. A chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. "Aerosol" means the 
suspended liquid or solid particles in air (except cloud droplets). "Ambient 
aerosol" is aerosol that has taken up ambient water through hygroscopic growth. 
The extent of hygroscopic growth depends on the relative humidity and the 
composition of the aerosol. "Pm10 aerosol" is an air pollutant with an 
aerodynamic diameter of less than or equal to 10 micrometers. To specify the 
relative humidity and temperature at which the particle size applies, provide 
scalar coordinate variables with the standard names of, respectively, 
"relative_humidity" and "air_temperature".

(commented by Philip Cameron-Smith on Mon, 3 Oct 2011 12:43:44 -0700):
[PJC] After a quick read these all look good to me :-).


I request addition to the standard_name table within 1 month.

Martin


---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] warming up old stuff - part 1: aerosol mie scattering

[Schultz, Martin]

Dear all,

on Oct 4, 2011, I had made a proposal to add

"volume_extinction_coefficient_in_air_due_to_mie_scattering_of_ambient_aerosol".

This had been discussed and after clarification of a lower-case "mie"  I was 
under the impression that this has been accepted. However, it is not on the 
list, nor can I find it in the current status of proposals.

I request addition to the list within 1 month.

Best regards,

Martin

---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] warming up old stuff - part 4: emissions of trace species

[Schultz, Martin]

Dear all,

this is my final attempt to propose these new emission standard names. The 
proposal dates back to June 8th, 2011 and has never been implemented. Here, I 
only provide the list of specific standard_name attributes we would like to see 
in the list. The old emails detail the concept and explain how these names were 
derived.

I request addition to the standard_name table within 1 month.

Martin


Group: 
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
Units: kg m-2 s-1
Definition: The 'energy production and distribution' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A1 and 1B as 
defined in the 2006 IPCC guidelines for national greenhouse gas inventories. It 
comprises fuel combustion activities related to energy industries (1A1) and 
fugitive emissions from fuels (1B). It may also include any not-classified or 
"other" combustion, which is commonly included in energy-related inventory data.
Standard_names:
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution


Group: 
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
Units: kg m-2 s-1
Definition: The 'industrial processes and combustion' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A2, 2A, 2B, 2C, 
2D and 2E as defined in the 2006 IPCC guidelines for national greenhouse gas 
inventories. It comprises fuel combustion activities related to manufacturing 
industries and construction (1A2) and industrial processes related to the 
mineral products (2A), the chemical industry (2B), the metal production (2C), 
the pulp, paper, food and drink production (2D), and non-energy use of 
lubricants/waxes (2G). It may also include any not-classified or "other" 
combustion, which is commonly included in industry-related inventory data.
Standard_names:
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion


Group: 
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_residential_and_commercial_combustion
Units: kg m-2 s-1
Definition: The 'residential and commercial combustion' sector refers to the 
IPCC (Intergovernmental Panel on Climate Change) source category 1A4 as defined 
in the 2006 IPCC guidelines for national greenhouse gas inventories. It 
comprises fuel combustion activities related to the commercial/institutional 
sector (1A4a), the residential sector (1A4b) and the 
agriculture/forestry/fishing sector (1A4c). It may also include any 
not-classified or "other" combustion, w

Re: [CF-metadata] mailing list and trac tickets

[Schultz, Martin]

> John Graybeal   wrote:
> +1.  A notification of each new trac ticket would be ideal in my book, then I
> can subscribe.  I'd rather explicitly subscribe to the trac discussions I care
> about.
>
> While I appreciate that there is a lot of traffic inherent in the discussions 
> of
> each variable, those discussions were the original purpose of the list. I 
> would
> definitely not want to have to subscribe to each of those discussions.
> (Especially because they often go beyond the original topic over time.)
>
> John

Thanks for "+1". Re your second point: maybe the list could be split into 
cf-metadata for general topics and cf-standardnames for the discussion on 
individual names. While most people might want to subscribe to both lists, this 
would make it easier to "ignore" some discussions in either list at certain 
times. Personally, I'd like to get a "cf-metadata-digest" and a 
"cf-standardname-digest" in separate emails.

Martin

---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] mailing list and trac tickets

[Schultz, Martin]

> Jonathan,
>
> What do you mean by "deliver trac tickets to everyone"?
>
> There is some old documentation on how the CF trac system handles e-mail
> notification:
>
>   http://cf-pcmdi.llnl.gov/discussion/about-the-cf-trac-ticket-system
>
> In particular: "The mailing lists are arranged in such a way that you can 
> choose
> to subscribe to only the discussions of interest to you - or you can subscribe
> to the parent list and receive an email for every single message post."
>
> In my experience this is how the trac system has been working -- except that
> I was never able to find the user setting for subscribing to the "parent 
> list".
> So like others said, I get trac e-mails only for tickets that I contribute 
> to.  I am
> subscribed independently to the general discussion list, i.e. "CF-metadata".
>
> If possible, please maintain this degree of specificity.  I would much prefer 
> to
> not receive all trac e-mails just because I am subscribed to the discussion 
> list
> or to individual trac tickets.  Thank you.
>
> --Dave

Agreed! But I have to admit that I wasn't aware of the distinction between 
"general" and "track ticket" discussions until recently. My personal view is 
that there are too many "specific" discussions on the general list (i.e. all 
discussions about specific standard_name entries, for example), but that there 
are is important "general" information that is missed, because these 
discussions are carried out exclusively in the track tickets system. It is not 
trivial to organize the information flow, and ultimately this will always 
depend on the discipline of everyone who contributes (and you don't want to 
scare people away by imposing too many or too strict rules). Ideally, every new 
subject should be brought up once in the general discussion list, but then it 
should be assigned a track ticket and people who are interested in this 
particular subject can then subscribe. Perhaps this subscription could be 
facilitated by a "first response" email which would simply state that the topic 
 has been entered into the ticket system and "here is a link to subscribe to 
this discussion". (not sure if there is an easy technical solution for this) In 
this way we would use the "push" media email list and the "pull" media track 
ticket in a somewhat more transparent and efficient way -- and as a side effect 
the general email  list may become a little more lightweight, which could 
potentially engage a few more people to listen in and perhaps even contribute. 
The consequence would of course be that the "discussion" list would become more 
of a billboard and the actual discussions would take place exclusively in the 
track ticket system (where it may also be easier traceable).

Martin

PS: I know - I still have to open my own track issue...




---
---
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---
---

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] 2. Re: [cf-satellite] Sharing quality flags among multiple variables (Jonathan Gregory)

[Schultz, Martin]

Dear Jonathan,

  while it makes sense what you say, the lines are somewhat blurred and 
this is the philosophical fabric which makes it sometimes hard to communicate 
the usefulness of CF to others. It may be about time to begin thinking about 
CF-2.0 and initiate a discussion which should have simplicity as one major 
goal. There is to my knowledge (and there should be) no rush in this, but it 
may be worthwhile to begin to think about the future. Well, I am sure you have 
done this already! But what is the user involvement in this process? Should we 
think about a "CF conference", or maybe a somewhat larger scope "metadata 
conference"?

But to get specific again: to me there is not much difference if you count 
(valid) observations over a given time interval or if you calculate a 
percentile or mean value. All of these operations aggregate information from 
the variable over time. This also means you always loose some 
detail/information. But where do you begin and end with this? A typical air 
quality measurement may be done every minute. What is archived are often the 
hourly data which have already been processed and averaged, and you will 
(hopefully) find at least some information about this in the metadata, at least 
a simple data quality flag that says if a given hourly value is ok or not. Then 
you can process, for example monthly mean values for one given year or monthly 
mean values over a "climatology" period (i.e. all "January" values from 1980 to 
present). Parallel to these mean values you may want to know the number of the 
obs entering this mean value, and the percentiles or the standard deviation. T
 hen you create a regional mean value where you combine data from different 
stations in a certain geographical domain. Again, all of these operations 
aggregate data and eliminate or reduce at least one dimension. In my view the 
"modifier" case where an observation count applies to several variables is just 
a special case, where you actually have various obs coming from the same 
instrument. In general, even if instruments are operated in parallel you will 
encounter failure of one measurement at other times than failure of another 
measurement. So, the general case is that obs are independent of each other. 
Therefore, I would argue that the "synchronizing" of obs is a special thing and 
should be treated separately from the statistical treatment of variables. 
Hence, the default in the sea water temperature and salinity case would be that 
each variable has its own "count" (via cell_methods?). One could then define a 
way to create this link via some sort of cross-referencing.

Cheers,

Martin


> -Original Message-
> From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
> Sent: Friday, November 18, 2011 4:43 PM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] 2. Re: [cf-satellite] Sharing quality flags among
> multiple variables (Jonathan Gregory)
>
> Dear Martin
>
> >what is the difference between a mean value and an observation
> > count? You may add the 25th percentile to this list as well. As far as
> > I can tell, the cell_methods attribute should be best suited for all
> > of these and I don't see a need to work with standard_name modifiers
>
> Though this has not been thoroughly debated, I think the reasons why there
> are these two different mechanisms are that the two functions are
> distinguished like this:
>
> * cell_methods represents subgrid variation. They always imply that the data
> variable formerly had a higher dimensionality or a higher resolution, and they
> refer to one or more dimensions of the data on which the reduction or
> collapse was done. The relationships indicated by standard_name modifiers
> do not refer to particular dimensions of the data.
>
> * The operations cell_methods records are done on the data in the variable
> itself. Ancillary variables, described by standard_name modifiers, are extra
> information about the data in the variable. This cannot be inferred from the
> data; they are metadata, really, not a statistical reduction of data.
>
> However, I agree there's a similarity. In particular, both of them were
> motivated by a desire to avoid proliferation of standard_names because of
> the need to describe very common operations that could be applied to
> anything, and both of them could modify the units.
>
> Best wishes
>
> Jonathan



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitze

[CF-metadata] 2. Re: [cf-satellite] Sharing quality flags among multiple variables (Jonathan Gregory)

[Schultz, Martin]

Dear Jonathan et al.,

   what is the difference between a mean value and an observation count? 
You may add the 25th percentile to this list as well. As far as I can tell, the 
cell_methods attribute should be best suited for all of these and I don't see a 
need to work with standard_name modifiers. Blank separated lists would indeed 
be useful for this case.

float thetao(lat,lon);
   thetao:standard_name="sea_water_potential_temperature";
   thetao:ancillary_variables="nobs flags";
   thetao:units="degC";
float so(lat,lon);
   thetao:standard_name="sea_water_salinity";
   thetao:ancillary_variables="nobs flags";
   thetao:units="psu"; // not allowed currently---but that's a different story!
int nobs(lat,lon);
   nobs:standard_name=" sea_water_potential_temperature sea_water_salinity";
   nobs:cell_methods="count(time)" // syntax may be wrong - I didn't look 
it up
int flags(lat,lon);
   flags:flag_values = 0, 1, 2;
   flags:flag_meanings = "accepted_value range_outlier failed_inversion_check";


Cheers,

Martin


> Message: 2
> Date: Sat, 5 Nov 2011 09:16:18 +
> From: Jonathan Gregory 
> Subject: Re: [CF-metadata] [cf-satellite] Sharing quality flags
>   amongmultiple variables
> To: upendra.d...@noaa.gov
> Cc: cf-metadata@cgd.ucar.edu, cf-satell...@unidata.ucar.edu
> Message-ID: <2005091618.ga16...@met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear all
>
> Referring to Mike's comment. I agree that the ancillary_variables attribute
> indicates that the status_flag variable is associated with its data variable, 
> and
> that alone identifies it to some extent, but (a) it doesn't specifically 
> indicate
> its purpose, since there could be more than one ancillary variable for a given
> data variables (status flag, standard error, number of observations, ...); (b)
> the status flag variable can be regarded as a data variable in its own right, 
> and
> as such needs a standard_name to be self-describing; it is quite possible, for
> example, that variables for status_flag or number_of_observations might be
> stored in different netCDF files from the variables they describe, and then
> the correspondence would depend on them being distinguishable e.g. by
>   standard_name="sea_water_salinity number_of_observations"
>   standard_name="sea_water_potential_temperature
> number_of_observations".
> However, when the standard_name modifiers were introduced, I don't think
> we foresaw the possibility that several data variables might need to share
> the same ancillary variable e.g. when the number of observations for salinity
> and temperature are the same.
>
>
> Referring to Upendra's comment. We could introduce both changes, but I
> think we should do that only if really necessary for existing examples that 
> are
> likely to represent common use-cases. We should not complicate the CF
> standard more than we have to! I would say the same about Mike's
> ingenious scheme for include-statements.
>
> If it would serve the purpose that began this discussion, personally I would
> favour the first solution, and generalise the use of the standard_name att,
> like Edward said e.g.
>
> float thetao(lat,lon);
>   thetao:standard_name="sea_water_potential_temperature";
>   thetao:ancillary_variables="nobs flags";
>   thetao:units="degC";
> float so(lat,lon);
>   thetao:standard_name="sea_water_salinity";
>   thetao:ancillary_variables="nobs flags";
>   thetao:units="psu"; // not allowed currently---but that's a different story!
> int nobs(lat,lon);
>   nobs:standard_name="sea_water_potential_temperature
> sea_water_salinity number_of_observations"; int flags(lat,lon);
>   flags:flag_values = 0, 1, 2;
>   flags:flag_meanings = "accepted_value range_outlier
> failed_inversion_check";
>
> That is, we would change the text in CF sect 3.3 that reads
>
> "A standard name is associated with a variable via the attribute
> standard_name which takes a string value comprised of a standard name
> optionally followed by one or more blanks and a standard name modifier (a
> string value from Appendix C, Standard Name Modifiers)."
>
> to
>
> "A standard name is associated with a variable via the attribute
> standard_name which takes a string value that can have either of two forms.
> The first form is a standard name alone. The second form is a blank-
> separated list beginning with one or more standard names and ending with a
> single standard name modifier (a string value from Appendix C, Standard
> Name Modifiers) i.e. standard_name [standard_name ...]
> standard_name_modifier. This second form permits a single variable to
> provide ancillary data (see Section 3.4) for several variables that have 
> various
> standard names."
>
> Naturally this would require change to software, such as the CF_checker,
> which analyses the standard_name att, but it would not require any change
> to software which uses the complete att simply as an identifying string, to
> label plots, etc.
>
> What does you think?

Re: [CF-metadata] daily maximum of running 8-hour means

[Schultz, Martin]

Dear Jonathan,

 I'd appreciate this.

Thanks,

Martin

> -Original Message-
> From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
> Sent: Thursday, October 27, 2011 8:07 PM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] daily maximum of running 8-hour means
>
> Dear Martin
>
> I think we all prefer the second alternative then i.e. the summary of what
> was done, rather than explicit coordinates.
>
> > Upon calculating this "index", one will generally assign the daily value to
> one single time "coordinate" value representing the respective day. Now,
> this would mean that the "offset" value will likely be undefined if I
> understood this correctly.
>
> I suppose so. I think the "offset" and "period" would both be optional
> anyway.
> It sounds like you really only need to record the "period" i.e. 8 hours, and I
> suggested the "offset" too for completeness, following Philip's email. It
> would be sufficient to put
> "time: mean (period: 8 hours) time: maximum (interval: 1 hour)".
> to indicate a (daily) maximum made from 8-hour running means if you aren't
> concerned exactly how the 8-hourly periods correspond to the days. In that
> case we can simplify the proposal by omitting "offset" until someone needs
> it.
>
> If no-one has a better idea, shall we propose this extended syntax in a trac
> ticket?
>
> Cheers
>
> Jonathan



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] daily maximum of running 8-hour means

[Schultz, Martin]

Dear Jonathan, Philip,

 I tend to lean towards the second alternative. Partly, because I believe 
it is easier to understand, and partly, because I think that in most cases the 
extra information which cell_bounds entered the "daily max. 8-hour running 
mean" is not preserved (at least I never saw it in any data set). Upon 
calculating this "index", one will generally assign the daily value to one 
single time "coordinate" value representing the respective day. Now, this would 
mean that the "offset" value will likely be undefined if I understood this 
correctly.

Best regards,

Martin

>
> Dear Martin and Philip
>
> [...]
> One possibility would be to extend CF to allow you to preserve the
> original time axis to which the first operation applied, even though
> it is no longer provides the time coordinates once the second
> operation has been carried out. For instance, we could allow:
> [...]
>
> Another possibility would be to define new kinds of standardised
> metadata, following Philip's categories, to describe the superseded
> time coordinate e.g.
> cell_methods="time: mean (period: 8 hours offset: -15.5 hours) time:
> maximum
> (interval: 1 hour)". The second entry is standard, and records that
> hourly values were input to the calculation of the daily maximum. The
> first entry records that those values were themselves means calculated
> over periods of 8 hours, and the first such period began 15.5 hours
> before the first time coordinate (12 - 15.5 = -3.5, the lower bound of
> the first old_time cell).





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] daily maximum of running 8-hour means

[Schultz, Martin]

Dear Jonathan,

I really appreciate your thoroughness. Yes - there can also be the need to 
record the "daily maximum 1-hour value".

   Just to wet your appetite: it can get worse than that if you look at the US 
EPA ozone standard: "0.075 ppm over 8 hour period: To attain this standard, the 
3-year average of the fourth-highest daily maximum 8-hour average ozone 
concentrations measured at each monitor within an area over each year must not 
exceed 0.075 ppm." Or (even better) from a new standard proposal 
http://www.epa.gov/air/ozonepollution/fr/20100119.pdf : "cumulative, seasonal 
standard expressed as an annual index of the sum of weighted hourly 
concentrations, cumulated over 12 hours per day (8 am to 8 pm) during the 
consecutive 3-month period within the O3 season with the maximum index value, 
set at a level within the range of 7 to 15 ppm-hours"

   These kind of "interval" definitions may not be imminent right now, but as 
we are trying to engage the air quality community in "semantic 
interoperability", I am quite sure this will come up eventually. Is there any 
other community out there that has similar issues?

Cheers,

Martin




> -Original Message-
> From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
> Sent: Thursday, October 20, 2011 11:40 AM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: daily maximum of running 8-hour means
>
> Dear Martin
>
> Yes, I agree, "interval" is an ambiguous word, unfortunately.
>
> > YES - there will be a need for this. Current air quality data bases -
> > the largest are probably the American AQS and the European AirBase
> > systems - do store hourly data and "daily max 8-hour mean" values, and
> > you want to be able to differentiate between those automatically
>
> OK. The distinction between those two can already be made like this:
>
> - hourly data have coordinates spaced hourly, and cell_methods with "mean"
> or "point" (depending on wheher they were hourly time-means or
> instantaneous values at hourly intervals).
>
> - daily max of running means have coordinates spaced daily, and
> cell_methods with "maximum".
>
> What we *can't* record in a standardised way is the extra information that
> the maximum was calculated from running means. We need to do this if
> there are also daily maxima calculated from other kinds of subdaily data.
>
> I apologise if this is frustrating. I am trying only to clarify what is 
> needed in
> practice!
>
> Best wishes
>
> Jonathan



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] daily maximum of running 8-hour means

[Schultz, Martin]

Dear Jonathan,

 oh! The wonderful world of semantics. I guess we could argue for a while 
if the "interval" is supposed to be 1-hour or 8-hours in the case of a running 
mean. But I would be prepared to settle for 1-hour as "original resolution", so 
let me answer your question directly: YES - there will be a need for this. 
Current air quality data bases - the largest are probably the American AQS and 
the European AirBase systems - do store hourly data and "daily max 8-hour mean" 
values, and you want to be able to differentiate between those automatically 
(say in a catalogue application such as GI-Cat or Core.uFind). While this could 
in principle be achieved by other means (extra XML metadata), it would indeed 
be valuable to have this information also stored directly in the netcdf file in 
a way that is easily distinguishable (and automatically distinguishable) from 
the "original" 1-hour data.

The current suggestion cell_methods = "max (interval: 1 hour comment: 
8-hour running means at 1-hour intervals)" frankly doesn't sound right and 
rather convoluted. I'd much rather see something like "max (interval: 8-hour 
running means at 1-hour intervals)", or, if this would make it easier to 
formulate a grammar rule "max (interval: running means of 8-hours at 1-hour 
intervals)". In the latter case, the term "running mean" would substitute the 
immediate specification of the interval and fork the parser off to analyze the 
rest of the string.

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] daily maximum of running 8-hour means

[Schultz, Martin]

Dear Jonathan,

thanks for your comments. The time axis and bounds are correctly described 
(indeed this reminded me that it does make sense to include time_bounds in this 
case which we often don't do). Automatic processing would indeed be useful 
here. Further: since it is the maximum of an 8-hour mean, the cell_methods 
should read "time: maximum (interval: 8 hours)", shouldn't it? In practice, 
this might already suffice, unless I have a misconception what the interval 
stands for. Reading the documentation (CF 1.5) again, I believe one can argue 
that the "typical interval between the original data values to which the method 
was applied" is indeed 8 hours in this case - the only ambiguity is that the 
8-hour values were running means rather than discrete 8-hour intervals. If we 
can live with such ambiguity: fine. Otherwise I would suggest  to specify 
"time: maximum (interval: 8 hours running mean)" or even "time: maximum 
(interval: 8 hours running mean from 1 hour values)". If the parser st
 ops after the standardized "8 hours", it will still get the main part. If it 
reads on, it gets the full picture.

Cheers,

Martin


> Whether the CF convention needs to be extended for this depends on how
> much you need to be recorded in standardised metadata. I assume you have
> a time axis with times at daily intervals, whose bounds indicate periods of a
> day e.g. the time coordinates might be 2011-10-18 12:00, 2011-10-19 12:00
> with bounds [2011-10-18 0:00, 2011-10-19 0:00], [2011-10-19 0:00, 2011-10-20
> 0:00].
> If the time coordinate is "time", cell_methods can record a maximum made
> from hourly values with "time: maximum (interval: 1 hour)". This, however,
> does not record that the hourly value were running 8-hour means. That could
> done in an unstandardised way e.g. "time: maximum (interval: 1 hour
> comment: hourly values were running 8-hour means)". Is it sufficient to
> record the information in such a way, or do you need to be able to process it
> automatically in order to distinguish running 8-hour means from, say,
> instantaneous hourly values, or means for single hours?



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Standard_name table entries for air quality data

[Schultz, Martin]

Dear Philip, Jonathan,

1.) thanks for your helpful comments. After a little side discussion with 
Philip, it appears that there is indeed a need for "expressed_as" phrases even 
for molar quantities. Hence, my suggestion reduces to

* add "mole_fraction_of_nox_in_air" as an alias to 
"mole_fraction_of_nox_expressed_as_nitrogen_in_air"

This way old datasets and code won't be corrupted, but it will be possible 
to use a more correct standard_name.

2.)   we couldn't quite agree on the need for defining the "expressed_as" terms 
for mass quantities. I'll accept that no action is immediately required - 
however, it may be that such need will arise if more air quality data goes CF.

3.)  the "expressed_as" definition could be improved, but it's not wrong - so, 
again, no short-term action is needed.

4.)  concerning the new standard_names which follow the accepted grammar, I 
hope that these can be accepted. At least Philip had no objections to them.

5.) the other issues
> > > * (actually more a question): How do I express the "daily 8 hour
> > > maximum" value that is derived from hourly measurements of (surface)
> > > ozone mole fractions? I would tend to apply cell_methods here, but
> > > how should this attribute look like? To explain in more detail:
> > > first an 8- hour running mean of hourly concentrations is
> > > calculated, then the daily maximum value of these running means is
> picked as the indicator.
>
> Do you mean you end up with one value for each day, being the largest of
> the 24 running-8-hour means within the day? There is not current a way to
> describe this in cell_methods. We'll have to devise one if this is a common
> need.
Yes - this is correct, and there is a need for this.

> > > "..." (and would "Mie" be spelled with "M" or "m"?)
> I think it would be lower case, as we use lower case for everything, even
> when upper case is more common (e.g. toa for top of atmosphere). This is to
> avoid irritating problems with wrong case being accidentally used. I am sure 
> it
> would be very unsafe to distinguish two names just on the basis of lower vs
> upper case, so we lose nothing by ignoring case, in effect.
Agreed. Hence, I request to add the standard_name: 
"volume_extinction_coefficient_in_air_due_to_mie_scattering_of_ambient_aerosol"


> > > * Stumbling over the "group" or "lumping" concept again, I would
> > > propose to add a new attribute to the CF standard which is
> > > specifically used to describe the group compounds.
>
> I am not sure whether you mean a variable att or a global att. I would
> certainly favour the former, because I think it's better for variables to
> describe themselves. Is a new att really needed, though? Could you provide
> a more detailed description in the long_name, perhaps? You could
> standardise the long_name, to allow automatic processing, for particular
> applications. On the other hand, if there is a common need to distinguish
> different choices of lumping, because the quantities are not really
> comparable for the purpose in hand, that would be a reason for making the
> distinction in the standard name.

This should of course be a variable attribute as you could have various "group" 
variables in one file. I don't think it would make sense to include the group 
specification in the standard_name. A) this would get too clumsy, and B) the 
merit of having a name that indicates at least some consistency between such 
variables would be lost. I don't like using the long_name either for two 
reasons: A) the contents of a long_name attribute is not standardized, B) some 
software will make use of the long_name attribute to define plot labels, and 
you don't want to see a (potentially long) list of species names on the plot 
title where, for example, NMVOC would do and look much better.

But I do see the point that this type of metadata might fall in the realm of a 
specific community (here "air quality"), and the community will have to get 
their act together to define what they need. For your information: we have 
started to institutionalize the standardization process via the AQ Community of 
Practice wiki (see http://wiki.esipfed.org/index.php/ADN_Standards; still a bit 
bare-bone), and there is a proposal for a common set of metadata tags which 
focuses on the purpose of finding data sets (see 
http://wiki.esipfed.org/index.php/AQ_Community_Metadata_Discussion). Any 
feedback on these is appreciated.

Best regards,

Martin







Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. H

[CF-metadata] Standard_name table entries for air quality data

[Schultz, Martin]

Dear all,

  I am currently reviewing a set of variables from two major data hubs with 
air quality data, and the objective is to enable those systems to serve 
netcdf-CF data. Looking through their variables and descriptions, I came across 
a couple of things and I would like to initiate the discussion about these now. 
I group the following into three categories: 1) errors/inconsistencies in the 
current CF standard_name table, 2) request for additional standard_names 
following the accepted grammar rules, 3) other issues and questions potentially 
requiring new grammar rules or further discussion. As always your feedback is 
greatly appreciated.

Best regards,

Martin

1. standard_name table errors/inconsistencies:

* "mole_fraction_of_nox_expressed_as_nitrogen_in_air"
   The distinction "expressed_as_nitrogen" doesn't make sense for the 
"mole_fraction" quantity. The mole fraction basically counts the number of 
molecules and normalized this quantitiy with respect to the number of air 
molecules. Hence, you can simply add the mole fraction of NO and the mole 
fraction of NO2 to arrive at the mole fraction of NOx. This is different for 
the mass_fraction, where you need to express this relative to a given molar 
mass. Thus, "mass_fraction_of_nox_expressed_as_nitrogen_in_air" makes perfect 
sense, but "mole_fraction_of_nox_expressed_as_nitrogen_in_air" should be 
changed into "mole_fraction_of_nox_in_air" and the present standard_name should 
be deprecated. [I recall that there was some discussion about this earlier, but 
I don't know how this ever made it into the table]

* The same issue applies to 
"mole_fraction_of_nox_expressed_as_nitrogen_in_air",  " 
mole_fraction_of_clox_expressed_as_chlorine_in_air",
 " mole_fraction_of_nmvoc_expressed_as_carbon_in_air" and potentially other 
"group" names.

* " mass_fraction_of_alkanes_in_air"   (and other "group" names)
   Here we face the opposite problem: mass fraction requires an agreement on 
the "reference mass", so here it should be added "..._expressed_as_carbon_..."


* Definition of the phrase:  "expressed_as"
Current wording:
The phrase 'expressed_as' is used in the construction A_expressed_as_B, whereB 
is a chemical constituent of A. It means that the quantity indicated by the 
standard name is calculated solely with respect to the B contained in A, 
neglecting all other chemical constituents of A.
Suggested improvement:
Change last half-sentence to " neglecting all other elemental constituents of 
A."
Actually, this may be more complicated, because in the air quality world it is 
also common to express things relative to one molecule. Example: 
"nox_expressed_as_nitrogen_dioxide". In this case the phrase " calculated 
solely with respect to the B contained in A" does not really make sense, as 
"NO2" is not "contained in NO"  (which is part of NOx, however).



2. request for new standard names following the accepted grammar rules

* " mass_concentration_of_pm2p5_ambient_aerosol_in_air", units "kg m-3"
Definition: Mass concentration means mass per unit volume and is used in the 
construction mass_concentration_of_X_in_Y, where X is a material constituent of 
Y. A chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. "Aerosol" means the 
suspended liquid or solid particles in air (except cloud droplets). "Ambient 
aerosol" is aerosol that has taken up ambient water through hygroscopic growth. 
The extent of hygroscopic growth depends on the relative humidity and the 
composition of the aerosol. "Pm2p5 aerosol" is an air pollutant with an 
aerodynamic diameter of less than or equal to 2.5 micrometers. To specify the 
relative humidity and temperature at which the particle size applies, provide 
scalar coordinate variables with the standard names of, respectively, 
"relative_humidity" and "air_temperature".

* " mass_concentration_of_pm1_ambient_aerosol_in_air", units "kg m-3"
Definition: Mass concentration means mass per unit volume and is used in the 
construction mass_concentration_of_X_in_Y, where X is a material constituent of 
Y. A chemical species denoted by X may be described by a single term such as 
'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. "Aerosol" means the 
suspended liquid or solid particles in air (except cloud droplets). "Ambient 
aerosol" is aerosol that has taken up ambient water through hygroscopic growth. 
The extent of hygroscopic growth depends on the relative humidity and the 
composition of the aerosol. "Pm1 aerosol" is an air pollutant with an 
aerodynamic diameter of less than or equal to 1 micrometer. To specify the 
relative humidity and temperature at which the particle size applies, provide 
scalar coordinate variables with the standard names of, respectively, 
"relative_humidity" and "air_temperature".
[Note that pm1 actually coincides with the current definition of "coarse_mode" 
- it may be helpful to allow both terms 

Re: [CF-metadata] standard names for stations (Jonathan Gregory)

[Schultz, Martin]

> Date: Wed, 31 Aug 2011 10:33:26 +0100
> From: Jonathan Gregory 
> Subject: Re: [CF-metadata] standard names for stations
> Dear Nan
>
> > Do we need to specify whether the _id is numeric or character? I'd
> > prefer to leave that to the user and his code.
>
> Yes, I think we have to specify this for standard_names; in the standard
> name table, all of them are either assigned units => numeric, or stated to be
> "string". Of course, a number can be written in a string, and maybe that's the
> right thing to do if this variable would never be processed as a number.
>
> Best wishes
>
> Jonathan
>

Dear Jonathan,

... but strings may be formatted differently. "001" is not the same as "1" or 
"01". I think you are right about using strings instead of numbers (if 
sometimes the ID can actually be a string), but someone (in the user community) 
then needs to define the formatting of number IDs.

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] More background on the burned area (Jonathan Gregory)

[Schultz, Martin]

Jonathan, Kevin,

I don't think that it is necessary to further qualify "burned_area". If you 
do an internet search for this term you always come up with hits related to 
"wildfire" which would suggest that there is little ambiguity in this term. I 
propose to add the vegetation fire relationship in the definition of the term 
but keep the term short and concise. Should there ever be a conflict we can 
still create an alias or re-define. (Just imagine you start arguing about 
"air_temperature": is this the temperature of air inside a box or a house? ...)

Cheers,

Martin



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_names for emissions - part 2: species

[Schultz, Martin]

Hi Jonathan,

   unless I missed anything, your comment appears to be the only one on our 
proposal so far. Thanks for your support.

   Concerning the re-organisation of sectors into an additional variable 
dimension, we don't think that this is a viable option. Firstly, current tools 
all assume that sectors are found in individual variables. Secondly, the number 
of sectors can vary by species, so you end up with different dimension sizes in 
different files -- not impossible, but rather ugly. I'd rather see progress in 
the development of a CF grammar, whereby it's not individual standard_names 
that are cast in XML, but rather the rules how names are created and then some 
sort of dictionary mapping which will describe which combinations are possible 
and which ones aren't...

   In short: mainly for (important) practical reasons, we'd like to stick with 
our original proposal as is.

Cheers,

Martin



> -Original Message-
> From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
> Sent: Wednesday, June 08, 2011 7:33 PM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] standard_names for emissions -
> part 2: species
>
> Dear Martin and Angelika
>
> Your proposal looks very careful and sensible to me. The new
> chemical species and processes will fit the existing
> patterns. I support the use of
> tendency_of_atmosphere_mass_content_of_X
>
> One comment, though. Since all the processes are
> due_to_emission_from_Y, where Y is a sector of activity, I
> would like the raise the question of whether it would be a
> good idea to keep Y out of the standard name and store it in
> some other fashion, probably a [scalar] coordinate variable?
> As usual, this is a question about an essentially arbitrary
> boundary. We decided not to do it with chemical species in
> order to make sure everything makes sense chemically in
> standard names, but perhaps in order to limit the number of
> standard_names we might factor out this new distinction? An
> analogy would be with area_type and region, which we have now
> generalised in this way (though some area_types of particular
> importance do appear in standard names). I can imagine there
> could be a practical advantage of being able to contain the
> emissions of a particular species from all the sectors in a
> single data variable, if Y were made a dimension. Another
> reason is that the Y are getting some way from being
> "geophysical", which is the core purpose of standard_name
> descriptions.
>
> Best wishes
>
> Jonathan
>



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] standard_names for emissions - part 2: species

[Schultz, Martin]

Hi again,

   here is the association of chemical compounds with the various emission 
sectors proposed in our last email. New species which have no standard_name 
assigned yet are marked with a *.


1) sector: energy_production_and_distribution

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, benzene, toluene, xylene, * trimethylbenzene, 
formaldehyde, * ketones, * organic_acids

2) sector: industrial_processes_and_combustion

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, benzene, toluene, xylene, formaldehyde, * ketones, * 
organic_acids

3) sector: residential_and_commercial_combustion

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, benzene, toluene, xylene, * ethers, formaldehyde, * 
ketones, * organic_acids

4) sector: solvent_production_and_use

X = carbon_monoxide, * nmvoc, * alcohols, (* hexane_and_higher_alkanes), 
toluene, xylene, * esters, * ethers, * chlorinated_hydrocarbons, * ketones

5) sector: agricultural_production

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, * nmvoc, * alcohols, 
ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), ethene, 
propene, ethyne, benzene, toluene, xylene, * ethers, formaldehyde, * ketones, * 
organic_acids

6) sector: agricultural_waste_burning

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, benzene, toluene, xylene, formaldehyde, * ketones, * 
organic_acids

7) sector: waste_treatment_and_disposal

X = carbon_monoxide, methane, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, benzene, toluene, xylene, * esters, * ethers, * 
chlorinated_hydrocarbons, formaldehyde, * ketones, * organic_acids

8) sector: forest_fires

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, isoprene, terpenes, benzene, toluene, xylene, * 
ethers, * chlorinated_hydrocarbons, formaldehyde, * ketones, * organic_acids

9) sector: savanna_and_grassland_fires

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, * 
alcohols, ethane, propane, butane, * pentane, (* hexane_and_higher_alkanes), 
ethene, propene, ethyne, isoprene, terpenes, benzene, toluene, xylene, * 
ethers, * chlorinated_hydrocarbons, formaldehyde, * ketones, * organic_acids

10) sector: land_transport

X = carbon_monoxide, methane, ammonia, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, ethane, 
propane, butane, * pentane, (* hexane_and_higher_alkanes), ethene, propene, 
ethyne, benzene, toluene, xylene, * esters, * ethers, * 
chlorinated_hydrocarbons, formaldehyde, * ketones

11) sector: maritime_transport

X = carbon_monoxide, methane, nitrogen_monoxide, sulfur_dioxide, 
black_carbon_dry_aerosol, * 
particulate_organic_matter_dry_aerosol_expressed_as_carbon, * nmvoc, ethane, 
propane, butane, * pentane, (* hexane_and_higher_alkanes), ethene, propene, 
ethyne, toluene, xylene,

12) sector: aviation

X = nitrogen_monoxide, nitrogen_dioxide, black_carbon_dry_aerosol


Notes:
a) it seems like the definition of "black_carbon" is not always included in the 
term definitions

b) nmvoc is not "expressed_as_carbon" - instead the total mass content is given 
(it's the practice of reporting)

c) * alcohols need to be defined: "Alcohols include all organic compounds with 
an alcoholic group."

d) * pentane needs to be defined: "The chemical formula for pentane is C5H12. 
Pentane is a member of the group of hydrocarbons known as alkanes. There are 
standard names for the alkane group as well as for some of the individual 
species."

e) * hexane_and_higher_alkanes: this is one of the l

[CF-metadata] standard_names for emission sectors

[Schultz, Martin]

Dear all,

   we would like to follow-up on a discussion we had about a year ago (see 
posts by a.h...@fz-juelich.de from 23 March 2010 and reply by Philip and others 
as well as related discussion on CO2 emissions).

   Main point is the introduction of some sort of speciation for various 
emission sectors as applied in the ACCMIP (Atmospheric Chemistry Climate Model 
Intercomparison Project) emissions data. These emissions are described in the 
published paper by Lamarque et al., 2010: 
http://www.atmos-chem-phys.net/10/7017/2010/acp-10-7017-2010.pdf.

   In this email we provide a definition of the sectors and their standard 
names. A follow-up mail will deal with the species definitions. Below we use 
"X" as a template for the species name.

   We decided to propose standard_names only for the 
"tendency_of_atmosphere_mass_content" to avoid a distinction between surface 
emission fluxes and "3D volume emissions". The reason is that this distinction 
is not always clear - see for example smoke stack emissions from power plants 
which are sometimes injected into higher model levels and sometimes added to 
the surface flux boundary condition in a model. An exception are aviation 
emissions, which we propose as "tendency_of_mass_concentration_of_X_in_air..." 
(see 12 below).

1)
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_energy_production_and_distribution

sector: energy_production_and_distribution
units: kg m-2 s-1
The 'energy production and distribution' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A1 and 1B as 
defined in the 2006 IPCC guidelines for national greenhouse gas inventories. It 
comprises fuel combustion activities related to energy industries (1A1) and 
fugitive emissions from fuels (1B). It may also include any not-classified or 
"other" combustion, which is commonly included in energy-related inventory data.

2)
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_industrial_processes_and_combustion

sector: industrial_processes_and_combustion
units: kg m-2 s-1
The 'industrial processes and combustion' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source categories 1A2, 2A, 2B, 2C, 
2D and 2E as defined in the 2006 IPCC guidelines for national greenhouse gas 
inventories. It comprises fuel combustion activities related to manufacturing 
industries and construction (1A2) and industrial processes related to the 
mineral products (2A), the chemical industry (2B), the metal production (2C), 
the pulp, paper, food and drink production (2D), and non-energy use of 
lubricants/waxes (2G). It may also include any not-classified or "other" 
combustion, which is commonly included in industry-related inventory data.

3)
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_residential_and_commercial_combustion

sector: residential_and_commercial_combustion
units: kg m-2 s-1
The 'residential and commercial combustion' sector refers to the IPCC 
(Intergovernmental Panel on Climate Change) source category 1A4 as defined in 
the 2006 IPCC guidelines for national greenhouse gas inventories. It comprises 
fuel combustion activities related to the commercial/institutional sector 
(1A4a), the residential sector (1A4b) and the agriculture/forestry/fishing 
sector (1A4c). It may also include any not-classified or "other" combustion, 
which is commonly included in the inventory data.

4)
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_solvent_production_and_use

sector: solvent_production_and_use
units: kg m-2 s-1
The 'solvent residential and use' sector refers to the IPCC (Intergovernmental 
Panel on Climate Change) source categories 2F and 3 as defined in the 2006 IPCC 
guidelines for national greenhouse gas inventories. It comprises industrial 
processes related to the consumption of halocarbons and SF6 (2F) and solvent 
and other product use (3).

5)
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_agricultural_production

sector: agricultural_production
units: kg m-2 s-1
The 'agricultural production' sector refers to the IPCC (Intergovernmental 
Panel on Climate Change) source categories 4A, 4B, 4C, 4D and 4G as defined in 
the 2006 IPCC guidelines for national greenhouse gas inventories. It comprises 
the agricultural processes enteric fermentation (4A), manure management (4B), 
rice cultivation (4C), agricultural soils (4D) and other (4G). It may also 
include any not-classified or "other" combustion, which is commonly included in 
industry-related inventory data.


6)
tendency_of_atmosphere_mass_content_of_X_due_to_emission_from_agricultural_waste_burning

sector: agricultural_waste_burning
units: kg m-2 s-1
The 'agricultural waste burning' sector refers to the IPCC (Intergovernmental 
Panel on Climate Change) source category 4F as defined in the 2006 IPCC 
guidelines for national greenhouse gas inventories. It comprises field burning 
of agricultural residues (4F).

7)
te

Re: [CF-metadata] generalizing forecast_reference_time and forecast_period

[Schultz, Martin]

Dear all,

once again I haven't followed the entire discussion carefully, but I sense 
there is more to the problem than what has been discussed so far:

1) if we define the meaning of "time" as a specific datetime instance on a 
given calendar, then all time values along a trajectory should indeed be in a 
form that can be expressed in the usual "days since DATE" units.

2) the trajectory "starting point" (as 4D space-time tuple if you like to get 
fancy ;-) is a unique characteristic of the trajectory as a whole. This means 
that within the same model (or interpolation technique) you will always be able 
to reproduce the exact same trajectory if you know this one location and time. 
In this sense it is similar to the "reference time" of for example a 3D model 
run, which is usually expressed as the DATE in the time units attribute. In 
order to avoid confusion here, I suggest to use the term 
"trajectory_start_time" (or short: "start_time") here.

3) trajectories can be run forward and backward in time. Therefore the "time" 
values can be negative relative to the "trajectory_start_time".

4) in the simple case of having one trajectory in the file (equivalent to some 
output interval from a model simulation), one could easily live with the 
standard way of setting the reference time (DATE part of time units attribute) 
to the trajectory_start_time and have the time values express the relatve time 
shift with respect to the trajectory_start_time.

5) in the more complex case with several trajectories in the file, one option 
could be to allow for a new DATE value in the time units attribute, such as:
time: units = 'days since trajectory_start_time'
string trajectory_start_time(ntraj)
double time(ntraj, nsteps)
Hence, the term "trajectory_start_time" would refer to a variable rather than a 
given fixed date.
Not so nice if you have to evaluate a lot of strings every time you use this.

6) Alternatively, DATE would still be an arbitrary reference date, and the 
trajectory_start_time variable would be an offset relative to this. Hence:
real_time = reftime + trajectory_start_time + time
This would, however, require some means of expressing the meaning of the 
"trajectory_start_time" variable, because otherwise any automated system would 
compute time simply as real_time = reftime + time. Could one use the formula 
terms for this?

7) Trajectories don't necessarily all have the same length (for example flight 
tracks of ozone sondes which end when the balloon bursts). Not too careful 
thinking suggests that one should then either move to hdf or agree on a certain 
maximum number of "steps" for all trajectories.

Hope this helps a bit,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] physical vs dimensional units

[Schultz, Martin]

> Message: 6
> Date: Wed, 13 Apr 2011 14:52:26 -0600
> From: Steve Emmerson 
> Subject: Re: [CF-metadata] physical vs dimensional units
> To: cf-metadata@cgd.ucar.edu
> Message-ID: <4da60d0a.1010...@unidata.ucar.edu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 04/13/2011 02:25 PM, John Caron wrote:
> > the point im trying to make is that it would be better to understand
> > that "mol mol-1" (canonical udunit = 1) is not the same as  "m3 m-3"
> > (canonical udunit = 1).
>
> In my opinion, the distinction between "mol/mol" and "m3/m3" is better
> indicated by the name of the physical quantity being displayed rather
> than by its unit attribute. In the cases under consideration, the
> respective physical quantities would be "amount of substance fraction"
> and "volume fraction".
>
> See Table 12 of
>  for more
> information.
>
> For example, the Y-axis of a plot could be labeled "Amount of
> Substance
> Fraction of Carbon / 1e-9" to plot nanomoles of carbon per
> mole of whatever.

Sorry, Steve - but if I would suggest this to any of my colleagues, they would 
declare me as insane. And according to the principle that "short and concise is 
beautiful", I would also much rather continue to see plots labeled as "C2H4 
[nmolC/mol]" instead of "Amount of C2H4 fraction of carbon / 1e-9".

I can see the point that this may not be solved by tweaking the units 
attribute. But it means that software that wants to automate the use of CF data 
and present them to users will have to have more "intelligence" (well, actually 
a rather simple dictionary) built in. It's one of those areas where good 
principles collide with pragmatism. Here I see a majority of the CF community 
tending to principles - there were other cases in this discussion list where 
pragmatism reigned.

Cheers,

Martin





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] physical vs dimensional units

[Schultz, Martin]

Dear all,

> Jonathan wrote:
> I don't really agree with this. Units are units, not
> descriptins of quantities.
> grams of CO2 per grams of air is a mass mixing ratio and is
> dimensionless.
> [...]
> Steve wrote:
> The National Institute of Science and Technology (NIST)
> agrees that information shouldn't be attached to unit
> specifications. See
>  and
>  for more
> information.

   if this is the direction to take, then we will need several "expressed_as" 
standard_names for atmospheric chemistry. Typical example: volatile organic 
compounds are often "expressed as" mass mixing ratio based on either their 
molecular mass or in "grams C" which counts only the mass of the C atoms 
(because this is what counts in the sense that it ultimately produces CO2 at 
the end of the reaction chain). Hence, one would need things like
"mass_mixing_ratio_of_ethane_in_air_expressed_as_carbon_mass" and many similar 
ones. You can do the same with nitogen for species like NO, NO2, HNO3, N2O, etc.

I am not opposed to this idea, just like to point out the consequence.

Still, there may then be a need to define "readable units" which would be 
obtained from the combination of standard_name and units. I do sympathize with 
people who prefer to read "nmol mol-1" on a plot rather than "1" (or "1.e-9" in 
this case).

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] udunits time units question

[Schultz, Martin]

Hi Chris et al.,

 indeed it seems like some clarification is necessary about the use of 
different calendars in modelling. Your suggestion to "map" the 360 day calendar 
onto the Gregorian calendar in output files won't work: there would be no need 
for a 360 day calendar if it would. The idea behind fixed-length-year calendars 
is precisely the opposite: preserve seasonality without having to deal with 
leap years etc. Of course you need to adjust the solar cycle accordingly, that 
means your model will have a solar year that is precisely 360 days long (and 
not 365.25 as in reality). If you were to map these dates onto the gregorian 
calendar, you would have to interpolate the time axis so that days 1 to 360 fit 
into the range 1 to 365 or 366, respectively. Yes - a converter 360-days (or 
365-days) to gregorian (and reverse) could be written, but you would redce the 
number of your friends if you insist that this is the only valid way to 
represent time of the model output ;-)

You are right that a date such as 1960-01-31 is invalid in a 360-day 
calendar, and indeed a smart tool should flag this as an error.

Hope this helps,

Martin





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] udunits handling of fuzzy time units

[Schultz, Martin]

Dear all,

in our work, we have often been confronted with the current limitations 
where the only times allowed by CF are "real" times using the "days since date" 
syntax and assuming the Gregorian calendar. We often have "climatological" 
fields as model input data, where monthly variation is included, but we don't 
care whether the field is valid for the 14th or 15th of February. Also, much of 
our output is analyzed as monthly means and we happily accept that some 
Februaries contain an extra day. It's still a month, and variations in weather 
patterns don't change with leap year anyhow.

In my opinion, Steve hit the nail on the head when he writes:

> There are two ways in which dimensions (positions and
> intervals) can be handled.  Each of them is self-consistent:
>
>1. *represent positions as strings*.
>   * Then create special functions to compute the implied
> distance between those string representations.  In this
> outlook units must be specified when the interval is computed.
>2. *represent positions with a zero reference, and an offset value.
>   * Then create special functions to generate formatted strings
> representing positions along the axis.  In this outlook
> units must be stored with the representation.
>

So, if new calendars are defined/introduced, they must come with a 
self-consistent (and complete) set of rules how to compute differences and how 
to map one unit (days, weeks, months, years) onto the other. Within these rules 
you can of course disallow certain units (see Python's timedelta), that's 
erfectly legal. Once these rules are clear, it would be no problem to deal with 
any kind of calendar (even including the poor person who models the atmosphere 
on Venus or Mars which have very different calendars). You can then even 
transform data from one calendar into the other and you know what you will get 
(this is helpful if you construct such climatologies from daily model output, 
for example). It doesn't necessarily mean that the transformation must work 
"bidirectional" (can't find the correct english word for what I want to say 
here), i.e. "February 12 of year 203" in a "360 days" calendar (as often used 
in paleo studies) can be translated into "February 12, 1834" (if you define 
that your base year was 1631, which will be somewhat arbitrary), but "February 
12, 1834" might not necessarily be converted back into "February 12, 1834", but 
could be some other date. Indeed, this is the "fuzziness" of the subject - here 
is where it comes in. Within each calendar, there should not be any ambiguities.

Hope, this is useful,

Martin

PS: I do disagree with Christopher when he says ''"30 days since 31 Jan 2008" 
is perfectly well defined.'' - do you refer to 00 UTC or 12 UTC on 31 Jan 2008? 
Or even 00:00 UTC or 01:02:30.3625132 h UTC? OK: if you define an 
"oceanographic calendar" (where anything shorter than a day doesn't matter), 
you could have a rule that all hours, minutes, seconds, milliseconds, etc. are 
mapped onto one value (say 00:00:00 h UTC). But you will need to define this 
rule in order to give a meaning to your calendar.


= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF grammar and online tool

[Schultz, Martin]

Dear Robert,

this is great! I would definitively support any proposal to try and follow 
this route in the future. However, it will require some further discussion how 
to handle semantically incorrect names. As I understand it, the grammar can 
ensure that we arrive at syntactically correct names (which then have a fair 
chance of being physically meaningful), but all in all the matrix will remain 
sparse and we would need to find a way how to exclude useless combinations of 
grammar terms (to come back to the example from your Prolog grammar 
description: "bone eats dog" doesn't make sense).

Related to the approval process two points: 1) I still think a 
standard_name list will be useful to maintain (at least for a while to come), 
simply because it can be relatively easily integrated in any kind of data 
analysis or checking tool. If you would have to interact with a web application 
each time before you want to make a plot of your data, you might be getting a 
lot of frustration over time. This doesn't mean that the list could not 
eventually be generated automatically, but there should still be some "approved 
list" which doesn't change too frequently so that people can keep track with 
downloading it. 2) Perhaps one could redirect attention of the approval process 
to grammar elements rather than complete standard names? As the "sedimentation" 
discussion shows very nicely, adding a new term often merits a good discussion. 
On the other hand, if I copy a concept (i.e. use an existing standard 
name/grammar as template), such discussion may not be needed. Here, I would 
indeed welcome the "timer" idea, so that new standard names would be accepted 
automatically if no one objects within a period of 1 month or so.

If there was a web-based tool for testing new standard_names and perhaps 
even automatically "registering" them for approval, the email discussions on 
this list could be cut down to the more fundamental discussions and the 
discussion about those names that are not universally accepted.

Next: modifiers or not? Indeed, this question hinges on the approval 
process. If there is no need to approve the exact standard name, but only its 
elements, then the modifier could indeed become part of the standard_name 
(again: the individual modifiers should be agreed upon, but their (recursive) 
combination would be flexible).

Finally: concerning the provisional web tool. I tried to enter 
"mass_flux_of_nitrogen_oxide_in_air_due_to_emission_from_boreal_forest_fires" 
as a test case and received the answer "IS NOT" a valid standard name. OK: 
that's good to know, but is there a chance that the tool could also tell me 
which rule(s) are violated? That would be extremly helpful and probably key to 
success or failure of such a tool in the long run.

Best regards,

Martin

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =


-- referes to:
>Date: Tue, 08 Mar 2011 13:14:09 +
>From: Robert Muetzelfeldt 
>Subject: Re: [CF-metadata] standard_name modifiers
>To: cf-metadata@cgd.ucar.edu
>Message-ID: <4d762ba1.4040...@ed.ac.uk>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>Dear all,
>
>Jonathan suggested having a web-based tool which can be used to check possible 
>standard names, prior to
>submitting them for human approval.
>This could use the grammar he developed for CF-metadata names, and which he 
>has written up at
>http://www.met.reading.ac.uk/~jonathan/CF_metadata/14.1/   [...]
>
>I thought it might help the discussion to implement this idea. This involved 
>two steps:
>1. Converting his grammar (as presented on Jonathan's web page) into Prolog's 
>grammar notation.
>2. Making a parser for this grammar available on the web.
>
>The implementation of Jonathan's grammar in Prolog follows the approach which 
>I have described previously
>on this mailing list, and which is written up at
>http://envarml.pbworks.com/w/page/8988921/Prototype+grammar+for+CF-metadata+%22standard+names%22+(Prolog+version)
> - the only difference being that I have now used his grammar rules rather 
> than ones based on the
>CF-metadata guidelines.
> [...]



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---

Re: [CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear Jonathan et al.,

maybe I am fighting a lost battle here, but let me try to argue once more 
for a generalized solution, i.e. the addition of "anomaly" as a standard name 
modifier. I don't like the idea of adding a new standard name for each new 
anomaly: i) this seems illogical and new users will ask "why is there an 
anomaly defined for temperature, but nor for precipitation?", ii) past 
experience has shown that it takes time to get new standard names adopted, and 
if new use cases come up (as they are bound to be for something as essential as 
anomalies) it may discourage people to even go for standard names for these 
variables. Why not try to make the system as systematic as possible? I don't 
want to argue against a pragmatic approach, but if you decide to change the 
anomalies from individual standard names to a modifier in three years, the 
effort might be much larger, the confusion will be greater and other 
"operators" with similar problems will come along. So, my suggestion would be 
to de
 precate the use of air_pressure_anomaly, air_temperature_anomaly, 
geopotential_height_anomaly and surface_temperature_anomaly now and introduce 
"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow 
;-)

As we just developed some tools to compute multi-model means and model 
anomalies for the TFHTAP data sets, I would otherwise have to come up with a 
list of ~20 new "_anomaly" standard names. So, besides what I see a rational 
argument (above), I have a personal reason for arguing so vehemently.

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear Jonathan,

I don't quite agree with the implication you derive from : "In general, CF 
metadata describes what a quantity *is* and not how it was calculated from 
other quantities."  -- a temperature difference is a temperature, but you don't 
want to confuse it with a temperature (pun intended). Suppose you have this 
wonderful search engine that finds out that NOAA, UK Met Office, JMA, ECMWF and 
many others provide daily fields of sea surface temperatures. Then you load 
them all and compute a mean value. What happens if the NOAA values are SST 
anomalies rather than actual temperatures? As far as I can tell, the software 
would have no way of telling. OK: you can argue this is why we still need 
humans, but in my view it defeats the GEOSS concept of interoperability. In 
particular, because it should be avoidable. But perhaps a simple solution yould 
be to add a standard_name modifier called "derived_quantity" which would mean 
that it has similar properties (grid, units, etc.) like the ori
 ginal, but values should not be compared with the original.

Best,

Martin


>
> It would probably help if we focussed on some real use-cases
> where it is essential to provide *systematic* metadata i.e.
> which can be processed by programs. It is always possible to
> provide descriptive metadata, useful to humans, in
> non-standardised attributes such as long_name and history,
> and this can explain how the quantity is obtained.
>
> Best wishes
>
> Jonathan
>



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear John,

there is a distinct difference between cell_methods and the kind of 
operators I am talking about (or I misunderstand the cell_methods description): 
cell_methods describe operations that are done with respect to variable 
dimensions (averaging over time and/or lon or lat, etc.). From the CF1.5 
document:
"Each "name: method" pair indicates that for an axis identified by name, the 
cell values representing the field have been determined or derived by the 
specified method."
The "modifier" or "operator" describes operations that are done to the variable 
values themselves without changing the dimensions. Let me clarify:

Take a global model output of temperature, for example. How do you describe 
temperature differences between this model and another one? The resulting 
quantity is still an "air_temperature" (OK, actually 
"air_temperature_difference") with units of "K". Yet, it would be nice to know 
that this field is a result of differencing two models. "Difference" could be 
accomodated relatively easily with the standard_name modifier (but how do you 
describe what has been differenced?). More complicated operations, such as 
normalized mean bias (X-Y/(X+Y)) will at some point be impossible to maintain 
through standard_name modifiers, I believe.

Reading through the CF1.5 description of cell_methods again, I see that 
this is probably the way to go, but one would need to define a way of 
expressing such methods that are not associated with a dimension.  For example, 
this could be done with ":difference", but this might be rather 
clumsy (think of 
"atmosphere_absorption_optical_thickness_due_to_particulate_organic_matter_ambient_aerosol:difference").
 "self:difference" could be another option, with additional information in 
paranthesis (e.g. "self:difference (ERA-interim, CRU)"). Writing only 
"difference" is a third option - however this complicates the syntax again, 
because you parse for colon in some cases but not always.

Cheers,

Martin


> -Original Message-
> From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
> Sent: Thursday, February 24, 2011 7:08 PM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] standard_name modifiers
>
> Dear Martin
>
> The idea of the modifiers was to provide standard names for
> ancillary data, such as count of obs, standard error, and so
> on. The other kinds of thing you mention, such as means over
> periods and other statistics, can often be described by
> cell_methods, which is more flexible because it refers to the
> dimensions of the data.
>
> Best wishes
>
> Jonathan
>



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear all,

   perhaps I am not aware of the previous discussions on this issue, but 
reading through the comments about the "count" modifier, I am wondering whether 
the concept of standard_name modifiers is a good solution. Once again, I am 
presently biased towards observational data (ozone time series from stations), 
and I can think of a couple of use cases here. A typical thing to do with obs. 
data is to create a monthly means file from hourly observations. Then we would 
be interested in the mean value, the standard deviation, the number of valid(!) 
data points and potentially other parameters (percentiles, mean of daytime 
values, mean of nighttime values, etc.). Is it practical to include all this in 
pre-defined standard_name modifiers? Or wouldn't it make more sense to define 
some sort of "operator" attribute which describes what has been done to the 
data? In order to be traceable, one would of course have to define the allowed 
operations, but ultimately it may become possible to even define more complex 
formulae which could then describe operations such as differences between a 
model realisation and an ensemble, a normalized mean bias between model and 
observations, a root mean square error, etc.

   For "CF checking" I do see a point though that actually advocates the 
present approach: if I am not mistaken, the the standard_name attribute is the 
only attribute that defines which units a variable should have, so the CF 
checker needs to parse only standard_name to find out if the given units are 
allowed. With a new "operator" attribute one would need to parse another 
attribute (and first check if it exists).

Best regards,

Martin

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF Standards (CF checker)

[Schultz, Martin]

Dear all (and Christina in particular),

if you'd like to get a second oppinion, please try the Juelich CF checker. 
You can either access it "graphically" through 
http://ogc-interface.icg.kfa-juelich.de:50080/upload (Browse for a file, click 
"Upload" and then click on the "log" button in the status row). Our you can 
download the Python code from 
http://repositories.icg.kfa-juelich.de/hg/CFchecker/ . This code contains unit 
tests for every rule and has a flexible interface for error protocols (see 
integration in the web application). We'd be happy about feedback.

Cheers,

Martin







Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF:featureType and Naming Conventions

[Schultz, Martin]

Dear all,

here is my daily fanpost (don't worry I will be quiet again at some 
point;-):

in the discussion document on "discrete sampling geometries" a 
recommendation is made to introduce a CF:featureType attribute (with values of 
point, timeSeries, trajectory, etc.). While this is very reasonable in 
principle, it opens up the name space for CF attributes. Rule 2.3 for checking 
CF compliance says:

"2.3 Naming Conventions
Requirements:
* Variable, dimension and attribute names must begin with a letter and be 
composed of letters, digits, and underscores.
"

 Thus, the colon in the attribute name would constitute a violation of this 
rule.



 A minor issue: why did you choose attribute names which begin with lower 
case characters but have upper case chars embedded in the name? Wouldn't it be 
more logical to say "TimeSeries" instead of "timeSeries"?


Cheers,

Martin





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF and ISO19115

[Schultz, Martin]

Dear all,

after searching the mailing list archive without success, I would like to 
bring up the topic of the ISO19115 metadata standard for geographical 
information and how to best map this into CF. Obviously, the ISO standard 
builds on XML and its hierarchical structures, while (global) attributes in 
netcdf files are "flat". While "professional" applications can organize 
databases and maintain proper links between metadata information in XML files 
and data in netcdf files, the normal user risks loosing a lot of metadata 
information if he relies solely on the content of the file. All that CF1.5 
lists for the "Description of file contents" is:

"
title:A succinct description of what is in the dataset.
institution:Specifies where the original data was produced.
source:The method of production of the original data. [...]
history:Provides an audit trail for modifications to the original data. 
[...]
references:  Published or web-based references that describe the data or 
methods used to produce it.
comment:Miscellaneous information about the data or methods used to produce 
it.
"

As an example of the level of detail ISO19115 defines, here is an excerpt from 
http://eden.ign.fr/xsd/isotc211/isofull/20090316/gmd/citation.xsd/view:



Standardized resource 
reference






















I believe it would be nice if these two worlds could be better connected. 
Obviously, an easy way would be via URI (for example in a global attribute 
called iso19115 which would point to a location where the XML file can be 
obtained). However, this is rather fragile and it would be nice to save the 
extended metadata information in the file itself. One way could be an attribute 
named xml (either global or variable attribute(s)" which would contain XML text 
- this text could then identify itself as being ISO19115 compliant, for 
example. A virtue of such a concept would be that automated data servers could 
insert the "external" metadata information in the file upon delivery. Since the 
present attributes to describe the file content are optional anyway, CF 
wouldn't need to be modified much, except for mentioning the xml attribute and 
its purpose.

If there are other ways to integrate ISO19115 and CF which have proven 
efficient in practice, I'd be happy to learn about them.

Best regards,

Martin Schultz

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] ... wind speed

[Schultz, Martin]

Hi again,

   more on the CASTNET data. They provide
15,WINDSPEED,m/sec,"Vector wind speed; m/sec.",NUMBER,"16,4",
and
23,WINDSPEED_SCALAR,m/sec,"Scalar wind speed; m/sec.",NUMBER,"16,4",

   The first appears to be a vector average = sqrt( mean(u)**2 + mean(v)**2 )
   the second is = mean( sqrt(u**2 + v**2) )

   Are both tied to "wind_speed" as standard_name and should they differ in the 
cell_method attribute?

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF standard_name irradiation ?

[Schultz, Martin]

Nan,

   unfortunately I don't know the instrument type. I am dealing with the 
CASTNET data http://java.epa.gov/castnet/ and I am primarily interested in 
ozone. A brief search didn't turn up any info on the instrument type. But 
"downwelling_shortwave_flux_in_air" or 
"surface_downwelling_shortwave_flux_in_air" both seem to be good options.

Thanks,

Martin


> -Original Message-
> From: Nan Galbraith [mailto:ngalbra...@whoi.edu]
> Sent: Friday, February 18, 2011 2:40 PM
> To: Schultz, Martin; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF standard_name irradiation ?
>
> Hello -
>
> It would be useful to know what type of measurement you're
> working with. Is it an observed variable? What kind
> instrument made the measurement, and at what position - i.e
> is it on a surface buoy?
>
> We use surface_downwelling_shortwave_flux_in_air for swr
> measured by an Eppley PSP (Precision Spectral Pyranometer) on
> a surface buoy.
>
> - Nan



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF standard_name irradiation ?

[Schultz, Martin]

Hi Roy,

   thanks - yes: I think that would do. I am not an expert in this field and 
don't know if the light meter spectral response is close enough to what models 
generally consider "shortwave flux", but this might be a rather fine point.

   In any case it would be good if a search for "irradiance" or "radiation" 
would turn up something that points to "shortwave" and "longwave" as well. 
"downwelling_shortwave_*radiation*_flux_in_air" would be more precise, but also 
redundant for a human being...

Cheers,

Martin


> -Original Message-
> From: Lowry, Roy K. [mailto:r...@bodc.ac.uk]
> Sent: Friday, February 18, 2011 2:38 PM
> To: Schultz, Martin; cf-metadata@cgd.ucar.edu
> Subject: RE: CF standard_name irradiation ?
>
> Hi Martin,
>
> There are two Standard Names
> 'downwelling_shortwave_flux_in_air' and
> 'downwelling_longwave_flux_in_air'.  Do either of these fit
> your data.  I have associated the former with downwelling
> irradiance data from PAR cosine-collector light meters.
>
> Cheers, Roy.



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF standard_name irradiation ?

[Schultz, Martin]

Dear colleagues,

I am trying to clean up some data files and make them CF compliant. But I 
am confused about the standard name that I could use for (measured) 
irradiation. There is an entry

"downwelling_spectral_radiative_flux_in_air
Downwelling radiation is radiation from above. It does not mean "net downward". 
"spectral" means per unit wavelength or as a function of wavelength; spectral 
quantities are sometimes called "monochromatic". Radiation wavelength has 
standard name radiation_wavelength. When thought of as being incident on a 
surface, a radiative flux is sometimes called "irradiance". In addition, it is 
identical with the quantity measured by a cosine-collector light-meter and 
sometimes called "vector irradiance". In accordance with common usage in 
geophysical disciplines, "flux" implies per unit area, called "flux density" in 
physics."

This definition explicitly mentions "irradiance", so I guess I am close to 
the solution. However, the irradiance measurement data I have are not 
"spectral". I did not find a standard_name entry 
"downwelling_radiative_flux_in_air" which I would have expected to be the 
integral flux. There are only various variants of "surface_net..." or 
"surface_spectral..." fluxes. These don't help, or am I wrong here?

Unless I am mistaken or have overlooked something obvious, I therefore 
propose to add a standard_name tabel entry:

"downwelling_radiative_flux_in_air
Downwelling radiation is radiation from above. It does not mean "net downward". 
When thought of as being incident on a surface, a radiative flux is sometimes 
called "irradiance". In addition, it is identical with the quantity measured by 
a cosine-collector light-meter and sometimes called "vector irradiance". In 
accordance with common usage in geophysical disciplines, "flux" implies per 
unit area, called "flux density" in physics. For spectrally resolved radiative 
flux or net radiative flux see downwelling_spectral_radiative_flux_in_air
or surface_net_downward_radiative_flux, respectively."


Best regards,

Martin Schultz

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF compliance of TFHTAP model data

[Schultz, Martin]

Dear colleagues,

we just posted a summary of "CF problems" which were encountered in the 
TFHTAP multi-model initiative and their fixes on the HTAP Wiki: 
http://htap.icg.fz-juelich.de/data/CFAdaption (or go to 
http://htap.icg.fz-juelich.de/ then navigate to "HTAP Model and Experiment 
Descriptions" and then click on "Adaption of HTAP data to CF standard 1.0 
(WCS)"). We hope that you find this illustrative as a "community of practice" 
example and that the TFHTAP modellers who will be involved in other 
intercomparison activities can make use of the information and shell scripts 
provided in order to ease the burden for those people who attempt to analyze 
such multi-model data sets.

Kind regards,

Martin Schultz, Sabine Schröder and Michael Decker

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] non-standard standard_names

[Schultz, Martin]

Dear all,

   first of all let me say that I truely appreciate the careful
discussion my proposal has initiated. This indeed is probably the most
convincing reason why CF has been accepted already in several parts of
the community.

   Steve made a very nice distinction to clarify what my suggestion of
_standard_names was really about. In fact it really had
elements of his (1) and (2) approaches. Let me re-iterate on both of
them:

(1) for the process of defining new standard names, I believe the
suggestions that were made all point into the right direction.
Personally, I like the standard_name: "proposed: " approach. Any
tool could then easily test if the string behind "proposed" exists in
the current standard_name table or not. If it doesn't, a warning occurs
but no error. Hence, no modification would be required to any existing
data set, albeit these files could be upgraded by removing the
"proposed" string once the name has been accepted. I also see the point
that communities should enhance their efforts to have names defined
before running their experiments. However, practical experience rarely
allows for this and we can only hope that over time there will be enough
standard names available to cover almost all aspects of such experiments
(in the atmospheric chemistry domain we have already come quite far
now).

(2) the "private" name space was more central to my suggestion. Steve
made cautioning comments about the development of non-standard GRIB
tables, and indeed these are a great pain. However, there is a
fundamental difference here in that netcdf files will always be amenable
to at least some interpretation provided that "good" metadata is
provided, while one is completely lost with a GRIB file if the code
table cannot be found (we experienced this the hard way when we first
added chemical species into the ECHAM model).

The discussion so far has viewed my proposal mainly from the CF
perspective. I would like to invite you again to take the view of the
project coordinator for a minute. Experience shows that about 95% or
more of the preparations for new experiments go into scientific
validation of the model and making sure it runs at all and hopefully
reasonably efficient. Then someone at a meeting gets up and displays a
long list of seemingly glibberish semantic phrases which are to be
proposed as standard names in some weird "convention". Typically this
presentation is given during the last 5 minutes of a meeting and 50% of
the audience have already left for the airport. Consequently, the
coordinator (or some nice fellow supporting him/her) has to deal with
this standardisation on his/her own (while at the same time preparing
their own model). Finally, a proposal for new standard names is
submitted and by the time the discussion is over 30% have passed
unaltered, 60% require modification and 10% are rejected. At that point
in time most model runs have been submitted. Now: what do you do? I
guess each and every one of these coordinating fellows/fellas will be
happy if he/she can assure that all data in the archive are not
corrupted, the models have worked and the analysis that was planned can
be performed. Proper archiving and interoperability (still) come as an
afterthought. [I only hope this doesn't sound too negative, I may have
been watching too much cabaret lately ;-)]

-- back to the actual suggestion: what I wanted to express with my
proposal is that we should find a way to acknowledge that someone has
tried to establish new standard names while at the same time the "pure"
standard should not be corrupted. The proposal of using "proposed:"
actually captures this very nicely. By the same token we could even go
as far as to allow the keyword "private:" in the standard_name string
(instead of defining a new _standard_name). Yes: it does to
some extent weaken the stringency of a standard_name, but only on the
surface. In reality I believe such qualifiers could even strengthen the
concept. We could require that a "project" attribute must be part of the
global attributes if the "private" qualifier is used and the project
attribute must point to a web resource where information on the project
is given (perhaps one could even think of a central "project" database
with a simple registration process to make eternity easier to achieve).
As project manager you may be glad to surf on the well-designed concept
that CF and the standard names provide and there is currently no
standardized way to do this. By allowing such qualifier keywords to the
standard_name attribute, nothing would change in terms of "official"
standards (as these are the standard_names without any qualifier) while
it would become a lot easier for newcomers and other groups to take
advantage of the concept. In effect this would be a neat way to address
the needs both of the operational community, where it is very important
to rely on the long lifetime of a name and of the "experimental"
community, which needs flexibility more than a

[CF-metadata] non-standard standard_names

[Schultz, Martin]

Dear all,

we are currently cleaning all files on our TFHTAP multi-model
experiment server to make them fully CF(1.0) conformant. It has been
about 3 years since we had drafted the original format description of
these experiments and also initiated the standard name discussion for
chemical constituents (thanks again to Christiane Textor who did a lot
of this initial work). Many standard names which we needed have now been
defined (thanks to all who contributed and to Allison for maintaining
the list!). Nevertheless, there are a number of model variables left for
which no standard name has been agreed upon and where we (or the CF
mailing list group) also felt that they are too specialized to deserve a
"standard" name. From the perspective of the CF community this may not
be an issue, but in the context of interoperability (we now operate a
WCS server to share these files) the fact that some variables do have a
standard_name attribute and others don't poses considerable challenges.
The CF convention states that "either standard_name or long_name" should
be present. In our view, the long_name attribute is a poor substitute
for the standard_name, because it has no rules attached. We are now
planning to substitute "illegal" standard_name attributes by a new
"htap-_standard_name" attribute, which shall make clear that these names
are derived according to the CF guidelines, but they are not accepted
standard_names. Such a concept would enable software tools to easily
scan additional standard_name tables and make use of the well-defined
semantics that a standard_name provides without having to push
additional standard_names through the discussion - in particular if they
are no so "standard". I can see the danger that certain groups might
think it no longer necessary to go through the tedious but ultimately
worthwhile discussion process in this mailing list and the meaning of
"standard" names could get diluted. However, in my view the advantage of
having the possibility to extend the convention without breaking
standard-conformance outweighs this potential disadvantage.

Specifically I would thus propose to add an optional attribute to
the CF documents such as:

_standard_name: use this attribute to define the meaning of
variables which have no accepted standard_name defined (yet). The
project name should be a single string without blanks or underscore
characters. These project-specific standard_names must follow the
guidelines for the construction of standard_names, but they will not be
evaluated by generic tools which test a data file for CF compliance.
Groups who wish to define such project-specific standard names should
first consider to submit their proposals to the CF mailing list for
inclusion in the CF standard name table. A variable can contain either a
standard_name or _standard_name attribute but not both. A
long_name attribute is not needed when a _standard_name is
given.


Best regards,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata