shift_discrete_system: substitution rebuilds a + with mismatched shapes (Unknown(2) vs scalar) on MTK 11.37
まだ誰も着手していません。
評価
調査の方向性
まず ModelingToolkitTearing/src/tearingstate.jl:1092 と clock_inference/interface.jl:127 からの shift_discrete_system 呼び出しを確認し、次に、3行の GoHome セットアップと記載されているパッケージバージョンで再現してください。失敗するスタックを、11.34.0/1.54.1/1.19.3 で動作するスタックと比較し、スカラーのシフトされた変数の置換に焦点を当ててください。split_system がスカラーのクロック付きモデルで成功し、既存の完全なテストスイートがパスすれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Goal
Upgrade the MTK stack under a purely-discrete (clocked) model that we compile with SynchToolkit's stkcompile. We currently pin ModelingToolkit = "= 11.34.0" / ModelingToolkitBase = "= 1.54.1" / ModelingToolkitTearing = "= 1.19.3", and we'd like to move to current versions.
What fails
On the newer stack, split_system throws while shifting the discrete system:
ArgumentError: Cannot add arguments of different sizes -
encountered shapes UnitRange{Int64}[] and SymbolicUtils.Unknown(2).
[1] throw_unequal_shape_error(x::SymbolicUtils.Unknown, y::SymbolicUtils.SmallVec{UnitRange{Int64}, …})
@ SymbolicUtils src/symbolic_ops/addsub.jl:2
[2] promote_shape(::typeof(+), …)
@ SymbolicUtils src/symbolic_ops/addsub.jl:10
[3] maketerm(::Type{…BasicSymbolicImpl{SymReal}}, f, args, metadata; type)
@ SymbolicUtils src/terminterface.jl:354
[5] DefaultSubstituter{…}(ex)
@ SymbolicUtils src/substitute.jl:198
[9] shift_discrete_system(ts::TearingState)
@ ModelingToolkitTearing src/tearingstate.jl:1092
[10] mark_discrete
@ ModelingToolkitTearing src/clock_inference/interface.jl:127
Line 1092 is the equation-substitution loop in shift_discrete_system:
for k in discvars
k in fullvars_set || continue
MTKBase.isoperator(k, Union{Sample, Hold, Pre}) && continue
discmap[k] = MTKBase.simplify_shifts(Shift(iv, 1)(k))
end
...
for i in eachindex(eqs)
eqs[i] = MTKBase.simplify_shifts(substitute( # <-- throws here
eqs[i], discmap; filterer = Symbolics.FPSubFilterer{Union{Sample, Hold, Pre}}()))
end
So substituting k → Shift(iv, 1)(k) into an equation rebuilds a + whose operands no longer agree on shape: one side is scalar (UnitRange{Int64}[]), the other reports SymbolicUtils.Unknown(2). Every variable involved is scalar in our models — we have no array variables in these components.
infer_clocks! succeeds; it is split_system that throws:
state = MTKTearing.TearingState(expand_connections(sys))
ci = MTKTearing.infer_clocks!(MTKTearing.ClockInference(state))
MTKTearing.split_system(ci) # ArgumentError here
Versions
Fails with ModelingToolkit 11.37.1 (master), ModelingToolkitBase 1.57.1 (master), ModelingToolkitTearing 1.20.0 (main), SymbolicUtils 4.42.0, Symbolics 7.34.0, SciMLBase 3.39.1, on Julia 1.12.6.
Works with ModelingToolkit 11.34.0 / ModelingToolkitBase 1.54.1 / ModelingToolkitTearing 1.19.3 — our full test suite (5453 tests) passes there and exercises exactly this path.
Reproduction
Any of several clocked components in QuanserComponents reproduce it through the three lines above — GoHome, SwingupCatch, RuntimeController, SwingupWithHoming. They are ordinary controller blocks assembled from DiscreteComponents delay and filter primitives (UnitDelay, DiscreteDerivative, ExponentialFilter), i.e. the equations contain u@(clk-1)-style shifts, all on scalar signals. The simplest failing one is GoHome.
I have not reduced this to a dependency-free example, and I have not yet checked whether released 11.37.0 is also affected — in that configuration an unrelated SampleTime error (SynchToolkit#172, fixed on MTK master) aborted compilation before split_system was reached, so the two were masking each other. Happy to bisect further or produce a minimal case if that would help.
Question
Is there something our models should be doing differently for the shift pass on the newer stack — some shape or metadata expectation on scalar discrete variables that changed — or is shift_discrete_system reconstructing terms in a way that no longer satisfies the newer promote_shape? Also happy to move this issue if it belongs in ModelingToolkitBase or SymbolicUtils rather than here; I filed it where the throwing frame lives.
🤖 Generated with Claude Code
- 主要言語
- Julia
- スター
- 8
- フォーク
- 14
- 平均マージ
- 8日 8時間
- マージ済み PR(30日)
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
JuliaComputing/StateSelection.jl のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
-
Inlined linear SCC of three unknowns: the run-time solve dominates the cost of the right-hand sideオープン
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
JuliaComputing/StateSelection.jl#173 · コメント 3 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
JuliaComputing/StateSelection.jl#172 · コメント 1 件 ·
-
State-machine query operators in ModelingToolkitTearing throw UndefVarError for wrap対応中かも @baggepinnen が 14 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
-
`maybe_zeros` check does not look inside a division, so tearing divides by a parameter expression that is zero (NaN in initialization)対応中かも @mwhincup が 18 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
JuliaComputing/StateSelection.jl#166 · コメント 1 件 ·
JuliaComputing/StateSelection.jl の issue をすべて見る
似ている issue
-
`ShallowWaterModel` allocates ~9 KiB per grid point per RK3 stage on the CPU対応中かも @ali-ramadhan が今日担当しました。 オープンperformance 🏍️
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
CliMA/Oceananigans.jl#6421 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
JuliaQUBO/QUBOLib.jl#105 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
NCAR/musica#1118 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
`AMSGrad` state starts at `epsilon` instead of zero, so zero gradients move parameters and small gradients are damped対応中かも @parth-patel010 が 1 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
FluxML/Optimisers.jl#247 · コメント 1 件 ·
-
README should say that row and column order must match対応中かも @SAUMYARSH が 1 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 84/100