| 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. |