Pass custom_data through assemblers to kernel functions. by sclaus2 · Pull Request #4013 · FEniCS/dolfinx

sclaus2 · 2025-12-01T14:16:43Z

Add void* custom_data member to integral_data struct and pass it to assembly functions (matrix, vector, scalar, lifting). Custom_data defaults back to nullptr if no custom_data is set explicitly (with set_custom_data()). The required changes are minimal

Form.h: Add custom_data to integral_data, add accessors
assemble_matrix_impl.h: Pass custom_data through all functions
assemble_vector_impl.h: Pass custom_data through all functions
assemble_scalar_impl.h: Pass custom_data through all functions
Python bindings: Expose set_custom_data() and custom_data()
Add test_custom_data.py with comprehensive tests

This enables integration kernels to receive additional per-cell user data which is essential for example for runtime quadrature rules. With this extensions users are no longer required to completely rewrite all assembly routines for customised C-kernels.

For an example library that relies on custom_data and its integration into the assembler see

https://github.com/sclaus2/runintgen

jhale · 2025-12-01T15:47:57Z

Instead of void* and nullptr it would probably be better to use std::optional<void*>.

jhale · 2025-12-01T15:49:27Z

I say probably because it's a performance critical part of the code - might need a bit of thought.

sclaus2 · 2025-12-01T16:33:43Z

The void* approach should have minimal overhead because:

The kernel function pointer signature hasn't changed, it is
void (kernel)(T, const T*, const T*, const U*, const int*, const uint8_t*, void*)
The call site simply passes the pointer (or nullptr)
kernel(..., custom_data); // Same cost whether nullptr or valid pointer, before: null_ptr

Potential overhead is:

Storing the pointer in integral_data struct (+8 bytes per integral)
Passing the pointer to kernel (already in the signature)

I can run some performance benchmarks of this branch vs 0.10 release. If you have any existing performance benchmarks that you trust let me know.

jhale · 2025-12-01T17:53:09Z

I didn't explain myself very well. In modern C++ it's canonical to use std::optional rather than a pointer and nullptr to represent a value or absence of value. This also tends to wrap nicely into Python.

For example:

std::optional<void*> opt;
void* raw = opt.value_or(nullptr);
// pass raw up to C kernel

schnellerhase · 2025-12-01T21:27:57Z

How about std::any? It is also type agnostic, but type safe, and would get rid of the undesirable void* in the source. For the kernel invocation it can be cast down to void*.

sclaus2 · 2025-12-01T21:33:56Z

I have changed it to std::optional<void*> for now. Open for suggestions.

Replace void* with nullptr pattern with std::optional<void*> for custom_data in the Form class and assembly functions. This is the canonical modern C++ approach for representing optional values. Changes: - Form.h: integral_data::custom_data now uses std::optional<void*> - Form.h: custom_data() returns std::optional<void*> - Form.h: set_custom_data() accepts std::optional<void*> - assemble_*_impl.h: Function parameters use std::optional<void*> - assemble_*_impl.h: Kernel calls use .value_or(nullptr) - Python bindings: Handle std::optional with None support - Test: Update to expect None instead of 0 for unset custom_data Benefits: - Clearer intent: "optional value" vs "magic nullptr" - Type safety: Distinguishes "no value" from "null pointer value" - Pythonic: Returns None instead of 0 when not set - Zero-cost: .value_or(nullptr) compiles to same code

jhale

Looks pretty good - a few small changes to make.

python/dolfinx/wrappers/fem.cpp

python/test/unit/fem/test_custom_data.py

cpp/dolfinx/fem/Form.h

python/dolfinx/wrappers/fem.cpp

python/test/unit/fem/test_custom_data.py

jhale · 2025-12-02T15:49:30Z

How about std::any? It is also type agnostic, but type safe, and would get rid of the undesirable void* in the source. For the kernel invocation it can be cast down to void*.

I don't think nanobind supports std::any.

I'm not sure about the argument regardingvoid* being undesirable. This feature is deliberately type and memory-unsafe, and this clearly signals that the user needs to be very, very careful. I've asked @sclaus2 to add something in the docstring to that effect.

Address review comments to maintain Form immutability: - Remove set_custom_data method from Form class - Pass custom_data as 5th element of integrals tuple at Form creation - Integrals tuple format: (id, kernel_ptr, entities, coeffs, custom_data) - custom_data can be None (maps to std::nullopt) or a pointer (uintptr_t) Pass cell index through entity_local_index for cell integrals: - Cell integrals now receive &cell instead of nullptr for entity_local_index - Enables per-cell data lookup in custom kernels via custom_data - FFCx-generated kernels don't read entity_local_index for cells (return 0) Safety documentation: - Add warning about void pointer safety to Form.h and Python bindings - Document that users must keep data alive while Form is in use Update tests: - Update test_custom_jit_kernels.py to use 5-element tuples - Expand test_custom_data.py with per-cell material property example

jhale · 2026-01-05T09:13:15Z

python/test/unit/fem/test_custom_data.py

+    return tabulate
+
+
+@pytest.mark.parametrize("dtype", [np.float64])


Would be good to test both np.float64 and np.float32.

jhale · 2026-01-05T09:16:16Z

python/test/unit/fem/test_custom_data.py

+    assert L._cpp_object.custom_data(IntegralType.cell, 0, 0) is None
+
+
+@pytest.mark.parametrize("dtype", [np.float64])


Extend all tests to use float64 and float32.

Pass custom_data through assemblers to kernel functions.

fa84113

sclaus2 requested review from chrisrichardson, jhale and jorgensd December 1, 2025 14:17

sclaus2 force-pushed the sclaus2/pass_custom_data_to_assembler branch from 648f439 to cf52114 Compare December 1, 2025 21:36

sclaus2 force-pushed the sclaus2/pass_custom_data_to_assembler branch from cf52114 to 8101685 Compare December 2, 2025 08:25

jhale requested changes Dec 2, 2025

View reviewed changes

sclaus2 added 10 commits December 3, 2025 19:06

add None as fifth argument to integrals

c073221

add runtime quadrature rule test

8ea554b

Make sure that just custom_data is passed. No other changes

f62e7de

fix ruff and add ffcx branch for custom_data ptr casting

310f93e

fix clang-format

2bfcf1a

fix docs

0864699

fix clang

709b0f4

more doc fixes

dd72a49

Fix tests in parallel

487fb2e

sclaus2 requested a review from jhale December 5, 2025 20:11

schnellerhase mentioned this pull request Dec 8, 2025

Add numba backend FEniCS/ffcx#801

Merged

Merge branch 'main' into sclaus2/pass_custom_data_to_assembler

0f7d14b

sclaus2 mentioned this pull request Dec 23, 2025

Add Numba void* -> typed-pointer intrinsics and tests FEniCS/ffcx#804

Open

jhale requested changes Jan 5, 2026

View reviewed changes

Merge branch 'main' into sclaus2/pass_custom_data_to_assembler

f7a5ac0

		return tabulate


		@pytest.mark.parametrize("dtype", [np.float64])

		assert L._cpp_object.custom_data(IntegralType.cell, 0, 0) is None


		@pytest.mark.parametrize("dtype", [np.float64])

Uh oh!

Conversation

sclaus2 commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jhale commented Dec 1, 2025

Uh oh!

jhale commented Dec 1, 2025

Uh oh!

sclaus2 commented Dec 1, 2025

Uh oh!

jhale commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

schnellerhase commented Dec 1, 2025

Uh oh!

sclaus2 commented Dec 1, 2025

Uh oh!

jhale left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jhale commented Dec 2, 2025

Uh oh!

jhale Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

jhale Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sclaus2 commented Dec 1, 2025 •

edited

Loading

jhale commented Dec 1, 2025 •

edited

Loading