Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(sciml): build the planned SciMLOperators jac_prototype adapter (DESIGN §7)

Abierto
  • ¿Algo no está bien?
#65 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
julia
Área
backend-api-design

Línea de trabajo

Read README.md:158 and DESIGN.md §7, then inspect prepare and LinearizedOp and the planned ext/…SciMLExt.jl location. Implement only the jac_prototype adapter so ODEFunction(f; jac_prototype = sciml(prepare(L))) works and KrylovJL_GMRES reaches the existing zero-allocation flat mul! path; full SciMLOperators semantics are out of scope.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Status

Already scoped, not built. README.md:164-166 and DESIGN.md §7 describe a thin FunctionOperator-style adapter as the jac_prototype hook for implicit OrdinaryDiffEq, in a future ext/…SciMLExt.jl. This issue is to give it a real downstream forcing function rather than to propose it fresh.

The trait prerequisite has landed: #89 made PreparedOperator/PreparedForest declare islinear/isconstant/isselfadjoint/isdiagonal explicitly (src/linalg.jl:75-82) and gave PreparedComposed/PreparedAdjoint their trait methods (src/linalg.jl:308-309, :337-338), so the wrapper can forward traits from the prepared operator without falling through to a default it did not earn.

Why now

The microvascular transport model marches its coupled system with KenCarp47 + KrylovJL_GMRES. To hand OrdinaryDiffEq a matrix-free Jacobian it needs a SciMLOperators-shaped object, and MFO's LinearizedOp / EnzymeLinearizedOp is exactly that object wearing the wrong interface. Without the adapter, the downstream package is pushed into one of two bad options, and has taken both:

  • AutoFiniteDiff everywhere, because its preallocated Float64 work buffers reject ForwardDiff.Duals — so it gets finite-difference Jacobians even though MFO can supply exact ones via Enzyme.
  • Assemble a sparse W = I − γJ and ILU(0) it, with a hand-built Jacobian sparsity pattern and a Curtis–Powell–Reid colouring, purely to get a preconditioner into LinearSolve. That is a full sparse-matrix detour bolted onto a matrix-free stack, and it exists only because the matrix-free path couldn't reach the integrator.

Both disappear if prepare/LinearizedOp can be presented as a SciML operator.

Minimum useful shape

jac_prototype only, as §7 already scopes it — enough that ODEFunction(f; jac_prototype = sciml(prepare(L))) works and KrylovJL_GMRES calls straight into the zero-alloc flat mul!. Lazy algebra and adjoints through the SciML interface can wait; the integrator hook is what unblocks.

Two pieces of the SciML contract are on that path, though, and are in scope here (moved from #73, which keeps the SplitODEFunction + solver-search layer above this one):

  • linearize! exposed as update_coefficients!. An implicit integrator refreshes the Jacobian at the current state through update_coefficients!(J, u, p, t). The package already has exactly those semantics in linearize!(J, u) (src/operators/linearize.jl:110-113 for LinearizedOp, ext/MatrixFreeOperatorsEnzymeExt.jl:66-69 for EnzymeLinearizedOp): it overwrites J.u0.data in place and keeps the existing prepare valid — refresh without re-prepare. The adapter's update_coefficients! should forward to it rather than reinvent it.
  • ldiv! on MultigridPreconditioner. It exposes only size/eltype/mul! (src/multigrid.jl:378-395), which is Krylov.jl's preconditioner convention; LinearSolve's Pl/Pr (and therefore the precs argument) want ldiv!. Without it the multigrid V-cycle cannot stand in for the downstream ILU.

Pairs naturally with #62 — a Robin-aware operator_diagonal is what makes MultigridPreconditioner usable as the precs argument, and between the two the downstream ILU path can be retired rather than ported.

—
🤖 Claude gave this issue two more chores from #73.
claude-opus-5-5[1m] (high) · claude-code 2.1.285 · unreviewed

Lenguaje dominante
Julia
Estrellas
3
Forks
1
Merge medio
1 d 28 min
PR fusionados (30 d)
6

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RallypointOne/MatrixFreeOperators.jl

Todos los issues de RallypointOne/MatrixFreeOperators.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.