Unstructured Grids Vocabulary Request

[tomgross]

Welcome to the Unstructured Grid Mailing lists. This task will be a sort of test for our ability to use the new CF task tracking and mailing list methods. Remember: Don't "reply" to the emails directly, use the web page instead. See GettingStarted and UnstructuredTaskLists

This first task/discussion thread concerns the creation of a vocabulary for Unstructured Grids. We began the task at the workshop and agreed upon a few useful starting points, such as the use of "Unstructured Grids" rather than "Unstructured Meshes", and the use of "Cell" instead of "Element" to refer to that fine grain structure which is usually a triangle or quadralateral made up of nodes, edges and faces.

Contribute to this thread your ideas for other necessary vocabulary and perhaps other structures and "things" we need to describe in the construction of the Unstructured Grid Data Model

Tom Gross

[dstuebe]

Hi Folks

To kick things off on the Unstructured Grids WIKI page I have added some ideas that I scribbled down on the flight home to the wiki page that Tom has set up.

*I need to change everything to Grid rather than Mesh, oops! Does anyone know how to fix the pages which are miss named mesh? how do I move those pages to xxxgrid instead of xxxmesh?

In the CdlDiscussion section, I added a bunch of topics and some of my thoughts about workable solutions.

The topics are:

​http://cf-pcmdi.llnl.gov/trac/wiki/Terminology

​http://cf-pcmdi.llnl.gov/trac/wiki/GlobalAttributes

​http://cf-pcmdi.llnl.gov/trac/wiki/MeshMetaData

​http://cf-pcmdi.llnl.gov/trac/wiki/CellTypes

​http://cf-pcmdi.llnl.gov/trac/wiki/ExtrudedMesh

​http://cf-pcmdi.llnl.gov/trac/wiki/StorageVsApplication

​http://cf-pcmdi.llnl.gov/trac/wiki/Dimensions

​http://cf-pcmdi.llnl.gov/trac/wiki/Variables

sorry about the http's, I am still getting the hang of the wiki thing...

The focus here is a practical approach to fitting our needs into the existing NetCDF CDL framework. I structured the meta data from the perspective of a programmer trying to write an API to read any compliant data set. The organization I tried to create is top down from the global attributes, to the grids, to the variables. It needs a lot of work so please add your own perspective, I hope it will be a good starting place though!

David

[tomgross]

Continuing the discussion of Unstructured Grid Vocabulary:

Most of this is detailed in the wiki page: UgCellArrays

The unstructured grids are two things: A collection of variables which are associated with a few simple geometric objects and more complex geometric constructions made out of those objects. There will be spacially located 1-d points which reside somewhere in space. Then there are triangles which are simply three of those points. A simple vocabulary hierarchy:

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.

The grid is the descriptor of the unstructured collection of triangles. Each cell of three points would be described by the indices of those three points [node1, node2, node3} Generalized a little bit to also call out the face and edges:

int grid(ncells, cell_length) ;

grid:cell_type = "tri_face_edged" grid:dims=[ nodes, nodes, nodes, faces, edges, edges, edges ]; grid:standard_name= "Cell_Connectivity_Indices"

A question for the CF conventions: Does this violate the "coordinate" dimension and variable concept? Or does the coordinate dimension of "nodes" make the connection to the variables Longitude(nodes), Latitude(nodes) etc.??

Replying to dstuebe:

Hi Folks

To kick things off on the Unstructured Grids WIKI page I have added some ideas that I scribbled down on the flight home to the wiki page that Tom has set up.

*I need to change everything to Grid rather than Mesh, oops! Does anyone know how to fix the pages which are miss named mesh? how do I move those pages to xxxgrid instead of xxxmesh?

In the CdlDiscussion section, I added a bunch of topics and some of my thoughts about workable solutions.

The topics are:

​http://cf-pcmdi.llnl.gov/trac/wiki/Terminology

​http://cf-pcmdi.llnl.gov/trac/wiki/GlobalAttributes

​http://cf-pcmdi.llnl.gov/trac/wiki/MeshMetaData

​http://cf-pcmdi.llnl.gov/trac/wiki/CellTypes

​http://cf-pcmdi.llnl.gov/trac/wiki/ExtrudedMesh

​http://cf-pcmdi.llnl.gov/trac/wiki/StorageVsApplication

​http://cf-pcmdi.llnl.gov/trac/wiki/Dimensions

​http://cf-pcmdi.llnl.gov/trac/wiki/Variables

sorry about the http's, I am still getting the hang of the wiki thing...

The focus here is a practical approach to fitting our needs into the existing NetCDF CDL framework. I structured the meta data from the perspective of a programmer trying to write an API to read any compliant data set. The organization I tried to create is top down from the global attributes, to the grids, to the variables. It needs a lot of work so please add your own perspective, I hope it will be a good starting place though!

David

[jonathan]

Replying to tomgross:

int grid(ncells, cell_length) ;

grid:cell_type = "tri_face_edged" grid:dims=[ nodes, nodes, nodes, faces, edges, edges, edges ]; grid:standard_name= "Cell_Connectivity_Indices"

A question for the CF conventions: Does this violate the "coordinate" dimension and variable concept? Or does the coordinate dimension of "nodes" make the connection to the variables Longitude(nodes), Latitude(nodes) etc.??

Dear Tom

To be CF complaint, all the variables ought to have coordinates and bounds. A data variable dimensioned (nodes) needs auxiliary coordinate variables (pointed to by its coordinates attribute) of latitude and longitude e.g. lat(nodes), and these should have bounds variables (named by their bounds attributes) such as lat_bounds(nodes,vertices). I presume that one of your objectives is to devise a scheme whereby the nodes of one grid e.g. the temperature grid can be indicated to be the faces of another e.g. velocity, whereas currently in CF there is no association of grids.

It is interesting to look at this example of the use of trac. My initial impression is that it may make it harder to engage people and help them follow the discussion, especially if the wiki is used. To follow a thread, it may work best to reply, like this. Then it can be read sequentially by other people. If it is dotted all over, it is hard to digest. Moreover, if only a small part of the actual information is in the trac ticket, observers of the discussion don't know what's going on unless they read the wiki too, and this may lead to less participation, as you can't pick it up without special effort. I think a wiki is useful if you are working on a document and editing it together, like a tracked-changes word document. But in that case, I wonder whether this system could automatically email out the current version of the wiki page whenever the ticket is updated. Could it do that, Kyle?

I wonder if we could use trac just like an email list, but with the advantage that people will be more aware than they are with email of the organisation of discussions into threads. It is unfortunately less convenient to type this kind of thing into trac than it is to write an email.

Best wishes

Jonathan

[taylor13]

Dear all,

Given that there is a small working group exploring options for representing unstructured grids, I am closing this ticket with the expectation that a new ticket will be opened when the working group comes up with one or more concrete proposals.

Best regards, Karl