On Fri, Feb 8, 2013 at 5:50 PM, Charles Seaton <cse...@stccmop.org
> The main questions are:
> 1) If face_x and face_y are truly optional variables, and data is defined on
> faces, what should be used for the value of the coordinates attribute, or
> should the coordinates attribute be omitted?
I've always been a little fuzzy on exactly what the requirements are
for the coordinates attribute are. But my instict is to say omit it in
this case -- clients that understand UGRID would use the:
:location = "face"
attribute no know the data is on the faces.
> 2) Is the location index set intended to be sufficient to handle variables
> defined on boundary edges and is the inconvenience of having to define the
> full edge_node_connectivity in order to subset it considered an acceptable
It's a matter of how the application thinks about the grid -- in our
case "edges" actually have no meaning, except where we have defined
boundary conditions -- I guess it' s not that big a deal to create
them just for dumping in the output file, but I don't see the point,
either. And as a rule, i don't like redundant info in data files --
the edges themselves are redundant with the cells, unless the
application at hand is using them for something.
> For the face_x and face_y question, your reasoning makes sense that the
> values are not associated with the center of the face, but rather with the
> face, and that an application can calculate the centroid for display
> purposes from the face_nodes variable. However, at least as I understand it,
> the CF standard requires that variables that reference a location have a
> "coordinates" attribute that references the variables that contain the lat
> and lon location of the data.
right, but in this case there is no point location for the data -- I
guess I need to dig in a bit more to what CF does with cell data in
regular grids, but what I've seen assumes that the cells have an
simple relationship to surrounding points.
> In the examples given in the UGRID standard,
> the face located volume data had a coordinates attribute that references
> face_x and face_y
> Mesh2_volumes:coordinates = "Mesh2_face_x Mesh2_face_y" ;
> and nothing notes that as optional. So the UGRID standard seems unclear
> whether the coordinates attribute is optional for face or edge based
> variables, or what the coordinates attribute should reference if face_x and
> face_y are not defined, or if face_x and face_y are "optional required"
yup -- that's what this discussion is for -- to clarify the standard!
> For the boundary edges question, the location index set seems to only have
> the problem that it requires having a full edge_node_connectivity variable
> in order to be able to subset the relevant face edges, which is mostly a
> problem because of file size bloat.
and producing apps need to create the information, perhaps only for
> 1) Under the existing spec, the grid data can be stored in a separate netcdf
> file and merged with the data netcdf files via ncml.
> This means that the space lost to including the extra mesh information is
> not large (since the mesh information only needs to be stored once and then
> used with multiple data files).
True -- and the size of the extra data is probably pretty small
compared to the data attached to the mesh anyway.
> 2) The spec could be modified so that the edge_node_connectivity variable
> could be incomplete and only contain edges that were used by a variable.
> This has the disadvantage that the edge_node_connectivity variable could not
> be reliably used as a substitute for regenerating the edge_node_connectivity
yes -- is this a common need? to use the full edge-node-connectivity
when the original data set doesn't need it?
> 3) The concept of the grid boundary could be explicitly included in the
> UGRID standard (with an optional required attribute:
> "boundary_node_connectivity") and then variables could be defined with
> location = "boundary"
hmm -- actually, I like this one - boundaries are very important to
us, and often model output does not include them. Perhaps having them
an explicit part of the standard would encourage folks to include
them. I had been thinking that boundary info was just a special case
of info-on-the-edges, but maybe it should be explicit.
[note: in any case some standards for variable and attribute names for
boundary info would be great]
> but it would not handle cases where there is a small subset of edges that
> have variables defined on them, but those edges are not mesh boundaries
> (such as weirs and gates).
yeah, that's a problem -- we do need to cover those cases -- an edge
can be a "boundary condition" without being the actual boundary of the
mesh -- but maybe that's OK -- the boundary edges do not need to be
the outer boundary of the mesh.