Argument class for SplineFunction kernel arguments

[max-models]

Stack: part 10 of 14, based on #720 (merge that first), next: #724. Full order: #709 → #708 → #711 → #712 → #705 → #713 → #714 → #718 → #720 → #721 → #724 → #725 → #723 → #722.

Stack merge: in SplineFunction.__init__ (feec/psydac_derham.py), the SplineArguments/CudaSplineArguments are now built after #709's degree check and its host-to-device copy of the knots.

---

Solves the following issue(s):

Solves #678 (the remaining point: #667 (comment)). Part of #650.

Core changes:

SplineFunction no longer builds (kind, pn, tn1, tn2, tn3, starts) tuples for the spline evaluation kernels. It now uses an argument class pair, like DerhamArguments/CudaDerhamArguments:

• New pyccel class kernel_arguments/spline_args_kernels.SplineArguments(kind, pn, tn1, tn2, tn3, starts) and its CUDA twin kernel_arguments/spline_args_cuda.CudaSplineArguments (a CudaStructArguments with struct SplineArgs). The header kernel_arguments/spline_args.cuh is generated by the new write_spline_header(). SPLINE_STRUCTS is added to CUDA_STRUCTS.
• SplineFunction.__init__ creates one argument object per component: SplineArguments on NumPy, CudaSplineArguments on CuPy. They are stored in _args_spline, which replaces _args_eval. The CUDA degree check (degrees 1 to 8) moves from SplineFunction into CudaSplineArguments, the same as in CudaDerhamArguments.
• eval_spline_mpi_markers, eval_spline_mpi_matrix and eval_spline_mpi_sparse_meshgrid (pyccel and CUDA, still 1:1) take args_spline instead of the six loose arguments. The shared helper eval_spline_mpi (pyccel and __device__) keeps its flat signature, because other kernels call it too.
• CudaSplineArguments accepts only C-contiguous knot vectors. SplineFunction already passes contiguous ones, so test_evaluation_parity now uses contiguous knots instead of strided views.

No CUDA kernel other than these three takes the spline arguments, and pushers and accumulation already use DerhamArguments. One possible follow-up: eval_spline_mpi_tensor_product_fixed is a pyccel-only kernel in evaluation_kernels_3d.py that SplineFunction still calls with loose kind, pn, starts (no knots).

Tests:

• test_kernel_backends.py: the new pair is added to ARGUMENT_PAIRS, so the mirror check (and the struct layout check on a GPU) covers it. New test test_generated_spline_header. The owner test checks that SplineFunction creates SplineArguments on NumPy.
• kernel_test_args.spline_evaluation_arguments returns (_data, args_spline), so the parity and emulation cases now pass the argument object. test_cuda_emulation.CUDA_CLASSES includes CudaSplineArguments.

Local tests (macOS, no GPU), after recompiling the changed kernels:

• bsplines/tests, feec/tests/test_eval_field.py, feec/tests/test_derham_gpu.py, pic/tests/test_cuda_emulation.py, pic/tests/test_kernel_backends.py, pic/tests/test_cuda_parity.py, pic/tests/test_pushers.py, pic/tests/test_accum_vec_H1.py: 258 passed, 315 skipped. On devel, the same files gave 256 passed, 314 skipped; the differences are the 2 new tests and 1 new GPU-only skip.
• mpirun -n 2 on bsplines/tests/test_eval_spline_mpi.py, feec/tests/test_eval_field.py, pic/tests/test_pushers.py, pic/tests/test_accum_vec_H1.py: 139 passed (139 on devel).
• CPU emulation of the three CUDA kernels against pyccel passes (test_emulated_parity[eval_spline_mpi_*]).
• With cunumpy's fake CuPy, an ad-hoc check built CudaSplineArguments and packed the struct, and the degree check and the rejection of host arrays both work. The fake CuPy cannot construct a full Derham, so SplineFunction on CuPy was not run end-to-end.

GPU tests were not run (no GPU available). This affects the struct layout, the parity tests and test_spline_function_backends[cupy].

Model-specific changes:

None.

Documentation changes:

CUDA_STRATEGY.md: the new pair is added to the argument class table and the current-state table, plus a short note in the PR 16 implementation notes.

🤖 Generated with Claude Code