Hanging nodes handling?

[frlacf]

Hello,

I would like to start using t8code with Fenicsx/dolfinx. There is quite some work to interface the two libraries. One point on which I am unsure how to proceed is how to handle hanging nodes. There is currently no standard way to deal with hanging nodes in dolfinx, so I was wondering if there was an option in t8code to adapt without creating hanging nodes. For instance, using transition cells or any other mechanism. I know there is a PR regarding this in t8code, is it still something you are planning to implement in the future?

Thank you!

Francis

[holke]

Hi @frlacf and thank you for posting the issue.
We very much welcome the integration of t8code into Fenicsx/dolfinx and are happy to help with any questions.
I suggest that you join our Mattermost Chat since there we could get more deeply into details and directly react to questions: https://mattermost.hzdr.de/signup_user_complete/?id=wbu4efea7f817eri4jdkn61heo&md=link&sbr=su

To answer you query about hanging nodes:

1. We are planning to integrate removing hanging nodes in t8code. For 2D quads this is already implemented, 2D triangles will probably follow during the next year. 3D will take some more time. We have an open PR which does resolve hanging nodes on faces but will still leave hanging nodes on edges. Resolving hanging nodes in 3D completely is a long term project.

2. Therefore, handling hanging nodes in the solvers would be the current best solution. I have seen you posting an issue about it in the dolphinx github Handling hanging nodes jorgensd/dolfinx_mpc#135
   On the solver side you then have to solve the appropriate interpolation routines, however, for almost all numerical schemes hanging nodes have been incorporated and there is a lot of literature out there.

3. How do you get the hanging nodes information from t8code?
   You could checkout our advection solver example, which does handle hanging nodes. It is a (numerically very slow) first order finite volume solver and demonstrates the interplay of solvers and t8code.
   See here:

   t8code/example/advect/t8_advection.cxx

   Line 400 in facc24c

   /* Compute the flux if the element has hanging neighbors:

   
   here:

   t8code/example/advect/t8_advection.cxx

   Line 1315 in facc24c

   /* Compute whether this is a hanging face

Basically to find out if a face is hanging you call t8_forest_leaf_face_neighbors and query whether the refinement levels of the neighbor element(s) differ from the current element.

Next year we will be working on better interfaces, also for hanging nodes. If you have any input our wishes, please formulate them and we will be able to incorporate them.

[frlacf]

Thank you @holke for your answer,

I will create an account; I didn't know this Chat existed.

1. I see that two of your students did a thesis on the topic, it doesn't seem trivial to accomplish while keeping exascale performance. I think it's a very useful topic that could benefit many codes. That would be a very welcome feature to have.

2. Well, I answered to the dolfinx_mpc thread first without knowing the level of complexity needed to remove hanging nodes completely. I'll have to get back to dolfinx and see how hanging nodes can be handled in the code.

3. I see thank you. If I can know which elements are impacted by hanging nodes, I could probably deal with them in post-processing using a local Delaunay. It won't be exascale-ready, as I would have to work with 2 meshes at the same time (one for dolfinx and one for t8code) and so some manipulations when I import the mesh in dolfinx but it should work.

I guess the best solution would be to be able to handle hanging nodes in Dolfinx. I'll see how much time I can dedicate to this project.

Anyway, thank you for your answer.

Francis Lacombe