Hi Rich et. al.,
Regarding the need for a new grid structure variable ("grid_info" in your
example) that can encapsulate the types of detailed structure information
helpful for modelers communicating with modelers ---
We chatted briefly about the pressure for "compliance levels" as CF grows in
scope and complexity. I think this is an example where that reasoning should
be applied. I'd lobby that grid structure variables, if deemed necessary,
should be conceived as a new level of optional feature -- with a guarantee that
CF files will remain interpretable when the "grid_info" variables are omitted.
This will imply some level of redundancy -- that some of the same information
will be communicated both through attributes (e.g. "coordinates=") and through
the grid_info variable. To a degree this is inevitable, for reasons of
backwards compatibility, anyway. But it will be a specific consideration when
designing new encodings for unstructured meshes.
The proposed area of development represents a new avenue of development.
Complex grid inter-relationships are for the most part understood *implicitly*
in model code, in paragraph form in papers and text books, and not-at -all in
the overwhelming majority of file-reading applications. Metadata standards of
this type for model outputs largely do not exist at this time. So this
development area is virtually guaranteed to remain at a rapid level of evolution
for some time to come. I urge you proceed cautiously with respect to
"standardizing" it as a published part of CF until it is known to be stable.
In my own group we put analogous machinery into COARDS files ten years ago, but
largely abandoned it, in part because of complexity. Even a simple rectilinear
(staggered) MOM output ended up requiring six "grid_info" variables to capture
all of the permutations of 2D and 3D staggered grids that were commonly combined
in a file. The result was that although, the enhanced file structure was more
powerful, it was painful to explain and use.
- steve (Mr. Caution)
P.S. The essence of this discussion lies in arriving at agreement on
**requirements**. What is required now v.s. what would be nice to have now and
may be required in the future.
=====================================
Rich Signell wrote:
> CF Community,
>
> I think Brian's idea of a "grid" attribute is great!
> By creating an attribute pointing to a
> variable with metadata about the grid is a great solution
> that not only solves the unstructured mesh problem, but the
> previously unresolved staggered grid problem as well.
>
>
> I would argue (I think along with John Caron, if I interpret
> his posts from a year ago correctly) that there *is* value
> in the explicit specification of staggered grid information.
> For example, the C grid is used by most ocean models (POM,
> NCOM, ROMS, to name a few), and these models also have
> dimensionless coordinates that need to be calculated based on
> time dependent variables like the sea surface height. Since the
> sea surface height does not exist at the u and v points,
> a client application trying to plot a vertical section of u
> needs to interpolate the sea surface height (and the depth)
> to the u locations. Clients *could* be made smart enough
> to do interpolations whenever something doesn't exist at the
> location it is needed, but if we *know* that we are dealing
> with a C grid, the clients can be simpler and more efficient,
> just averaging the sea surface height and depth from pressure
> points "to the right" and "to the left" of the u points.
>
> Of course the pressure point "to the right" of a u(i,j) point
> might be p(i,j) or it might be p(i+1,j). Again, the client
> *could* be smart enough to figure this out by looking at the
> relative location of the lon,lat points for u and p, but why
> not specify this explicitly to make it easy for client builders?
> So for C grid, we could specify something like this:
>
> netcdf c_grid_example {
> ....
> u:grid = "grid_info"
>
>
> v:grid = "grid_info"
>
>
> char grid_info
> grid_info:grid_name = "Arakawa_C_grid"
> grid_info:u_relative_to_pressure = "left"
> grid_info:v_relative_to_pressure = "below"
> }
>
>
> where the last two attributes would signify that u(i,j) is
> "left" of p(i,j) and v(i,j) is "below" p(i,j).
>
>
> Specifying C-grid would also allow the lon and lat positions
> of the u and v points to be estimated in the case that they
> were not supplied. This is often the case -- there are many
> C-grid netcdf data sets I know of where only then lon,lat of
> the pressure points is given.
>
>
> Again I think this is a great development and hope we get some
> discussion and or confirmation of these ideas!
>
>
> -Rich Signell
>
> Brian Eaton wrote:
>
> >All,
> >
> >I agree with Steve's general comments on the current proposal. And I agree
> >with adding new attributes to point to the variables that will describe
> >properties of the mesh. The only thing I'd like to modify about Steve's
> >proposal is that rather than attaching those attributes directly to the
> >dependent variables, I'd prefer an analogous approach to the one we chose
> >(after a lengthy discussion) for describing grid mappings. In this case
> >we're trying to describe the grid, so I propose a "grid" attribute to
> >attach to the dependent variable, and that attribute points to a variable
> >which just acts as a container for all the specific attributes needed to
> >describe connections and boundary nodes for a particular type of mesh.
> >I've modified the original proposal to illustrate the idea, without having
> >given much thought to whether or not the specific attribute names are the
> >best ones.
> >
> >netcdf umesh_cf {
> >dimensions:
> > node = 9700 ;
> > nele = 17925 ;
> > nbnd = 1476 ;
> > nface = 3 ;
> > nbi = 4 ;
> > sigma = 1 ;
> > time = UNLIMITED ; // (0 currently)
> >variables:
> > float time(time) ;
> > time:long_name = "Time" ;
> > time:units = "days since 2003-01-01 0:00:00 00:00" ;
> > time:base_date = 2003, 1, 1, 0 ;
> > time:standard_name = "time" ;
> > float lon(node) ;
> > lon:long_name = "Longitude" ;
> > lon:units = "degrees_east" ;
> > lon:standard_name = "longitude" ;
> > float lat(node) ;
> > lat:long_name = "Latitude" ;
> > lat:units = "degrees_north" ;
> > lat:standard_name = "latitude" ;
> > float depth(node) ;
> > depth:long_name = "Bathymetry" ;
> > depth:units = "meters" ;
> > depth:positive = "down" ;
> > depth:standard_name = "depth" ;
> > depth:grid = "grid_description";
> > char grid_description
> > mesh:grid_name = "triangular_mesh";
> > mesh:Horizontal_Triangular_Element_Incidence_List = "ele";
> > mesh:Boundary_Segment_Node_List = "bnd";
> > mesh:index_start = 1;
> > int ele(nele, nface) ;
> > int bnd(nbnd, nbi) ;
> >
> >
> >Brian
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> >
>
> --
> Richard P. Signell rsignell at usgs.gov
> U.S. Geological Survey Phone: (508) 457-2229
> 384 Woods Hole Road Fax: (508) 457-2310
> Woods Hole, MA 02543-1598
>
> _______________________________________________
> 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
Received on Mon Nov 22 2004 - 11:27:45 GMT
