Causal.jl VS DifferentialEquations.jl

The thing to watch in the space of Simulink/Modelica is https://github.com/SciML/ModelingToolkit.jl . It's an acausal modeling system similar to Modelica (though extended to things like SDEs, PDEs, and nonlinear optimization), and has a standard library (https://github.com/SciML/ModelingToolkitStandardLibrary.jl) similar to the MSL. There's still a lot to do, but it's pretty functional at this point. The two other projects to watch are FunctionalModels.jl (https://github.com/tshort/FunctionalModels.jl, which is the renamed Sims.jl), which is built using ModelingToolkit.jl and puts a more functional interface on it. Then there's Modia.jl (https://github.com/ModiaSim/Modia.jl) which had a complete rewrite not too long ago, and in its new form it's fairly similar to ModelingToolkit.jl and the differences are more in the details. For causal modeling similar to Simulink, there's Causal.jl (https://github.com/zekeriyasari/Causal.jl) which is fairly feature-complete, though I think a lot of people these days are going towards acausal modeling instead so flipping Simulink -> acausal, and in that transition picking up Julia, is what I think is the most likely direction (and given MTK has gotten 40,000 downloads in the last year, I think there's good data backing it up).

And quick mention to bring it back to the main thread here, the DataDrivenDiffEq symbolic regression API gives back Symbolics.jl/ModelingToolkit.jl objects, meaning that the learned equations can be put directly into the simulation tools or composed with other physical models. We're really trying to marry this process modeling and engineering world with these "newer" AI tools.

ModelingToolkit is not equivalent to Simulink. Simulink is a causal modeling framework with a code-based underpinning. The closest to Simulnik would actually be Causal.jl, which is a really nice package in its own right, quite fast, and has a really expansive feature-set. For causal modeling in the form of Simulink, it is definitely a cool package to look into.

This lists some of its unique abilities:

https://docs.sciml.ai/DiffEqDocs/stable/

The routines are sufficiently generic, with regard to Julia’s type system, to allow the solvers to automatically compose with other packages and to seamlessly use types other than Numbers. For example, instead of handling just functions Number→Number, you can define your ODE in terms of quantities with physical dimensions, uncertainties, quaternions, etc., and it will just work (for example, propagating uncertainties correctly to the solution¹). Recent developments involve research into the automated selection of solution routines based on the properties of the ODE, something that seems really next-level to me.

[1] https://lwn.net/Articles/834571/

https://github.com/SciML/DifferentialEquations.jl/issues/786. As you could see from the tweet, it's now at 0.1 seconds. That has been within one year.

Also, if you take a look at a tutorial, say the tutorial video from 2018,

It's not faith, and it's not all from Julia itself. https://github.com/SciML/DifferentialEquations.jl/issues/785 should reduce compile times of what OP mentioned for example.

Let's even put raw numbers to it. DifferentialEquations.jl usage has seen compile times drop from 22 seconds to 3 seconds over the last few months.

https://github.com/SciML/DifferentialEquations.jl/issues/786

https://github.com/SciML/DifferentialEquations.jl/issues/737 double posted, with the answer here. Please don't do that.