-
Notifications
You must be signed in to change notification settings - Fork 53
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
Common baseclass for schemes #963
base: main
Are you sure you want to change the base?
Conversation
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.
Looks good in general. It is impressive, that this general implementation is only 2 times slower than our spezialisations.
Is there a branch, where our test-suite runs over our specialization and this base-class?
* \param [in] elem The element. | ||
* \return The number of faces of \a elem. | ||
*/ | ||
virtual int |
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.
The face functions are much better documented than the others. Can you please add a documentation to all of your functions?
update copyright Co-authored-by: David Knapp <[email protected]>
small changes and doc Co-authored-by: David Knapp <[email protected]>
const Co-authored-by: David Knapp <[email protected]>
Describe your changes here:
Introduce a convenience baseclass for different schemes.
This baseclass includes 3 different concepts:
t8_element_new
andt8_element_destroy
SC_ABORT
To check that these standard implementations actually still work, check branch
feature-common-deleted
, where the specific implementation for the element types is deleted.For creating a new forest, this is slower by a factor of 2, as you have additional virtual table overhead in the generic implementation. But this is mostly meant as a base to more easily add new schemes, where a faster implementation can be added after checking the general SFC functionality.
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)