Ability to run Python functions in C++

[mattpurvance]

As per discussion with @IvanGrigorik on March 9, 2026 and Slack messages with @JBludau, this issue is a request for added functionality to be able to run a function defined in Python inside a C++ parallel_ loop. The goal is for users to easily change functionality in the C++ loop without having to change the C++ code base and recompile. Say there is a simple C++ function like:

KOKKOS_FUNCTION void compute(const Matrix<double,6,1> &strain,Matrix<double,6,1> &stress) const {
    stress += strain * 100;
}

That is used inside a parallel_ loop such as:

Kokkos::parallel_for("updateStrainStress",Kokkos::RangePolicy<ExecSpace>(0, num_),KOKKOS_CLASS_LAMBDA(uint64_t mp) {
    DMat vGrad = velGrad_.view_device()(mp);
    SymTen strainInc(0);
    compXX(strainInc) = vGrad(0,0) * timestep;
    compXY(strainInc) = (vGrad(0,1) + vGrad(1,0)) * hTimeStep;
    compYY(strainInc) = vGrad(1,1) * timestep;
    compute(strainInc,stress_.view_device()(mp));
});

The goal is to be able to write a Python function instead for the compute method and then be able to call it inside the updateStrainStress parallel_for loop in C++.

[JBludau]

The goal is for users to easily change functionality in the C++ loop without having to change the C++ code base and recompile.

avoiding recompilation will be the hardest point. Kokkos introspects the functor/lambda that you execute in parallel_for etc. e.g. for the size (which results from the functor having data members). Additionally, device code is inlined into the executable (unless you compile with RDC). That means, if you want to switch the implementation, you will need to recompile.
Compiling with RDC would help, but you sacrifice a lot of performance.

[IvanGrigorik]

I don't think that there will be any issue with recompilation. Basically, how I see that is:

1. PyKokkos generates dll files
2. Load these DLL files in our runtime application (dlfcn for Linux, HMODULE for Windows)
3. At this step, the further logic should be handled by Matt, but in this case, it should be something like "change the current kernel from X to freshly-loaded".
4. We execute this kernel

If the user decided to change the kernel, it should be the Matt application's responsibility to check if the kernel was changed. In this case, yes, the kernel should be recompiled.

The quintessence of this issue can be stated as:

we should provide:

1. some interface to do C++ to Python interaction (and back) (subissue: Support for passing a Kokkos::View to python #314)
2. ability to compile kernels w/o execution

[JBludau]

I don't think that there will be any issue with recompilation. Basically, how I see that is:

1. PyKokkos generates `dll` files

2. Load these DLL files in our runtime application (`dlfcn` for Linux, `HMODULE` for Windows)

3. At this step, the further logic should be handled by Matt, but in this case, it should be something like "change the current kernel from _X_ to freshly-loaded".

4. We execute this kernel

If the user decided to change the kernel, it should be the Matt application's responsibility to check if the kernel was changed. In this case, yes, the kernel should be recompiled.

I see what you are saying. I meant recompiling the kernel not recompiling the cpp application that is calling it.

1. some interface to do C++ to Python interaction (and back) (subissue: [Support for passing a Kokkos::View to python #314](https://github.com/kokkos/pykokkos/issues/314))

I commented some updates on that subissue

2. ability to compile kernels w/o execution

We could have something like a precompile that goes and just compiles all the kernels in a python file? That might also be beneficial for the pure python side of pykokkos