Dear All,
we are setting up some climate runs and use the Arakawa C grid in our
model.
Up to now I could not find any official comment describing how to
handle staggered grids in CF-Conventions.
There was an email discussion about this more than a year ago. The
last email on this I found in the CF-archive was from Rich Signell
November 22, 2004 (see below).
Is there already an official way how to handle staggered grids in CF-
Conventions? If yes, can anyone sent me an example? If not, how
should I proceed?
Regards
Burkhardt
Rich Signell
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
Received on Wed Aug 17 2005 - 05:05:23 BST
