Hi All,
Coming back from a few days of travel I see this lengthy thread of
discussion about cell_measure. I'd like to offer a couple of
observations -- taking on my usual role as gadfly. As background for
the philosophy that guides me here I offer this quotation that Russ Rew
presented at GO-ESSP in June:
... from "The Rise and Fall of CORBA" (Henning, 2006):
*"To create quality software [or standards], the ability to say 'no'
is usually far more important than the ability to say 'yes.'"*
OK, with that curmudgeonly start ;-) :
Some pretty basic issues have been raised here that seem to live on the
boundary between "CF conventions" and "CF standard name".
* We are about to see the startup of a major new CF development in
the area of so-called "unstructured grids". This was an outcome
of the GO-ESSP meeting in June. These discussions should lead to
a CF formulation for non-rectangular grids that includes
reference files, testing, and a requirement that multiple
applications can read non-rectangular grid data from CF files.
Have these fundamental milestones been achieved at present with
respect to any value of "nv" that is not a power of two? For
example the nv=6 "spherical geodesic grid" of example 7.3? (It
will be vital to know this as the unstructured grid work ramps
up.) If a concept has been written into the CF-1.0 document, but
barely implemented in code and the same concept is going to be
fully developed in another area of the standard might it make
sense to leave the door open for deprecating a (minor) part of the
version 1.0 standard? Will it make sense to continue to allow nv
to take on values that are not powers of two?
All I am really saying is that it is ok not to come to a decision so
quickly. This topic has been open for 24 hours and has generated 10
messages. (11 counting this curmudgeon's contribution.) Maybe it needs
a wider airing and some time to think about it in light of anticipated work.
But maybe not, too. I have not tried to follow every word of the
dialog. Just urging caution.
- Steve
=======================================================
Jonathan Gregory wrote:
> Dear Christiane
>
>
>> Can I conclude from your discussion that standard names describing the
>> grid are to be accepted as "data variables in their own right"? This was
>> demanded by the HTAP community?
>>
>
> I wonder whether anyone strongly disagrees. In the new CF process, as the old,
> consensus should be found if possible. I think Alison will sum up, as she
> posted yesterday.
>
>
>> grid_cell_area
>> grid_cell_height
>>
>
> (1) I would omit "grid" because of consistency with cell_measures and
> cell_methods, and because "grid" might imply that it is only relevant for,
> say, a 2D array of cells, which might not be the case; you could use such
> a variable even if there were only a single cell.
>
> (2)
>
>> For the latter I prefer height to thickness, because it indicates a
>> vertical direction.
>>
> In existing CF stdnames, "height" means distance above the surface, and
> "thickness" means vertical extent, so I think this measurement is a thickness.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061005/eebcb8bb/attachment-0002.html>
Received on Thu Oct 05 2006 - 15:57:41 BST
