Dear Jonathan,
>> Regarding "dry": When we provide the total particle mass or the
>> particle size distribution, it is important to distinguish between
>> dry and wet particle condition. When we provide the mass of one
>> species (independent of the particle size) it does not matter
>> whether we consider dry oder wet particles. Therefore, dry does not
>> need to be included in these names.
> OK - that's fine. Do you also not need to mention "aerosol"? I mean, does
> "particulate" necessarily mean "aerosol"? I suppose it does, in air.
Yes, your are right.
>> Is it feasible to rename all affected standard names?
> It would be feasible (using aliases) but is it necessary? It seems to me that
> your question has identified that there should be a distinction between e.g.
> mass_concentration_of_particulate_X_in_air
> and
> mass_concentration_of_X_dry_aerosol_particles_in_air
> for X=ammonium etc. These are different quantities: the former refers to the
> mass of ammonium only, the latter to the dry mass of the aerosol of that type.
> That is, we need new names for CMIP6, not aliases.
Yes, there should be a distinction between both standard names. However,
the latter name has been used as synonym for the first name up till now
(e.g. in CMIP5 or in a data set I published recently). Additionally, the
latter name has no real application - at least I am not aware of an
application (neither for model nor for measurement data). Therefore, it
might be reasonable for backward compatibility to use aliases.
Best,
Daniel
>> On 21.12.2017 11:51, Jonathan Gregory wrote:
>>> Dear Daniel
>>>
>>> I see this is an awkward problem. I can't think of a better idea than your
>>> suggestion of mass_concentration_of_particulate_X_in_air where X is
>>> ammonium etc. There are some ocean standard names with "particulate" in this
>>> sense. Does it matter that you don't have "dry aerosol" in there? I guess
>>> you could say mass_concentrations_of_dry_aerosol_particulate_X_in_air.
>>>
>>> Best wishes
>>>
>>> Jonathan
>>>
>>> ----- Forwarded message from Daniel Neumann<daniel.neumann at io-warnemuende.de> -----
>>>
>>>> To:cf-metadata at cgd.ucar.edu
>>>> From: Daniel Neumann<daniel.neumann at io-warnemuende.de>
>>>> Date: Thu, 21 Dec 2017 01:07:45 +0100
>>>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>>>> Thunderbird/52.5.0
>>>> Subject: Re: [CF-metadata] grid cells with a varying number of cell bounds
>>>>
>>>> Hi Karl,
>>>>
>>>> please note, that the usage of some of the standard names used in
>>>> the CMIP6 variable list do not comply with the current state of
>>>> discussion on the CF-Mailing list. I know it is not a topic in this
>>>> thread but I don't get people from CMIP6 Aerosol section involved on
>>>> this mailing list (tried William Collins and Michael Schulz).
>>>>
>>>> The affected standard names are (in the Tables Eday and AERmon):
>>>> tendency_of_atmosphere_mass_content_of_ammonium_dry_aerosol_particles_due_to_dry_deposition
>>>> tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_particles_due_to_dry_deposition
>>>> mass_fraction_of_ammonium_dry_aerosol_particles_in_air
>>>> mass_fraction_of_nitrate_dry_aerosol_particles_in_air
>>>> mass_fraction_of_sulfate_dry_aerosol_particles_in_air
>>>> mass_fraction_of_secondary_particulate_organic_matter_dry_aerosol_particles_in_air
>>>> tendency_of_atmosphere_mass_content_of_ammonium_dry_aerosol_particles_due_to_wet_deposition
>>>> tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_particles_due_to_wet_deposition
>>>> atmosphere_mass_content_of_nitrate_dry_aerosol
>>>> atmosphere_mass_content_of_ammonium_dry_aerosol
>>>> atmosphere_mass_content_of_sulfate_dry_aerosol
>>>>
>>>> The problem arose here:
>>>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059554.html
>>>> Text passages following "10. ..." and "11. ...".
>>>>
>>>> and please see my last reminder on this topic including a summary here:
>>>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059573.html
>>>> and here
>>>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059768.html
>>>>
>>>> Yes, I am pushy on this topic ;-) . I would like to have this
>>>> ambiguity resolved at one point of time. This state of discussion
>>>> can be changed IF ENOUGH PEOPLE PARTICIPATE IN THE DISCUSSION --
>>>> which I would love.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>>
>>>>
>>>> On 20.12.2017 23:21, Karl Taylor wrote:
>>>>> Hi all,
>>>>>
>>>>> It now becomes urgent to resolve this discussion.
>>>>>
>>>>> My sense is that no one violently opposes the use of missing_value
>>>>> to fill unused vertices for grid cells with fewer than the maximum
>>>>> number of vertices.? For CMIP6 some models may need to define
>>>>> grids with a few cells having one less vertex than the majority. I
>>>>> am (much too late in the process) writing down the data
>>>>> requirements for CMIP6 model output, and unless someone objects, I
>>>>> will specify that the missing_value can be used in this way.
>>>>>
>>>>> My only qualm is that technically, some might regard such files as
>>>>> non compliant with CF, but in practice I don't think the
>>>>> non-compliance will have much (if any) impact.
>>>>>
>>>>> Speak now, or forever hold your peace. (The wedding is imminent).
>>>>>
>>>>> best regards,
>>>>> Karl
>>>>>
>>>>> On 9/12/17 8:08 AM, Whiteaker, Timothy L wrote:
>>>>>> Wearing my simple geometry hat: While simple geometries could
>>>>>> handle this case, that proposal was intended to support discrete
>>>>>> geospatial features such as river segments or watershed areas,
>>>>>> including multi-part polygons such as Hawaii and polygons with
>>>>>> holes such as a lake polygon with an island in the middle.? It
>>>>>> may be overkill for the OP's use case.
>>>>>>
>>>>>> My humble opinion as a general netCDF user: Allowing missing
>>>>>> values seems simple and efficient for the OP's use case. My only
>>>>>> worry would be that this solution introduces a competing method
>>>>>> of encoding discrete polygons like what the simple geometries
>>>>>> proposal targets; this would be alleviated with proper guidance
>>>>>> on when to use these various solutions in the CF documentation.
>>>>>> I also admit my ignorance regarding prevalence of other grid
>>>>>> cell configurations in datasets out in the wild which the
>>>>>> missing value solution wouldn't cleanly support, or the impact
>>>>>> of the missing value solution on netCDF software libraries.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tim Whiteaker
>>>>>>
>>>>>> Research Scientist
>>>>>>
>>>>>> The University of Texas at Austin
>>>>>>
>>>>>> *From:*CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] *On
>>>>>> Behalf Of *David Hassell
>>>>>> *Sent:* Monday, September 11, 2017 4:22 AM
>>>>>> *To:* Jonathan Gregory<j.m.gregory at reading.ac.uk>
>>>>>> *Cc:* CF Metadata<cf-metadata at cgd.ucar.edu>
>>>>>> *Subject:* Re: [CF-metadata] grid cells with a varying number of
>>>>>> cell bounds
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Coorecting an error in my last post:
>>>>>>
>>>>>> On 8 September 2017 at 17:51, David Hassell
>>>>>> <david.hassell at ncas.ac.uk <mailto:david.hassell at ncas.ac.uk>>
>>>>>> wrote:
>>>>>>
>>>>>> Hello Karl, Jonathan, Jim,
>>>>>>
>>>>>> I also support Karl's suggested changes, with the possible
>>>>>> exception of insisting that the valid bounds values always
>>>>>> precede the any missing data. Whilst that is surely the easiest
>>>>>> case for software to deal with, and is an attractive restriction
>>>>>> to me, it that may not be how people want to do it, or have
>>>>>> already done it in the past.
>>>>>>
>>>>>> ??
>>>>>>
>>>>>> I'm don't think that allowing this would not cause any more
>>>>>> confusion than is already (will be!) there with the inclusion of
>>>>>> simple geometries. As Jonathan points out, it would be "not
>>>>>> recommended" to use simple geometries when standard bounds
>>>>>> suffice. That advice easily includes standard bounds being
>>>>>> allowed missing values, I think.
>>>>>>
>>>>>> ?I had one too many negatives in last paragraph. It should have read:?
>>>>>>
>>>>>> ??I'm *DO* think that allowing this would not cause any more
>>>>>> confusion than is already (will be!) there with the inclusion of
>>>>>> simple geometries. As Jonathan points out, it would be "not
>>>>>> recommended" to use simple geometries when standard bounds
>>>>>> suffice. That advice easily includes standard bounds being
>>>>>> allowed missing values, I think.?
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Sorry for the confusion,
>>>>>>
>>>>>> David?
>>>>>>
>>>>>> All the best,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 8 September 2017 at 16:24, Jonathan Gregory
>>>>>> <j.m.gregory at reading.ac.uk <mailto:j.m.gregory at reading.ac.uk>> wrote:
>>>>>>
>>>>>> Dear Karl
>>>>>>
>>>>>> I agree, other views are needed; it would be especially
>>>>>> useful to hear from
>>>>>> Dave Blodgett and other proposers of the simple geometries.
>>>>>> Although I agree
>>>>>> that what you describe is not necessarily inefficient (and in
>>>>>> the case you
>>>>>> mention it would be more efficient than the simple
>>>>>> geometries), and it's not
>>>>>> a large change to the existing convention, I do think it *is*
>>>>>> a change, since
>>>>>> we don't normally permit missing data in boundary variables.
>>>>>>
>>>>>> I don't have a strong preference between the methods. What
>>>>>> discomforts me is
>>>>>> introducing two methods for doing the same thing. If we did
>>>>>> that, we should
>>>>>> give some clear guidance to data-writers about which to choose.
>>>>>>
>>>>>> Of course, there is no suggestion that the simple geometries
>>>>>> approach should
>>>>>> replace the existing one for cells with polygons that all
>>>>>> have the same number
>>>>>> of vertices. Consistent with the last paragraph, I suggest
>>>>>> that we should
>>>>>> recommend the use of the existing convention for that case,
>>>>>> rather than the
>>>>>> simple geometries convention.
>>>>>>
>>>>>> Best wishes
>>>>>>
>>>>>> Jonathan
>>>>>>
>>>>>> ----- Forwarded message from Karl Taylor <taylor13 at llnl.gov
>>>>>> <mailto:taylor13 at llnl.gov>> -----
>>>>>>
>>>>>> > Date: Fri, 8 Sep 2017 07:12:06 -0700
>>>>>> > From: Karl Taylor <taylor13 at llnl.gov
>>>>>> <mailto:taylor13 at llnl.gov>>
>>>>>> > To:cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>>>>>> > Subject: Re: [CF-metadata] grid cells with a varying number
>>>>>> of cell bounds
>>>>>> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11;
>>>>>> rv:52.0)
>>>>>> >? ? ? ?Gecko/20100101 Thunderbird/52.2.1
>>>>>> >
>>>>>> > Dear Jonathan and all,
>>>>>> >
>>>>>> > Regarding the options for representing polygon cells with
>>>>>> varying
>>>>>> > number of sides (see below), I agree that the "simple
>>>>>> geometries"
>>>>>> > proposal can indeed handle this case. ( It of course could also
>>>>>> > handle the case when all grid cells have the same number of
>>>>>> sides.)
>>>>>> >
>>>>>> > I think, however, it might be a mistake to rule out the
>>>>>> alternative
>>>>>> > method of storing data on these grids using the old method
>>>>>> with cell
>>>>>> > bounds described by their vertices (without the need for
>>>>>> > "containers").? Certainly, I would want to retain the current
>>>>>> > treatment? when dealing with cells having the? *same* number of
>>>>>> > sides.? I also favor an option to use our current method
>>>>>> (which is
>>>>>> > however incompletely described, as I've pointed out) to
>>>>>> handle grids
>>>>>> > with cells of different shapes.? All we would need to make the
>>>>>> > current method well-described is to specify that the bounds
>>>>>> could
>>>>>> > include "missing_values" when the number of grid cell
>>>>>> vertices were
>>>>>> > fewer than the maximum specified in the dimension statement
>>>>>> (and the
>>>>>> > missing_values would be the last ones in the bounds dimension).
>>>>>> >
>>>>>> > I would point out that for at least one icosahedral grid (see
>>>>>> > Heikes, R., and D. A. Randall, 1995a: Numerical integration
>>>>>> of the
>>>>>> > shallow-water equations on a twisted icosahedral grid. Part
>>>>>> I: Basic
>>>>>> > design and results of tests. /Mon. Wea. Rev.,/*123,*
>>>>>> 1862?1880), all
>>>>>> > the grid cells except 12 are hexagons. The 12 exceptions
>>>>>> come from
>>>>>> > the "corners" of a cube and are pentagons. This means that
>>>>>> the cell
>>>>>> > bounds would contain only 12 missing_values, so not a
>>>>>> significant
>>>>>> > problem with wasting storage.
>>>>>> >
>>>>>> > If we decide to eliminate the "old" option for handling
>>>>>> these grid
>>>>>> > cells, we should:
>>>>>> >
>>>>>> > 1) first poll the modeling groups to see if anyone knows of any
>>>>>> > attempts to use the current CF conventions to store data on
>>>>>> such
>>>>>> > grids.? If not, then changing the standard won't have any real
>>>>>> > consequences on legacy datasets.
>>>>>> >
>>>>>> > 2)? Provide an example in the proposed section 7.5
>>>>>> illustrating how
>>>>>> > an icosahedral grid like the one referenced above would be
>>>>>> stored. I
>>>>>> > must say I think few would be able to quickly read section
>>>>>> 7.5 and
>>>>>> > be able to successfully store CF-compliant data on such
>>>>>> grids;? the
>>>>>> > current method, on the other hand, is easy to understand.
>>>>>> >
>>>>>> > I have no problem allowing the new method to be used, but
>>>>>> wonder if
>>>>>> > most users wouldn't find it easier in the case under
>>>>>> consideration
>>>>>> > here, to interpret datasets stored with the older method?
>>>>>> Hope to
>>>>>> > hear other views on this.
>>>>>> >
>>>>>> > best regards,
>>>>>> > Karl
>>>>>> >
>>>>>> >
>>>>>> > >>I certainly always envisaged the possibility of cells of
>>>>>> different
>>>>>> > >>shapes, and we imply that this might be the case in the
>>>>>> description
>>>>>> > >>of cell bounds with the explicit mention of "maximum":
>>>>>> > >>
>>>>>> > >>/"A boundary variable will have one more dimension than its
>>>>>> > >>associated coordinate or auxiliary coordinate variable./ The
>>>>>> > >>additional dimension should be the most rapidly varying
>>>>>> one, and its
>>>>>> > >>size is the maximum number of cell vertices."
>>>>>> > >That's true. Nonetheless we didn't provide for it later on
>>>>>> in the document!
>>>>>> > >
>>>>>> > >Well, now we have a choice. Dave Blodgett's proposal has
>>>>>> been debated and
>>>>>> > >revised over many months, and I support it in its current
>>>>>> form. That is a
>>>>>> > >more general solution, which allows not only mixtures of
>>>>>> different sorts of
>>>>>> > >polygons, but also sets of discontiguous polygons (for
>>>>>> each cell), polygons
>>>>>> > >with holes in them, and lines. It does not require missing
>>>>>> data to be stored
>>>>>> > >in the bounds, because it has a count of how many vertices
>>>>>> belong to each cell.
>>>>>> > >Permitting missing data in polygon bounds in sect 7.1
>>>>>> would be a different
>>>>>> > >way of describing a mixture of different sorts of
>>>>>> polygons. Providing more
>>>>>> > >than one method to do this would introduce unnecessary
>>>>>> complexity. How do you
>>>>>> > >and others think we should choose?
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>> > _______________________________________________
>>>>>> > CF-metadata mailing list
>>>>>> >CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>>>> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>>>
>>>>>>
>>>>>> ----- End forwarded message -----
>>>>>> _______________________________________________
>>>>>> CF-metadata mailing list
>>>>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> David Hassell
>>>>>> National Centre for Atmospheric Science
>>>>>> Department of Meteorology, University of Reading,
>>>>>> Earley Gate, PO Box 243, Reading RG6 6BB
>>>>>> Tel: +44 118 378 5613 <tel:+44%20118%20378%205613>
>>>>>> http://www.met.reading.ac.uk/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> David Hassell
>>>>>> National Centre for Atmospheric Science
>>>>>> Department of Meteorology, University of Reading,
>>>>>> Earley Gate, PO Box 243, Reading RG6 6BB
>>>>>> Tel: +44 118 378 5613
>>>>>> http://www.met.reading.ac.uk/
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CF-metadata mailing list
>>>>>> CF-metadata at cgd.ucar.edu
>>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>> _______________________________________________
>>>>> CF-metadata mailing list
>>>>> CF-metadata at cgd.ucar.edu
>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>> --
>>>> Daniel Neumann
>>>>
>>>> Leibniz Institute for Baltic Sea Research Warnemuende
>>>> Physical Oceanography and Instrumentation
>>>> Seestrasse 15
>>>> 18119 Rostock
>>>> Germany
>>>>
>>>> phone: +49-381-5197-287
>>>> fax: +49-381-5197-114 or 440
>>>> e-mail:daniel.neumann at io-warnemuende.de
>>>>
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu
>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>> ----- End forwarded message -----
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> --
>> Daniel Neumann
>>
>> Leibniz Institute for Baltic Sea Research Warnemuende
>> Physical Oceanography and Instrumentation
>> Seestrasse 15
>> 18119 Rostock
>> Germany
>>
>> phone: +49-381-5197-287
>> fax: +49-381-5197-114 or 440
>> e-mail:daniel.neumann at io-warnemuende.de
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Daniel Neumann
Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany
phone: +49-381-5197-287
fax: +49-381-5197-114 or 440
e-mail:daniel.neumann at io-warnemuende.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180103/f72d3746/attachment.html>
Received on Wed Jan 03 2018 - 02:58:05 GMT
