Julia at the 2021 Modelica Conference
GeneralJuliaModelicaMechanomy develops physical systems models in Modelica, with Julia increasingly providing the pre- and post-simulation calculation and analysis (in place of Matlab or Python). We do the simple math and basic checks in Julia's fast and responsive environment in order to justify and focus model development in Modelica.
Coming into the 2021 Modelica conference, then, I was particularly interested to see a dedicated Julia session, one that I hoped would explain the relationship between these languages and show some examples of how the communities communities were benefitting each other. Let me sketch here what I think is emerging and where we're going to be putting some resources.
Modia & ModelingToolkit
The conference continued to dance around the question of how acausal Modelica models might be included in or at least run from Julia's scripting environment. I'll try to briefly describe the issue, but it's necessarily ill-defined and softly political. In emerging languages and voluntary communities, participants' good will motivates them to collaborate and produce compatible contributions, whereas more mature ecosystems tend to negotiate new features and improvements through deliberative processess like standards and steering committees. This necessarily limits coordination in favor of variety, permitting a vibrant, try-everything attitude while prolonging user questions of where to focus application development efforts.
One big focus from the Julia world is on the Modeling Toolkit (MTK), a set of packages that enable the modular, symbolic construction of partial/ordinary/etc differential equations into system models, their transformation between various forms, and their numerical solution via a leading number of differential equation algorithms. It uses some of the best ideas of the Julia language to deliver exceptional performance in a very easy to use environment, at least when it comes to differential equations packages. This performance and solver variety makes MTK an attractive basis for modeling physical systems, but so far MTK has not occasioned modeling libraries designed in familiar physics-based topologies.
This matters because while the original strength of Modelica was its acausal language and fast solvers, strengths that earned it a strong place in industry, today it has an inertia that will be hard to overcome directly. Julia and MTK improve on basically every technical strength, but to become trusted by engineers and industry they will have to tactfully and accurately outreach to the Modelica users to explain and substantiate Julia's capabilities and minimize the pain of switching to a new ecosystem. My off-hand estimate is that 70%[1] of Modelica users are using and developing it in the course of their regular job, which means that they find it productive and useful; at present there is far less value in the Julia community, but the energy is encouraging.
Modia.jl
The session got under way with Dr. Hildig Elmqvist's talk on Modia[pdf]. Hildig is known across the Modelica world as it was his Doctoral work that became the Modelica language and Dymola model simulation tool and has spent his career nurturing the Modelica ecosystem. He remains interested in the fundamental language design, and I'd say sees in Julia the chance to reconceive some of the core choices of Modelica. His and colleagues' work on Modia boils down to the creation of a domain-specific language (DSL) that allows Modelica-like grammar to be written natively in Julia. The Modia package converts this familiar interface into symbolic equations for ModelingToolkit's methods and algorithms. As a DSL, Modia can focus on the language design and leave the many, many details of creating and running the simulation to other packages.
The limitation is that existing Modelica models and libraries need to be translated into Modia, a simple process for simple models and an impossible process for complex ones, as Modelica has accumulated language features that Modia (and MTK) has not or perhaps cannot implement. That said, Modia includes a translator for Modelica models but its limitations are not recounted in the paper and will have to wait for a followup post.
The power of the DSL approach is really shown in sections 5.3 and 5.4 of the paper, where the authors describe use of the Measurements.jl package, which models measurement accuracy, and MonteCarloMeasurements.jl, which facilitates MonteCarlo analysis of complex systems, within a model that is familiar to Modelica users. As said in the paper, "Usage of the Measurements.jl package is attractive because, with very small effort, uncertainties of many variables can be defined and the propagated uncertainties of all variables computed in a reasonably efficient way." And likewise, "Usage of the MonteCarloMeasurements.jl package is attractive because, with very small effort, uncertainties of a reasonable amount of variables with large uncertainties can be defined for a large variety of probability distributions and the nonlinear propagation of these distributions is computed in an efficient way." That is to say that using Measurements.jl or MonteCarloMeasurements.jl allows the user to apply a known parameter distribution or to evaluate the effect of unknown parameter distributions on the model, operations that other Modelica systems are forced to execute in separate or external modules.
OpenModelica.jl
A more modest but more immediately useful effort was John Tinnerholm's presentation of OpenModelica's work rewriting the OpenModelica compiler in Julia, with MTK providing the interface to the equation solvers. As compared to OMJulia.jl, which is a simple Julia scripting frontend to a standard OpenModelica installation, OpenModelica.jl is essentially writing a Julia parser for the MetaModelica specification of the OpenModelica compiler.
The result is a Modelica compiler and simulation runtime that written in (autogenerated) Julia, instead of C, with MTK providing the interface to the differential equation solvers, instead of linking to their C binaries directly. This project is narrowly designed to allow Modelica users to run Modelica models in a Julia ecosystem, an approach that should allow maximum usage of existing Modelica resources, while gaining the speed and variety of MTK's solvers, and returning simulation data in Julia datatypes for subsequent analysis.
ModelingToolkit & JuliaSIM
Whereas the prior projects are directly addressed to Modelica users, Chris Rackauckas' technical talk, Composing Modeling and Simulation with Machine Learning in Julia[pdf] focused on Julia Computing's work enabling faster system designs via approximate system models, with no particular emphasis on Modelica. The talk had two aims: describe the continuous-time echo-state network (CTESN) approach to model approximation, and introduce JuliaSim, a cloud-computing product that features trained surrogates for a variety of models in a cloud environment facilitating immediate commissioning of cloud resources to simulate models in parallel.
CTESN's are an interesting way to solve one of the core challenges in physical system modeling, that of stiff systems which have events that occur at vastly different time scales (eg a microsecond impulse separated by weeks) or experience effects of greatly differing magnitude (eg a solenoid valve controlling a large hydraulic flow). Employing this approach on a building HVAC simulation, where an individual heater may be on for short bursts over the course of a year, the paper demonstrated large decreases in simulation time with very small reductions in accuracy; ie the CTESN approximation of the actual system equations is valid and useful.
Takeaways
The JuliaSim talk didn't really acknowledge or address the topic of Modelica model solving in Julia like the Modia and OpenModelica talks, a disappointing omission. One explanation is that the JuliaSim folks have come to the conclusion that the modeling and simulation of real, physical systems all but requires a massively parallel approach, with the implication that composing and running simulations on individual workstations is an inherently-limited activity.
Chris has sort-of said this, in response to a question on whether there will be a Modelica Standard Library for MTK:
The JuliaSim component library is a cloud computing product, and its curated model library will not be FOSS [free and open-source]. However, it is built using a lot of open source tools, and this tooling (ModelingToolkit.jl, Symbolics.jl, etc.) will continue to be open source. This includes a lot of model importers. For example, CellMLToolkit.jl, the work going on with SBML readers, etc. will continue to be available. And then there's a bunch of domain-specific academic component libraries in power systems, neuroscience models, etc. which are being built as open source.
With these tools we are scouring all of the academic and industry work we can find to generate a model library where everything is already converted to documentation Julia packages and a distribution network for handling the thousands of models, along with pre-trained machine learning accelerated versions of the models. That is JuliaSim, and of course that then becomes of a product given the compute and manpower required to maintain such a library, and hopefully that provides a value to the industry users who tend to be most in need of the pre-made models. That said, this does not preclude other standard libraries popping up, even in SciML, for specific domains and uses and all of that. In fact, we encourage the larger community to keep building open tools around the open tools.
If this is the argument, well this would have made a very interesting keynote. If that isn't the argument, then we'll just have to wait for the direction of these projects to become more clear. I do think the industry players are quite aware of what they need and are giving feedback (and funding) to all involved.
I am not too familiar with MTK but understand that it currently lacks the ability to model hybrid systems, those containing flow logic like for(), if(), when(), etc. This is a significant limitation by itself, but it was not mentioned by any of the talks as preventing general applicability, sounding more like a temporary impediment.
With all of that said, I'm looking forward to testing OpenModelica.jl and Modia.jl and watching their progress. I also need to do a deeper dive through MTK and to understand how its modeling approach and Julia's multiple-dispatch design may enable more flexible system models. One of the great possible benefits of moving to MTK for compiling and simulation is the chance to debug models more thoroughly, especially as failures in model translation are hard to connect to the originating modeling error.
Finally, though it was not a focus of the talks, Julia's git-based package system is really great; I'm hopeful OpenModelica's upcoming package manager
Comments, thoughts? Reply on twitter or email
[1]: Seriously off-hand: 70% feels right, but I would love for anyone with the real number to send it my way.
— Ben Conrad