Version 4 (modified by tomgross, 12 years ago) (diff) |
---|

## Strawman Example of CDL for Cell Array Method

This is an example of a CDL based a simple hierarchy of geometric objects:

- node
- The 1d geometry point. A location.
- edge
- Simple line segments, defined by two locations
- face
- An area defined on a cell
- cell
- An object with corners, edges and faces. May or may not be three dimensional.
- grid
- A collection of cells
- mosaic
- A collection of grids with connectivity information
- track
- A collection of edges. Used to describe coastlines, boundaries or interior elongated objects like roadways or levees.

A simple cell is defined by the indices which call out the nodes, edges, and faces that comprise the cell. In this strawman CDL case the simple cell for the grid will be a triangle defined by three nodes and having some variables specified at edges and the central face of the triangle. Below in the grid meta data I call this "tri_face_edged" .

The data set will consist of a grid of cells. The index array for the grid will be dimensioned to the number of cells. The data set will also consist of a collection of nodes, defined by their spatial location. The data set will also contain a collection of edges. Edges are defined by two nodes. Edges must have a direction associated with them, so it is necessary to define an edge independent of the two different cells which it may be part of. So, grid(icell,:) provides the indices to all the other data:

- grid(icell, :) = [ 4 5 8 2 3 4 10 ]
- The triangle is defined by lon([4 5 8]), lat([4 5 8])
- The face or area average temperature is at: temp(2)
- The Heat flux to the inside of the triangle is given by the sum( Ftemp([3 4 10]).*length_edge([3 4 10]) ) with something clever done to get the sign of the inside to outside of the triangle correct. That info is in there, but more later.....(sorry)

I find it interesting that there is enough information specified in the grid and edge arrays to define the connectivity of the irregular grid. But it all makes no sense without data which needs to be pointed to by indices of the grid. So there must be locations for the nodes, longitude and latitude. A variable which is specified at the nodes will be dimensioned by the number of nodes, like the zeta variable below. Edge variables are not defined at the center of an edge. They are defined for the whole line segment and you would expect them to be objects like normal fluxes, Uf and Ftemp below. If you want to locate a variable like flux at a point, I think you are not thinking about flux anymore. To have any transport a flux must be applied to a length or area, not a single point. A useful auxilliary array might be provided, length_edges. But of course it could have been derived from lon, lat and edge indices.

- length_edge(iedge) = sqrt( (lon(edge(iedge,1))-lon(edge(iedge,2)))
^{2}+ (lat(edge(iedge,1))-lat(edge(iedge,2)))^{2}) (ok lon2meters etc..)

netcdf tri_grid { dimensions: nodes = 300 ; cells = 570 ; faces = 570 ; edges = 870 ; cell_length = 7 ; two = 2 ; time = UNLIMITED ; // ( not many, currently) variables: int grid(cells, cell_length) ; grid:cell_type = "tri_face_edged" grid:dims=[ nodes, nodes, nodes, faces, edges, edges, edges ]; grid:standard_name= "Cell_Connectivity_Indices" int edge(edges,two) edge:dims= [ nodes, nodes ]; edge:standard_name="Edge_Connectivity_Indices" float lon(nodes) lon:standard_name="longitude"; float lat(nodes) lat:standard_name="latitude"; float length_edge(edges) units="m" standard_name="length_edge" float zeta(nodes) zeta:standard_name="sea_surface_height"; float temp(faces) temp:standard_name="temperature"; temp:units="degrees centigrade" float Uf(edges) Uf:standard_name="Normal_Velocity"; Uf:units="m/s" float Ftemp(edges) Ftemp:standard_name="Normal_heat_flux"; Ftemp:units="Calories m/s"

**Go Back to** CdlDiscussion ** Table of Contents**

**Go Back to** UnstructuredGrids **Table of Contents**