You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the default size types of KokkosSparse::CrsMatrix and several other matrix types were changed to default_size_type. This is typically int or size_t depending on the configuration of Kokkos-kernels.
However, in Kokkos::StaticCrsGraph, the default size type is taken from a ViewTraits instance. Typically, that size type is in turn a size type of a space, and it need not be int or size_t.
The issue is thus that these default size types are not necessarily the same. And because KokkosSparse::CrsMatrix and Kokkos::StaticCrsGraph are so interrelated, this discrepancy can lead to problems when using eg. the KokkosSparse::CrsMatrix constructor that takes a Kokkos::StaticCrsGraph among its arguments.
This issue is thus a suggestion to consider whether further consistency across the size types may be worth pursuing.
The text was updated successfully, but these errors were encountered:
Yes, it was good timing you reminded me about this, I was able to "jump on it" effectively during the meeting.
Since we are the biggest user of this container I think it is reasonable to move it : )
@brian-kelley
@romintomasetti
In the following PR:
the default size types of
KokkosSparse::CrsMatrix
and several other matrix types were changed todefault_size_type
. This is typicallyint
orsize_t
depending on the configuration of Kokkos-kernels.However, in
Kokkos::StaticCrsGraph
, the default size type is taken from aViewTraits
instance. Typically, that size type is in turn a size type of a space, and it need not beint
orsize_t
.The issue is thus that these default size types are not necessarily the same. And because
KokkosSparse::CrsMatrix
andKokkos::StaticCrsGraph
are so interrelated, this discrepancy can lead to problems when using eg. theKokkosSparse::CrsMatrix
constructor that takes aKokkos::StaticCrsGraph
among its arguments.This issue is thus a suggestion to consider whether further consistency across the size types may be worth pursuing.
The text was updated successfully, but these errors were encountered: