ExtremeFLOW
Feature/mesh geometry-connectivity split
Okay, this is a bunch of stuff! I might not grasp this PR completely, but overall this PR adds more classes to handle the geometric aspects of one element? If we could write a short summary of the intent of the PR and what we want to do I think that can help when going through it. I think overall it looks really impressive an I think separating the topology and connectivity is going to be very nice.
One thing I wonder overall is whether it is possible to have vertex and global ids in integer8? This will be important as we get even larger meshes I think.
This figure can help.
The goal is to provide a full description of the mesh splitting topology and geometry. There are two main classes: polytope_t and polytope_aligned_t. The firs one describes objects like topology objects (polytope_topology_t; vertices, edges and in 3D quads) and mesh elements (polytope_mesh_t, quads in 2D and hexes in 3D). The second one combines a general polytope with alignement (alignment_t class), and allows to build relations between topology objects (polytope_oriented_t) and the realisation of the abstract topology objects in a real mesh (polytope_actualisation_t). I use here word actualisation to distinguis from polytope realisations (monon, dion, faces, cells). Realisations of polytope_oriented_t and polytope_actualisation_t (vertices, edges, quads, hexes) are bulding blocks of topology (polytope_topology_t) and mesh elements (polytope_mesh_t) realisations and do not show in any other place. On the other hand realisations of topology and mesh object will be listed in the arrays (this part of the code is not written yet). The hwole idea is to have all vertices, edges, quads and hexes as objects with attached methods and not just as integers in the lists. If you have any more questions we can meet. Regarding int8. We certainly can do it, but not sure it is needed ritht now. One would need to change entity_t and gsid field in polytope_t. The range of int4 is 2*10⁹, so we could support 10⁸ hex elements.
Hi! I think these comments will be it for me. As I wrote previously on Zulip, I would generally like the enforcement of "Prepend the implementations of type-bound procedures (TBPs) with the name of the type, sans the _t." to be strict.
I did find it hard to keep track of all the types when doing the review, and I think the extra helper types that just wrap an allocatable to increase that issue quite considerably. I would therefore be in favour of enforcing some convention for those, as currently defined in at topic on Zulip. But I don't think this should prevent the merge atm, we can do that later.
I think we will also need some kind of "developer guide" discussing some of the questions that pop up. Maybe extended module level docstrings similar to that I added for the alignment. I honestly think things might become clear as the _topology and _mesh objects actually become used. So we can do that in a alter PR as well.
