Refactor __init codepath into smaller helper functions #2975
+383
−165
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR addresses issue SciML#2557 by refactoring the monolithic `__init` function in OrdinaryDiffEqCore into smaller, more focused helper functions. This improves code maintainability and makes the initialization flow easier to understand. ## Summary of changes Added the following helper functions extracted from `__init`: - `validate_prob_alg_compat`: Validates problem-algorithm compatibility - `validate_dt_requirements`: Validates timestep requirements - `prepare_algorithm`: Prepares algorithm (converts AutoSwitch to AutoSwitchCache) - `resolve_aliases`: Resolves ODEAliasSpecifier from kwargs - `extract_state_variables`: Extracts f, p, u, du, duprev from problem - `compute_tolerances`: Computes abstol/reltol with defaults - `compute_rate_prototype`: Computes rate and residual prototypes - `setup_callback_cache`: Sets up callback cache for vector callbacks - `setup_controller`: Sets up step size controller with deprecation handling - `finalize_integrator_init!`: Performs final initialization steps The `__init` function now delegates to these helpers, making the code flow clearer while maintaining full backward compatibility. ## Notes on init codepath architecture Added documentation explaining the full dispatch chain: `CommonSolve.init -> DiffEqBase.init -> DiffEqBase.init_up -> DiffEqBase.init_call -> SciMLBase.__init` The `init_up` layer exists to support ChainRules differentiation (since kwargs can't be differentiated). Currently only `solve_up` has AD rules defined, but the structure is maintained for consistency and future AD support for `init`. Fixes SciML#2557 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR addresses issue #2557 by refactoring the monolithic
__initfunction in OrdinaryDiffEqCore into smaller, more focused helper functions. This improves code maintainability and makes the initialization flow easier to understand.Changes
Added the following helper functions extracted from
__init:validate_prob_alg_compat: Validates problem-algorithm compatibilityvalidate_dt_requirements: Validates timestep requirementsprepare_algorithm: Prepares algorithm (converts AutoSwitch to AutoSwitchCache)resolve_aliases: Resolves ODEAliasSpecifier from kwargsextract_state_variables: Extracts f, p, u, du, duprev from problemcompute_tolerances: Computes abstol/reltol with defaultscompute_rate_prototype: Computes rate and residual prototypessetup_callback_cache: Sets up callback cache for vector callbackssetup_controller: Sets up step size controller with deprecation handlingfinalize_integrator_init!: Performs final initialization stepsThe
__initfunction now delegates to these helpers, making the code flow clearer while maintaining full backward compatibility.Notes on init codepath architecture
Added documentation explaining the full dispatch chain:
The
init_uplayer exists to support ChainRules differentiation (since kwargs can't be differentiated). Currently onlysolve_uphas AD rules defined, but the structure is maintained for consistency and future AD support forinit.Test plan
init/solve!workflow works correctlyFixes #2557
cc @ChrisRackauckas
🤖 Generated with Claude Code