Issue with t8_forest_leaf_face_neighbors()

[CFDER-HF]

Bug report

Describe the bug
I am working on flow past a cylinder, and following is the coarse mesh I use which is created by Gmsh.

I've noticed that the face neighbors returned by t8_forest_leaf_face_neighbors() appear to be incorrect when the neighboring cells belong to different tree_id. I'm unsure whether this issue stems from a potential bug in t8code related to the imported hybrid mesh file, or if I should be using different interface functions for this specific scenario. Could you clarify this for me?

cylinder_hybrid1.msh.zip

To Reproduce
Which command did you run/which function did you call?
t8_forest_leaf_face_neighbors (problem->forest,itree,elem,&neighs,iface,&elem_data->dual_faces[iface],
&elem_data->num_neighbors[iface],&elem_data->neighs[iface],&neigh_scheme,1);

Estimated priority
Which of these is most applicable (remove the others):

"Priority: high" Should be solved as soon as possible

[sandro-elsweijer]

Hey @CFDER-HF,
thank you for reaching out to us!
This problem seems to be related to this issue here: #865
Unfortunately, this bug is very hard to get a hold of. We will take this in our next developer meeting on Monday and come back to you.

Greetings,
Sandro

[CFDER-HF]

Got it! Wait for your good news！

[sandro-elsweijer]

Hey @CFDER-HF,

currently, most of us are on holiday and we had to postpone the discussion to Monday of the next week.

Greetings,
Sandro

[lukasdreyer]

Hey @CFDER-HF,

do you have a specific tree boundary, at which these problems appear in the example you have given?

Also, could you clarify what you mean by not correct? Ideally, I would want to know for which refinement level you did this, and for which element the neighbors are not what you expected. Even better if you can tell me what you expected.

Thank you for your help!

[lukasdreyer]

Just putting down my first observation here: The cmesh that you provided seems to have all element vertices in an order, that does not fit to the expected orientation for t8_code cmesh elements.
Thus, it will reorient these elements by switching some of the vertices.

          t8_debugf ("Correcting negative volume of tree %li\n", static_cast<long> (tree_count));
          switch (eclass) {
          case T8_ECLASS_TRIANGLE:
          case T8_ECLASS_QUAD:
            /* We switch vertex 1 and vertex 2. */
            num_switches = 2;
            switch_indices[0] = 0;
            switch_indices[1] = 2;
            break;

Thus, the t8code internal enumeration of vertices will not correspond to your ordering of vertices, and the t8code internal ordering of faces might also not correspond to your ordering of faces.

That might already explain the discrepancies that you are experiencing, but I'm looking forward to getting more detail

[CFDER-HF]

Thank you for your attention! I encountered an issue where t8_forest_leaf_face_neighbors() fails to correctly identify neighbors from different trees, although it works fine when the neighbors are within the same tree. Below are the details:
This is the tree_id distribution,

and this is the element_id distribution,

All elements seem to exhibit a similar issue. For example, consider element_id: 269. Its neighbors should be 267, 270, and 1836 (with the first two coming from the same tree). However, the function mistakenly identifies 1836 as 1825.

[lukasdreyer]

Are you able to reorient the original mesh in gmsh and try it again?
Currently, all of your coarse mesh elements have a negative orientation in the x-y plane.
There seems to be a bug in the reorientation handling of t8code, leading to wrong face-neighbors after reorientation.

You could also try commenting out this part:

          case T8_ECLASS_TRIANGLE:
          case T8_ECLASS_QUAD:
            /* We switch vertex 1 and vertex 2. */
            num_switches = 2;
            switch_indices[0] = 0;
            switch_indices[1] = 2;
            break;

in the gmsh4 file reader. Then, all of your refined elements would be oriented negatively, but the face-neighbor relation should work.

[CFDER-HF]

I just tried to comment out the corresponding code and check it again. This time, this function interface works within the same cmesh type. However, element at the interface of the triangular and rectangular failed to find any neighbor from the other tree.

This is the element id distribution,

and this is the neighors of element 851,

where neighbor 9960 is missed. And I'm going to reorient the original mesh in gmsh and have another try.

[lukasdreyer]

If the problem at the quad tri boundaries still occurs after reorienting, it might be that your mesh from gmsh is not connected at these boundaries, so the boundary vertices are duplicated and t8code cannot identify the face connection.

Could you check at the left right border between quads and tris? You might have the gmsh connectivity there.

The edges need to be the same transfinite line, so probably you have to split the upper and lower rectangular element into 3 parts, so that you can connect the middle parts to the triangle part.

[CFDER-HF]

I have changed the orientation in GMSH and everything is going as expected. Thanks for your enthusiastic help!

[holke]

Just read the conversation here.
Really good but hunting @lukasdreyer and thank you @CFDER-HF for the detailed problem description that certainly helped a lot!

@lukasdreyer: Is there now still a bug in t8code, i.e. the reorientation?
Just so that we properly document what steps need to be done in t8code in order to close this issue.