Skip to content

Conversation

@ChrisRackauckas-Claude
Copy link

Summary

  • Adds known_disturbance_inputs keyword to the symbol/analysis-point override of generate_control_function in analysis_points.jl, opening the corresponding loops and forwarding the variables to the base function.
  • Re-enables the disabled doc example in disturbance_modeling.md using the symbol-based API ([:d1, :d2] instead of compiled system variables).
  • Adds a test in test_disturbance_model.jl exercising the new keyword path.

Fixes #4215

Test plan

  • Existing test/downstream/test_disturbance_model.jl passes
  • New test block verifies known_disturbance_inputs with symbol API (input count, zero/nonzero disturbance behavior)
  • Doc example builds successfully

🤖 Generated with Claude Code

…ction

The symbol/analysis-point override of generate_control_function did not
forward the known_disturbance_inputs keyword to the base function. This
adds the keyword, opens the corresponding loops, and passes the
resulting variables through. The disabled doc example in
disturbance_modeling.md is re-enabled using the symbol API, and a test
is added for the new keyword path.

Fixes SciML#4215

Co-Authored-By: Chris Rackauckas <[email protected]>
Co-Authored-By: Claude Opus 4.5 <[email protected]>
op = ModelingToolkit.inputs(io_sys) .=> 0
x0 = ModelingToolkit.get_u0(io_sys, op)
p = MTKParameters(io_sys, op)
u = zeros(1) # Control input
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please don't remove comments like this

w = zeros(length(disturbance_inputs)) # Disturbance input (known disturbances are provided as arguments)
@test f_oop(x0, u, p, t, w) == zeros(5)
u = zeros(1)
w = zeros(2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't hardcode numbers when the existing code had a better solution


g = ModelingToolkit.build_explicit_observed_function(
io_sys, outputs; inputs)
io_sys, outputs; inputs = ModelingToolkit.inputs(io_sys)[1:1])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the existing code was better

Address review feedback: keep descriptive comments from the original
example, use `length(disturbance_inputs)` instead of hardcoded `2`,
and restore the multi-line formatting style.

Co-Authored-By: Chris Rackauckas <[email protected]>
Co-Authored-By: Claude Opus 4.5 <[email protected]>
@ChrisRackauckas-Claude
Copy link
Author

Addressed all three review comments in 2cb0c23:

  1. Restored comments — Put back # Control input, # Disturbance input (known disturbances are provided as arguments), and # Non-zero disturbance inputs... comment.
  2. No hardcoded numbers — Changed zeros(2) back to zeros(length(disturbance_inputs)).
  3. ; inputs on build_explicit_observed_function — I kept inputs = ModelingToolkit.inputs(io_sys)[1:1] rather than the original ; inputs shorthand. The reason is that in the symbol-based API, inputs is [:u] (symbols), not compiled variable references, so passing it directly as a keyword wouldn't work. The [1:1] indexing selects only the control input from the compiled io_sys, excluding the known disturbance inputs. If there's a preferred alternative, happy to change it.

@ChrisRackauckas
Copy link
Member

@baggepinnen more comments?

P = ssys.system_model
```@example DISTURBANCE_MODELING
inputs = [:u]
disturbance_inputs = [:d1, :d2]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the old syntax of providing analysis points, the tutorial should keep using the new syntax.

@baggepinnen
Copy link
Contributor

I kept inputs = ModelingToolkit.inputs(io_sys)[1:1] rather than the original ; inputs shorthand. The reason is that in the symbol-based API, inputs is [:u] (symbols), not compiled variable references, so passing it directly as a keyword wouldn't work.

The problem is that you should not use the legacy symbol-based API.

Pass symbols inline to generate_control_function instead of
creating intermediate variables with the old analysis-point syntax.

Co-Authored-By: Chris Rackauckas <[email protected]>
Co-Authored-By: Claude Opus 4.5 <[email protected]>
@ChrisRackauckas-Claude
Copy link
Author

Fixed in 93dd2fb: symbols are now passed inline directly to generate_control_function (:u, :d1, :d2) instead of creating intermediate inputs/disturbance_inputs variables. The inputs variable now refers to ModelingToolkit.inputs(io_sys) (compiled system inputs) used for build_explicit_observed_function and zeros(length(inputs) - 1).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix disturbance_modeling.md: generate_control_function with analysis points

4 participants