Hi all,
I've been following this discussion with much interest, and I think
Steve provides wise guidance here. We shouldn't stop expanding, but
keep some redundancy so that less sophisticated (i.e., all currently
available) applications can proceed at least quasi-reasonably even if
they don't understand the new capabilities.
Karl
Steve Hankin wrote:
> 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
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Mon Nov 22 2004 - 11:56:19 GMT
