Modelica on the Java Virtual Machine Christoph Höger Technische Universität Berlin, Germany, [email protected] Abstract First, Modelica allows for the easy exchange of mod- Modelica has seen a steady growth of adaption in industry els in forms of libraries. Those libraries are not developed and research. Yet, most of the currently available tools by a tool vendor and tested and shipped with a specific follow the same technological path: A Modelica model is implementation of the language. They rather depend (ide- usually interpreted into a system of equations which is then ally) only on the language’s specification and are platform- compiled into e.g. C. independent. When a Modelica model shall be simulated, In this work, we demonstrate how a compiler can trans- it is first instantiated (or elaborated). During this process, late Modelica models into Java classes. Those Java classes all the equations that make up the final mathematical model can be evaluated into a system of equations which can be are generated. solved directly on the JVM. A Modelica library is thus basically a collection of more Implementing this tool yields some interesting prob- or less sophisticated methods to create a mathematical lems. Among these are the representation of polymorphic model. In that sense it is comparable to any other library data, runtime-causalisation and equation optimization and of software. And as for any other computer-language it Modelica’s modification system. All those problems can be becomes important for Modelica’s library-developers that solved efficiently on the JVM. their models behave correctly when being instantiated by a client (i.e. that they do not cause the model instantiation to Keywords Modelica, separate compilation, Java fail in some situations). Since Modelica is a statically-typed language, this ques- 1. Introduction tion can, in theory, be answered by checking that any model conforms to its interface. Unfortunately, there is no formal Modelica [1] is an open, standardized language for the algorithmic specification of the model instantiation process description of hybrid systems of differential and alge- for Modelica. Instead, every tool provides its own, slightly braic equations. It brings well-known features from object- different interpretation of the specification. Therefore a ac- oriented languages (like hierarchic composition, inheri- tual useful typecheck would have to assume a certain exe- tance and encapsulation) into the domain of multi-physics cution model. Hence, any safety assumption is only valid modeling. Our focus is the implementation of Modelica. In for a given interpretation of the Modelica specification. this work, we present a prototypical extension of modim The second problem follows directly from the usage of [10] that allows us to compile Modelica to the Java Virtual libraries. Naturally, libraries tend to offer more features Machine. than actually required for a single application. From the The rest of the paper is organized as follows: First, we modelers perspective this may lead to unexpected large sys- will motivate the need for a Modelica Compiler and the tems of equations. A simple pendulum, for example might JVM as its target platform. Afterwards, we show some be modeled by using the Modelica Multibody library as details of the translation and the runtime system. Finally well as by a few equations from the textbook. Naturally, the we will demonstrate how our prototype performs in model Multibody approach is much more generic, since it might instantiation and simulation. easily be adapted to (and used in) more complex mechani- cal systems. Such systems require the a fast model instan- 2. Compiling Modelica tiation since otherwise instantiation time might exceed the actual simulation. In fact it may happen that model engi- As Modelica’s adoption in Industry and Science grows, neers are slowed down in their development process just three aspects of the language gain more and more attention: because of the model instantiation overhead. Finally, Modelica offers a lot of means to actually com- pute models. Currently, those computations range from ar- 5th International Workshop on Equation-Based Object-Oriented Modeling rays and loops to redeclarations. Yet it is not hard to pre- Languages and Tools. 19 April, 2013, University of Nottingham, UK. dict, that more higher-order modeling features (recursive Copyright is held by the author/owner(s). The proceedings are published by models, models as parameters etc.) will find their way into Linköping University Electronic Press. Proceedings available at: http://www.ep.liu.se/ecp/TBD/ the language. All those features share one common pattern: EOOLT 2013 website: The relation between models and their instances becomes http://www.eoolt.org/2013/ 111 1 : n with very large n. In such a case it may become im- plementations is to generate a model for each mode and possible to actually generate code for each instance due to process it before simulation [15]. practical reasons: As we have shown in [9], such an attempt This method has two drawbacks: yields C-code with a size proportional to the number of model-instances. Therefore for very large n, at least the C- • Every possible mode needs to be known before the Compiler will usually be unable to generate an executable simulation starts. This excludes sophisticated models, model. where some mode depends on the simulation results of another as well as models that contain a large number 2.1 Interpreting vs. Compiling Modelica of possible modes. To all of those problems exists a common solution: Model- • It is impossible to decide which mode will become ica models should be compiled separately. When we think active during a simulation. Therefore it is quite likely of a Modelica model as a method to describe a system of that computational effort is wasted in the translation of equations, it becomes quite obvious that most current tools unneeded modes. (and even the specification) insist on interpreting Modelica. There are a few indicators for this: On the other hand it is quite obvious that a compiler has • Most current tools can be steered into an endless loop to postpone all this processing until the instantiation was during instantiation. A compiler should guarantee ter- successful. Naturally, this means that variable-structure mination (for finite input). processing can be solved by the same machinery as a com- piled model: Once a mode-change occurs, instantiate the • Some implementations will even try to call external new model the same way as the old one and continue functions during instantiation. This may lead to severe simulation. Of course, the efficiency of this transition is problems e.g. in case of cross-compilation. quite important, but technically, compilation and variable- • The language specification defines array-types to in- structure systems share a lot of problems. clude the actual size. This kind of dependent typing naturally requires an interpreter for a type-check. Since 2.3 JVM Modelica does not place any syntactical bounds on the Our compiler requires a much more sophisticated runtime expressions used for array-access, this means that a system than an interpreter: We need to be able to describe fully compliant type-checker must contain a full Mod- and instantiate data-structures and higher-order functions elica interpreter. (part of Modelica since version 3.2). Additionally, our run- In contrast, a compiler does not need to evaluate any time needs to support sophisticated graph-algorithms and Modelica expressions at all 1. Instead, a model or a group some numerical methods. For reasons that are explained of models (called the compilation unit) is translated into a later, we need an accessible intermediate representation of target language. The effect of the model instantiation, i.e. code. Finally our runtime system needs to be fast enough the creation of a system of equations is done by evaluating for real-world applications. the compilation result according to the semantics of the At least two platforms fulfill those requirements: The target language. Java Virtual Machine (JVM, [12]) and the Low Level Vir- This way, we gain multiple benefits: tual Machine (LLVM, [11]). Although both are available for practically every platform we preferred the JVM for the • A compiler can be implemented in a way that guaran- following reasons: tees termination. • The compiled fragments can be reused in different con- • The JVM is tightly integrated with (but not bound to) texts. Java, which is far more productive than C. This makes • The instantiated model is memory-efficient: Only the it easier to implement the necessary runtime system. parts that actually differ between different instances • The JVM is the foundation of a large, active ecosystem. need to be allocated dynamically. Currently there exist hundreds of thousands of free Java 2 It is important to note that to achieve all those benefits, libraries . Currently this is mostly beneficial for the it is not necessary that the compilation targets are portable implementation of the runtime system. But integrating (i.e. compatible between different tools). It suffices that Modelica into this ecosystem might yield additional there is a known way to compile models for a known tool. benefits in the future. • The mainstream JVM implementation, Hotspot is fast. 2.2 Separate Compilation & Variable Structure In fact, a modern Java program may beat an equivalent Besides better language scalability and safety an additional C program in certain areas [3]. point motivates the compilation of models: In case of a • In contrast to LLVM, the JVM already contains a notion variable-structure system, every mode of the system needs of classes and objects which makes it a natural goal for to be processed into a computable form (causalisation, in- the compilation of Modelica. dex reduction etc.). A way to achieve this with current im- 1 It might choose to do so for certain optimizations 2 available e.g.