[meta2meta]

Rackauckas has done a lot of work to create the whole scientific machine learning (SciML) ecosystem (with collaborators).

Symbolics.jl is the new step to a universal CAS tool in Julia to bridge the gap between symbolic manipulation and numerical computation

It is especially useful as a foundation for equation-based simulation package ModelingToolkit.jl. In the foreseeable future, I expect ModelingToolkit.jl can be comparable with the Modelica ecosystem to provide fast, accurate modeling and simulation capability and easy integration with machine learning methods for Julia ecosystem, which is crucial for engineering application and scientific research.

[ChrisRackauckas]

Thanks! The tutorials on the Modelica-like features of ModelingToolkit.jl are just starting to roll out. For example: https://mtk.sciml.ai/dev/tutorials/acausal_components/ . Indeed, there's a lot to do in this space, but we already have some pretty big improvements that we'll start writing down and share (hopefully) at JuliaCon 2021!

[vsskanth]

Hi Chris, I am a very heavy Modelica user and having an equivalent system in Julia is very welcome. Using Sciml's solvers in our models would be a killer feature. Obviously, I am tempted to contrast ModelingToolkit.jl with Modelica and I have some questions, if you don't mind:

Could you elaborate on the design choice to model components as functions as opposed to objects ? functions seem compose well from your example but what about initial conditions and type safety ? In Modelica each component is an object where you can specify initial conditions inside each of them with constraints and can eventually make a big system, and if it compiles you can be reasonably confident you aren't mismatching units, missing outputs etc.

Do you have any plans for graphical representation ? Some of the systems I work on in Motorsports are absolutely massive with 150k equations, and having a diagram to see the connections are really helpful. An auto generated one from code would be more than good enough.

How do you handle FFI and interaction with other Julia objects inside ModelingToolkit.jl since it requires symbolic reduction ?

The FMI standard is a very popular export standard for these models. Any plans to support it here ?

I understand these are early days and I am very excited to know there's more on the pipeline. Thanks for your contribution.

[ChrisRackauckas]

Most of the answers to this will be in a big JuliaCon talk this summer. But I'll give a few hints.

>Could you elaborate on the design choice to model components as functions as opposed to objects ? functions seem compose well from your example but what about initial conditions and type safety ? In Modelica each component is an object where you can specify initial conditions inside each of them with constraints and can eventually make a big system, and if it compiles you can be reasonably confident you aren't mismatching units, missing outputs etc.

There's things for type verification and all of that. The decision comes from how it interacts with the compiler. You can easily redefine functions and create them on the fly, less so for structs. That turns out to make it easier to do features like inheritance easily in a functional workflow. Symbolic computing seems to work very well in this setup.

>Do you have any plans for graphical representation ? Some of the systems I work on in Motorsports are absolutely massive with 150k equations, and having a diagram to see the connections are really helpful. An auto generated one from code would be more than good enough.

Somewhat. Auto-generated ones from code already exist in the Catalyst.jl extension library (https://catalyst.sciml.ai/dev/). That kind of graphing will get added to MTK: we just added the dependency graph tooling to allow it to happen, so it's just waiting for someone to care.

A full GUI? There's stuff we're thinking about. More at JuliaCon.

>How do you handle FFI and interaction with other Julia objects inside ModelingToolkit.jl since it requires symbolic reduction ?

All of the functions are Julia functions, and you can easily extend the system by registering new Julia functions to be "nodes" that are not traced. See https://symbolics.juliasymbolics.org/dev/manual/functions/#R... . So if you do `f(x,y) = 2x^2 + y`, then it will eagerly expand f in your equations. If you do `@register f` (and optionally add derivative rules), then it'll keep it as a node in the graph and put its function calls into the generated code. This is how we're doing FFI for media libraries in a new HVAC model we're building.

>The FMI standard is a very popular export standard for these models. Any plans to support it here ?

There is a way to read in FMI that will be explained much more at JuliaCon, with some details probably shared earlier. It's somewhat complex so I'll just wait till the demos are together, but yes we have examples with FMU inputs already working.

[vsskanth]

Thank you

[meta2meta]

Thank you for your hard work on SciML ecosystem and community, Rackauckas!

The new Modelica-like usage of ModelingToolkit.jl is really a game changer for acasual DAE system simulation in Julia. It makes composable hierarchical component-based simulation of large and complex system possible with pure Julia.

Based on full featured dynamic simulation capability and machine learning ecosystem (Flux.jl etc), Julia will be a perfect choice for reinforcenment learning research, where simulation and training process can all be implemented in pure Julia with promising performance. It delivers the promise of "solve two language problem" of Julia language.