Why does AOSOA not support non-arithmetic data type??

[FlyingCat2023]

For some reasons I would like to use a class as the Datatype. However, I found it is not supported in Cabana_MemberTypes.hpp. What is the background of forcing its member to be arithmetic types?

template <std::size_t M, typename T, typename... Types> struct CheckMemberTypesImpl { using type = T; static_assert( std::is_trivial::value, "Member types must be trivial" ); using value_type = typename std::remove_all_extents::type; static_assert( std::is_arithmetic::value, "Member value types must be arithmetic" );

static constexpr bool value = CheckMemberTypesImpl<M - 1, Types...>::value;

}; //! \endcond

[streeve]

First, we're fundamentally limited by https://kokkos.org/kokkos-core-wiki/ProgrammingGuide/View.html?highlight=trivial#what-types-of-data-may-a-view-contain

But you're correct that we're more restrictive since https://github.com/ECP-copa/Cabana/pull/203. The discussion there is pretty good, but I'm happy to discuss further

[FlyingCat2023]

Thank for replying. As in #203 Rfbird asked for use cases, here I provide one that uses truncated hierarchical B-spline (THB) which is typical for many particle in cell (PIC) solvers. The THB spline is uniquely defined by the grid topology around its knot/grid node. If we consider it as a property of the node, an AOSOA data structure will be helpful to manage the data of the grids including the splines.

[streeve]

It may be possible to store that in an AoSoA, but it's generally only intended to pack multiple particle fields together. We have fully separate structured grids on which we evaluate the current B-splines (and I imagine that could handle something like THB). Am I missing something you're hoping to get out of using the AoSoA for splines specifically?

[FlyingCat2023]

Understood that AoSoA was not designed for grids. However, I observed that the class Cabana::Grid::Experimental::SparseArray is already designed on top of AoSoA. That is why I built my own splines using the AoSoA. Current B-splines are built on the base of Cardinal B spline if I am not mistaken. The cardinal B splines share some very nice properties, e.g., they can be scaled and translated without changing their shapes, meaning that all cardinal splines are essentially of the same. Therefore, they do not need to be stored separately. On the other hand, the THB splines behave differently due to the lack of these properties. All THBs need to be indexed and stored separately. To have a performant P2G interpolation, it is intended to store them in a way of AoSoA.