FEniCS
Add Numba void* -> typed-pointer intrinsics and tests
This PR adds a small, reliable Numba intrinsic factory for casting void* (FFCx custom_data) to typed C pointers and provides convenience casters for common primitive types, plus unit tests exercising those casters. This PR is relevant for custom_data functionality in dolfinx https://github.com/FEniCS/dolfinx/pull/4013.
coverage: 83.075% (+0.03%) from 83.044% when pulling 4fe12804b5795e13b942fba0eab9c15fefb5cacd on sclaus2/add_voidptr_cast_intrinsic into 818267a4f538d0eeab1afb54274b2580d2dbbaa0 on main.
I'm not convinced that this is code we want to support. One can write really good (and compact) assemblers in Numba if one doesn't use the UFCx interface. Allocated arrays in Numba are dynamically allocated and therefore go on the heap rather than the stack, which is a performance problem. This doesn't mean we shouldn't support Numba for simple problems which require virtually no extra code, but we should really keep it very simple.
@garth-wells In this PR, the functions are only intended as test scaffolding to validate passing custom_data through to the integral kernel (in support of the dolfinx PR [FEniCS/dolfinx/pull/4013] ). They are not meant to be performant or to establish a supported Numba-based assembly path.
I initially had the relevant intrinsics embedded directly in the dolfinx test that checks custom_data passing, but moved them into FFCx to follow the existing pattern (other intrinsics live in FFCx as well). If you’d prefer a different testing approach that avoids introducing even minimal Numba-side code, I’m very open to suggestions. The key requirement is simply having a reliable test for the custom_data passing.
The longer-term goal here is to use custom_data for runtime quadrature rules; this PR is only about ensuring the mechanism is correctly wired and testable.
I think @garth-wells is just talking about making this new method private. Then there is no future obligation on us maintain the API stability or even keep the code around. Or it could go back in the DOLFINx tests (sorry!).
I don't follow the heap vs stack argument here - the data passed by through this new voidptr is not allocated by numba.
I don't follow the heap vs stack argument here - the data passed by through this new voidptr is not allocated by numba.
The point is that Numba kernels that follow the UFCx interface are not performant. We shouldn't add tooling to support an interface that can't give good performance.