Dear Daniel
> 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.
> 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.
Best wishes
Jonathan
> 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 -----
Received on Wed Dec 27 2017 - 02:44:03 GMT
