Questions about UGRID standard

[Christopher Barker]

Hi Folks,

We are (finally!) getting around to moving some of our stuff to the
new ugrid standard, and we've come up with some questions.

At this point, we are only interested in triangular mesh grids, and
while I like that the standard is very flexible, it's also nice that
the simple stuff is simple, for the most part.

working from:

http://bit.ly/ugrid_cf (thanks Bert for making that available again...)

On to the questions:

1) Where are we at with the clockwise / counterclockwise issue? I
personally prefer counter-clockwise always, but if others want it to
be a specify-able attribute, that's OK too. But I'd like to nail that
down so we know what to put in our client software.

2) I see that "edge_node_connectivity" is listed as a "Optionally
required attribute" -- I"m not sure what the difference is from an
"Optional attribute", but anyway -- we often need to specify data on
some edges, but not all -- can we put only those edges that we care
about in the edge_node_connectivity array? Or do we need to put them
all in, then use a Location index set to specify which ones we have
data on -- it seems somewhat redundant to do so.

If we can specify only those edges that we care about, there should be
a standard way to specify whether the edge_node_connectivity is a
complete set or not. Maybe a different name?

3) I see" face_face_connectivity" as an optional variable. While we
often do want to know what the neighbors of a given triangle are,
specifying it in this way requires one to search through the whole
list. On the other hand, we (and some of the models we've looked at)
often work with a neighbors set -- i.e for each triangle, there are
three neighbors (though some could be outside the domain, and thus get
an invalid flag or something). So we'd like a
face_neighbor_connectivity array that was (in the case of triangles)
(nMesh2_face X 3). Not sure about the name, though. GRanted, this is
re-constructable, but often the data is there in model output file,s
so why not use it?

4) Not a standard issue, per se, but we often need to know what the
boundary types are for a model -- i.e. is it an open or closed
boundary. There are ways in the standard to specify data on the edges,
so the mechanism is there, but it would be nice to officially make
this an optional (and encouraged) data -- give it a standard name,
maybe even a standardized set of flags, or something (that may no be
possible, each model has its own boundary types(conditions) ).

I noticed that the data sets put together for the Modeling Test Bed
project don't have this information, but we'd really like it!


Thanks for your comments,

-Chris


--
Christopher Barker, PhD

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

[Bert Jagers]

Hi Chris,

1) I don't remember receiving any objections to the
anti/counter-clockwise requirement, so I have now updated the page to
reflect that it is counter-clockwise (for horizontal faces).

2a) I have added a text to explain the meaning of "Optionally required
attribute": meaning e.g. that the attribute edge_node_connectivity for a
2D/3D mesh is required only if you have data to store on those edges
(then the edge numbering order is important and that's explicitly
defined by the edge_node_connectivity).

2b) I would prefer that the edge_node_connectivity array is always the
full array. I'm open to investigate solutions to support for other
attributes to indicate one or more partial connectivity arrays. What are
the ideas of other readers on this topic?

3) I agree that the face connectivity array would be useful to store in
the file such that one doesn't have to reconstruct it. I would propose
to keep it optional, but recommend it. Looking at the
face_face_connectivity description on the page I'm slightly confused; I
expected it to see a definition that corresponds to what you want but it
doesn't. I have added a "to check" statement, and will do so next week.

4) That would be great; do you have an initial list of boundary types?

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]

Thanks for the note, Bert.

On Tue, Sep 11, 2012 at 11:55 PM, Bert Jagers <bert....@deltares.nl> wrote:

> 1) I don't remember receiving any objections to the anti/counter-clockwise
> requirement, so I have now updated the page to reflect that it is
> counter-clockwise (for horizontal faces).

Sounds good - CCW it is.

> 2a) I have added a text to explain the meaning of "Optionally required
> attribute": meaning e.g. that the attribute edge_node_connectivity for a
> 2D/3D mesh is required only if you have data to store on those edges (then
> the edge numbering order is important and that's explicitly defined by the
> edge_node_connectivity).

Got it now, thanks.

> 2b) I would prefer that the edge_node_connectivity array is always the full
> array. I'm open to investigate solutions to support for other attributes to
> indicate one or more partial connectivity arrays. What are the ideas of
> other readers on this topic?

Well, the question is -- is this a definition of connectiviyt, or a
definiton of edges you need to specify data on -- the definition of
"Optionally required attribute" implies the second to me. And I'd
rather not have all that extra (and redundant) information there.

Also -- we have the case where we need to store/exchange bathymetry
data on nodes that we build our mesh from -- the triangulation has not
yet been defined -- so we need nodes, and we need to define some edges
(the boundaries, primarily), but we don't have all the edges defined.

So I think defining only the edges you need makes sense.

> 3) I agree that the face connectivity array would be useful to store in the
> file such that one doesn't have to reconstruct it. I would propose to keep
> it optional, but recommend it. Looking at the face_face_connectivity
> description on the page I'm slightly confused; I expected it to see a
> definition that corresponds to what you want but it doesn't. I have added a
> "to check" statement, and will do so next week.

Great, thanks.

> 4) That would be great; do you have an initial list of boundary types?

We're more consumers of models, though we have our own in-house one,
so I"ll get a list started, and hopefully others can add to it. --
stay tuned

[Richard Signell]

Bert,
I'm glad we agreed to have the default *not* be clockwise, but I think
in the text of the UGRID spec at http://bit.ly/ugrid_cf we need to
say either "anti-clockwise" or "counter-clockwise". Right now we
say "anti/counter-clockwise" which sounds a lot like clockwise! Can
you just change it to "anti-clockwise"?

Thanks,

-Rich

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



--
Rich Signell
81 Queen St
Falmouth, MA

[Bert Jagers]

Hi Rich,

The page now consistently uses "anticlockwise" which is the same name as
the CF conventions use.
I kept one "(also referred to as counterclockwise)" remark.

Bert
-------

[Richard Signell]

Thanks Bert!

[Christopher Barker]

Folks,

Now that I know there is some life on tis list -- any thoughts on
Brian's last post?


"1st Draft of NOAA CATS Currents in UGRID NetCDF Format"

- https://groups.google.com/forum/?fromgroups=#!topic/ugrid-interoperability/ghOaEzzGRtc


We discovered a copule issues there that we'd like to resolve.

Thanks,
-Chris