-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature test cmesh set partition offset #869
Conversation
According to a comment in the code, t8_cmesh_set_partition_offsets does not work with underived cmeshes. We started with test cases to check this comment.
…set_partition_offsets
- value ranges over classes and tree count - check that the cmesh is committed - check that the cmesh is partitioned according to the offset
…e-test_cmesh_set_partition_offset
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In both Tests you can also move the cmesh
, the shmem_array
and the initialization of the communicator in the SetUp
-function of the class. The counterpart can be moved into the TearDown
-function. That way the test shows exactly what is tested.
In the Test cmesh_set_partition_offsets_nocommit
nothing is tested, but you say, that we need a "valid partition". Is this something we can test for?
Describe your changes here:
Note: Merge #868 first.
Add two test cases for the t8_cmesh_set_partition_offsets function with an underived cmesh.
We build a cmesh from scratch and call t8_cmesh_set_partition_offsets.
in the first test, we destroy the cmesh immediately, in the second we commit the cmesh and check whether it was partitioned correctly.
The tests iterate over the eclasses and a range of tree counts.
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
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):
Scripts and Wiki
script/find_all_source_files.scp
to check the indentation of these files.Licence
doc/
(or already has one)