Bump DiscreteComponents to v0.3 (SynchToolkit 0.5 initialization semantics)

[baggepinnen]

DiscreteComponents v0.3 requires SynchToolkit 0.5, whose initialization comes exclusively from initialization equations (JuliaComputing/SynchToolkit.jl#183): initial conditions declared on discrete variables, and shift-history overrides in a problem's u0, are now rejected.

(Rebased onto main after #12 landed — that merge brought in the CompiledNode consumption path the first version of this branch had to write by hand, so what's left is much smaller.)

The Dyad sources need no changes

Nothing here declares either of the rejected forms. The clocked states in friction.dyad and identification.dyad are already initialized by initial x@(clk-1) = ... equations; UnitDelay/ZeroOrderHold's initial_condition is an ordinary parameter feeding DiscreteComponents' own such equation; and Revolute(phi(initial = ...)) is a continuous state. The adaptations for the new semantics were confined to DiscreteComponents itself (JuliaComputing/DiscreteComponents.jl#108).

What the bump does break

One ModelingToolkit name. 11.39.1 switched from using SymbolicIndexingInterface to import, so ModelingToolkit.default_values no longer resolves. It's taken from its owner instead, which becomes a direct dependency of both the package and the test env (src/program.jl, and the two uses in test/runtests.jl).

Compat: DiscreteComponents = "0.3", SynchToolkit = "0.5", SynchJulia = "0.4.4", SynchCompiler = "0.4.3". Note the SynchToolkit bound was still 0.4.8 even though the CompiledNode path this repo already uses needs 0.4.9.

Verification

test/runtests.jl was run in two environments — one with DiscreteComponents 0.3.0 / SynchToolkit 0.5.0, one pinned to a pre-#183 baseline (SynchToolkit at ecac23e, DiscreteComponents 0.2, same source otherwise). Results are identical:

	DC 0.3 / ST 0.5	pre-#183 baseline
full suite	8 pass, 2 error	8 pass, 2 error
suite with the :c backend removed	2792 pass, 5 error	2792 pass, 5 error
design_lqr gain	[-2.831113224036648, -21.52650125219085, -0.9274687478416253, -1.7177662878222943]	[-2.831113224033555, -21.52650125217831, -0.9274687478408721, -1.7177662878212678]

Testset for testset the two runs match (compile and step (julia), shared analysis base, run_program!, friction experiment, friction fit, FurutaFrictionExperiment analysis, swingup — Dyad plant (SeeToDee) at 2403 assertions, and the rest). So the bump is behaviour-neutral.

Pre-existing failures, not from this PR

Identical before and after, and left alone:

• :c backend and C export are broken on main — filed upstream as JuliaComputing/SynchJulia.jl#234. SynchCompiler's C backend throws InternalError: IFunction ^ has no emitted C name; register the callee before reaching emit_call. Reduced to a bare @node with y = x^3: exponent 3 is the only one that fails (0, 1, 2, 4, 5, 6, 7, -1, -3 and float/variable exponents all emit fine), so the trigger here is k3 * w ^ 3 in FrictionAndBackEMF (dyad/friction.dyad), which reaches the compiled node through swingup_catch's friction feed-forward. That also explains why C export worked before the program layer landed: the older controller had no friction feed-forward. It kills compile and step (c), C export and FurutaSwingupExperiment analysis, and aborts the suite at the first testset — which is why the second row above exists at all. Reproduces identically on the pre-#183 baseline, so it is not a SynchToolkit-semantics regression.
• identification replay / safety supervisor / FurutaIdentificationExperiment analysis need input_design.csv, which is gitignored and so absent from a fresh checkout; they error with Cannot open '.../input_design.csv': not a file until examples/input_design.jl has been run.

🤖 Generated with Claude Code