[CF-metadata] Clarifying standard names for 'mass_concentration_of_*_dry_aerosol_particles'

Jonathan Gregory j.m.gregory at reading.ac.uk
Thu Dec 21 03:51:06 MST 2017


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 -----



More information about the CF-metadata mailing list