Re: UGRID-0.9

[Rich Signell]

Chris,

I've only heard positive comments except for your initial ones, but
then it sounded like you were okay with versioning the current doc at
0.9. Is that correct?

@Bert: Haven't heard you chime in yet. Are you okay with this
also? I assume so since you wanted to version this way back in Feb,
but just wanted to check.

-Rich

On Tue, May 7, 2013 at 5:51 PM, Brian Zelenke <br...@zelenke.com> wrote:
> 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....@noaa.gov
> Web: http://response.restoration.noaa.gov/
>
>
>
>
> On Tuesday, May 7, 2013 2:37:00 PM UTC-7, Rich Signell wrote:
>>
>> Brian (& Chris)
>> Excellent. Then are you guys okay with us versioning the existing doc
>> with 0.9?
>>
>> Thanks,
>> Rich
>>
>> On Tue, May 7, 2013 at 5:31 PM, Brian Zelenke <br...@zelenke.com> wrote:
>> > 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:
>> >
>> > 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
>> >
>> > face_face_connectivity would also need to include a flag to note if the
>> > region "out of mesh" abuts a given face
>> >
>> > 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
>> >
>> >
>> >
>> >
>> > On Tuesday, May 7, 2013 12:36:36 PM UTC-7, Chris Barker wrote:
>> >>
>> >> 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
>> >>
>> >>
>> >>
>> >>>
>> >>> -Rich
>> >>>
>> >>> On Tue, May 7, 2013 at 2:33 PM, Christopher Barker <pyth...@gmail.com>
>> >>> wrote:
>> >>> > 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
>
> --
> 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.
>
>



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

[Brian Zelenke]

Hello Rich,

I met with Chris Barker yesterday and he was hoping that the following could be incorporated into the v.0.9 standard (and at http://bit.ly/ugrid_cf) before it's adopted as such:

[...since no one has objected to these changes/corrections since they were proposed some three months ago.]

1. Including the concept of boundary-node connectivity (viz. boundary_node_connectivity and boundary_type variables) so that information about the nature of the mesh boundaries can be communicated.
2. Clarifying that specifying the aforementioned optional "boundary information" attributes doesn't constitute "[storing] data on the edges," and thus doesn't necessitate specification of the "Optionally required" edge_node_connectivity attribute.
   
3. Under section "2D triangular mesh topology" at http://bit.ly/ugrid_cf, correct the description of the face_face_connectivity attribute to read, "face_face_connectivity pointing to an index variable identifying all faces (here consistently triangle) that share an edge with each face, i.e. are neighbors. This connectivity array will thus be a matrix of size nFaces x 3 with a flag to note if the region 'out of mesh' abuts a given face."

The thinking here being that the v.0.9 standard needs to at least include those changes to the draft that no one has objected to; rather than omitting corrections people have already worked on, only to have to re-justify them for inclusion in the eventual v.1.0.

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/

On Wednesday, May 15, 2013 3:25:09 AM UTC-7, Rich Signell wrote:

Chris,

I've only heard positive comments except for your initial ones, but
then it sounded like you were okay with versioning the current doc at
0.9.    Is that correct?

@Bert:   Haven't heard you chime in yet.   Are you okay with this
also?   I assume so since you wanted to version this way back in Feb,
but just wanted  to check.

-Rich 

[Rich Signell]

Folks,
I don't have problems with these changes. Dp others?

@Bert, is it time to move this page to another confluence site (e.g.
USGS has one) or the CF wiki where folks other than yourself (e.g.
Brian) could edit? It seems unfair for you to have to make all the
changes in the code examples, for instance.

-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.
>
>