Enable compilation with clangcuda++ and enable kokkoscuda build tests [Related to 4C]

[PhilipOesterlePekrun]

@mayrmt

Description

This change allows one to use the clangcuda++ wrapper as the CXX_COMPILER, rather than nvcc_wrapper, when building with CUDA backend enabled. The primary motivation is that this allows upstream projects like 4C to fetch MIRCO using FetchContent and to compile it correctly with CUDA backend enabled. An additional benefit is that no MIRCO_HOST_COMPILER needs to be specified in this case, because clangcuda++ can compile things like ryml without issue. To achieve this split, the MIRCO_CLANGCUDA option is introduced, and when it is true, the relevant targets are marked with CLANGCUDA_MODE_HOST or CLANGCUDA_MODE_DEVICE.

Build tests

Additionally, build tests were setup for Kokkos with CUDA backend, both with the nvcc_wrapper and clangcuda++ as the compiler. This required adding the relevant cuda-related apt-get items to the Dockerfile, which leads to a significantly larger Docker image (3,0GiB -> 7,8GiB)

Making the build test for the variant using clangcuda++ required this wrapper to be available, so I have added it into MIRCO's source. This does of course pose the problem that MIRCO and 4C will both have this wrapper. I could remove it from 4C to prevent this redundancy, and then just clone the small MIRCO repository to make clangcuda++ available for the build tests in 4C.

Visualization Export

I also discovered while working on this that the visualization export functionality was not working while using Kokkos CUDA. I thought I tested it, but a small change was required. A larger change was required to make it work with clangcuda++, which is that I needed to split the visualization export into a TU that depends only on VTK and one that depends only on Kokkos. I decided to just make that conceptually simple change to make sure it always works.

Related Issues and Pull Requests

• Precedes Enable using Kokkos with CUDA backend for MIRCO and in general 4C-multiphysics/4C#2012

[PhilipOesterlePekrun]

Huh, the tests are not going off. That is odd. Looking into it. Edit: fixed by closing and reopening.

[mayrmt]

@PhilipOesterlePekrun I am fine with the proposed changes. The increase in size of the docker image is natural and I do not see a big issue in that.

A couple of thoughts though:

• The docker image is currently hosted in your personal GitHub space. We should find a more flexible solution in the near future.
• Duplication of the clangcuda++ compiler wrapper is not great. I can see, how it would work if it lives on here in MIRCO and 4C uses it through MIRCO. However, this would prevent 4C Kokkos Cuda compilation without MIRCO. An alternative would be to move it into its own repository, so that both MIRCO and 4C can access it. However, this seems overly complicated and only pays off as long as both need the exact same version. @PhilipOesterlePekrun Do you see cases, where one would need slightly different versions or will one version be guaranteed to be sufficient for all code projects?

[PhilipOesterlePekrun]

@mayrmt Thanks for looking at it. To answer your points,

• Github recommends using a workflow to automatically publish the docker to the organization the repo is part of. Trying that now.
• I think that it is small enough that if there are any changes, we can just make them without really tracking the version or anything like that, so maybe two copies is fine actually. That's just my opinion. The only difference in MIRCO and 4C is that there is the license header in 4C.

[PhilipOesterlePekrun]

@mayrmt I think only you can create the package in imcs-compsim. I would probably just pull my newest package and then push it to imcs-compsim like

docker pull ghcr.io/philipoesterlepekrun/mirco-kokkos-dependencies:latest
docker tag ghcr.io/philipoesterlepekrun/mirco-kokkos-dependencies:latest ghcr.io/imcs-compsim/mirco-dependencies:latest
docker push ghcr.io/imcs-compsim/mirco-dependencies:latest

And then for this repository to be able to update it through the workflow, you might have to link MIRCO to the package under the Package Settings.

[PhilipOesterlePekrun]

@mayrmt Should we publish the docker container under the imcs-compsim organization? I think only you can do this. Once it is published once and the package is linked to this repository, PRs like this should be able to publish the docker automatically when the workflow file, DockerFile, or docker/dependencies/ are changed. Or rather, the docker is pushed after a PR that changes those is merged.

[mayrmt]

@PhilipOesterlePekrun I can look into it next week.

[PhilipOesterlePekrun]

@mayrmt No worries, not urgent!

[mayrmt]

@PhilipOesterlePekrun I followed the steps, that you have sent me on slack. What's next? Can we somehow test, if this was successful?

[PhilipOesterlePekrun]

@mayrmt Yes, the tests succeed. We can only know for sure that the push to the package works after it is merged.

[mayrmt]

@PhilipOesterlePekrun Feel free to merge this PR.