Those changes look fine to me, thanks, David. The clarification is useful.
--
Reply to this email directly or view it on GitHub:
Dear Jonathan,
I have made some commits that hopefully make clearer the relationship between
CF-netCDF mesh topology and location index variables, and CF data model Domain
and Domain Topology constructs. What do you think?
Dear Jonathan,
Thank you for your comments.
> In Appendix I (the data model), you describe the new CF-netCDF element as
> "Domain(s) with cell connectivity" and the new CF construct as "Connectivity
> of domain cells". I wonder if these should be the same.
Good point, In this case I think
Dear @davidhassell
Thanks for summarising the discussion up to now and writing the pull requests.
As far as I know, this covers everything. The proposed changes look fine to me
from a CF point of view. I noticed three small things:
* In Appendix I (the data model), you describe the new
Hello all,
I have created a couple of pull requests to hopefully finally get UGRID into
CF. I've not consulted anyone on the new text yet, so I fully expect some
constructive comments! but I thought it a good idea to have something that we
can discuss in less abstract terms.
I have copied the
Thanks guys, i think I get in now -- the ocean basins example is a good one, I
didn't really know what that meant the first time it was mentioned. "axis" it
is :-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear Chris and David
I agree that UGRID uses a discrete axis. There isn't necessarily any ordering
implied by such an axis, just as in the case of UGRID. For example, ocean
basins or other geographical regions may be arranged along a discrete axis in
any order.
Best wishes
Jonathan
--
You
Hi @ChrisBarker-NOAA,
This puzzled me for a bit, until I remembered that in the CF data model, DSGs
are _not_ special. This is because what looks like a discrete axis in the
encoding of a DSG is a really just a form of lossless packing for an orthogonal
multidimensional array (with the data
thanks @JonathanGregory: that is better.
Final note on "axis" -- I think I'm being pedantic here, and it's probably bad
to introduce new terms, but:
David wrote:
> A "discrete axis" in CF is one which does not correspond to a continuous
> physical quantity, for example, this is the case for
Dear @JonathanGregory,
Thanks for your comments.
> I think that "unlike" implies it's somehow inconsistent ...
Agreed. With your new text, that last paragraph becomes
In CF-netCDF a domain topology can only be provided for a domain defined by a
UGRID mesh topology variable. In this case, the
Dear Chris and David
Thanks for this discussion.
In David's revised text
> Unlike the domain topology construct's connectivity array, a
> UGRID connectivity variable's data is not stored as a symmetric matrix that
> indicates the connectivity between any two cells. Instead, the trailing
>
Hi @ChrisBarker-NOAA,
> The whole concept of an "axis" matches orthogonal coordinates of some sort.
> (that's kind the definition of orthogonal, yes?). Mapping a Ugrid to the real
> world, the real world is 2D (Or 3D, but let's not go there yet) -- and that
> 2D world has 2 orthogonal axis --
I think I'm (slowly) getting this, but a few thoughts on language:
"the CF data model is independent of the encoding, and the symmetric matrix is
logically what is going on here."
That makes sense but the language I first noticed said a "symmetric array" -- I
think we need to be careful about
Hi @ChrisBarker-NOAA and @pp-mo,
I have been away and am just catching up with the conversation. Thank you for
an interesting read!
> From the data model perspective, there needs to be SOME way to define the
> connectivity. how it's done is a matter of the "encoding", yes?
Absolutely.
> From the data model perspective, there needs to be SOME way to define the
> connectivity. how it's done is a matter of the "encoding", yes?
Yes, that is what I was "trying" to say !
> ?? -- but does X connect to Y is the key concept we are trying to capture
> here.
> in "lay" terms, I
> Looking at it again, from the viewpoint of actual UGRID connectivity data,
that does make the 'does X connect to X' question seem a rather abstruse and
unimportant.
?? -- but does X connect to Y is the key concept we are trying to capture here.
>From the data model perspective, there needs to
> It sounds like we agree that the domain could have multiple topologies (as
> opposed to topology constructs). It's a good point that we have no use case
> for two or more topology constructs, each of which applies to a single unique
> domain axis, and in fact we have no way of encoding it, so
Dear David
It's a good point that there may be domain axes which aren't involved in the
topology. Thanks for the correction. We can supply a ?? topology construct
provided it refers to a single domain axis (the UGRID case). I'm not sure there
would be more than topology for a domain, although
@davidhassell:
Thanks! this looks good to me.
Am am curious why you chose "network topology" rather than "mesh topology" --
I"m not sure it matters much but at least that wikipedia article is pretty
focused on the topology of communication networks which is pretty similar, but
not quite.
On
Hello @ChrisBarker-NOAA and all,
After some very illuminating discussion over at
https://urldefense.us/v3/__https://github.com/ugrid-conventions/ugrid-conventions/issues/52__;!!G2kpM7uM-TzIFchu!gsrPpUHyBO1L3RCLlnbI4ykGpE8GyFUQGCnBa97TVwjO6tJnc_z4tfusXiad6JE3NXdsbwwppNw$
, and some offline
Dear Patrick,
Thank you for bringing up "location index set" variables. I agree that in the
absence of the `cf_role` attribute it is not always possible to distinguish one
from data variable, so I would be happy with retaining it on these variables.
By extension, I think that we should drop
Hi, sorry to be late to the table with this issue, but I have been listening in
here a while, in hopes of understanding better and maybe contributing.
I think that I may have spotted a potential problem with the removal of
'cf_role' :
As stated (above), the role of a mesh-variable is
Dear Klaus,
I hope to allay your concerns by noting that all of the UGRID machinery for
storing connectivity will certainly be imported into CF unchanged - it is just
that in the logical data model we don't need to make special mention of it.
This is because it turns out the connectivity
Note that not having explicit connectivity creates a (potentially) rather large
computational overhead for the reconstruction of it. This will be exacerbated
with more complicated grids in the future, think time-dependent unstructured
grids, perhaps with regionally varying timestep.
I think it
Dear Jonathan,
That's right. I should have made that clearer, so many thanks for pointing it
out!
CF provides cell connectivity by inspection of coincident (or possibly
overlapping) bounds.
UGRID provides an index based encoding for making the connectivity easier to
find in many
I agree that a cell which is an edge bounded by two nodes is fine in the CF
data model, yes. (H) is correct that CF doesn't explicitly recognise
connectivity, although you could infer it from coincidence - isn't that right?
Jonathan
--
You are receiving this because you are subscribed to this
Hello,
In starting to think about:
> (H) Further to the discussion on implications on the CF data model
> (ugrid-conventions/ugrid-conventions/issues/52), the CF data model needs to
> be updated to allow the storage of topological connections between cells
> ("cells" in the CF data model
This is fine, thanks. If we agree, I suppose that we need to write propose some
textual changes in the CF documents for some of these points.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hello,
Following on from some discussions that have been taking place on the [UGRID
issue
tracker](https://urldefense.us/v3/__https://github.com/ugrid-conventions/ugrid-conventions/issues__;!!G2kpM7uM-TzIFchu!jNG-Y16d7c-C88U9VVZoa-yNuIMgPRCdgpg_rDn4glZ59EsZV9mellI5RhDBXtvHkx_max3jEsU$
), a
Thank you, @davidhassell . Looking good to me as well. As shown above on the
discussion page, I have posted in the UGRID forum (as well as the SGRID forum
following [this
comment](https://github.com/cf-convention/cf-conventions/issues/153#issuecomment-712262386))
a request for feedback on this
Thank you, @davidhassell. I think this is fine.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/153#issuecomment-738180915
This list forwards relevant notifications
Dear @JonathanGregory and @hrajagers,
Here is a synthesis current proposal. How does it sound?
**(A)** The governance is written up along the lines of @hrajagers ideas: #153
(comment)
**(B)** Comprehensive conformance rules are written up for UGRID. These should
be maintained alongside UGRID
Dear @davidhassell
> Is it "Even though UGRID is being included in CF, we don't have to consider
> the relationship between domains of different data variables at the moment."
Yes, that is what I meant. By "not being included in CF" I meant "in the CF
_document_". Sorry to be unclear.
Thanks
(sorry - pressed send too early - I'll try again!)
Dear @JonathanGregory,
Thanks for these comments
I agree with your updated **(C)**.
I'm also fine in **(D)** with a mesh topology variable getting its canonical
identity from the `topology_dimension` attribute (which is similar in principle
Dear @JonathanGregory,
Thanks for these comments
I agree with your updated **(C)**.
I'm also fine in (D) with a mesh topology variable getting its canonical
identity from the `topology_dimension`
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Dear @davidhassell
Thanks for this summary. I agree with **(A)**, **(B)** and **(E)** as given.
Re **(C)**, I would suggest that only the UGRID attributes which can appear on
data variables should be added to CF Appendix A. If I have read the document
correctly, these are `mesh`, `location`
Thanks to everyone who is working through this important issues.
I strongly support incorporating SGRID into this same framework.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
A note on the CF data model:
I think that UGRID need not affect the CF data model at this time.
This is because CF does not currently formalise connections between data
variables, on the same or different domains. A mesh topology variable collates
multiple domains (one for faces, one for
Dear Bert, Jonathan, and all,
I would like to try to summarize the ideas that have been discussed in the form
of some broad proposals that I hope could be acceptable to allow us conclude
this issue. I welcome your feedback.
In no particular order:
**(A)** The governance is written up along
Dear Bert,
Thank you for describing all of the history that has occurred here - it really
is very helpful, particularly the interactions you have had on the geometries
front.
A summary of my position would be that I would support UGRID being moved into
CF ("chapter 10"), but if this is not
Dear David, Jonathan,
Thank you for moving this forward. In the very beginning we were thinking to
move the definiiton for unstructured grids into the CF conventions, later the
discussion moved more in the direction of a separate but affiliated convention,
and in the end the discussion seems
> It would be great to hear from some folks who work on UGRID.
I see that the [UGRID conventions GitHub
repository](https://github.com/ugrid-conventions/ugrid-conventions) has not
been updated for 2 years, and the version being recommended for CF is `UGRID
1.0`, which was released 4 1/2 years
In general, I'm not a huge fan of tight coupling but I don't have objections to
the thrust of these changes - they aren't very onerous and won't force us to
increment if we have no reason to.
The specifics make me slightly more nervous. My understanding is that, if
proposed changes to CF are
Here are my proposed additions to
https://github.com/cf-convention/cf-convention.github.io/blob/master/rules.md.
I probably haven't quite got it yet, but it's a start.
A key thing to note is the second line: _"The assessment will be carried out by
a member of the conventions committee or
Yes, please. That would be most helpful. Jonathan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/153#issuecomment-702146979
This list forwards relevant notifications
Hello,
Some colleagues were asking after the status of this proposal. As far as I'm
aware, there are no outstanding objections other than the requirement to spell
out some rules for the co-management of the two conventions: CF and UGRID.
The CF data model has now been accepted, and the [rules
I think that this is essentially correct. The naming issues are also not
insurmountable. Finite element has its own conventions, but they are just
naming conventions. If UGRID has finite difference naming then this will merely
be a bit confusing for finite element users.
In the specific cases
Hello,
I have been looking at the Finite Element based CF proposal for Unstructured
Grid data model
(https://publicwiki.deltares.nl/display/NETCDF/Finite+Element+based+CF+proposal+for+Unstructured+Grid+data+model)
which was written up some time ago by Bert. This proposes an encoding for the
48 matches
Mail list logo
