inducer
Weaken mesh check in `make_same_mesh_connection`
Weakens the mesh check a bit to fix #358. Also adds an object identity check to the mesh __eq__ so it doesn't need to compare all the attributes if the two mesh objects are actually the same one.
I don't know that I love this, because pretty much by definition, we'll have redundant meshes flying around, which seems avoidable. First of all, could you remind me where those come from? (Restart or something?) And do you think it'd be plausible to replace those two meshes with one "canonical" copy after determining that they're equal? I wouldn't be opposed to adding tools to help with that.
I don't know that I love this, because pretty much by definition, we'll have redundant meshes flying around, which seems avoidable. First of all, could you remind me where those come from? (Restart or something?) And do you think it'd be plausible to replace those two meshes with one "canonical" copy after determining that they're equal? I wouldn't be opposed to adding tools to help with that.
It comes from here in inducer/grudge#285, where we promote the "part ID"s (rank, volume, or both depending on the problem) in the incoming mesh's adjacency data to a single data structure PartID. So each time a dcoll is created it makes a new mesh object. (We have two dcolls temporarily when we restart using a different order than what was stored in the restart file.) We could maybe memoize that function, but a mesh seems like kind of a heavyweight thing to memoize?
Could you explain the reason for that normalization step? Why is it needed? (I'm not suggesting that it isn't, I'm just not currently understanding.)
That was added to provide a uniform way of retrieving the neighbor parts' rank/volume for all of the possible mesh configurations (single/multiple volume, distributed/non-distributed). It was suggested as an alternative to the way I had been doing it previously with the part_id_helpers (see inducer/grudge#239, specifically https://github.com/inducer/grudge/pull/239/commits/09bac09d98f54dce412fac6d0b4f52babce4916f).
Still sort of puzzled, sorry. Let's talk about it during our meeting tomorrow.
As discussed during meeting: We'll leave this open, but for now the creation of duplicate meshes seems avoidable by checking if the normalization step is a no-op.