[RFC] Add functional guesses - #4839
Conversation
5a2e50b to
b8da5fe
Compare
|
I think in principle this is good. It doesn't even need to just be for dynamic optimization? |
|
yeah, we could have it interpreted in other problem types. is the name ok or should that be adjusted? |
| ) | ||
| ) | ||
|
|
||
| return Symbolics.build_function(expr, iv; expression = Val(false)) |
There was a problem hiding this comment.
This should use ModelingToolkitBase.build_function_wrapper and then eval_or_rgf to get an RGF out.
There was a problem hiding this comment.
Done and also moved the reusable codegen part to codegen.jl
| opts = GeneratedFunctionOptions(; expression = Val{false}, eval_expression, eval_module) | ||
| rgf = generate_trajectory(sys, expr, opts) | ||
|
|
||
| return Base.Fix1(rgf, p) |
There was a problem hiding this comment.
Won't this cause problems with remake? Or initialization, which re-creates p as a copy.
There was a problem hiding this comment.
Hmm... I don't think we run initialization on the dynamic optimization path, I'll have to double check. On remake I'm not sure how to handle it... The issue is that the backends need only a function of t, but we want to be able to use the (MTK) parameters in the functions. I don't think that we can easily remake, since almost everything else on this path has the same problem of baking the p in, as we need to substitute in the backend specific parameter representation. Probably remake needs to go through the process_ function again and we don't have a fast path remake possible for external backends, that would need to remake the underlying backend specific problem...
There was a problem hiding this comment.
Ah, right, that makes sense
|
One of the dynamic optimization tests is failing in Tests / tests / Optimization (julia 1, ubuntu-latest) / Tests - Optimization. Could you also rebase so the rest of the failures disappear? |
Allow users to provide function-valued initial trajectories for state variables via the initial_trajectory kwarg. Functions are applied via dispatched set_initial_trajectory! after variable creation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add a tutorial section covering the `initial_trajectory` keyword: the map-from-states-to-functions form, that unlisted states keep their constant `u0map` seed, backend support (JuMP, InfiniteOpt, CasADi), and the normalized `[0, 1]` time base used for free final time problems. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Take the trajectory guess as a symbolic expression in the independent variable rather than a function, keeping the interface consistent with the other symbolic keyword arguments. Parameters referenced by the expression are resolved from the operating point, and the expression is then compiled to a callable, which is what InfiniteOpt's `set_start_value` requires. Expressions that reduce to a constant become constant functions, and a `Function` is still passed through unchanged so guesses that cannot be written symbolically (an interpolation of measured data, say) remain usable. Anything left unresolved after substitution is reported by name. The backends are unchanged: they continue to receive a callable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cover expression compilation, constant guesses, `Function` passthrough, parameter resolution from the operating point, and the error raised for quantities that remain unresolved after substitution. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add generate_trajectory to codegen.jl producing f(p, t) per the ecosystem convention; parameters are read from the parameter object at evaluation time instead of being substituted numerically. Trajectories are symbolic-only for now. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
bfb53a1 to
68a4281
Compare
3 participants
Checklist
contributor guidelines, in particular the SciML Style Guide and
COLPRAC.
Additional context
For dynamic optimization problems it is not enough to provide constant guesses for the initial conditions and in some cases a functional form of the guess is needed. This also has a precedent in BoundaryValueDiffEq with continuation: https://docs.sciml.ai/BoundaryValueDiffEq/dev/tutorials/continuation/#On-providing-initial-guess
How do we want the interface for this to look like? The proposal here is
initial_trajectoryas aDictmapping the variables to the function, but we can adapt this to be closer to BVP.Another question is how should the free final time problems be handled. We could internally scale the time if the simpler approach in this PR is not good enough.