Derived relationships

[PetrKryslUCSD]

I would like to point out that MeshCore implements derivation of various adjacency relationships. I wonder if there is some synergy we could exploit here?

[juliohm]

Yes, it would be great to operate with incidence relations using a general approach like the one you have in MeshCore.jl. I am taking a course that starts next week on geometric processing where various data structures for meshes will be covered, and I will take the opportunity to compare the different approaches in the literature, possibly as a final project. Do you know if the book Polygon Mesh Processing covers the data structure and methods implemented in MeshCore.jl?

If you can play with the codebase we have put together here to see how incidence relations could fit, that would be helpful. Ideally we will place all the implementations in this repository to avoid fragmentation.

[PetrKryslUCSD]

As far as I can tell the book only deals with surface mesh structures.

[juliohm]

That is true. I will read your submitted paper carefully for additional references. I have the link from past discussions: https://github.com/JuliaGeometry/GeometryBasics.jl/files/4739240/102557_0_art_file_394454_qggdgd_sc.pdf

[PetrKryslUCSD]

Now I realize that you guys are big on arbitrary polygons and polyhedrons. MeshCore will unfortunately be no help there as it is.

[juliohm]

You mean that the incidence relations implemented in MeshCore.jl are for simplicial elements? They may be useful still.

[PetrKryslUCSD]

It is not as bad as that: the library handles three-dimensional and two-dimensional and lower-dimensional entities for the usual suspects: cube-like elements and simplex elements.

[serenity4]

Now I realize that you guys are big on arbitrary polygons and polyhedrons. MeshCore will unfortunately be no help there as it is.

Well, we like generality because it makes understanding things easier and leads to a cleaner and more consistent API. But, we are also interested in high-performance applications. As long as we rely on zero-cost abstractions, it's fine, but if there is a performance hit at some point then we need to start looking at more specific ways of doing things. #12 discusses about explicitly materializing polytopes. Naïvely doing it is probably the worst idea performance wise, but I'm interested to see how to leverage the language's zero-cost abstractions to improve that.

As I understand it MeshCore is very configurable from a user standpoint. The more you know the problem you want to solve, the more you'll be able to define the right structures for it and get performance. This is absolutely something we'll want to have IMO.

See for example the issues #6 and #11 about abstracting away ordering conventions. We went for a design where new polytope types like pyramids need to define their own ordering convention (which face has which number), and the user is free to implement his own OrderingConvention type and provide specific functions.

[serenity4]

We'd need to come up with a good design, but I don't see why we wouldn't be able to use what MeshCore offers. Although, Meshes will never be as lightweight, for sure.

[PetrKryslUCSD]

Adding pyramids and prisms to MeshCore would be no big deal.

[PetrKryslUCSD]

What makes the representation in MeshCore lightweight and efficient is the encoding of the topology in a separate data structure which does not change.

[serenity4]

What makes the representation in MeshCore lightweight and efficient is the encoding of the topology in a separate data structure which does not change.

Ah, I was mostly talking about the size of the library. Runtime wise, the goal would be not to lose any of that from MeshCore.

[PetrKryslUCSD]

https://github.com/PetrKryslUCSD/MeshTutor.jl now shows how to use implicitly defined geometry. Such as for topologically regular block, where no coordinates are stored but rather are computed on the fly.

[juliohm]

@PetrKryslUCSD I can't see any tutorial in the repository. Can you please point to the file you are referring to?

Also, the binder link is pointing to a non-working build.

[PetrKryslUCSD]

https://github.com/PetrKryslUCSD/MeshTutor.jl/blob/master/deps/tutorial9.jl

Sorry about the binder failure: it does not support Julia 1.6 yet, and hence the configuration files break the build.

[PetrKryslUCSD]

The tutorial may be run by including it from the Julia prompt.

[juliohm]

Thank you @PetrKryslUCSD for sharing the links. They are already in our radar. I will close the issue given that it is not an issue with the codebase but a discussion around possible features. Feel free to join the #meshes.jl Zulip channel to continue the discussions.