Build and install downstream Trilinos packages against pre-installed KokkosKernels and SEACAS using their native CMake build systems

[bartlettroscoe]

@lucbv, @crtrott, @rppawlo, @ndellingwood, @ibaned, @sebrowne, @jwillenbring

Description

Now that Kokkos 4.1 has been snapshotted into Trilinos 'develop' with the merge of PR #11988 the next step (other than waiting for Kokkos 4.1 to be released) is to get the native non-TriBITS CMake build system for KokkosKernels to be updated so that KokkosKernels can be pre-installed and build the rest of Trilinos against it.

This issue can also cover testing with the independent install of SECAS as well as would be done by Spack. (But since SEACAS is just using TriBITS, that should be pretty easy.)

[bartlettroscoe]

@ndellingwood and @lucbv,

Given that the release-candidate-4.1.00 branch in the KokkosKerenls GitHub repo is very new, could I consider patching the KokkosKernels CMake build system in the release-candidate-4.1.00 release branch and getting it to work with TriBITS? I think that just adding a KokkosKenels::all_libs target to the installed KokkosKerenlsConfig.cmake file.

What say you?

[ndellingwood]

Given that the release-candidate-4.1.00 branch in the KokkosKerenls GitHub repo is very new, could I consider patching the KokkosKernels CMake build system in the release-candidate-4.1.00 release branch

@bartlettroscoe it would be better to patch to develop since the release-candidate-4.1.00 branch is no longer active nor maintained now that the 4.1 release PR's have merged

[bartlettroscoe]

@ndellingwood,

How is the 4.1 release managed? Is a branch not created for the 4.1.z release series?

[ndellingwood]

Is a branch not created for the 4.1.z release series?

@bartlettroscoe 4.1.z will be branched off the master branch (which contains the merge of the release-candidate-4.1.00 branch). If you submit changes to develop, we will cherry-pick to the 4.1.01 branch

[bartlettroscoe]

@ndellingwood, @crtrott, @dalg24

@bartlettroscoe 4.1.z will be branched off the master branch (which contains the merge of the release-candidate-4.1.00 branch). If you submit changes to develop, we will cherry-pick to the 4.1.01 branch

Just an FYI, but the version identifier 4.1.01 is not consistent with the Semantic Versioning Standard (https://semver.org/#spec-item-2):

2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

Instead, it should be 4.1.0 and 4.1.1.

[dalg24]

This is a sore point.
As far as I know, no one in our team likes the 4.X.0Y scheme, but we decided we would stick with it for the 4.X series (in the name of consistency).

[bartlettroscoe]

It would seem that the SPARC team would like to have this capability for their custom Spack trilinos/package.py file.

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.
If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[bartlettroscoe]

@ndellingwood, @lucbv, @kuberry, has the KokkosKernels part not already been done? This was used by the Spack update:

• Kokkos complex_align variant, Trilinos+PETSc enforcement for Kokkos~complex_align spack/spack#47686

merged back on 2024-11-23.

But it does not look like anyone has done this for SEACAS with Spack-proper yet. But my memory was that the Sierra project's Spack build as doing this. @psakievich, @sebrowne?

[ndellingwood]

@bartlettroscoe we test nightly builds (Cuda and Hip) of Trilinos with small subset of packages (Tpetra, Sacado, Stokhos, those most sensitive to changes in Kokkos) against pre-built Kokkos and KokkosKernels as external TPLs. The configurations use -D Kokkos_ENABLE_COMPLEX_ALIGN=OFF , which I believe is the default needed for Trilinos builds