[slack] <chrisrackauckas> that will need an issue
[slack] <chrisrackauckas> algorithm dependent
[slack] <chrisrackauckas> it's something computed as part of the ODE solver, so it's not a parameter
[slack] <chrisrackauckas> it's a local error estimate
[slack] <Wei> Thanks. For a SDEproblem, is it possible that if I set a larger
g , the solver need more iterations and smaller dt to meet the abstol and reltol requirement? It means for the same abstol and reltol , the larger of g , the increasing of iterations and smaller adaptive dt ?
[slack] <chrisrackauckas> yes
[slack] <chrisrackauckas> that's quite common
[slack] <Wei> Ok, I got it. I don't know before. But I realized when I increasing the
g value and keeping the other same, the solver needs more time to return a result.
[slack] <Wei> Ok, I got it. Thanks.
[slack] <chrisrackauckas> it should
[slack] <simeondavidschaub99> The following example doesn't:
```using ModelingToolkit
@variables t x(t)
@derivatives ∂ₜ'~t
L = .5 ∂ₜ(x)^2 - .5 x^2
euler_lagrange(L, x) = expand_derivatives(Differential(x)(L) - ∂ₜ(Differential(∂ₜ(x))(L)))
julia> euler_lagrange(L, x)
derivative(0.5 derivative(x(t), t) ^ 2 + -0.5 x(t) ^ 2, x(t)) + -1 derivative(derivative(0.5 derivative(x(t), t) ^ 2 + -0.5 * x(t) ^ 2, derivative(x(t), t)), t)```
[slack] <chrisrackauckas> is that latest master?
[slack] <simeondavidschaub99> Yes:
``(@v1.5) pkg> st ModelingToolkit
Status~/.julia/environments/v1.5/Project.toml[961ee093] ModelingToolkit v3.13.0https://github.com/SciML/ModelingToolkit.jl.git#master````
[slack] <simeondavidschaub99> Just checked out the latest master
[slack] <Adam Gerlach> @AlCap23 In case you haven't seen this "Forecasting Sequential Data Using Consistent Koopman Autoencoders" may interest you. Includes Python code https://github.com/erichson/koopmanAE
[slack] <chrisrackauckas> I think @shashi fixed that
[slack] <chrisrackauckas> hashing operations is good
[slack] <chrisrackauckas> hashing variables is weird IIRC
[slack] <isaacsas> That's the opposite of my experience.
[slack] <shashi> yeah they should be safe in dicts
[slack] <chrisrackauckas> we have a hash defined for operations and it's the one that's tested?
[slack] <isaacsas> OK, interesting. I think all the MT code I've used with
Dicts used Variables (because previously I had issues with Operations). (I'm still trying to figure out this issetequal not working issue, for which it was suggested that maybe the problem is not having hash defined, but I guess it is something else.)
[slack] <isaacsas> Good to know that should be safe to do going forward at least.
[slack] <chrisrackauckas> I think so
[slack] <chrisrackauckas> the DEBio docs probably are worth a few pages, at least for tutorials and such, right?
[slack] <chrisrackauckas> JumpSystem and all of that is MTK, but I think ReactionSystem and the DSL for ReactionSystem might make sense as what Cataylst is?
[slack] <chrisrackauckas> I think that would make more sense then double docs for ReactionSystem
[slack] <isaacsas> It is a bit weird to have some stuff in MT and some in DEBio
[slack] <chrisrackauckas> I thought the split was, abstract systems in MTK
[slack] <chrisrackauckas> I think instead it's, abstract systems for symbolic numerics in MTK, and abstract systems for domains in a domain modeling package
[slack] <chrisrackauckas> so ODESystem MTK, JumpSystem MTK, ReactionSystem is it's own whole world