Skip to content

Kokkos cleanup - #4499

Draft
roystgnr wants to merge 47 commits into
libMesh:develfrom
roystgnr:kokkos-cleanup
Draft

Kokkos cleanup#4499
roystgnr wants to merge 47 commits into
libMesh:develfrom
roystgnr:kokkos-cleanup

Conversation

@roystgnr

@roystgnr roystgnr commented Jul 17, 2026

Copy link
Copy Markdown
Member

Accidentally hit "make pull request" when I was aiming for the arrow for "convert to draft".

Anyway, @rochi00 is seeing a weird Lapack LU failure in adaptivity_ex3 when running this branch himself, but I can't reproduce it, so I want to see what CI environments think.

@roystgnr
roystgnr marked this pull request as draft July 17, 2026 17:51
@moosebuild

moosebuild commented Jul 17, 2026

Copy link
Copy Markdown

Job Coverage, step Generate coverage on db00a5d wanted to post the following:

Coverage

907660 #4499 db00a5
Total Total +/- New
Rate 65.93% 65.93% -0.00% 100.00%
Hits 79374 79372 -2 7
Misses 41019 41021 +2 0

Diff coverage report

Full coverage report

This comment will be updated on new commits.

@roystgnr
roystgnr force-pushed the kokkos-cleanup branch 4 times, most recently from 81011e6 to 41b302f Compare August 18, 2026 20:52
Hopefully this fixes the problem when Kokkos yells at us when we
configure with OpenMP but then test its header (which we were doing
without -fopenmp), as well as any problems downstream from people
missing -fopenmp in pkgconfig.
This gets some Kokkos updates from Rochi
This fixes --enable-werror --enable-paranoid-warnings --enable-kokkos
builds for me.
rochi00 and others added 26 commits August 20, 2026 08:52
With Kokkos we may have device compilers that can't handle them.
This is necessary for --enable-werror --enable-paranoid-warnings (and
possibly just the former?) configurations with Ubuntu 26.4 Kokkos for
me.
This looks like more of the sort of redundancy I want to get rid of, but
I want to get compiling first.
I can't actually trigger this directly yet, but I needed it in
MetaPhysicL for indirectly included Kokkos headers (at least for the
version in Ubuntu 26.4) there.
"Should I add a layer of indirection to accomplish X" is one of the
hardest questions in software, unless X is "nothing".  Then it's easy.
This might become useful again depending on how we change things in the
backend, but for now it's redundant with operator().
operator() setters here lets us avoid an indirection layer
If we had to support arbitrary third-party classes directly this would
have been helpful, but we're writing our own shims here.
This gets them to respect $METHODS and $LIBMESH_RUN
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.

3 participants