Feature: t8code as meshing backend

[jmark]

This is the first of a series of probably many PRs to provide full t8code meshing support for Trixi.jl. As of now, only Quads (in 2D) is supported. The datastructures on the Trixi-side are almost identical to the p4est mesh. Hence, the DG solver implementation dgsem_p4est is now shared between the two meshing backends. Preliminary tests show that both backends give exact same convergence results up to floating point precisions as is proven by identical unit tests.

[jmark]

The code does not compile via Github CI since T8code.jl is not registered as an offical package yet.

[ranocha]

This is a great step forward, thanks a lot! Please find below some comments after a quick first look at the code. I think there are also some places where some additional comments explaining the "why and what" could be helpful.

[jmark]

Some thoughts to consider:

• T8codeMesh povides same functionality in terms of the DGSEM solver as P4estMesh.
• Tests are identical to the ones for p4est_2d giving exact same results.
• I tried to reuse as much of the code implemented for the P4estMesh as possible. The datastructures for the caches are exactly the same. Question: How to get rid of T8codeElementContainer, T8codeInterfaceContainer, ... in the cache implementation but still utilize multi dispatch?
• In this PR the backend only supports 2D quads in serial or threaded. 3D hexs and MPI are planned for later PRs.
• Addtional functionality comes from the t8code library itself, such as advanced geometry, complex meshing, etc., which offers more features than p4est provides.
• Other element types or hybrid meshes will be implemented via the DGMulti solver. This means a completly different approach on how t8code interacts with Trixi. Code from this PRs and related will not be useful.

[ranocha]

Thanks a lot for our work! Please find below some first comments. I will finish the review later (hopefully this week).

[jmark]

In df94655, you deleted a finalizer function. Does this mean that we leave garbage around? If so, could you check inside the call whether MPi is already finalized instead?

I opened an issue explaining the problem: #1585.

Proposed a solution for #1585. See discussion there.

[ranocha]

Thanks a lot! We are pretty close to finishing this. Thanks you your patience.

[ranocha]

Thanks a lot!

[jmark]

Made the sc_finalize logic optional. See #1585 (comment) .

[sloede]

Great work! 👍