Default loop-opened signals in trajectory_ss to their trajectory values - #86
Open
baggepinnen wants to merge 2 commits into
Open
Default loop-opened signals in trajectory_ss to their trajectory values#86baggepinnen wants to merge 2 commits into
baggepinnen wants to merge 2 commits into
Conversation
Opening a loop turns the opened signal into a parameter whose value must be supplied in the operating point. Previously the tutorial held these at 0, which linearizes at the wrong point for systems nonlinear in the opened signal — visible as identical controller linearizations along the whole trajectory in the batch-linearization tutorial. trajectory_ss now maps each opened signal to itself as a symbolic operating- point value, which ModelingToolkit.LinearizationOpPoint resolves from the loop-closed solution at each time point (requires the corresponding MTK support for symbolic op values). User-supplied op entries take precedence. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SWPXe76HwiugWWyLP7BYrL
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Opening a loop during linearization turns the opened signal into a parameter whose value must be supplied in the operating point. The batch-linearization tutorial previously held these signals at
0, which linearizes at the wrong point for systems nonlinear in the opened signal — visible in the tutorial as identical controller linearizations along the entire trajectory in the "Loop open at v and y" plot, even though the scheduling input varies.trajectory_ssnow defaults each opened signal to its own value in the loop-closed solution at every time point: the opened signal is mapped to itself as a symbolic operating-point value, whichModelingToolkit.LinearizationOpPointresolves from the solution. Since the connection still holds in the loop-closed solution, this equals the value of the driving signal, and the linearization is performed around the trajectory also for the opened signals. User-suppliedopentries take precedence, so any signal can still be held at a fixed value, e.g.op = Dict(sys.opened_signal => 0).Tutorial changes: the explicit
op = Dict(… => 0)workarounds are removed from alltrajectory_sscalls, and opening atvandynow coincides with opening atu(both schedule along the trajectory), verified by a newfreqresptest. The controller linearizations with the scheduling loop opened now genuinely vary along the trajectory.Depends on SciML/ModelingToolkit.jl#4894 (symbolic loop-opening op values resolved from the solution). CI will stay red until that PR merges, since
[sources]pins ModelingToolkit to master. TheModelingToolkitcompat bound should be bumped to the version containing that fix before release.🤖 Generated with Claude Code
https://claude.ai/code/session_01SWPXe76HwiugWWyLP7BYrL