UGRID-1.0

[Bert Jagers]

Dear all,

Different people have requested to switch to a more formal version management for the UGRID standard. To that end I would like to propose that we

• freeze the page as it has been for the past months,
• change the page from proposal into a formal definition of the UGRID convention, and
• label it as UGRID-1.0

To guide reading software, the page will recommend that the string "UGRID-1.0" will be added to the global Conventions attribute. Please let me know by March 1, 2013 if you have objections to this adjustment and version number.

This will allow us to start a new page to actively discuss extensions as have been raised a couple of times in this group without cluttering the main page.

Best regards,

Bert

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Christopher Barker]

On Tue, Feb 26, 2013 at 2:45 PM, Christopher Barker <pyth...@gmail.com> wrote:

> On Mon, Feb 25, 2013 at 11:30 PM, Bert Jagers <bert....@deltares.nl> wrote:
>
>> Different people have requested to switch to a more formal version
>> management for the UGRID standard. To that end I would like to propose that
>> we
>>
>> freeze the page as it has been for the past months,
>> change the page from proposal into a formal definition of the UGRID
>> convention, and
>> label it as UGRID-1.0
>>
>> To guide reading software, the page will recommend that the string
>> "UGRID-1.0" will be added to the global Conventions attribute. Please let me
>> know by March 1, 2013 if you have objections to this adjustment and version
>> number.
>

> This all sounds good, exept that It would be nice to resolve the
> issues that are alrady on teh table before declaring 1.0.
>
> Specifically:
>
> Do you need to define all the edges in a grid if you want to define
> data on only some of them? I think that edges in general are redundant
> with the face definitions themselves, and thus we should only need to
> define those that serve a purpose (boundary conditions and the like)
> on the other hand, we could rquire that if you define any edges, you
> need to define all ofthem, and refer to subsets with the location
> index set mechanism --not my first choice (see my previous notes),
> but we're going for consensus here.
>
> Also there is question of coordinate variables for data defined on
> faces -- the examples in the doc have coordinate variables for the
> face centroids, but values defined on the faces themselves are not
> strictly located at the centroid, or any other specific location
> within the face. I haven't had a chance to dig inot the DF docs to see
> how they handle values on cells in this regard. Anyone know?
>
> -Chris
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython



--
Christopher Barker, PhD

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

[Christopher Barker]

Folks,

A little mistaken off-list email, but bringing it back to the list...

On Wed, Feb 27, 2013 at 9:53 AM, Bert Jagers <bert....@deltares.nl> wrote:

> 1) edge_node_connectivity is indeed redundant in the context of
> face_node_connectivity, except for the fact that the edge_node_connectivity
> defines a numbering order for the edges.

yes -- that's why it might be required.

> I don't like a partial array for
> the edge_node_connectivity because that array would become unreliable and
> one might want to introduce multiple subsets of edges and then one would
> need multiple edge_node_connectivity tables.

I don't really see this point -- the creator of the file would create
the subset that was required to support all the edges they need -- why
would it be any more likely to be unreliable that a full set? And why
would multiple subsets be required?

> However, I agree that the index
> set isn't the nicest solution either; need to look a bit more at Charles'
> proposal of a boundary_node_connectivity.

> 2) I would say that the coordinates are optional for UGRID, but that they
> are currently required to be CF compliant or at least CF consistent.

hmm -- I've poked a bit more into cell structures in CF, cell_methods
seems to be close to what we want to do here. For instance, in some
finite volume models, the value on a cell is essentially the average
value over that cell.

http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-methods

part of the the example from there:

dimensions:
time = UNLIMITED; // (5 currently)
station = 10;
nv = 2;
variables:
float pressure(time,station);
pressure:long_name = "pressure";
pressure:units = "kPa";
pressure:cell_methods = "time: point";
double time(time);
time:long_name = "time";
time:units = "h since 1998-4-19 6:0:0";
time:bounds = "time_bnds";
double time_bnds(time,nv);
data:
time = 0., 12., 24., 36., 48.;
time_bnds = -12.,0., 0.,12., 12.,24., 24.,36., 36.,48.;

I _think_ this means that the cells are ranges in time. and pressure
on that cell is at one point in time. Frankly, this confuses me, as if
it's a point in time, whey is are there cells? But other options for
cell_methods are things like sum, mean, maximum, minimum, which make
sense to me. But in any case, note there is no "coordinates:"
attribute here. I think the reference to the cell (face in UGRID
lingo) is enough. We might want to specify the "cell_methods"
attribute, though -- maybe defining a few more if the existing ones
are sufficient.

[Christopher Barker]

Bert,

ONE more question:

Last Novemeber, Rich Signell pointed us to this doc:

http://www.met.rdg.ac.uk/~jonathan/CF_metadata/ugrid_gridspec.html

about unifying GridSpec and UGRID -- have you made those changes to
the UGRID doc? I recall a couple of us took a quick look and thought
it was reasonable.

I did just notice this in that doc:

"""
It is still unclear to me what the cell_methods entry should be for
data on meshes. CF now recommends cell_methods should be included for
all dimensions of the data. Are the existing methods in Appendix E
adequate to describe data on meshes? What should the default
interpretation be (if the recommendation to be explicit is not
followed)?
"""

So I think cell_methods should be addressed. The existing ones are
fine for our needs (specifically "mean", but maybe not for other
models.


-Chris

On Mon, Feb 25, 2013 at 11:30 PM, Bert Jagers <bert....@deltares.nl> wrote:

> --
> You received this message because you are subscribed to the Google Groups
> "UGRID Interoperability" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ugrid-interoperab...@googlegroups.com.
> To post to this group, send email to
> ugrid-inter...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/ugrid-interoperability?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.

[Bert Jagers]

Hi Chris,

>> I don't like a partial array for
>> the edge_node_connectivity because that array would become unreliable and
>> one might want to introduce multiple subsets of edges and then one would
>> need multiple edge_node_connectivity tables.
> I don't really see this point -- the creator of the file would create
> the subset that was required to support all the edges they need -- why
> would it be any more likely to be unreliable that a full set? And why
> would multiple subsets be required?

1) What I meant concerning "unreliability" was the following: If my
colleague, working in grid generation who is only interested in nodes
and edges and who doesn't bother about faces, or someone else who would
like to quickly draw a grid and hence prefers to draw edges rather than
empty faces (which draws most edges twice), opens a UGRID file and
observes that the edge_node_connectivity array is given. Can they use
the edge_node_connectivity array for their purpose, or not? How should
they tell? If we allow the edge_node_connectivity array to refer to only
a subset of the full set of edges, then a file reader needs to read the
faces, reconstruct the edges and then cross-check with the
edge_node_connectivity array to check whether all edges are there. The
only reason for reading the edge_node_connectivity array would be to
determine the order of the edges. From a readers perspective, it would
be useless for any other purpose. Of course, it could always happen that
an set of edge_node_connectivity array is incomplete even if we require
it to be complete -- however, that would be an error in the dataset,
rather than a common condition.

2) My second point concerning "multiple edge_node_connectivity" tables
was that if I want to store data on the edges, then I will need to store
the full edge_node_connectivity array. However, if I then also want to
indicate the boundary locations in a way that is compliant with your
tool then I need to also store another smaller edge_node_connectivity
array. You and I have to both support both methods (a) by means a small
edge_node_connectivity array (which consists of only or mostly boundary
edges), and (b) by means of the full array and an index set. Other
reasons for using smaller index sets could be identifying the locations
of hydraulic structures (weirs) along model boundaries or along general
edges depending on your model characteristics. Although I agree that the
reduced size edge_node_connectivity array seems to be attractive, I'm
not happy with giving it the same name and identification as a full
edge_node_connectivity array.

1) In the example above, time is a coordinate variable because its name
time equals the name time of its dimension (a convention inherited by CF
from the older COARDS conventions).
By using the same dimension time in the pressure variable, time is
automatically a coordinate of pressure and the coordinates attribute
isn't needed.
In an unstructured grid case where you have variables lat(nedges) and
lon(nedges), one needs the coordinates attribute because the variable
names lat and lon don't match their dimension nedges (these are not
referred to as coordinates but auxiliary coordinates).

2) You only copied part of the example, which adds to the confusion.
Indeed in the example above, the pressure is given for a couple of
points in time 0, 12, 24, 36, 48 hours after 1998/4/19 6am. There are
time ranges associated with these time points, but since pressure has
the cell_methods attribute defined as "time: point", the extent of the
time ranges is irrelevant. The other two quantities included in the CF
example, refer to cell_methods of "time: max" and "time: sum" which make
more sense in this context, namely the maximum value and the accumulated
value over the period given by the time_bnds array. For a triangular
mesh one could use this by defining water levels on faces/cells

dimensions:
cell = 2562 ; // number of grid cells
time = 12 ;
nv = 3 ; // number of cell vertices
variables:
float waterlevel(time,cell) ;
waterlevel:units = "m" ;
waterlevel:coordinates = "lon lat" ;
waterlevel:cell_methods = "area: mean" ;
float lon(cell) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:bounds="lon_vertices" ;
float lat(cell) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:bounds="lat_vertices" ;
float time(time) ;
time:long_name = "time" ;
time:units = "days since 1979-01-01 0:0:0" ;
float lon_vertices(cell,nv) ;
float lat_vertices(cell,nv) ;


This contains sufficient information to make 2D GIS plots of the spatial
distribution of the water level, however it doesn't include any
information on the connectivity of the triangles, and hence it has
limited use for modelling.It could be useful to somehow to indicate how
the value on a face, edge or node should be interpreted using something
like cell_methods. However, this is getting close to the CF standard,
and hence we need to discuss it with the CF community. Conceptually, one
might indeed want to say "face: mean", but there are some challenges to
do this properly for especially higher order finite element codes, and I
don't know the solution yet. There is a bit of a discussion on this
topic at
http://publicwiki.deltares.nl/display/NETCDF/Finite+Element+based+CF+proposal+for+Unstructured+Grid+data+model,
but it's far from complete.

[Bert Jagers]

Hi Chris,

1) Good point. I had replaced the use of standard_name by cf_role (which
was introduced for Discrete Geometry data sets before), but I had not
yet replaced the use of dimension by topology_dimension and the changes
to the mosaic attributes hadn't been applied either. I have now changed
the webpages based on his example. Please note that I would suggest to
keep the mosaics of unstructured grids outside the UGRID 1.0 standard
since I think that it's not mature enough yet. As far as I'm aware
nobody is using the mosaics yet. We will be using it soon, but one use
case doesn't prove that it's generic enough for a standard.

2) I have tried to stay a bit away from the cell_methods. For finite
volume codes, one could probably live with "face: mean" and "edge: mean"
quantities, and maybe some point quantities, but for finite element
codes the simple cell_method keywords don't suffice, whereas for finite
difference codes it's difficult to indicate what interpretation is valid
exactly. If one starts a discussion on cell_methods, I think one must
tackle the issue for a large number of the unstructured grid models
available today and many of those are finite element codes. In those
cases we need to more formally define the function space as illustrated
by the
http://publicwiki.deltares.nl/display/NETCDF/Finite+Element+based+CF+proposal+for+Unstructured+Grid+data+model
discussion page. That page reflects the discussion I had with David Ham
several years ago, but I'm lacking the time to really continue that
discussion in depth.

Best regards,

Bert
---------

[Bert Jagers]

Hi Chris,

I realize that my previous mail only said "no" without providing a
concrete alternative. So, let me try to come up with an alternative
building on Charles Seaton's suggestion on Feb 9 that ... 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". This would
indeed be a solution for keeping the requirement that the
edge_node_connectivity array should always be complete, while using the
same simple approach to define the boundaries. I like the concept of
adding an attribute to support this way of specifying boundary
locations, which is also often used in other file formats. However, I
wonder whether we should restrict it to boundaries only (see below).
Furthermore, a boundary_node_connectivity array only would label
boundary edges, but would still neither identify individual edges as
open or closed, nor would it include any grouping functionality to
identify edges that group together to form one boundary. In grid files
it's common to group boundaries by means of nodes or edges into
segments, for instance:

1 ! NOPE - TOTAL NUMBER OF OPEN BOUNDARY FORCING SEGMENTS
9 ! NETA - TOTAL NUMBER OF OPEN BOUNDARY FORCING NODES
9 ! NUMBER OF NODES ON OPEN BOUNDARY FORCING SEGMENT 1
7 ! BEGINNING NODE NUMBER ON OPEN BOUNDARY 1
14
21
28
35
42
49
56
63 ! ENDING NODE NUMBER ON OPEN BOUNDARY 1
1 ! NBOU - TOTAL NUMBER OF LAND BOUNDARY SEGMENTS
INCLUDING ISLAND SEGMENTS
21 ! NVEL - TOTAL NUMBER OF LAND BOUNDARY NODES
21 0 ! NUMBER OF NODES IN LAND BOUNDARY NO. 1 AND
BOUNDARY TYPE (MAINLAND)
63 ! BEGINNING NODE NUMBER OF LAND BOUNDARY NO. 1
62
61
60
59
58
57
50
43
36
29
22
15
8
1
2
3
4
5
6
7 ! END NODE NUMBER OF BOUNDARY 1

In this context we should maybe also consider the proposal by the German
Federal Waterways Engineering and Research Institute, BAW. They have
been looking for a way to identify transects (they refer to profiles)
and store point, edge and accumulated data (e.g. discharge) on such
aggregated elements. They propose to include prof_edge_connectivity and
prof_node_connectivity attributes, see:
http://www.baw.de/methoden/index.php5/NetCDF_Profile. I'm sure that
sooner or later other people will come up with other features besides
boundaries and profiles to be added to the topology. [note that for this
discussion they are linear features, but in a fully 3d model boundaries
and transects would be planes and they would be points in 1d models].
Therefore, I'm thinking whether it would make sense to introduce a more
neutral attribute "auxiliary_connectivity" which could refer to one or
more auxiliary connectivity arrays which could serve different purposes.
The exact purpose might be defined by a cf_role (or some other
attribute) on the connectivity variable. What do you think about this?

Best regards,

Bert
------

[Rich Signell]

UGRID folks,

I hope this discussion eventually gets resolved to the groups
satisfaction and included in a future version, but I don't think it
belongs in the current version, which should still be tagged with a
version number, because people are already using the existing UGRID
conventions to write software applications (the OPeNDAP.org UGRID
subset service, various workflows using NCTOOLBOX, etc).

In fact, folks were already using UGRID conventions back in January,
2011, and when changes were made, their software broke, emphasizing
the need for versioning. If we could go back and call that version
in January 2011 version 0.7 and the current version 0.9, I think that
might be appropriate, since we still anticipate future changes
(Jonathan's suggestions) that might break code, I gather.

I think we should wait for version 1.0 until we are somewhat confident
we can continue from that point with backwards compatibility (no more
breaking existing code).

But I think we should tag the current version with version 0.9.

What do others think?

Thanks,
Rich

> --
> You received this message because you are subscribed to the Google Groups
> "UGRID Interoperability" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ugrid-interoperab...@googlegroups.com.
> To post to this group, send email to
> ugrid-inter...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/ugrid-interoperability?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598

[Robert Oehmke]

Hi Rich,

I agree that we should start versioning as soon as possible. When we are describing what our code supports as far as mesh creation it would be clearer to have a fixed version to
point to. I don't have a strong opinion about what particular numbers to use, but I think that you make a good point about waiting for 1.0 until we are reasonably confident about backward compatibility.

- Bob

[Charles Seaton]

I also like this plan.

The only outstanding issue that seems to be a matter of clarification
rather than improvement is whether UGRID-0.9 requires that all data
points have 'coordinates' attributes even if they are on faces or edges,
or whether only the nodes require 'coordinates' and code should be able
to calculate nominal coordinates for faces and edges based on the node
coordinates for edge and face values that lack coordinates. I think the
documentation is ambiguous on this point, and it might be good to
explicitly answer this in version 0.9.

I think that version 0.9 should treat coordinates as required on all
data variables. While this is inconvenient from a data file generation
perspective, it requires no new specification of how to work with
cell_methods or other attribute information to determine how to
calculate coordinates for cells and sides, so it doesn't require adding
anything significant to the spec.

Charles

[Christopher Barker]

On Thu, Feb 28, 2013 at 1:45 PM, Bert Jagers <bert....@deltares.nl> wrote:
> Hi Chris,

> 1) What I meant concerning "unreliability" was the following: If my
> colleague, working in grid generation who is only interested in nodes and
> edges and who doesn't bother about faces, or someone else who would like to
> quickly draw a grid and hence prefers to draw edges rather than empty faces
> (which draws most edges twice), opens a UGRID file and observes that the
> edge_node_connectivity array is given. Can they use the
> edge_node_connectivity array for their purpose, or not?

OK -- I'm sold -- it should be either left our or complete...

Now on to how to handle things like boundary conditions:

> Although I agree that the reduced size
> edge_node_connectivity array seems to be attractive, I'm not happy with
> giving it the same name and identification as a full edge_node_connectivity
> array.

OK -- agreed here too.

> 2) You only copied part of the example, which adds to the confusion. Indeed
> in the example above, the pressure is given for a couple of points in time
> 0, 12, 24, 36, 48 hours after 1998/4/19 6am. There are time ranges
> associated with these time points, but since pressure has the cell_methods
> attribute defined as "time: point", the extent of the time ranges is
> irrelevant.

yeah -- not a great example in that case -- I found that frustrating too.

> For a triangular mesh one could use this by
> defining water levels on faces/cells
>
> dimensions:
> cell = 2562 ; // number of grid cells
> time = 12 ;
> nv = 3 ; // number of cell vertices
> variables:
> float waterlevel(time,cell) ;
> waterlevel:units = "m" ;
> waterlevel:coordinates = "lon lat" ;
> waterlevel:cell_methods = "area: mean" ;
> float lon(cell) ;
> lon:long_name = "longitude" ;
> lon:units = "degrees_east" ;
> lon:bounds="lon_vertices" ;
> float lat(cell) ;
> lat:long_name = "latitude" ;
> lat:units = "degrees_north" ;
> lat:bounds="lat_vertices" ;
> float time(time) ;
> time:long_name = "time" ;
> time:units = "days since 1979-01-01 0:0:0" ;
> float lon_vertices(cell,nv) ;
> float lat_vertices(cell,nv) ;

hmm -- interesting, I'm not entirely sure that using lat:bounds="lat
vertices" is appropriate -- it has a similar meaning the CF bounds,
but not exactly the same -- that may still be fine.

But i still don't like having cell (or face) data tied to a specific
lat-lon point. And cell data in DF does not have to be tied to a point
-- the points are the bounds of the cell, not the location of the data
-- why can't we do the same thing?

> This contains sufficient information to make 2D GIS plots of the spatial
> distribution of the water level, however it doesn't include any information
> on the connectivity of the triangles, and hence it has limited use for
> modelling.

Some GIS systems can use a a "TIN" -- would what I'm proposing map to that?

but in any case, yes, you can plot something by using the centroids of
the triangles on a mesh, but it isn't really the same as processing
the mesh properly -- I don't think we should encourage that! So I
still don't think we need the lat and lon variable in teh above case
-- all the information (and arguable more correct information) is in
the lat_vertices and lon_vertices variables.

> 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". This would indeed be a solution for keeping the requirement that the edge_node_connectivity
> array should always be complete, while using the same simple approach to define the boundaries.

sounds good.

> I like the concept of adding an attribute to support this way of specifying boundary locations, which is also
> often used in other file formats. However, I wonder whether we should restrict it to boundaries only (see
> below).

I agree -- we really want to support any data one might have on edges.

> Furthermore, a boundary_node_connectivity array only would label boundary edges, but would still neither
> identify individual edges as open or closed, nor would it include any grouping functionality to identify edges
> that group together to form one boundary.

right -- you'd need a variable associated with the
boundary_node_connectivity to specify the nature of a particular
boundary type.

> In grid files it's common to group boundaries by means of nodes or edges into segments, for instance:

indeed -- in our current file format, we specify the boundary by
specifying the first and last points along the boundary -- and the
points must be order in a particular direction around the boundary --
though I'd rather relax that requirement, and simply specify all the
segments.

> In this context we should maybe also consider the proposal by the German Federal Waterways Engineering
> and Research Institute, BAW. They have been looking for a way to identify transects (they refer to profiles)
> and store point, edge and accumulated data (e.g. discharge) on such aggregated elements. They propose
> to include prof_edge_connectivity and prof_node_connectivity attributes, see:
> http://www.baw.de/methoden/index.php5/NetCDF_Profile. I'm sure that sooner or later other people will
> come up with other features besides boundaries and profiles to be added to the topology. [note that for this
> discussion they are linear features, but in a fully 3d model boundaries and transects would be planes and
> they would be points in 1d models]. Therefore, I'm thinking whether it would make sense to introduce a
> more neutral attribute "auxiliary_connectivity" which could refer to one or more auxiliary connectivity arrays
> which could serve different purposes. The exact purpose might be defined by a cf_role (or some other
> attribute) on the connectivity variable. What do you think about this?

I like that -- flexible, but clear. We could use either a cf_role or a
standard_name to specify what it's used for.

I think we're converging on something here...

We'll try to put together a new example with our data that takes this
discussion into account.

[Christopher Barker]

Darn! accidentally only sent this to Rich....

---------- Forwarded message ----------
From: Christopher Barker <pyth...@gmail.com>
Date: Tue, Mar 5, 2013 at 5:11 PM
Subject: Re: UGRID-1.0
To: Rich Signell <rsig...@usgs.gov>


Hey Rich et al.

On Tue, Mar 5, 2013 at 4:06 AM, Rich Signell <rsig...@usgs.gov> wrote:
> I hope this discussion eventually gets resolved to the groups
> satisfaction and included in a future version, but I don't think it
> belongs in the current version, which should still be tagged with a
> version number, because people are already using the existing UGRID
> conventions to write software applications (the OPeNDAP.org UGRID
> subset service, various workflows using NCTOOLBOX, etc).

well, yes and no -- we're using it too, but I think the "standard" has
been clearly a draft, and changed, and I'm not sure that all the folks
using it are necessarily really conforming to the same thing.

For example:
- We're using , it, but with differences that we're trying to resolve
with this discussion
- We took a look at some of the results sets being used in the
modeling test bed project, and I think they are incomplete.
- The UGRID subsetting is project is definitely in flux.

And there is no tool that I know of to check if a given file conforms
to the standard (what would it take to do that? adapt the CF-checking
code?, or start something from scratch?)

All that being said, it's a fine idea that we give version numbers to
drafts that folks have referenced -- but hopefully we can be clear
that those are draft versions, and folks should try to update to 1.0
when it's declared and they are touching their code anyway.

> If we could go back and call that version
> in January 2011 version 0.7 and the current version 0.9, I think that
> might be appropriate, since we still anticipate future changes
> (Jonathan's suggestions) that might break code, I gather.

> I think we should wait for version 1.0 until we are somewhat confident
> we can continue from that point with backwards compatibility (no more
> breaking existing code).

yup -- but I don't know that we can ever have confidence in a standard
without people attempting ot use it to find the issues..I do wish we
had gotten more feed back on this list when people did start trying to
use it. Any of "this worked fine for me", "this didn't work", I don't
understand this", or "did i do this right" would be great.

In fact, it would be nice to have a repository of examples somewhere
to look at and see if we have exercised the standard.

> But I think we should tag the current version with version 0.9.

Seems reasonable -- I only hope that giving it a version number won't
discourage people from doing the work to move to 1.0 -- we really need
to get there.

-Chris


NOTE: more on Bert's suggestions soon, I hope....

[Bert Jagers]

Hi Charles,

If one would start with a UGRID standard from scratch I would strongly
promote to require only the nodal coordinates. The other coordinates are
not adding anything new unless you're using a finite difference code and
the points representing the edges and faces are not in their centroids.
However, we didn't start from scratch: we initially set out to get the
UGRID conventions adopted by the CF group. Now, using the CF conventions
already include options using coordinates and bounds to geometrically
non-rectangular grid cells (see
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-boundaries
subsections "Bounds for 2-D coordinate variables with 4-sided cells" and
"Bounds for multi-dimensional coordinate variables with p-sided cells"
and example "Example 7.2. Cells in a non-rectangular grid". Following
these conventions, one would define the location of a quantity using one
lat,lon pair and associated bounds. Hence to be compliant with CF, the
current text mixes both approaches.

Now for the time being UGRID does not become an integral part of the CF
conventions. This makes it sometimes more difficult, but also offers a
bit of extra freedom, and I would propose to use it to state the following:

* The UGRID-0.9 conventions require the use of node_coordinates;
combined with the topological connectivity is defines the basic
framework of the grid.
* Although UGRID conventions are not yet a part of the CF conventions,
we highly recommend files also to be CF compliant. This can be indicated
by specifying a global Conventions = "UGRID-0.9 CF-1.6" attribute (or
similar depending on the exact CF and UGRID version one claims to comply
to. Following the CF conventions, it is recommended to store as well
lat,lon coordinates and bounds for data at edges and faces as shown in
the examples. If you specify representative coordinates for edges and
faces then you should also refer to those coordinates using the
otherwise optional edge_coordinates and face_coordinates attributes of
the mesh_topology variable.

I believe these statements are consistent with the existing UGRID text
and tables. And more importantly, in this way we clearly separate CF
requirements from the UGRID requirements. Both UGRID and CF by
themselves are internally consistent and don't require redundant data.
However, their combination may cause redundant coordinate specification
requirements and resulting consistency issues. If we require all
coordinates to be specified then we should also come up with a way to
verify consistency.

Follow-up action:
* Get proposed bounds conventions for 1D networks and 2D flexible/mixed
meshes adopted within CF. The example of bounds for 2D triangular meshes
is already consistent with the CF formulation for bounds.

Best regards,

Bert
-----

[Bert Jagers]

On 06/03/2013 07:37, Christopher Barker wrote:

> On Thu, Feb 28, 2013 at 2:48 PM, Bert Jagers <bert....@deltares.nl> wrote:
>
>> Please note that I would suggest to keep the
>> mosaics of unstructured grids outside the UGRID 1.0 standard since I think
>> that it's not mature enough yet. As far as I'm aware nobody is using the
>> mosaics yet.

> I agree.

>
>> 2) I have tried to stay a bit away from the cell_methods. For finite volume
>> codes, one could probably live with "face: mean" and "edge: mean"
>> quantities, and maybe some point quantities, but for finite element codes
>> the simple cell_method keywords don't suffice, whereas for finite difference
>> codes it's difficult to indicate what interpretation is valid exactly.

> However, we need something -- data on cells is data on cells, and it
> would be nice to describe what it is. For our FE code, "face: mean"is
> a reasonable fit. If there are other codes for which none of the
> existing cell methods fit, it seems reasonable to crete some more.
>
> A thought there -- particular models will have used various schemes to
> arrive at values, which may or may not map neatly to "mean" or
> "point", so it would be nice to provide a hint to users as to an
> appropriate interpolation method. On the other hand, every model I've
> seen either puts values on cells or or points -- and maybe that's all
> consuming software NEEDS to know.

I agree that there is a whole range of gray shades between properly
specified and sufficient for most users. I think that most consuming
software will stop reading by the time it has figured out whether a
quantity is defined at nodes, edges or faces. However, when you want to
do things like mass balance calculations and conserving interpolations,
then it one needs to know more details, and a reasonable fit for one
purpose is not good enough for another.

Triggered by Charles' mail I realize that we have a difficult issue
here. Since UGRID is currently a separate entity from CF, a file that
would use cell_methods = "face: mean" cannot be CF compliant unless the
CF conventions also accept this formulation. However, UGRID not being
part of CF, the CF Conventions don't have a formal definition of
concepts like "face" and "edge". I will try to contact Jonathan Gregory
on this ...

>> If
>> one starts a discussion on cell_methods, I think one must tackle the issue
>> for a large number of the unstructured grid models available today and many
>> of those are finite element codes. In those cases we need to more formally
>> define the function space as illustrated by the
>> http://publicwiki.deltares.nl/display/NETCDF/Finite+Element+based+CF+proposal+for+Unstructured+Grid+data+model
>> discussion page. That page reflects the discussion I had with David Ham
>> several years ago, but I'm lacking the time to really continue that
>> discussion in depth.

> I wonder if this need to be part of the standard, or can be auxiliary
> information that is optional for a specific application. I guess i'm
> skeptical that anyone id going to write generic code to deal with
> arbitrary function spaces anyway. If anyone writes code that does the
> right thing with a specific function space, all it needs to know is
> that this is a compliant file, but this isn't a generic process.

True. That is one of the gray shades: knowing it's the right file can be
implemented as an assumption (end-user's judgement), a simple check on a
keyword in source or similar global attribute, or a formal check on the
metadata of all the variables. Some FE users believe in mathematical
purity and hence strict formal definition of the function space is the
only way forward: making assumptions on the consuming side is considered
a sin. On the other hand, there is a huge community that would like to
see basic interoperability first, and then grow from there as needed. My
personal opinion is that the current proposal satisfies most needs of
the main community without blocking a way forward for a more formal
function space extension to the standard.

> -Chris

[Bert Jagers]

[I removed most of items we agree on]

I'm convinced that this is consistent with the CF conventions. Read

http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-boundaries
subsections "Bounds for 2-D coordinate variables with 4-sided cells" and
"Bounds for multi-dimensional coordinate variables with p-sided cells"

and example "Example 7.2. Cells in a non-rectangular grid" that I also
mentioned in the reply to Charles. In addition to that I should refer to
example "Example 7.3. Cell areas for a spherical geodesic grid" in the
cell measures section (
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-measures
). This is almost the same as my example above except that it refers to
6-sides cells rather than triangles.

> But i still don't like having cell (or face) data tied to a specific
> lat-lon point. And cell data in DF does not have to be tied to a point
> -- the points are the bounds of the cell, not the location of the data
> -- why can't we do the same thing?

You wrote DF, but I assume you meant CF. If so, then I don't agree.
Consistent with the COARDS conventions, CF requires you (at least as
first step) to specify a single lat,lon pair for each data value. Only
from there you can continue to specify bounds and indicate that the
values shouldn't be literally interpreted as being defined at such
points. So, the use of coordinates and bounds on the UGRID page is
consistent with CF. I would prefer if CF could relax that requirement in
the future to also allow variables to be defined on a(n unstructured)
grid topology.

>> This contains sufficient information to make 2D GIS plots of the spatial
>> distribution of the water level, however it doesn't include any information
>> on the connectivity of the triangles, and hence it has limited use for
>> modelling.
> Some GIS systems can use a a "TIN" -- would what I'm proposing map to that?

The generic concept of CF bounds maps to general polygon datasets in GIS
(with the exception that all polygons need to have the same number of
vertices).
Besides point, line, polygon feature classes GIS systems also define
GRID/Raster and TIN concepts.
A GRID/Raster in GIS is always assumed to be a rectangular grid, being
consistent with the classical COARDS conventions using 1-dimensional
coordinate variables.
A TIN is a Triangulated Irregular Network with elevation data at its
nodes; the elevation at points in between the nodes is constructed using
linear interpolation on the data of the three nodes of the enclosing
triangle.
Hence a TIN is also much more restricted in scope than the UGRID
supported grids and data sets.

> but in any case, yes, you can plot something by using the centroids of
> the triangles on a mesh, but it isn't really the same as processing
> the mesh properly -- I don't think we should encourage that! So I
> still don't think we need the lat and lon variable in teh above case
> -- all the information (and arguable more correct information) is in
> the lat_vertices and lon_vertices variables.

Completely, agree. I wouldn't encourage it either, but it's a
consequence of being compatible with CF and one may prefer to include
this redundant data (for the time being) because of compatibility with
existing tools (e.g. GIS tools may then at least be able to show the
value, and if they support the bounds attribute they may also show face
data as patches).

>> In this context we should maybe also consider the proposal by the German Federal Waterways Engineering
>> and Research Institute, BAW. They have been looking for a way to identify transects (they refer to profiles)
>> and store point, edge and accumulated data (e.g. discharge) on such aggregated elements. They propose
>> to include prof_edge_connectivity and prof_node_connectivity attributes, see:
>> http://www.baw.de/methoden/index.php5/NetCDF_Profile. I'm sure that sooner or later other people will
>> come up with other features besides boundaries and profiles to be added to the topology. [note that for this
>> discussion they are linear features, but in a fully 3d model boundaries and transects would be planes and
>> they would be points in 1d models]. Therefore, I'm thinking whether it would make sense to introduce a
>> more neutral attribute "auxiliary_connectivity" which could refer to one or more auxiliary connectivity arrays
>> which could serve different purposes. The exact purpose might be defined by a cf_role (or some other
>> attribute) on the connectivity variable. What do you think about this?
> I like that -- flexible, but clear. We could use either a cf_role or a
> standard_name to specify what it's used for.
>
> I think we're converging on something here...
>
> We'll try to put together a new example with our data that takes this
> discussion into account.

Thanks! That would be great.

[Bert Jagers]

Hi Chris,

> And there is no tool that I know of to check if a given file conforms
> to the standard (what would it take to do that? adapt the CF-checking
> code?, or start something from scratch?)

Indeed I got a similar question last week from Eric Hutton from the CSDMS group (https://csdms.colorado.edu/). They are also starting to use the UGRID convention and were looking for a checker.
If UGRID had become an integral part of CF, incorporation in the CF-checker would be most logical. Now, I'm not sure, but support the idea of having an automated checker.
I only know that I'm not going to write it myself ;-).

Cheers,

Bert
--------

[Rich Signell]

Bert,
Just want to make sure I've got this straight:

For CF 1.6 compliance, folks need to specify the *face coordinates*
(e.g. element centers) and cell bounds. This supports plotting data
as filled polygons, but not much else -- wouldn't support
interpolation without regridding, for example.

For UGRID, folks need to supply the *node* coordinates, the
connectivity array and the location of the data on the mesh. This
supports shaded contour plotting, basic interpolation and the like (as
well as much more).

-Rich

[Bert Jagers]

Rich,

Indeed, for CF you have different coordinate specification requirements
than for UGRID.
CF requires coordinates and bounds for the location at which you define
you variable.
UGRID would only require the nodes coordinates.

Bert
------

[Christopher Barker]

On Tue, Mar 5, 2013 at 11:54 PM, Bert Jagers <bert....@deltares.nl> wrote:

> If one would start with a UGRID standard from scratch I would strongly
> promote to require only the nodal coordinates.

...

> Now, using the CF conventions already
> include options using coordinates and bounds to geometrically
> non-rectangular grid cells (see
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#cell-boundaries
> subsections "Bounds for 2-D coordinate variables with 4-sided cells" and
> "Bounds for multi-dimensional coordinate variables with p-sided cells" and
> example "Example 7.2. Cells in a non-rectangular grid". Following these
> conventions, one would define the location of a quantity using one lat,lon
> pair and associated bounds. Hence to be compliant with CF, the current text
> mixes both approaches.

Bert, thanks for clarifying the motivation here -- that really helps.
I had missed the DF required both the bounds of the cells AND a
lat-lon point -- frankly I think that's very odd. Also there examples
defined the grid, and cells, but didn't have a data variable on them,
so it wasn't clear to me how it would be used.

> Now for the time being UGRID does not become an integral part of the CF
> conventions. This makes it sometimes more difficult, but also offers a bit
> of extra freedom, and I would propose to use it to state the following:
>
> * The UGRID-0.9 conventions require the use of node_coordinates; combined
> with the topological connectivity is defines the basic framework of the
> grid.

> * Although UGRID conventions are not yet a part of the CF conventions, we
> highly recommend files also to be CF compliant. This can be indicated by
> specifying a global Conventions = "UGRID-0.9 CF-1.6" attribute (or similar
> depending on the exact CF and UGRID version one claims to comply to.
> Following the CF conventions, it is recommended to store as well lat,lon
> coordinates and bounds for data at edges and faces as shown in the examples.

Sounds good.

However, we'd have to see what the CF people think, but it seems to me
that if we add UGRID to CF, we are by definition changing CF, and in
that case, we could define that it's perfectly compliant not to have
point locations for cell variables -- i.e. if the cells are defined
properly, either via UGRID or the existing cell definitions, then the
point location is optional.

Maybe not one would go for that, but it seems to be the CF is
currently requiring unnecessary and, in fact, misleading information.

> However, their
> combination may cause redundant coordinate specification requirements and
> resulting consistency issues. If we require all coordinates to be specified
> then we should also come up with a way to verify consistency.

Does the CF checker do that? i.e. check if the stated requirement:

"""
The boundary variables lat_bnds and lon_bnds associate a gridpoint
(j,i) with the cell determined by the vertices
(lat_bnds(j,i,n),lon_bnds(j,i,n)), n=0,..,3. The gridpoint location,
(lat(j,i),lon(j,i)), should be contained within this region.
"""

Anyway, I'm less concerned about potential inconstancy/error in files
than I I am about mis-interpetetion. WE talked a bit about plotting
results in a GIS, for instance. In the quad-cell example in the CF
doc, the cell data should be interpreted as associated with a set of
polygons in the GIS data model. However, there are point coordinates,
associated with the data, so a not-very-smart reader cold well
interpret the data as point data, which would be wrong.

A reader that dealt properly with such a file would need to understand
the cell definitions (or face in the case of UGRID) and thus shouldn't
use, and wouldn't need, the point coordinates.

> * Get proposed bounds conventions for 1D networks and 2D flexible/mixed
> meshes adopted within CF.

Is the 1-D network spec different than 1-D cells in CF? Does it need to be?

> The example of bounds for 2D triangular meshes is
> already consistent with the CF formulation for bounds.

Similar, though I think different -- in UGRID, we define the node
locations, then define the faces in terms of the nodes -- in CF the
cell boundaries are defined directly in lat-lon space (such that
shared node coordinates are repeated).

As it happens, I like this difference, I think it gives us more
freedom to do things a new way (i.e not have phantom coordinates
points just to satisfy CF)

> Triggered by Charles' mail I realize that we have a difficult issue here. Since UGRID is currently a separate
> entity from CF, a file that would use cell_methods = "face: mean" cannot be CF compliant unless the CF
> conventions also accept this formulation.

True, but I'm realizing that our faces are different than CF cells
anyway -- so maybe we should define:

face_methods = face:mean

Instead, rather than try to re-use the existing cell_methods

then we can add whatever face_methods people need, similarly to adding
standard names...

(by the way, I'd love to have standard names for boundary conditions
at some point...if that's at all possible)

> However, UGRID not being part of CF, the CF Conventions don't
> have a formal definition of concepts like "face" and "edge". I will try to contact Jonathan Gregory on this ...

Good idea, thanks.

> That is one of the gray shades: knowing it's the right file can be implemented as an assumption (end-user's > judgement), a simple check on a keyword in source or similar global attribute, or a formal check on the
> metadata of all the variables. Some FE users believe in mathematical purity and hence strict formal
> definition of the function space is the only way forward: making assumptions on the consuming side is
> considered a sin. On the other hand, there is a huge community that would like to see basic interoperability
> first, and then grow from there as needed. My personal opinion is that the current proposal satisfies most
> needs of the main community without blocking a way forward for a more formal function space extension to > the standard.

Absolutely!

> A TIN is a Triangulated Irregular Network with elevation data at its nodes

Ah thanks -- I hadn't realized that a TIN was specifically used for
elevation -- you could presumably use it for any conceptual "surface",
but they don't seem to use them to store values on the faces, only the
nodes, in any case.

> I wouldn't encourage it either, but it's a consequence of being compatible with CF and one may prefer to
> include this redundant data (for the time being) because of compatibility with existing tools (e.g. GIS tools
> may then at least be able to show the value, and if they support the bounds attribute they may also show
> face data as patches).

Here's where I'm not sure we agree -- if a given tool understands the
bounds then they can do the right thing -- if it doesn't it may
display values on the coordinate points, but I'm not sure I'd want
that.

And no existing tools (i think!) are going to understand the mesh
definition we are proposing anyway.

Updated examples forthcoming....

[Stefan Vater]

Dear Bert,

I was wondering if global (NetCDF) attributes should be specified in the
standard. At least, something like

Conventions = "UGRID-0.x"

would be good to state some kind of compliance with the proposed standard.
What about thngs like "Author", "Title", "Institution", " References"... ?

I am not sure about what the CF convention says about that.

Best,
Stefan

Am Dienstag, 26. Februar 2013, 08:30:25 schrieb Bert Jagers:
> Dear all,
>
> Different people have requested to switch to a more formal version
> management for the UGRID standard. To that end I would like to propose
> that we
>

> * freeze the page as it has been for the past months,
> * change the page from proposal into a formal definition of the UGRID
> convention, and
> * label it as UGRID-1.0

[Rich Signell]

Bert,
Are we still stuck on this one outstanding issue that is preventing us
slapping a version on UGRID?

If so, maybe we should have a vote?

I vote for requiring face_coordinates if there are face variables and
edge_coordinates if there are edge variables.

In FVCOM, the velocities are specified at the faces. If someone wants
to just subset some velocity data and plot some arrows, all they have
to do is download the lon,lat face_coordinate variables, along with
the data. But without the face_coordinates, they would need to
download the entire connectivity array as well, then compute the cell
centers from the node_coordinates.

Here's an example of the FVCOM data in UGRID 0.9 (we hope) format:
http://www.smast.umassd.edu:8080/thredds/dodsC/fvcom/hindcasts/30yr_gom3/mean.html

-Rich

[Brian Zelenke]

In regards to the "forthcoming example" per Chris' March 6, 2013 post, attached is a NetCDF file (ElevenPoints_UGRIDv0.9.nc) for evaluation/comment by this group.  The (highly simplified) grid used in this example represents an imaginary bay as shown in the attached figure (ElevenPoints_UGRIDv0.9.png)  -- surrounded by land on all sides, save for the open ocean to the west, and with an island inset.

Intentionally omitted is an edge_node_connectivity variable; instead open (viz. water) and closed (viz. land) boundary information is specified via the boundary_node_connectivity and boundary_type variables.  Also, the face_face_connectivity variable now includes a complete Nx3 specification of all faces which neighbor each (triangular) face; as well as a flag to note if the region "out of mesh" abuts a given face.  Would you all please "proofread" this file and provide your feedback as to opportunities for improvement?

For your convenience, the following is an "ncdump" of this NetCDF file's header information:

Source:

           ElevenPoints_UGRIDv0.9.nc

Format:

           netcdf4

Global Attributes:

           Conventions = 'UGRID-0.9'

           Title       = 'UGRID for GNOME'

           Institution = 'USA/DOC/NOAA/NOS/ERD/TSSB'

           References  = 'brian....@noaa.gov'

Dimensions:

           nMesh2_face     = 13

           Three           = 3

           nMesh2_node     = 11

           nMesh2_boundary = 9

           Two             = 2

Variables:

    Mesh2               

           Size:       1x1

           Dimensions: 

           Datatype:   int32

           Attributes:

                       cf_role                    = 'mesh_topology'

                       long_name                  = 'Topology data of 2D unstructured mesh'

                       dimension                  = 2

                       node_coordinates           = 'Mesh2_node_x Mesh2_node_y'

                       face_node_connectivity     = 'Mesh2_face_nodes'

                       edge_node_connectivity     = 'Mesh2_edge_nodes'

                       face_face_connectivity     = 'Mesh2_face_links'

                       face_coordinates           = 'Mesh2_face_x Mesh2_face_y'

                       boundary_node_connectivity = 'Mesh2_boundary_nodes'

    Mesh2_face_nodes    

           Size:       13x3

           Dimensions: nMesh2_face,Three

           Datatype:   int32

           Attributes:

                       cf_role     = 'face_node_connectivity'

                       long_name   = 'Maps every triangular face to its three corner nodes.'

                       start_index = 1

    Mesh2_face_links    

           Size:       13x3

           Dimensions: nMesh2_face,Three

           Datatype:   int32

           Attributes:

                       cf_role       = 'face_face_connectivity'

                       long_name     = 'Indicates which other faces neighbor each face.'

                       start_index   = 1

                       flag_values   = -1

                       flag_meanings = 'out_of_mesh'

    Mesh2_node_x        

           Size:       11x1

           Dimensions: nMesh2_node

           Datatype:   double

           Attributes:

                       standard_name = 'longitude'

                       long_name     = 'Longitude of 2D mesh nodes.'

                       units         = 'degrees_east'

    Mesh2_node_y        

           Size:       11x1

           Dimensions: nMesh2_node

           Datatype:   double

           Attributes:

                       standard_name = 'latitude'

                       long_name     = 'Latitude of 2D mesh nodes.'

                       units         = 'degrees_north'

    Mesh2_face_x        

           Size:       13x1

           Dimensions: nMesh2_face

           Datatype:   double

           Attributes:

                       standard_name = 'longitude'

                       long_name     = 'Characteristic longitude of 2D mesh triangle (i.e. centroid coordinate).'

                       units         = 'degrees_east'

    Mesh2_face_y        

           Size:       13x1

           Dimensions: nMesh2_face

           Datatype:   double

           Attributes:

                       standard_name = 'latitude'

                       long_name     = 'Characteristic latitude of 2D mesh triangle (i.e. centroid coordinate).'

                       units         = 'degrees_north'

    Mesh2_face_u        

           Size:       13x1

           Dimensions: nMesh2_face

           Datatype:   double

           Attributes:

                       standard_name = 'eastward_sea_water_velocity'

                       units         = 'm/s'

                       coordinates   = 'Mesh2_face_x Mesh2_face_y'

                       face_methods  = 'area: mean'

    Mesh2_face_v        

           Size:       13x1

           Dimensions: nMesh2_face

           Datatype:   double

           Attributes:

                       standard_name = 'northward_sea_water_velocity'

                       units         = 'm/s'

                       coordinates   = 'Mesh2_face_x Mesh2_face_y'

                       face_methods  = 'area: mean'

    Mesh2_depth         

           Size:       11x1

           Dimensions: nMesh2_node

           Datatype:   double

           Attributes:

                       standard_name = 'sea_floor_depth_below_geoid'

                       units         = 'm'

                       positive      = 'down'

                       mesh          = 'Mesh2'

                       location      = 'node'

                       coordinates   = 'Mesh2_node_x Mesh2_node_y'

    Mesh2_boundary_nodes

           Size:       9x2

           Dimensions: nMesh2_boundary,Two

           Datatype:   int32

           Attributes:

                       cf_role     = 'boundary_node_connectivity'

                       long_name   = 'Maps every edge of each boundary to the two nodes that it connects.'

                       start_index = 1

    Mesh2_boundary_count

           Size:       9x1

           Dimensions: nMesh2_boundary

           Datatype:   int32

           Attributes:

                       cf_role     = 'boundary_type'

                       long_name   = 'Defines the group to which every edge of each boundary belongs.'

                       location    = 'boundary'

                       start_index = 1

    Mesh2_boundary_types

           Size:       9x1

           Dimensions: nMesh2_boundary

           Datatype:   int32

           Attributes:

                       cf_role       = 'boundary_type'

                       long_name     = 'Classification flag for every edge of each boundary.'

                       location      = 'boundary'

                       flag_range    = [0.00e+00 1.00e+00]

                       flag_values   = [0.00e+00 1.00e+00]

                       flag_meanings = 'closed_boundary open_boundary'

Best regards,

Brian

----------------------

Brian Zelenke

Oceanographer

National Oceanic & Atmospheric Administration (NOAA)

National Ocean Service | Office of Response & Restoration | Emergency Response Division

7600 Sand Point Way NE, Bldg. 3

Seattle, WA 98115-6349

United States of America

Phone:  (206)-526-6353

Fax:  (206)-526-6329

E-mail:  brian....@noaa.gov

Web:  http://response.restoration.noaa.gov/

[rsignell]

Bert, Chris, Brian & Co,

There doesn't seem to be much progress or resolution on this boundary issue.  Can we leave this out for now, and simply give a version number to the existing UGRID spec?  

Is anyone opposed to giving the current version a version number of 0.9?

Thanks,
Rich

[Alexander Crosby]

Ooops, sorry Rich, meant to reply to the whole group.

I agree with Rich in specifying a version number as soon as possible. It is getting hard  for us at ASA to remember what software is targeting what UGRID proposal specification.

Alex Crosby

--
You received this message because you are subscribed to the Google Groups "UGRID Interoperability" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ugrid-interoperab...@googlegroups.com.
To post to this group, send email to ugrid-inter...@googlegroups.com.

Visit this group at http://groups.google.com/group/ugrid-interoperability?hl=en-US.

[Brian Zelenke]

Hello Rich et al.,

I'm in favor; adopting a version number (viz. 0.9) for the present UGRID specification would aid NOAA ERD's efforts to develop compatible software.

Regards,

Brian

----------------------------------------------------------------------------------------

   Brian Zelenke
   Oceanographer

   National Oceanic & Atmospheric Administration (NOAA)

   National Ocean Service | Office of Response & Restoration

   7600 Sand Point Way NE
   Seattle, WA 98115-6349

   Phone:  (206)-526-6353
   Fax:  (206)-526-6329
   E-mail:  brian....@noaa.gov
   Web:  http://response.restoration.noaa.gov/

[Robert Oehmke]

Nope, 0.9 is fine with me. It would be useful for us at ESMF to have a version # to point to whatever the actual value. 

Thanks,

- Bob 

[Christopher Barker]

Opps,

Sent just to Rich by mistake...

-Chris

---------- Forwarded message ----------
From: Christopher Barker <pyth...@gmail.com>

Date: Tue, May 7, 2013 at 11:32 AM
Subject: Re: UGRID-1.0
To: rsignell <rsig...@gmail.com>

On Tue, May 7, 2013 at 6:58 AM, rsignell <rsig...@gmail.com> wrote:

 

There doesn't seem to be much progress or resolution on this boundary issue.  Can we leave this out for now, and simply give a version number to the existing UGRID spec?  

Is anyone opposed to giving the current version a version number of 0.9?

I'd rather not -- we've made some suggestions, and if we can agree on a version number, we should be able to agree or not with the suggestions -- or at least comment on them. Maybe no one objects to the changes? If there are real objections, then maybe we'll need to lock in a version number now, but I'd much rather give a version number to a more mature, ready to use, spec.

My concerns are:

1) I don't think it's all that clear what the "current" spec is, or if anyone has files in the wild that conform to anything in particular (note: I took a look a number of the early ugrid files in the modeling test bed project, and there were some issues with them, for instance. A specific example is the face_face_connectivity array -- it was defined in terms of pairs of faces, but that may have been a mistake, so there is now a note in there " TODO: CHECK DEFINITION" that has been there since last November I think. I'm pretty sure Bert and i think face_face_connectivity should be an Nx3 array (for a triangular mesh). I don't think anyone else has commented since last November.

(side note: in the examples, there is a lot of the use of "Three" for a triangular mesh - maybe there should be a defined variable, something like "num_cell_vertexes" or something. Not a big deal, and know there may be meshes with multiple cell types)

2) As soon as we assign a version number, people will be more likely to say: "I conform to UGRID 0.9 -- I'm done". Since we know already that there are issues that will require changes in the next version, we're kind of committing ourselves to version heck. Our goal should be to be able to write as little special case, version specific client code as we can. At least if folks have support the known-to-be-unfinshed standard, they are presumable expecting to have to tweak stuff in the future.

If everyone else want to set a version number fine -- but let's make it very clear that it's a verion number for an evolving spec.

-Chris

-- 

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython

[Christopher Barker]

Sorry about the typos, too.

Darn iPhone....

-Chris

[Rich Signell]

Chris & Co,

I'm still not convinced we need to get more issues resolved before we
just give the existing version a version number. I know there are
many of us who have been productively using the existing spec, and it
would be very useful to simply have a version number. I don't think
people will say they are 0.9 compliant and call it good. All folks I
know generating this type of unstructured grid products would be
willing to update as additional features like boundaries are
addressed.

If you still feel strongly that certain features need extra work
before we assign a version, I think we can get them resolved quickly
via e-mail if you are willing to ride herd.

-Rich

-Rich

The face_face_connectivity is listed as "optional" anyway.

Is there anything *required* that is not resolved?

-Rich

> --
> You received this message because you are subscribed to the Google Groups
> "UGRID Interoperability" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ugrid-interoperab...@googlegroups.com.
> To post to this group, send email to
> ugrid-inter...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/ugrid-interoperability?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Christopher Barker]

On Tue, May 7, 2013 at 12:22 PM, Rich Signell <rsig...@usgs.gov> wrote:

 I don't think
people will say they are 0.9 compliant and call it good.   All folks I
know generating this type of unstructured grid products would be
willing to update as additional features like boundaries are
addressed.

Let's hope so -- you know the community better than I do.

If you still feel strongly that certain features need extra work
before we assign a version, I think we can get them resolved quickly
via e-mail if you are willing to ride herd.

I've tried, but I guess simply posting to the list isn't "riding herd" !

The  face_face_connectivity is listed as "optional" anyway.

Is there anything *required* that is not resolved?

Good point! some of those are critical for us, but you're right, it may all be optional -- i haven't looked to see what people havebeen using.

I'm on travel, but: Brian, could you take a look and see if any ofthe tuff we're concerned about is not optional?

If it's all optional, then less of an issue.

-Chris

[Brian Zelenke]

Hello Chris,

Looking at the "2D triangular mesh topology" section of http://bit.ly/ugrid_cf (i.e., the section which most directly relates to the topology type currently employed by GNOME), it doesn't appear to me that any of the issues stymieing use of the present UGRID specification by GNOME relate to the "Required topology attributes" given in that section's table.  As I understand it, the blockers for GNOME are:

1. as mentioned in earlier posts (and as recognized by the "TODO" note at http://bit.ly/ugrid_cf), face_face_connectivity would need to be a complete Nx3 specification of all faces which neighbor each (triangular) face
1. face_face_connectivity would also need to include a flag to note if the region "out of mesh" abuts a given face
2. we'd like to be able to omit the edge_node_connectivity variable and instead specify open (viz. water) and closed (viz. land) boundary information via the proposed boundary_node_connectivity and boundary_type variables

Of these, I only see the issue with edge_node_connectivity being "Optionally required" as making life difficult -- if it were agreed that specifying optional "boundary information" attributes didn't constitute "[storing] data on the edges" than our concerns with the present implementation of UGRID would fall squarely within the realm of optional attributes.

Regards,

Brian

----------------------

Brian Zelenke

Oceanographer

National Oceanic & Atmospheric Administration (NOAA)

National Ocean Service | Office of Response & Restoration | Emergency Response Division

7600 Sand Point Way NE, Bldg. 3

Seattle, WA 98115-6349

United States of America

Phone:  (206)-526-6353

Fax:  (206)-526-6329

E-mail:  brian....@noaa.gov

Web:  http://response.restoration.noaa.gov/

[Rich Signell]

Brian (& Chris)
Excellent. Then are you guys okay with us versioning the existing doc with 0.9?

Thanks,
Rich

[Brian Zelenke]

Hello Rich,

I'll leave that determination to Chris (I understand he has looked at the UGRID specification separately, and may appreciate an issue that I've overlooked).

Cheers,

Brian

----------------------

Brian Zelenke

Oceanographer

National Oceanic & Atmospheric Administration (NOAA)

National Ocean Service | Office of Response & Restoration | Emergency Response Division

7600 Sand Point Way NE, Bldg. 3

Seattle, WA 98115-6349

United States of America

Phone:  (206)-526-6353

Fax:  (206)-526-6329

E-mail:  brian.zelenke@noaa.gov

Web:  http://response.restoration.noaa.gov/