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 <[email protected]> ----- > To: [email protected] > From: Daniel Neumann <[email protected]> > 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:[email protected]] *On > >>Behalf Of *David Hassell > >>*Sent:* Monday, September 11, 2017 4:22 AM > >>*To:* Jonathan Gregory <[email protected]> > >>*Cc:* CF Metadata <[email protected]> > >>*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 > >><[email protected] <mailto:[email protected]>> > >>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 > >> <[email protected] <mailto:[email protected]>> 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 <[email protected] > >> <mailto:[email protected]>> ----- > >> > >> > Date: Fri, 8 Sep 2017 07:12:06 -0700 > >> > From: Karl Taylor <[email protected] > >> <mailto:[email protected]>> > >> > To: [email protected] <mailto:[email protected]> > >> > 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 > >> > [email protected] <mailto:[email protected]> > >> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> > >> > >> ----- End forwarded message ----- > >> _______________________________________________ > >> CF-metadata mailing list > >> [email protected] <mailto:[email protected]> > >> 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 > >>[email protected] > >>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > >_______________________________________________ > >CF-metadata mailing list > >[email protected] > >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: [email protected] > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
