Implement cmesh brick connectivity.

[jmark]

Describe your changes here:

This PR implements two routines: t8_cmesh_new_brick_{2,3}d. They construct an optionally periodic connectivity of given nx * ny {* nz} trees.

All these boxes must be checked by the reviewers before merging the pull request:

As a reviewer please read through all the code lines and make sure that the code is fully understood, bug free, well-documented and well-structured.

General

• [ ] The reviewer executed the new code features at least once and checked the results manually

• [ ] The code follows the t8code coding guidelines

• [ ] New source/header files are properly added to the Makefiles

• [ ] The code is well documented

• [ ] All function declarations, structs/classes and their members have a proper doxygen documentation

• [ ] All new algorithms and data structures are sufficiently optimal in terms of memory and runtime (If this should be merged, but there is still potential for optimization, create a new issue)

Tests

• [ ] The code is covered in an existing or new test case using Google Test

Github action

• [ ] The code compiles without warning in debugging and release mode, with and without MPI (this should be executed automatically in a github action)

• [ ] All tests pass (in various configurations, this should be executed automatically in a github action)

  If the Pull request introduces code that is not covered by the github action (for example coupling with a new library):

  • [ ] Should this use case be added to the github action?
  • [ ] If not, does the specific use case compile and all tests pass (check manually)

Scripts and Wiki

• [ ] If a new directory with source-files is added, it must be covered by the script/find_all_source_files.scp to check the indentation of these files.
• [ ] If this PR introduces a new feature, it must be covered in an example/tutorial and a Wiki article.

Licence

• [ ] The author added a BSD statement to doc/ (or already has one)

[jmark]

@Davknapp I checked out the t8_cmesh_new_hypercube_pad routine. There is indeed an overlap of functionality here. However, also some divergence. This PR is limited to quads/hexes, provides optional periodic boundaries and supports cmesh partitioning. It will take time and effort to merge all this into one routine and it breaks the current API.

[jmark]

@Davknapp I just successfully tested this PR with Trixi. I published a draft PR https://github.com/trixi-framework/Trixi.jl/pull/1939 on the Trixi side waiting for the next t8code release.

[jmark]

I still think that this function is very close to t8_cmesh_hypercube_pad, especially creating the vertices of the trees and the creation of the connectivity between the trees. To avoid code duplication we should reuse the functions.

@Davknapp Here we go. I extended t8_cmesh_hypercube_pad to support periodic boundaries and partitioning.