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 -----
Received on Thu Dec 21 2017 - 03:51:06 GMT
