EthanJamesLew / AutoKoopman

AutoKoopman - automated Koopman operator methods for data-driven dynamical systems analysis and control.
GNU General Public License v3.0
53 stars 10 forks source link

Simulation with Resets #35

Open TUMcps opened 1 year ago

TUMcps commented 1 year ago

When we simulate with solve_ivp, are we currently resetting the state after each time-step? Or did I get this wrong. If yes, I think it would be good to have an option reset = "all" / "none" / integer (number of time steps between reset) for solve_ivp so that the user can choose.

EthanJamesLew commented 1 year ago

@TUMcps Idk what reset means. We currently run a simulation between each step and hold the inputs constant (ZOH). Would the idea be to run the simulation at a finer resolution?

TUMcps commented 1 year ago

Instead of mapping the initial state through the observable function and then simulating the linear system, I think we currently map the state again through the observable function after each simulation time step (thats what I meant with resets)

EthanJamesLew commented 1 year ago

Ah yes, this is coming back to me. Yes, we reset "all" in continuous mode because we pass it to an ODE solver that evaluates $\dot{\mathbf x} = f(\mathbf x, \mathbf u)$ instead of ${\mathbf y} = g(\mathbf x, \mathbf u)$.

TUMcps commented 1 year ago

My concern is actually about the discrete time systems: What I was expecting was that we simulate without resets, so $y_0 = g(x_0)$, $y_1 = F(y_0,u_0)$, $y_2 = F(y_1,u_1)$, $y_3 = F(y_2,u_2)$, ....

However, what I think is currently implemented is that the state is reseted to the original space after each time step and mapped through the observable function again: $y_0 = g(x_0)$, $y_1 = F(y_0,u_0) \Rightarrow x_1$, $y_1 = g(x_1)$, $y_2 = F(y_1,u_1) \Rightarrow x_2$, ....