This PR aims to fix incomplete check of the consistency of edge tag inside tetra
Reminder of Mmg data structures
We don't store the edges in a "unique" way inside an edge array.
Instead, each tetra is able to retrieve, for each of its edges, "geometrical" informations (is the edge a reference edge, a non-manifold one, a ridge one...). These informations are stored under the form of binary tags inside a MMG5_xTetra structure:
the MMG5_xTetra structures stores the edge tags inside its tag array for each of the 6 tetra edges;
if a tetra has a boundary face, the xt field of the tetra stores the position of its MMG5_xTetra inside the xtetra array.
Thus, for an edge shared by multiple tetras, bugs may lead to inconsistencies (differences) between the tags stored by tetra, while tags should be identical in all the tetra that are sharing the edge as soon as the edge is marked as MG_BDY inside the tetra (boundary edge belonging to a boundary face).
For illustration, on the attached picture, if we suppose that the edge p-q is the $4^{th}$ edge of the tetra number $1$ and the $2^d$ edge of the tetra $2$, as soon as the edge belongs to a boundary face in both tetra (edge marked MG_BDY in both tetra) we should have:
The MMG3D_chkmeshedgestag function is provided for debugging purpose and called by the MMG3D_chkmsh function at the end of the remeshing process (during the mesh packing) when debug mode is enabled (-d command line option).
Incomplete implementation
Initial implementation calls the MMG5_hashEdgeTag function which cumulates the edge tags inside a hash table :
if the tag of the edge is 16 the first time the edge is hased, the function stores the edge with tag 16 and returns 16;
if the tag of the edge is 1 or 17 the second time the edge is hased, then the tag of the edge inside the hash table is updated to 17 (acumulation of binary tags tag |= 1 or tag |= 17) and the function returns 17;
if the tag of the edge is 16 the third time the edge is hashed, then the tag of the edge inside the hash table stays 17 and the function still returns 17.
In consequence, if the edge p-q is processed first from the tetra 1 in which it has tag 16 (MG_BDY) then from the tetra 2 in which it has tag 17 (MG_REF & MG_BDY), the implementation in the develop branch fails to detect the lack of consistency. If tetra are processed in reverse order, the inconsistency is detected because we store first the tag 17 in the hash table, then we compare the tag stored inside the xtetra of tetra 2, which is 16 with the value stored in the hash table (17).
Fix
The current PR proposes to replace the call to the MMG5_hashEdgeTag function by a call to the MMG5_hGet function. This function:
returns 1 if the edge is founded in the hash table and stores the associated tag (so we can compare it with the tetra edge tag);
returns 0 if the edge is not founded: in this case, we call the MMG5_hEdge function to store the edge and the associated tag.
It allows to detect inconsistencies independently of the order in which we process the tetra.
This PR aims to fix incomplete check of the consistency of edge tag inside tetra
Reminder of Mmg data structures
We don't store the edges in a "unique" way inside an edge array. Instead, each tetra is able to retrieve, for each of its edges, "geometrical" informations (is the edge a
referenceedge, anon-manifoldone, aridgeone...). These informations are stored under the form of binary tags inside aMMG5_xTetrastructure:MMG5_xTetrastructures stores the edge tags inside itstagarray for each of the 6 tetra edges;xtfield of the tetra stores the position of itsMMG5_xTetrainside the xtetra array.Thus, for an edge shared by multiple tetras, bugs may lead to inconsistencies (differences) between the tags stored by tetra, while tags should be identical in all the tetra that are sharing the edge as soon as the edge is marked as
MG_BDYinside the tetra (boundary edge belonging to a boundary face).For illustration, on the attached picture, if we suppose that the edge
p-qis the $4^{th}$ edge of the tetra number $1$ and the $2^d$ edge of the tetra $2$, as soon as the edge belongs to a boundary face in both tetra (edge markedMG_BDYin both tetra) we should have:Debug function
MMG3D_chkmeshedgestagsThe
MMG3D_chkmeshedgestagfunction is provided for debugging purpose and called by theMMG3D_chkmshfunction at the end of the remeshing process (during the mesh packing) when debug mode is enabled (-dcommand line option).Incomplete implementation
Initial implementation calls the
MMG5_hashEdgeTagfunction which cumulates the edge tags inside a hash table :16the first time the edge is hased, the function stores the edge with tag16and returns16;1or17the second time the edge is hased, then the tag of the edge inside the hash table is updated to17(acumulation of binary tagstag |= 1ortag |= 17) and the function returns17;16the third time the edge is hashed, then the tag of the edge inside the hash table stays17and the function still returns17.In consequence, if the edge
p-qis processed first from the tetra 1 in which it has tag16(MG_BDY) then from the tetra 2 in which it has tag17(MG_REF & MG_BDY), the implementation in thedevelopbranch fails to detect the lack of consistency. If tetra are processed in reverse order, the inconsistency is detected because we store first the tag17in the hash table, then we compare the tag stored inside the xtetra of tetra 2, which is16with the value stored in the hash table (17).Fix
The current PR proposes to replace the call to the
MMG5_hashEdgeTagfunction by a call to theMMG5_hGetfunction. This function:1if the edge is founded in the hash table and stores the associated tag (so we can compare it with the tetra edge tag);0if the edge is not founded: in this case, we call theMMG5_hEdgefunction to store the edge and the associated tag.It allows to detect inconsistencies independently of the order in which we process the tetra.