> @ChrisBarker-NOAA Well, conceptually maybe -- but that's not how anyone 
> encodes the connectivity

Oh I see!  
I was really only thinking in abstract terms, about how why you would describe 
the validity constraint as a 'symmetry', and not the actual 
'face-face-connectivity' arrays or similar.  So, I assumed that was the 
viewpoint of the more abstract description in the CF datamodel.

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.  
However, the basic symmetry rule is still a relevant requirement : and it is 
still **_not_** implicit in the form of the data.

E.G. ... 
Suppose we have a "face-face-connectivity" array "ffc[i,j]",  where i ranges 
over faces and j over 1..nA, where nA is a maximum adjacency number (i.e. 
typically 3 or 4).
Then a "no-self-connections" rule is something like `for all j in 1..nA ; 
ffc[i,j] != i`
But a "symmetry rule" is rather more involved : something like ...
```
for all i1 in 1..nF ; for all j1 in 1..nA ; 
  EITHER ffc[i1,j1] = missing 
  OR exists j2 in 1..nA s.t. ffc[i2, j2] = ffc[i1, j1]
```
-- obviously, the 'missing' possibility complicates it

There are also some other possible rules you _might_ want to state here, such 
as 
`for any i, all the ffc[i,j] should be different (except for missing points)`.  

I _think_ that this is maybe showing that the more abstract form of a "binary 
connections map" does provide a more natural and flexible route for describing 
the mathematical properties  I'm really no expert, but I think that basic graph 
theory is written in terms like these.


-- 
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-883215451__;Iw!!G2kpM7uM-TzIFchu!kImQsXPjSEaIWEC45ICTWjlccvc9Z6hK5zY7GuxdlHsuXN-RfpXsMjs_kXU-cEeKm7MjaShbtS0$
 
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].

Reply via email to