-
Notifications
You must be signed in to change notification settings - Fork 55
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
Minimal tests for test level 2 #1418
base: main
Are you sure you want to change the base?
Conversation
test/t8_cmesh_generator/t8_cmesh_parameterized_examples/t8_cmesh_params.hxx
Outdated
Show resolved
Hide resolved
With the proposed changes I now have a test suite runtime of around 53 seconds at test level 2 (with By far the longest test is |
At the moment, in the CI, we use TEST_LEVEL 1 if the event is a PR, otherwise we use 0 (and never 2). I think this is fine for now. We should keep in mind that we could speed up the CI if necessary. |
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.
Please split the PR to create cleaner PRs
Describe your changes here:
Restricted some maximum levels for test level 2.
Deleted some duplicate tests.
Cleanup
Most important change is #define T8_CMESH_MAX_NUM_XYZ_TREES 1 instead of using 2 as in test level 1. I think this is ok for a minimal test, especially since this variable alone saves around 40 seconds. Of course, this significantly limits the test quality.
Side note:
Currently, for serial tests using AllCmeshsParam, we have unnecessary cases with do_partition and do_bcast (as we only use one processor). Doing a case distinction between parallel and serial is somehow complicated and produces more code, and the time gain is insignificant. If someone has a simple solution to this, it would be nice to include it.
Closes #1371.
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.License
doc/
(or already has one)Tag Label