Trajectory linearization: avoid per-timepoint recompilation; require op for loop-opening parameters

[baggepinnen]

Targets as/linearize-op (#4443).

While exercising this branch through ControlSystemsMTK.trajectory_ss (linearizing a gain-scheduled closed loop at ~800 points along a trajectory), the multi-timepoint path was ~340 ms/point with ~92% of the time spent in the Julia compiler, recompiling on essentially every iteration. This PR addresses the two causes (points 1 and 2 from my review comment in #4443).

1. Operating-point values are boxed into SymbolicT, forcing per-value codegen

_build_op_from_solution returns a Dict{SymbolicT, SymbolicT}, so every numeric value is stored as a symbolic constant. The op-application loop then took the symbolic_type(v) != NotSymbolic() branch for every entry and called getu(prob, v)(prob). For a constant, getu builds an observed function with the value baked into generated code, so a fresh RuntimeGeneratedFunction is compiled per distinct value — i.e. a recompile at almost every time point. (Confirmed empirically: replaying identical operating points cost 268 ms/pt cold but 33.8 ms/pt warm — the cost tracks the values.)

Fixed by _resolve_op_value, which unwraps symbolic constants to plain numbers/arrays and only routes genuinely symbolic expressions (e.g. op = Dict(ρ => A/K)) through getu.

2. The problem and setters were rebuilt every iteration

__linearize_multiple_op_barrier called the high-level per-point linearize in a loop, reconstructing the LinearizationProblem and rebuilding all setu accessors each iteration. It now builds the problem and setters once (the op keys are identical across time points) and per point only updates values via the cached setters and mutates .t, as the LinearizationProblem docstring already intends.

Results

Gain-scheduled closed loop (7 states, 21 op entries, 200 points, loop_openings active):

	per point
before	~340 ms
after	~3.6 ms (~95×)

Results are bit-identical to the per-point scalar LinearizationOpPoint path (max abs diff = 0 over sampled indices). The remaining per-point cost is the legitimate initialization solve + Jacobians, not compilation.

The single-point linearize op-application now shares _resolve_op_value, so the same speedup benefits any caller whose op values are numeric, and the symbolic-op case (Dict(ρ => A/K)) is preserved (verified). Extended the LinearizationOpPoint testset with a per-point scalar-vs-vector equivalence check.

This is purely a performance change; it does not touch operating-point semantics. (Separately, the opened-loop-parameter freezing I mentioned in #4443 is unaffected and still wants the "error if not provided" change.)

🤖 Generated with Claude Code

---

Also: require an operating point for loop-opening parameters (correctness)

Second commit. When loop_openings is used, each opened analysis point's output is turned into a parameter (Break(ap, true)) whose operating-point value is not implied by the rest of the system — and is not present in a solution passed via LinearizationOpPoint. Previously it silently took a stale/default value; along a trajectory it was effectively frozen at the point used to build the linearization function rather than tracking the trajectory.

Now handle_loop_openings returns the variables it promotes to parameters; they are threaded into a new loop_opening_params field on LinearizationFunction, and linearize errors (listing them) if any is missing from the operating point. To supply them when the op comes from a solution, LinearizationOpPoint gains an optional op keyword merged into the per-timepoint op:

LinearizationOpPoint(sol, t; op = Dict(opened_signal => 0))

The op must be keyed by the parameter as it appears in the linearization system (root namespace stripped); the error message lists the exact names. Added a loop_openings require an operating point testset.