Fix #375: Strip function wrappers for ModelingToolkit GPU compatibility

[ChrisRackauckas-Claude]

Description

Fixes #375 by ensuring all non-isbits types are properly stripped before GPU transfer when using ModelingToolkit-generated problems with EnsembleGPUKernel.

Problem

ModelingToolkit-generated ODEProblem instances contain:

• RuntimeGeneratedFunction wrappers
• Symbolic system metadata
• Complex nested type parameters

These non-isbits types cause the error: "CuArray only supports element types that are allocated inline" when attempting GPU transfer.

Solution

Modified make_prob_compatible in src/utils.jl to:

1. Strip RuntimeGeneratedFunction wrappers using SciMLBase.unwrapped_f
2. Remove the symbolic system (sys=nothing) from ODEFunction
3. Preserve all other ODEFunction properties (mass_matrix, jac, etc.)

Changes

• src/utils.jl: Enhanced make_prob_compatible to unwrap functions and strip symbolic systems
• test/gpu_kernel_de/mtk_compatibility.jl: Added test case for MTK-generated problems
• test/Project.toml: Added ModelingToolkit and OrdinaryDiffEqTsit5 test dependencies

Testing

• Added comprehensive test case using Lorenz system from ModelingToolkit
• Test verifies that MTK problems work with EnsembleGPUKernel and GPUTsit5
• Existing tests should pass without regressions

Related Issues

Closes #375

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

[ChrisRackauckas-Claude]

Implementation Details

This PR implements a targeted fix for the GPU compatibility issue with ModelingToolkit-generated problems.

Key Changes

Function Wrapper Stripping: The core issue was that RuntimeGeneratedFunction wrappers from ModelingToolkit are not isbits-compatible. Using SciMLBase.unwrapped_f(prob.f) extracts the underlying function that can be safely transferred to GPU.

Symbolic System Removal: The sys field in ODEFunction contains the complete symbolic system with metadata that isn't needed for solving and isn't isbits-compatible. Setting sys = nothing removes this while preserving all computational properties (mass_matrix, jac, etc.).

Compatibility: This approach maintains backward compatibility - problems that don't have these wrappers are unaffected, and the conversion still works through ImmutableODEProblem.

Testing Strategy

The test case in test/gpu_kernel_de/mtk_compatibility.jl:

• Uses a standard Lorenz system from ModelingToolkit
• Tests ensemble problems with parameter variations
• Verifies both the fix (no error) and correct execution (successful solutions)

Future Considerations

If MTKParameters still cause issues in some cases, we may need to add Adapt rules for them. However, the current approach of leaving parameters unchanged and letting existing Adapt rules handle them should work for most cases.