Kokkos complex_align variant, Trilinos+PETSc enforcement for Kokkos~complex_align#47686
Conversation
|
cc: @jczhang07 |
ec16062 to
ffb730a
Compare
haampie
left a comment
There was a problem hiding this comment.
Thanks, I'll let the trilinos/kokkos folks have a look, but in terms of style it's a big improvement as well.
@balay yes, we added |
|
This seems fine to me, but I'm not a core member of the kokkos team. |
cedricchevalier19
left a comment
There was a problem hiding this comment.
Ok for the kokkos recipe.
|
This change is triggering Before this change: After this change: |
This PR tackles two problems, but I felt that I will add it to a single PR. Let me know if I must split it into two.
The first issue is the missing variant of
complex_alignon Kokkos. Trilinos, when built with the builtin kokkos version will setcomplex_alignto OFF, which is the opposite of what the default in the Kokkos package is.This PR adds the variant with default value true, but enforcing it to false, when building trilinos.
Also PETSc, when building for complex scalars and kokkos support enforces that the variant
complex_alignis set to false.The second issue this PR tackles is the incorrect dependency on the external Kokkos package for trilinos. Basically this line
This is missing the upper boundary, and only restricts on the very specific trilinos version.
This leads to trilinos pulling in the internal kokkos version, and one would end up with two kokkos libraries. One provided by kokkos (correct) and one provided by trilinos (incorrect).
Also I have the feeling that when we enable
trilinos+kokkos, we actually also want to unbundlekokkos-kernelsfrom trilinos, hence I added this too.All in all, using this PR we can build a version of trilinos that links to
kokkosandkokkos-kernelswithout pulling in the bundled versions inside trilinos.Without this PR, building an environment with a view would lead to multiple
libkokkos_*.so, provided bytrilinos,kokkosandkokkos-kernels.