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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20171221/0fe94c4c/attachment.html>
Received on Wed Dec 20 2017 - 17:07:45 GMT
