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 agreed procedure from previous comments, and mapped them to new parts of the pull requests (one here and one over on https://urldefense.us/v3/__https://github.com/cf-convention/cf-convention.github.io__;!!G2kpM7uM-TzIFchu!lOoPYeWtDSqIZQsKNctTh7mqIX59dfz39Aur1lMQnlR_AKsuhnoT2eRf4jNkNezdlbDu_Y5ms58$ ). Thanks, David ### Procedure for incorporating UGRID into CF 1. UGRID will remain an independent convention, with independent governance. Agreed. 2. Comprehensive conformance rules will be written up for UGRID. These will be maintained alongside UGRID in its repository, and referenced from (not copied into) the CF conformance document. See PR #353 (conformance). The link to the UGRID conformance is a placeholder, as they are still being written. 3. The rules governing the evolution of CF will be modified to ensure that the CF conventions remain consistent with URGID. Whilst UGRID will not be formally constrained by the CF conventions, it will be in everyone’s interest for UGRID changes to be evaluated for compatibility with CF, and vice versa. If desirable changes in one convention would require changes in the other convention, then such changes should be proposed to the other community and discussed together as part of a shared interest. Different time scales of evolution between the two standards are accounted for, as CF will only formally accept a named version (or versions) of UGRID and so is not necessarily obliged to support the latest version of UGRID (although that would generally be the expectation). In the very unlikely event that changes to UGRID can not be accepted by CF then it would be the time to merge the last set of accepted UGRID conventions into the actual CF document, from where the CF representation of unstructured grids would evolve independently to UGRID. See PR https://urldefense.us/v3/__https://github.com/cf-convention/cf-convention.github.io/pull/210__;!!G2kpM7uM-TzIFchu!lOoPYeWtDSqIZQsKNctTh7mqIX59dfz39Aur1lMQnlR_AKsuhnoT2eRf4jNkNezdlbDu1DY2Yv4$ (Additional recommendations relating to UGRID) 4. A subsection will be added to CF section 1: Introduction to introduce UGRID and its purpose, to make clear its special synergy with CF, to remark on the appearance of attributes in CF appendices, and to say that it has its own conformance document which complements the CF conformance document. See PR #353 (section 1) 5. The standardised UGRID attributes will be documented in the CF conventions, thereby making them visible to all users, and it will be mentioned in the CF governance rules that they need maintaining. Only the UGRID attributes which can appear on data variables (currently `mesh`, `location` and `location_index_set`) should be added to CF appendix A: Attributes. All other UGRID attributes (such as those on mesh variables) should go into a new CF appendix specifically about the UGRID mesh topology variable. This would be like the treatment of the attributes of the grid mapping variable, which are in a table in CF appendix F: Grid Mappings, not in appendix A. (It is acknowledged that the geometry variable attributes appear in CF appendix A, but there are only five of them, whereas there are eighteen attributes of the mesh topology variable.) See PR #353 (appendix A, appendix K) 6. Some text will be added to CF section 5.8: Domain Variables to explain the UGRID mesh topology variable and how it relates to a CF domain variable. It may be the case that the occasional note relating to UGRID would be useful in other sections. See PR #353 (section 5). I took the approach of creating a new section (5.9 Mesh Topology Variables) instead, which references the CF domain. 7. It will be decided whether or not UGRID fits into the existing CF data model (defined in CF appendix I: The CF Data Model), and if not then the CF data model will be extended to accommodate UGRID. The understanding of interested parties from both the UGRID and CF communities coalesced on the need for a new CF data model construct that can make explicit the notion of a network topology for CF domain constructs. See PR #353 (appendix I) -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-1017626734__;Iw!!G2kpM7uM-TzIFchu!lOoPYeWtDSqIZQsKNctTh7mqIX59dfz39Aur1lMQnlR_AKsuhnoT2eRf4jNkNezdlbDuwa7Jw2U$ You are receiving this because you are subscribed to this thread. Message ID: <cf-convention/cf-conventions/issues/153/[email protected]> This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
