Attempt at BVP solver compatibility

[aditya-sengupta]

I've yet to test this, for now just adding it here in case there's something obvious that needs to change

[avik-pal]

@ChrisRackauckas does this need to be here? Can't we put it in a extension in BVPs itself?

[avik-pal]

Most of these are exported from SciMLBase

[ChrisRackauckas]

I don't know how you'd handle the init which auto-installs SciPy

[ChrisRackauckas-Claude]

PR Analysis

I've reviewed this BVP solver compatibility PR. Here's the current status:

Test Results

• ✅ All existing ODE tests pass locally
• ⚠️ No BVP-specific tests are included - the implementation is completely untested

Implementation Analysis

The PR adds a solve_bvp wrapper from scipy.integrate with the following structure:

1. Added dependencies: SciMLBase for AbstractBVPAlgorithm
2. New algorithm: collocation <: SciPyBVAlgorithm
3. BVP solver: Wraps scipy's solve_bvp function

Potential Issues

Without BVP tests, it's difficult to verify correctness, but the implementation has these characteristics:

1. Initial mesh setup (line 127): Assumes u0 has a specific structure - creates uniform mesh based on length(u0)
2. Boundary condition interface (lines 135-144): Assumes prob.bc[1] and prob.bc[2] structure which may not match modern SciML BVP interfaces
3. Matrix dimensions: The scipy solve_bvp expects y as shape (n, m) where columns are mesh points - need to verify this matches the DiffEqBase convention

Recommendations

Before merging, this PR needs:

1. BVP test cases - at least a simple two-point BVP to verify the implementation works
2. Documentation - example usage of the collocation algorithm
3. Architectural decision - @ChrisRackauckas should this be an extension in BVPs as @avik-pal suggested, or stay here?

The PR is almost 2 years old. Should we:

• Close it and implement BVP support as an extension instead?
• Add tests and merge?
• Wait for upstream changes?

@ChrisRackauckas what's your preference?

🤖 Generated with Claude Code