Yingbo Ma

```julia julia> solve(sense_prob,save_everystep=false) retcode: Success Interpolation: 1st order linear t: 2-element Vector{Float64}: 0.0 1.0 u: 2-element Vector{Vector{Float64}}: [0.5435269377237694, 0.5150956772555779, 0.501326117349611, 0.5890160312636273, 0.572724604965598, 0.595889016206594, 0.5572862102374384, 0.5665907426421062, 0.5349023180669545, 0.5002292722210575 … 0.0, 0.0,...

Num isn't in a lightweight package now, but we can move it.

I don't actually like that. It's very handy to write ```julia function foo(args...; kwargs...) something_else(;kwargs...) prob = ODEProblem(...; kwargs...) solve(prob; kwargs...) ... ``` and leave which kwarg to apply to...

Or default `verbose_interfacecheck = true`

You are computing the interpolant's residual, not the solution residual. They are not the same.

> and going to AutoTsit5(Rosenbrock23(chunk_size=1)) reduces the compile time down to the same as AutoTsit5(Rosenbrock23(autodiff=false)) without causing a runtime difference on this problem. The compile time is probably not accurate,...

Just to clarify, writing ```julia @parameters P(t) Q(t) ``` is wrong. It should be `@variables`. We could have better error messages though.

You can always mark a variable as `irreducible`, e.g. `@variables x [irreducible=true]`

It's not related to input/outputs. It's just the observed function generation isn't robust. I recommend to use `ODEProblem` when you encounter issues with the `ODAEProblem`.

Thanks for providing this example! Implementing dynamic state selection is planned. This is a rather hard example. Do you know how do Dymola/OpenModelica handle this?