Skip to content
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

batched_lu_serial: fix for ambiguous ? operation error #512

Merged
merged 1 commit into from
Dec 6, 2019

Conversation

ndellingwood
Copy link
Contributor

Detected during Trilinos integration testing.

Detected during Trilinos integration testing.
@ndellingwood
Copy link
Contributor Author

@kyungjoo-kim @brian-kelley or @srajama1 do any of you have a moment to review? Single line change for issue that came up during integration testing.

Copy link
Contributor

@brian-kelley brian-kelley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do the types of tiny and -tiny not match? It's not just the lack of const on -tiny, since the fix also selects either tiny or mst(-tiny) (const vs. non-const).

@@ -37,7 +37,8 @@ namespace KokkosBatched {
const int k = (m < n ? m : n);
if (k <= 0) return 0;

const auto abs_tiny = tiny > 0 ? tiny : -tiny;
using mst = typename MagnitudeScalarType<ValueType>::type;
const auto abs_tiny = tiny > 0 ? tiny : mst(-tiny);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the issue be that tiny has an unsigned integer type?

@ndellingwood
Copy link
Contributor Author

ndellingwood commented Dec 6, 2019

@brian-kelley @mhoemmen the issue occurred with Sacado due to some nuances of expression templates, here's the sample error code snip:

/ascldap/users/ndellin/trilinos/Trilinos/kokkos-kernels/src/batched/KokkosBatched_LU_Serial_Internal.hpp(40): error: ambiguous "?" operation: second operand of type "const Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosCudaWrapperNode>" can be converted to third operand type "Sacado::MP::UnaryMinusOp<Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosCudaWrapperNode>>", and vice versa

I'm adding Eric @etphipp if more detailed explanation is needed.

@brian-kelley
Copy link
Contributor

brian-kelley commented Dec 6, 2019

@ndellingwood OK, that makes sense. @etphipp Does Sacado provide specializations for Kokkos::ArithTraits? If it does, maybe we should use the ArithTraits<T>::abs(). Otherwise I'll approve.

@ndellingwood
Copy link
Contributor Author

@ndellingwood OK, that makes sense. Does Sacado provide specializations for Kokkos::ArithTraits? If it does, maybe we should use the ArithTraits<T>::abs(). Otherwise I'll approve.

@etphipp does Sacado have specializations of ArithTraits so that would allow for use of abs instead of requiring type conversion to create -tiny?

@mhoemmen
Copy link
Contributor

mhoemmen commented Dec 6, 2019

@ndellingwood wrote:

... the issue occurred with Sacado due to some nuances of expression templates....

Ah, that has bitten me before.

@ndellingwood ndellingwood mentioned this pull request Dec 6, 2019
3 tasks
@ndellingwood
Copy link
Contributor Author

@brian-kelley is it okay if we go ahead with this PR, and later I can submit new PR to replace with ArithTraits if it turns out there are ArithTraits specializations to support the failing case?

@ndellingwood
Copy link
Contributor Author

Thanks @brian-kelley !

@ndellingwood ndellingwood merged commit 10ca383 into develop Dec 6, 2019
@ndellingwood ndellingwood deleted the SerialLU_Internal-fix branch December 6, 2019 20:27
@brian-kelley
Copy link
Contributor

@ndellingwood Of course, I mainly just wanted to understand what was happening and it makes sense.

@etphipp
Copy link
Contributor

etphipp commented Dec 7, 2019

Yes there is an ArithTraits specialization for this scalar type.

Note that I was thinking yesterday that there might be a way for me fix these kinds of problems without having to put in the explicit conversion for -tiny, if I mark the unary expression template constructor explicit. I will experiment with that next week.

@kyungjoo-kim
Copy link
Contributor

@ndellingwood Would you please tell me where we see this error ? So far the function is used in ifpack2 block tridiag and I isolate sacado instanciation to avoid ETI with the type. Thus, this means that the code is used in other packages.

@ndellingwood
Copy link
Contributor Author

@kyungjoo-kim here is a more verbose copy of the error message that occurred during Trilinos integration testing:

/ascldap/users/ndellin/IntegrationTests-Blake/serial/trilinos-update/packages/kokkos-kernels/src/batched/KokkosBatched_LU_Serial_Internal.hpp(40): error: ambiguous "?" operation: second operand of type "const Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode>" can be converted to third operand type
          "Sacado::MP::UnaryMinusOp<Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode>>", and vice versa
      const auto       abs_tiny =  tiny > 0 ? tiny : -tiny;
                                                   ^
          detected during:
            instantiation of "int KokkosBatched::SerialLU_Internal<KokkosBatched::Algo::Level3::Unblocked>::invoke(int, int, ValueType *, int, int, KokkosBatched::MagnitudeScalarType<ValueType>::type) [with ValueType=Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode>]" at line 70 of
                      "/ascldap/users/ndellin/IntegrationTests-Blake/serial/trilinos-update/packages/kokkos-kernels/src/batched/KokkosBatched_LU_Serial_Impl.hpp"
            instantiation of "int KokkosBatched::SerialLU<KokkosBatched::Algo::Level3::Unblocked>::invoke(const AViewType &, KokkosBatched::MagnitudeScalarType<AViewType::non_const_value_type>::type) [with AViewType=Kokkos::View<Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode> **, Kokkos::LayoutLeft, Kokkos::Device<Kokkos::HostSpace::execution_space, Kokkos::HostSpace::memory_space>,
                      Kokkos::MemoryManaged>]" at line 96 of "/ascldap/users/ndellin/IntegrationTests-Blake/serial/trilinos-update/packages/tpetra/core/src/Tpetra_Details_scaleBlockDiagonal.hpp"
            instantiation of "void Tpetra::Details::inverseScaleBlockDiagonal(const MultiVectorType &, bool, MultiVectorType &) [with MultiVectorType=Tpetra::MultiVector<Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode>, default_local_ordinal_type={Tpetra::Details::DefaultTypes::local_ordinal_type={int}}, default_global_ordinal_type={Tpetra::Details::DefaultTypes::global_ordinal_type={int}},
                      Kokkos_Compat_KokkosSerialWrapperNode>]" at line 638 of "/ascldap/users/ndellin/IntegrationTests-Blake/serial/trilinos-update/packages/xpetra/sup/Utils/Xpetra_MatrixUtils.hpp"
            instantiation of "void Xpetra::MatrixUtils<Scalar, LocalOrdinal, GlobalOrdinal, Node>::inverseScaleBlockDiagonal(const Xpetra::MultiVector<Scalar, LocalOrdinal, GlobalOrdinal, Node> &, bool, Xpetra::MultiVector<Scalar, LocalOrdinal, GlobalOrdinal, Node> &) [with Scalar=Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode>,
                      LocalOrdinal=default_local_ordinal_type={Tpetra::Details::DefaultTypes::local_ordinal_type={int}}, GlobalOrdinal=default_global_ordinal_type={Tpetra::Details::DefaultTypes::global_ordinal_type={int}}, Node=Kokkos_Compat_KokkosSerialWrapperNode]" at line 120 of "/ascldap/users/ndellin/IntegrationTests-Blake/serial/trilinos-update/packages/muelu/src/Interface/../Transfers/Smoothed-Aggregation/MueLu_ScaledNullspaceFactory_def.hpp"
            instantiation of "void MueLu::ScaledNullspaceFactory<Scalar, LocalOrdinal, GlobalOrdinal, Node>::Build(MueLu::ScaledNullspaceFactory<Scalar, LocalOrdinal, GlobalOrdinal, Node>::Level &) const [with Scalar=Sacado::MP::Vector<SFS_int_double_16_DFN_CPU_default_local_ordinal_type_default_global_ordinal_type_Kokkos_Compat_KokkosSerialWrapperNode>, LocalOrdinal=default_local_ordinal_type={Tpetra::Details::DefaultTypes::local_ordinal_type={int}},
                      GlobalOrdinal=default_global_ordinal_type={Tpetra::Details::DefaultTypes::global_ordinal_type={int}}, Node=Kokkos_Compat_KokkosSerialWrapperNode]" at line 61 of "/ascldap/users/ndellin/IntegrationTests-Blake/serial/build_updated/packages/stokhos/src/MueLu_ScaledNullspaceFactory_MP_Vector_16_Serial.cpp"

compilation aborted for /ascldap/users/ndellin/IntegrationTests-Blake/serial/build_updated/packages/stokhos/src/MueLu_ScaledNullspaceFactory_MP_Vector_16_Serial.cpp (code 2)
make[2]: *** [packages/stokhos/src/CMakeFiles/stokhos_muelu_mp_16_serial.dir/build.make:1833: packages/stokhos/src/CMakeFiles/stokhos_muelu_mp_16_serial.dir/MueLu_ScaledNullspaceFactory_MP_Vector_16_Serial.cpp.o] Error 2

@kyungjoo-kim
Copy link
Contributor

Oh.... I see it. @etphipp Is it safe to naively use temporal sacado variables inside of a functor ? KokkosKernels might use temporal variables without special constructors, which might not be working with DFAD types (SFAD should be fine and this MP Vector is also fine). Do we have Trilinos level cmake option to detect compatibility of ETI types ?

@etphipp
Copy link
Contributor

etphipp commented Dec 9, 2019

Oh.... I see it. @etphipp Is it safe to naively use temporal sacado variables inside of a functor ? KokkosKernels might use temporal variables without special constructors, which might not be working with DFAD types (SFAD should be fine and this MP Vector is also fine). Do we have Trilinos level cmake option to detect compatibility of ETI types ?

It is always safe to use a temporary with any Sacado/Stokhos scalar type. It would be pretty much impossible to write complex kernels without temporaries!

That being said, I am about to push a PR for Sacado/Stokhos that makes this particular change unnecessary (although there are still situations where an explicit conversion is needed because of limitations of the standard).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants