arborx
Provide specialization of AccessTraits for std::vector
This PR provides a specialization of AccessTraits for std::vector for user convenience.
In general, we should document somewhere that we reserve the right to provide those specializations for something user's don't control in their libraries (like, things from std::). If users want to provide custom specializations for those, they should wrap inside a holder.
Not sure it is a good idea
When updating the wrappers for deal.II, we realized that there is a lot of boiler code to write with the new interface. It makes it unnecessary hard to use ArborX. With ArborX 1.X, we only needed to write access_traits. Now to do the same thing, we need to write an ExtractIndex structure, the acces_traits, and the IndexableGetter. For most people, only the IndexableGetter uses user data.
Not sure it is a good idea
What do you see as the difference between Kokkos::View and std::vector specializations?
Views are fit for accelerators. What would we want to do about host device annotations on the access functions?
What would we want to do about host device annotations on the access functions?
Not use them. Everything will be HostSpace, so we won't need annotations.
It is not about what memory space we tag it with, we'd run into issues when CUDA or HIP are enabled. Also, I am not sure how it interacts with NVHPC when stdpar is enabled.
It is not about what memory space we tag it with, we'd run into issues when CUDA or HIP are enabled.
Why? It worked correctly with the previous API. I have been doing that for years in adamantine.