preserve subdomains & boundaries in MeshQuad._splitquads

[gdmcbain]

For #385

[gdmcbain]

I noticed that MeshQuad._splitquads isn't covered by a test. I'll see if I can add one.

[kinnala]

This naming, _splitquads, seems to imply that it is a private method. Originally it was, as the reason for introducing it was to do plotting of solutions on quadrilateral meshes and it was used internally by MeshQuad.plot3.

Currently I can think of many other use cases so I wonder if we should add an alias, MeshQuad.split_quads, MeshQuad.split, or something. Note that we also have the variant MeshQuad._splitquads_symmetric which is supposed to split each quad into four triangles.

[gdmcbain]

I see, yes, good point about the private-looking name.

On the two new names, the 'quads' in the first seems redundant but then there are lots of other functions and methods already called split. And maybe it could be thought to be an inverse of the new Mesh.__add__ , so maybe the former. Or what about MeshQuad.to_meshtri?

And for the symmetric variant, I hoping that they can be refactored later. As I generally have to work with unstructured meshes, I haven't looked at it myself.

[gdmcbain]

Oh, I see that MeshQuad._splitquads_symmetric introduces new points in the centroids; that'll break the implementation above. And the tests, which are based on checking that the points supporting the subdomains and boundaries don't change. Can that be deferred?

[kinnala]

Yes, to_meshtri sounds reasonable. NumPy/SciPy uses tolist, toarray, etc. but I think tomeshtri sounds too terse. Also, we already have to_dict and to_json etc.

We can later add m.to_meshtri(symmetric=True) flag.