I agree that Brian and Steve's idea of adding a new variable to contain
the grid mesh or staggered info is the right way to do it. Still to do
is to agree on the exact attributes and their meanings.
FYI there are some differences in way the CF does things and a design i
have been working on as part of the netcdf-java and netcdf-4 work. CF
now has 2 "container variables": the "grid mapping" and now the "grid
description". The dependent variables must all seperately point to
these. From my POV, both are properties of a "coordinate system" object,
so i prefer a design that attaches the grid mapping and description (and
whatever else will eventually be needed) to a coordinate system
"container variable"; the dependent variables then only have to point to
this, and all the information is contained in one place. I think i can
also incorporate "dimensionless vertical coordinates" in the same
framework: rather than having a seperate mechanism for specifying
"grid_mappings" and "dimensionless vertical coordinates", both are kinds
of "coordinate system transformations". Not really a big deal, but as we
try for a richer description of grids, a bit simpler syntax perhaps.
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
>>
>>
>
>
Received on Mon Nov 22 2004 - 11:11:30 GMT
