Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hybrid systems behavior #722

Open
YingboMa opened this issue Jun 17, 2024 · 5 comments
Open

Hybrid systems behavior #722

YingboMa opened this issue Jun 17, 2024 · 5 comments

Comments

@YingboMa
Copy link
Member

  • If x is discrete variable or a vector of discrete variables with matching clock and continuous variables, then sol[x] should return at the clock times of the x.
  • If x, y have different discrete clocks (excluding continuous variables), then sol[[x, y]] or sol[f(x, y)] where both x and y occur in the f(x, y) expression should error with incompatible clocks.
  • saveat isa Real in solve(...,; saveat) can only be set such that for all discrete clock time step dt, isinteger(saveat/dt) or isinteger(dt/saveat).
@YingboMa
Copy link
Member Author

To index a clock time exactly, one can use sol(Clock(t, dt)[10], idxs=[x]).

@ChrisRackauckas
Copy link
Member

sol[Hold(x)] should then match sol.t times?

Plot recipes should plot discrete as scatters plus dashed lines

@YingboMa
Copy link
Member Author

Yes

@AayushSabharwal
Copy link
Member

How do we handle sol[x, y] where x is discrete and y is continuous

saveat isa Real in solve(...,; saveat) can only be set such that for all discrete clock time step dt, isinteger(saveat/dt) or isinteger(dt/saveat)

When saveat is an AbstractVector when do we save the clocks? Only at coinciding times?

To index a clock time exactly, one can use sol(Clock(t, dt)[10], idxs=[x]).

Why not just sol[x, 10]? This syntax is unnecessarily verbose, and doesn't allow leveraging getu. Implementing the above syntax would also require pulling Clock down into SII/SciMLBase which is unnecessary.

sol[Hold(x)] should then match sol.t times?

Is there any standardization whether x will be a parameter or Hold(x)? Because this gives different semantics to sol[Hold(x)] and sol[x]. From SII's perspective, Hold(x) and x are identical (they have the same index) but one is indexed at the continuous timeseries, and the other in the discrete timeseries.

Also, since MTK doesn't support hybrid systems, does MTKParameters need to have a complicated discrete partition? It's only ever going to store the callback parameters. For these callback parameters, should they have the same semantics as discrete variables, or should they have an implicit hold?

While all of the proposed changes are possible, they're technically breaking for SII. This wouldn't be a problem if RAT didn't also have a release with the current implementation of discrete save, since it means that part of the API can't change or else old RAT with new SII will error.

@YingboMa
Copy link
Member Author

YingboMa commented Jun 17, 2024

Why not just sol[x, 10]? This syntax is unnecessarily verbose, and doesn't allow leveraging getu. Implementing the above syntax would also require pulling Clock down into SII/SciMLBase which is unnecessary.

Because sol(Clock(t, dt)[10], idxs=z) still works if z is a continuous variable.

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

No branches or pull requests

3 participants