Clarify nlprob docs for ODEFunction #844
Conversation
| multi-level structure). The rationale here is essentially that implicit ODE integration algorithms | ||
| need do solve the a nonlinear problems, usually of the form `dt⋅f(γ⋅z+inner_tmp,p,t) + outer_tmp = z`, | ||
| during time integration, where users want to use extra structure of f during the nonlinear solve. | ||
| Here `z` is the stage solution vector, `p` is the parameter vector of the ODE problem, `t` is |
There was a problem hiding this comment.
how are dt, inner_tmp, outer_tmp, and z defined? in p? Where in p is it assumed? Or does it match some interface?
Aren't you missing a function that updates the prob based on those values?
There was a problem hiding this comment.
Good point. Tried to resolve this in the latest commit.
There was a problem hiding this comment.
I don't see how that addresses it. So okay, how do I update inner_tmp?
There was a problem hiding this comment.
I do not see how that logic changes in OrdinaryDiffEqNonlinearSolve.jl. From my current understanding the specific ode integrator at hand passes some struct with e.g. inner_tmp into the nlprob (e.g. via remake?) to update these during setup and remake.
There was a problem hiding this comment.
Okay that struct is currently just a tuple. I specifically refer to https://github.com/SciML/OrdinaryDiffEq.jl/blob/1d05b16b9bc52c31f5ec27e347b77d9e5306bee1/lib/OrdinaryDiffEqNonlinearSolve/src/newton.jl#L46-L47 where the tmp variable comes from the nonlinear solver struct in https://github.com/SciML/OrdinaryDiffEq.jl/blob/1d05b16b9bc52c31f5ec27e347b77d9e5306bee1/lib/OrdinaryDiffEqNonlinearSolve/src/type.jl#L216-L225
There was a problem hiding this comment.
We probably should have a better interface (a NamedTuple at least would be a step up)
There was a problem hiding this comment.
I'm not sure a functional interface buys us much here since the only things the user is expected to do is get the elements out...
There was a problem hiding this comment.
MTK cannot easily generate a NamedTuple. An interface via a function would make it easy to generate via SII
There was a problem hiding this comment.
[...] functional interface [...]
Functional interface as in non-defective interface or as in function programming?
Regarding the tuples, I think we are on the same page then. I see two main advantage of having structs to control the dispatches for the initialization of different nonlinear solver classes (over having tuples and hard-coded if-else blocks on types):
- Being extensible for custom solvers for specific problem classes
- Being less error prone to changes, e.g. when there might be some decision in the future to add another possibility to the values of
method.
There was a problem hiding this comment.
what does SymbolicIndexingInterface have to do with this?
I think I get the idea about what needs to be done next. To make sure we are all on the same page, let me try to clarify the docs here.