-
Notifications
You must be signed in to change notification settings - Fork 6
Parallel for abstraction #6
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
Conversation
do as kokkos does in their parallel_for
|
@HenryCullom Please add a description of the PR (i.e., what was added) in the opening post. |
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 to me. I pushed a commit to use std::move(...) on the slice object in makeField(...). Based on valgrind, this doesn't appear like it was required, but I think the code better expresses the intent of the Field instance owning the slice.
One suggestion, I think we should prefix the test file names with test to make it clearer that they are tests and not implementations of the header files. -- Just pushed this with c9bccae.
Created the MeshField class and Field class that are templated over the SliceWrapper and SliceController types as abstractions to hide the underlying implementation, whether it be cabana, omega_h, kokkos, or something else.
Created a parallel_for absraction that adds parallel_for functionality and hides the underlying implementation from the user