Improvement: Mesh handle tutorials

[Vyp3er]

Describe your changes here:

All these boxes must be checked by the AUTHOR before requesting review:

• The PR is small enough to be reviewed easily. If not, consider splitting up the changes in multiple PRs.
• The title starts with one of the following prefixes: Documentation:, Bugfix:, Feature:, Improvement: or Other:.
• If the PR is related to an issue, make sure to link it.
• The author made sure that, as a reviewer, he/she would check all boxes below.

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 CMake files.
• The code is well documented. In particular, all function declarations, structs/classes and their members have a proper doxygen documentation. Make sure to add a file documentation for each file!
• README.md files are updated if necessary.
• 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.
• The code coverage of the project (reported in the CI) should not decrease. If coverage is decreased, make sure that this is reasonable and acceptable.
• Valgrind doesn't find any bugs in the new code. This script can be used to check for errors; see also this wiki article.

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 scripts/internal/find_all_source_files.sh to check the indentation of these files.
• If this PR introduces a new feature, it must be covered in an example or tutorial and a Wiki article.

License

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.80%. Comparing base (e1593be) to head (80cbf78).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2348   +/-   ##
=======================================
  Coverage   82.80%   82.80%           
=======================================
  Files         139      139           
  Lines       21584    21584           
=======================================
  Hits        17872    17872           
  Misses       3712     3712           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lenaploetzke]

Partial review. Thank you for your work, this is really nice and my comments are mainly documentation! :)

[lenaploetzke]

Review adapt callback file

[lenaploetzke]

Could you please have a look at the failing workflows?
Please also make sure in the future to try your code once before committing.

[lenaploetzke]

Most things are just typos and capitalization.

[lenaploetzke]

Thanks for your work :) I am sorry for all the comments but i think consistency is really important for tutorials that a beginner should learn with :)

[lenaploetzke]

I think the space between ] ( is too much. In the readme, this is not clickable :)

[lenaploetzke]

Moreover i thinkk the mesh_handle/ is too much. You can check this in github by just switching the branch. Please check that all links work.

[lenaploetzke]

This also does not return type int right

[lenaploetzke]

Suggested change

	/** This is not doing anything here, because we only adapt once before this line,
	* so the difference between elements is +1 or -1 at most.
	* We still include it here for demonstration purposes.
	*/

Sorry i think this is not true although i said it... Because you can of course coarsen one element and refine its neighbor so we have a level diff of 2

[lenaploetzke]

There are many bools, can you maybe add inline comments like /* write_treeid */ true, /* write_mpirank */ true
?

[lenaploetzke]

This /** style comments are only for declarations for doxygen. So please use normal /* comments inside function bodies.

[lenaploetzke]

concept is not used here because of your using mesh type

[lenaploetzke]

Do you use this here explicitly?

[lenaploetzke]

Why the blank lines? Please remove these everywhere in the file

[lenaploetzke]

I think everywhere else in the tutorials you used \param [in] right so with a space