Reimplement *_satisfying in a more generic fashion

[kinnala]

The methods named:

• Mesh3D.nodes_satisfying
• Mesh3D.facets_satisfying
• Mesh3D.elements_satisfying

could be implemented in a generic fashion for both 2D and 3D meshes and moved to Mesh superclass. They already look very similar: the tuple unpack notation via * could be used to make the implementation equivalent.

[gdmcbain]

Oh, another idea: if a point in the line, plane, or space were represented by a single grouped entity rather than the separated Cartesian coordinates. ndarray is the obvious choice here as this correspondence to the columns of Mesh.p. Would thus be another way of achieving dimension-independent code?

[kinnala]

I'm sorry I missed your idea. The reason why columns of p correspond to points is mostly historical but also in assembly we require efficient slicing of all x-coordinates, all y-coordinates, etc. Default memory ordering of NumPy makes the current approach more efficient in terms of processor-level caching. NumPy supports changing this but I haven't seen a reason to rewrite everything.

[gdmcbain]

Oh, no, I didn't mean columns as opposed to rows. (I agree with that choice, by the way.) I just meant that a point might be passed as a single argument rather than `dim` arguments, one per coordinate. As far as that goes it could be a tuple, list, ndarray, dict, object, whatever, but `ndarray` is probably best. A point (say the i-th) is naturally obtained from a `skfem.Mesh`, however, as `mesh.p[:, i]`, the i-th column of `mesh.p`, which is an `ndarray` of shape `(dim,)`. Isn't that the form that the points will be in already when they're passed to the lambda function? (I didn't check, I just assumed that they'd be sliced out of `mesh.p`.) Envoyé depuis ProtonMail mobile

…

-------- Message d'origine -------- On 20 sept. 2018 à 19:31, Tom Gustafsson a écrit :

I'm sorry I missed your idea. The reason why columns of p correspond to points is mostly historical but also in assembly we require efficient slicing of all x-coordinates. Default memory ordering of NumPy makes this more efficient in terms of caching. — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#51 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/ABg-0yov5vT-BBnJ3IbKfYEPIdctvITQks5uc2BxgaJpZM4Wwmet).

[kinnala]

This would also be consistent with how it's done in the bilinear and linear forms.

It's a good idea but requires some rewriting of examples and tests and other code. Mesh.submesh must be modified accordingly.