state_priority ineffective across alias equations of unequal differentiation depth: singleton-SCC demotion that #103's block merge cannot reach (forced by tier mismatch)

Inizia con dummy_derivative_graph! e merge_dummy_derivative_blocks, poi riproduci il comportamento usando MultibodyComponents.tests.WheelInWorld sul branch fbc/wheel-state-selection. Esamina le tre opzioni di progettazione e il contesto esistente di #103 prima di scegliere un approccio; il lavoro è completato quando il caso di alias con profondità disuguali ha una risoluzione concordata e un controllo di regressione dimostra che state_priority si comporta come previsto.

Summary

state_priority cannot promote a variable whose connection to the rest of the system is an alias equation that Pantelides differentiates less deeply than the alternative variable's chain. The variable's derivative ends up alone in a singleton SCC matched to the differentiated alias equation and is demoted unconditionally — state_priority 30 (or 3000) loses to 15. This is a sibling of #101 that #103's merge_dummy_derivative_blocks cannot reach, and (unlike #101) it is not fixable by priority-aware tie-breaking alone: the demotion is forced by a differentiation-depth mismatch.

Observed on MultibodyComponents.tests.WheelInWorld: the RollingWheel wrapper declares x/z/angles/der_angles (priority 20/30) aliased to RollingWheelJoint's internal coordinates (then 15/15/15/30); the internal low-priority variables were always selected.

Mechanism (debug-traced)

With an env-gated print in dummy_derivative_graph! (per-SCC vars/extended_sp after the priority sort) and in merge_dummy_derivative_blocks (partner analysis for singleton SCCs), on WheelInWorld with the wrapper's angles at priority 3000 for contrast:

SS_DEBUG_MERGE singleton scc 111: var 3 matched diff-eq 103
  partner var 6: matched=u is_deriv=true has_deriv=true present=true scc_of_candidate=0
SS_DEBUG_MERGE singleton scc 113: var 2 matched diff-eq 102
  partner var 5: matched=u is_deriv=true has_deriv=true present=true scc_of_candidate=0
SS_DEBUG_MERGE singleton scc 115: var 1 matched diff-eq 101
  partner var 4: matched=u is_deriv=true has_deriv=true present=true scc_of_candidate=0
...
SS_DEBUG_DD scc: nvars=1 neqs=1
  vars (ascending sp): [(3, 3000)]
  demote(J): var 3        # and likewise vars 2, 1

vars 1–3 = D(wheel.angles[i]) (priority 3000), vars 4–6 = D(wheel.wheeljoint.angles[i]) (priority 15), eqs 101–103 = the differentiated alias equations D(wheel.angles[i]) ~ D(wheel.wheeljoint.angles[i]).

Chain of causes:

1. The joint's internal equations force wheeljoint.angles to be differentiated twice (the rolling constraints are velocity-level), while the alias equation wheel.angles ~ wheeljoint.angles only needs one differentiation. So at the top tier, the only highest-order derivative incident to the differentiated alias equation is D(wheel.angles[i]) — D(wheeljoint.angles[i]) is mid-chain (has_deriv=true).
2. The maximum matching must therefore match the differentiated alias equation to D(wheel.angles[i]) (the invariant var_to_diff[var] === nothing → else "Invalid SCC" excludes mid-chain variables). The partner stays unmatched (matched=u).
3. find_var_sccs puts the matched variable alone in a singleton SCC; merge_dummy_derivative_blocks (#103) only merges via partners that are matched candidates of another SCC (scc_of_candidate[var2] == 0 here), so no merge.
4. The singleton block demotes its only candidate unconditionally, regardless of priority.

I also tried the naive fix of adding unmatched, present derivative partners as demotion candidates in dummy_derivative_graph! — it cannot fire, because the partner fails the highest-tier requirement (var_to_diff[var2] !== nothing); demoting a mid-chain derivative from a tier-1 block conflicts with the tier-descent bookkeeping of the surrounding while-loop.

Note the contrast with the wrapper's scalar x/z in the same model: their alias chains happen to be differentiated to the same depth as the joint's (through the body's translational dynamics), and priority works exactly as intended there. The failure is specific to unequal differentiation depth across the alias.

Why this is hard / design options

Within the static dummy-derivative scheme, the demotion is structurally forced by minimal differentiation: nothing requires the alias equation's second derivative, so the high-priority side's chain is too short to compete at the tier where the choice is made. Options I can see:

1. Over-differentiate alias-like equations connecting chains of unequal depth (equalize depth, then the existing priority sort decides at the top tier and the descent compares the lower tiers). Cost: extra differentiated equations/variables.
2. Tier-aware demotion: allow a block to demote a mid-chain alternative and reconcile with the descent bookkeeping (essentially dynamic re-tiering).
3. Treat it as a documentation/modeling constraint: priorities only act among chains of equal differentiation depth (this is what we've done in MultibodyComponents for now — the wrapper's duplicated coordinates are documented as unselectable, and the deliberate priorities were moved to the joint's own coordinates: JuliaComputing/MultibodyComponents.jl PR following this issue).

Priority-aware matching (#96) alone does not help here: the matching has no freedom — only one top-tier variable is incident to the differentiated alias equation.

Reproduction

MultibodyComponents.jl branch fbc/wheel-state-selection:

using ModelingToolkit, MultibodyComponents
@named model = MultibodyComponents.tests.WheelInWorld()
ssys = multibody(model)
unknowns(ssys)  # wheel.wheeljoint.* selected; wheel.* (wrapper, priority 20/30) never selectable

(Wrapper-variable selection requires the wrapper's der_angles ~ D(angles) relation, included on that branch; without it the wrapper variables have no derivative chain at all and are trivially unselectable.) Versions: StateSelection fix-state-priority-merged-blocks (PR#103 head), ModelingToolkitTearing from lib/, MTK v11.26.8. The debug instrumentation is ~15 lines in dummy_derivative_graph!/merge_dummy_derivative_blocks; happy to push it behind an env gate if useful.