kokkos
Moving KokkosKernelsHandle, SpADD and SpGEMM out of experimental
See issue #741 for more background information
This does not change any kernel code but simply rearrange the namespaces so that SpADD and SpGEMM kernels are not implemented in experimental anymore. Added macro and pre-processor guards to allow down stream packages to turn on and off warnings/code.
@brian-kelley @ndellingwood @srajama1
I have not tested this at the moment but will do shortly.
Do we need to worry about the impact on Trilinos right-away even if this gets merged in develop only at the moment?
@seheracer if you go to the issue linked you can add it to the list of kernels to move out of experimental. To me it was more clear that SpADD and SpGEMM needed to move at as they have been very important kernels for many years... but we can discuss that in the issue or tomorrow?
@seheracer if you go to the issue linked you can add it to the list of kernels to move out of experimental. To me it was more clear that SpADD and SpGEMM needed to move at as they have been very important kernels for many years... but we can discuss that in the issue or tomorrow?
That's fine by me. I was just confused because your PR also touches the jacobi files.
@lucbv Kokkos removed deprecated code and the CMake option to enable/disable deprecated code (always off, though the cmake definition still exists): https://github.com/kokkos/kokkos/pull/2969/files
I think before moving forward with your changes we need to clean out current dead code from kokkos-kernels (otherwise we lose track of newly deprecated stuff post-3.0 versus pre-3.0), and should add a kokkos-kernels macro and cmake option for deprecation. I'll open an issue to clean out deprecated code.
Edit: Opened #793 to clean up dead code
@lucbv I wouldn't worry much about the impact on Trilinos, since this will be an easy change for the 3.2 integration. AFAIK spadd and spgemm are both only called in 1 or 2 files in Tpetra and nowhere else in Trilinos.
I wouldn't worry much about the impact on Trilinos, since this will be an easy change for the 3.2 integration.
I have a frozen branch for the 3.2 integration used for the snapshot into the Trilinos PR, this change won't be included in 3.2
@ndellingwood I figured we would definitely not include that in 3.2 as it is too late and I don't want to add to you plate : ) Also I do not think that there is any rush to get this deprecation done, it just makes a lot of sense to me to do it so at least at this point there is some momentum, it will get done. @brian-kelley OK, I am mainly worried about certain app that could be getting adventurous with the branch of kk they use in their Trilinos build. But agreed there are not so many places that uses these, I might have snuck a couple calls to SpGEMM in MueLu for Notay aggregation but it is easy to clean-up.
Overall I feel it might be good to make an announcement tomorrow as a topic of discussion for our stand-up especially if we also want to remove pre 3.0 deprecated things. Thanks for the feedback!
Also removing the handle from experimental, this took more doing but that seems to work just fine.
Status Flag 'Pre-Test Inspection' - Auto Inspected - Inspection is Not Necessary for this Pull Request.
Status Flag 'Pull Request AutoTester' - GitHub reports Mergeable status = False