_MeshIndexSet first pass#7149
Conversation
trexfeathers
added
Feature: UGRID
Type: Feature Branch
|
pre-commit.ci autofix |
|
@stephenworsley please can you review the approach I have used with this code, accepting that various |
| raise NotImplementedError() | ||
|
|
||
| def is_view_of(self, other: MeshXY) -> bool: | ||
| """Whether this instance is either itself, or a view of the given :class:`MeshXY`. |
There was a problem hiding this comment.
Have you considered how this ought to behave when you've sliced or indexed a _MeshIndexSet? If I'm interpreting the code correctly, it looks like you ought to end up with another smaller _MeshIndexSet. In such a case, I could imagine you might want this method to also return True.
I also wonder if it might be worth considering two different methods, one for comparing a _MeshIndexSet to a MeshXY, another for comparing two _MeshIndexSets. I haven't entirely thought through which contexts you might expect to call these methods so I've not come to a conclusion on this myself yet.
There was a problem hiding this comment.
This is not intended to be possible, and I've taken some steps to avoid it happening:
iris/lib/iris/mesh/components.py
Lines 3619 to 3630 in ec132b0
| result = [self.to_MeshCoord(location=location, axis=ax) for ax in self.AXES] | ||
| return tuple(result) | ||
|
|
||
| def is_view_of(self, other: "MeshXY") -> bool: |
There was a problem hiding this comment.
Offline conversation with @stephenworsley: is_view_of is not necessary, and any value it might offer is offset by potential confusion. We should remove it.
| result_dict = {k: v for k, v in self._members.items() if id(v) in result_ids} | ||
| return result_dict | ||
|
|
||
| def index( |
There was a problem hiding this comment.
Offline conversation with @stephenworsley: this concept of mutability only really extends to altering the membership of the Manager, there is no decent way 1 to protect the coordinates/connectivities themselves from modification, since users are free to assign those to their own variables, and/or to modify the arrays within them.
If we're comfortable with this 'insecurity', then we could consider generating new constituent coordinates/connectivities that explicitly share the same NumPy array as the ones on the original Mesh (as opposed to directly using the slicing API, since that explicitly creates a copy). That would allow the MeshIndexSet to be a true view, with live updating, potentially avoiding the weirdness of re-indexing every time a Manager is requested.
Footnotes
2 participants
No description provided.