Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
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 variables are just one (very convenient) way of encoding something in CF that can _in principle_ already be done another way. We call the CF data model a "minimal" logical data model, meaning that we keep it simple by not overlapping the contents of one part of the model with another. All the best, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-871526998__;Iw!!G2kpM7uM-TzIFchu!nJQQ-SJUjuYRcEafLmhlUyS5zK6UjwoUb96yVMPZZ89A_s5kED9DGNpFVzdetcE__uB-R3l6E6Y$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
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 would be good to provide a standardized way of storing connectivity, though I agree it also makes sense to make it optional, at least for most commonly used classes of grids today. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-871478644__;Iw!!G2kpM7uM-TzIFchu!iWswTipYA5EBK8IzXGOj5Vq_lVnALN16Cgw9Az-6h551zh55jPZldda2WlknBq9UZI98Ip1OvI0$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
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 circumstances, but the CF data model does not need to copy this. Not including these connectivity indices in the CF data model in no way prevents a software application from managing, and utilising, them "alongside" the data model representation. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-871270692__;Iw!!G2kpM7uM-TzIFchu!g4yoe64-ExvhkL70aKWrCFJ5lJylfftHb1VyVnOGSA4MW4qFPyII6ukaJPOgR-FUAaXy6R7S_cM$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
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 thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-871264221__;Iw!!G2kpM7uM-TzIFchu!gpU7DJSuTUOiA4uZ1OyXdF852Z6xqnWdZuZbdo7H0bWNCsz5x9z7MgLRM4JoppL1er5_M60eMp8$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Reference UGRID conventions in CF (#153)
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 sense). It is not necessary at this stage for
> the connectivity between cell elements (such as the edge of a face) to be a
> part of the CF data model.
For the one case that I thought was not possible in the current CF data model,
i.e. a [1D network
topology](https://urldefense.us/v3/__https://ugrid-conventions.github.io/ugrid-conventions/*1d-network-topology__;Iw!!G2kpM7uM-TzIFchu!gkEbRVWDm8OAd0GAR_p9pl8dtYki7o7-HSGJLjtIHnNlpvKRtYuQk9d3o7xJUf_EfmafcA7vglQ$
),
I now realise the current data model is OK. I was thinking that in this case
the CF domain cells were the nodes, but really a cell is an edge bounded by
two nodes. In this view, the existing CF framework suffices. Remember that the
CF data model is independent of the netCDF encoding, including the UGRID. It
doesn't matter if the CF data model view of the world looks quite different to
that of the UGRID view, as long as it is possible to unambiguously map between
the two.
Thanks,
David
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-871255936__;Iw!!G2kpM7uM-TzIFchu!gkEbRVWDm8OAd0GAR_p9pl8dtYki7o7-HSGJLjtIHnNlpvKRtYuQk9d3o7xJUf_EfmafUs7YDn8$
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, 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
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Lossy Compression by Coordinate Sampling (#327)
Dear @AndersMS. Daniel @erget et al., > Concerning terminology, following discussion in the group, these terms seem > good candidates: > At tie-point level: "subsampled dimension", "non-interpolated dimension" > At reconstituted level: "interpolated dimension", "non-interpolated dimension" Yes, that terminology seems clear and self-explanatory to me. Thanks for your patience and carefulness. > Actionees! I take on myself an action to review the rest of the proposal (Appendix and conformance document) this week. Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/327*issuecomment-871248157__;Iw!!G2kpM7uM-TzIFchu!gsxrOv2ysX6OgZprPT0fXVbdQLwq41YWHk6IHGuWuMSd8cWalg1hnnCaipIGE1BuDEpqgqKegaM$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, 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 cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
