RustedSciThe for Python

RustedSciThe brings a symbolic engine and a family of stiff ODE, boundary-value, nonlinear-system and fitting solvers to Python. The Python package is a thin, idiomatic interface over a compiled Rust numerical core: expressions are parsed and differentiated in Rust, solver workspaces and algorithms stay in Rust, and Python receives ordinary typed objects and detached NumPy results.

This project is for problems where a trustworthy derivative, a stiff or strongly nonlinear method, and visibility into numerical behavior matter more than hiding every solver choice behind one universal interface.

Why RustedSciThe

• Symbolic derivatives without a Python CAS dependency. Build expressions, simplify and substitute them, and derive exact Jacobians with RustedSciThe's own symbolic engine. Prepared residual and Jacobian callbacks are reused instead of being rebuilt during every numerical iteration.
• Native stiff IVP and BVP solvers. Use Rust implementations inspired by SciPy's Radau, variable-order BDF and collocation methods, alongside LSODE2, Backward Euler and the damped BVP solver. The numerical solve runs in Rust, not in a Python loop around a native linear algebra call.
• More than ODE integration. Solve square nonlinear systems, rectangular least-squares problems, observation-based fitting and separable models with VarPro. These are first-class numerical workflows, not just helper routines attached to an IVP API.
• Algorithms beyond the SciPy-like IVP/BVP set. Native nonlinear methods, a dedicated rectangular Levenberg-Marquardt solver, Gavin fitting and variable projection cover workflows that are not merely wrappers around SciPy's ODE interfaces.
• Choose the linear algebra layout when the solver supports it. Dense, Sparse and Banded routes are available across most solver families. Their performance depends on the equation structure and problem size; there is no universally fastest layout. BVP_sci additionally offers opt-in SuperLU.
• Lambdify and AOT execution. Use prepared in-process callbacks for a fast development cycle, or generated compiled callbacks where supported. The symbolic frontend (expr_legacy or atom_native) is a separate choice from the execution route (lambdify or aot).
• Prepared models and parameter series. Reuse symbolic preparation across continuation and restart workflows where the solver exposes that lifecycle.
• Diagnostics designed for numerical work. Typed exceptions, route provenance, optional counters and stage timings help explain what happened without parsing console output or error messages.

Performance is workload-dependent. A Rust implementation is not automatically the fastest choice for every equation, frontend, layout or lifecycle. Compare the same workload and inspect preparation, callback and full-solve timings before choosing a route.

Architecture

Python model and NumPy inputs
             |
       PyO3 boundary
             |
Rust symbolic preparation -> exact derivatives -> Lambdify or AOT callbacks
             |
Rust solver -> Dense / Sparse / Banded linear algebra where supported
             |
typed result, telemetry and owned NumPy arrays

Python is the user-facing layer, not a second implementation of the algorithms. NumPy arrays returned by result objects own their data; they do not borrow a mutable solver workspace. The package does not require SymPy.

Quick Start

This small stiff IVP uses Radau with its default symbolic and numerical configuration:

from rustedscithe import Expr, RadauSolver

y = Expr.variable("y")
solver = RadauSolver([-y], ["y"], "t", 0.0, 1.0, 0.1)
solution = solver.solve([1.0])
print(f"y(1) = {solution.final_state[0]:.8f}")

Install the published package with python -m pip install rustedscithe. For a checkout-based editable build, install maturin and run:

python -m maturin develop --manifest-path bindings/python/Cargo.toml

The extension uses the stable abi3 Python 3.10+ ABI and NumPy 2.x. Import the public API from rustedscithe; _native is an implementation module.

Solver Families

Use capabilities("solver_name") to inspect the Python-supported routes. Native features that are not exposed by this package are not implied by a shared option name; unsupported combinations raise a typed error instead of silently selecting a different backend.

Configuration Choices

Several independent axes shape a solve, and a given solver supports only a documented subset of their combinations:

Check the relevant guide and capabilities() before combining options. A structured layout is useful only when the problem has exploitable structure; parallel callback evaluation and AOT compilation also have workload-dependent break-even points. For continuation, distinguish cold preparation from warm solve time.

Guides and Examples

The overview guides explain shared Python conventions. Solver-specific guides preserve each native solver's option breadth, supported routes, limitations and recommended workflows.

Runnable, commented Python examples include Robertson kinetics, Lorenz and three-body systems, frontend/layout comparisons, continuation, AOT and task documents. See the Python example index; the repository's Rust examples are collected separately in the root examples directory.

Text Tasks and Executable

Python users can parse and run text task documents with TaskDocument or task(...), and batch independent documents with run_task_batch(...). The batch API preserves typed per-task failures and can write a compact table. The Windows console executable is part of the main Rust project, not this Python package; see the task parser documentation.

Diagnostics and Development

Native exceptions preserve their Python class and expose machine-readable stage, solver and route attributes. Telemetry is opt-in and solutions provide detached counters, timings and report writers where supported. Prefer these fields over parsing exception text or redirecting build output into a performance report.

For development and contribution checks, see the Python contract tests, the strict typing consumer, and the Python binding roadmap. The core crate's broader algorithm documentation and release evidence remain in the main README and solver guides.