Modelica on the Java Virtual Machine

Eoolt 2013, Nottingham, UK


Christoph Höger
christoph.hoeger@tu-berlin.de
Technische Universität Berlin
19.04.2013

Agenda

  1. Motivation

    What is this guy talking about?

  2. Compiling Modelica ...

    Difficulties & solutions.

  3. ... and Simulate the Result

    Finally getting a plot.

  4. State of the implementation

    A few facts and figures.

  5. Questions

    Room for your questions.

Motivation

Definition of Compilation

Contrary to popular belief, most current implementations do not compile Modelica.

[Given language semantics ⟦⟧L,S,T] Formally, c is an S-to-T compiler written in L, if for all sources, d ∈ D:

⟦⟦c⟧L source⟧T d = ⟦source⟧S d

N. Jones, Partial Evaluation

Depending on the model, the user might provide e.g. structural parameters:

model A
  parameter Real p; 
  Real x if p > 0;
end A;

What does that mean?

What does that mean?

What does that mean?

Compiling Modelica to Java

General Considerations

When compiling, the target language usually is in some sense simple than the target language:

In case of Modelica (or any other equation based modeling language), we want to translate equations and models into something more "computational".

This talk will focus largely on model instantiation.

Java as target language

Compilation to Java is a novelty for Modelica. This was a (successful) experiment to determine, whether the JVM can actually host Modelica.

Reasons for Java:

In fact, also LLVM or even x86 assembler would be suitable, but require some additional work.

Structural records

Modelica's objects can be used in contexts that expect a smaller record:

  record A
    Real x;
  end A;
	
  record B
    Real x,y;
  end B;
	
  function f
    input A a;
    output Real y = a.x;
  end f;
	
  Real z = f(B(1.0, 0.0)); //legal!
	
  class JB extends MObject {
    Object x, y;
    
    ...
    
    Object get(final String name) {
      switch(name) {
        case "x": return x;
        case "y": return y;
        case default: 
          throw new IllegalArgException(name);      
      }    
    }
  }
	

The success of get can be guaranteed by static typechecking.

Multiple Inheritance

Modelica's classes can inherit from multiple sources:

  record A
    Real x;
  end A;
	
  record B
    Real y;
  end B;	
	
  record C
    extends A;
    extends B;
  end C;
	
  C c(x=1.0, y=0.0);
  Real z = c.y;
	
  class JC extends MObject {
    JA superclass1; 
    JB superclass2; 
	
	  ...
	   
    Object get(final String name) {
      switch(name) {
        case "x": return superclass1.x;
        case "y": return superclass2.y;
        case default: 
          throw new IllegalArgException(name);      
      }    
    }
  } 
	

Fortunately, super classes cannot be redeclared in Modelica!

Redefinitions

Fields of Modelica's classes can be defined on the creation site:

  record A
    Real x;
  end A;
	
  record B
    Real x,y;
  end B;	
	
  record C
    A a(x=1.0));
  end C;
  C c(a = B(x=2.0, y=0.0)));
  Real z = c.x; //2.0
	
  class JC extends MObject {

		 MObject a;    
    
    public JC(MObject ctxt, ...) {
      this.a = (MObject) ctxt.
        getOrEval("a", JA.
          CREATE_NEW.apply(1.0)));   
      ... 
    }
    
    
  } 
	

Every class takes a context parameter (holding all modifications). In case the ctxt does not provide a value, the default constructor is called.

Redefinitions

Type applications are reflected at object level

  record A
    Real x=1.0;
  end A;
	
  record B
    Real x=2.0,y=1.0;
  end B;	
	
  record C
    replaceble record R = A;
    A a;
  end C;
  C c(redeclare record R = B);
  
  Real z = c.x; //2.0
	
  class JC extends MObject {

    MFunction create_a;    
    
    public JC(MObject ctxt, ...) {
    		this.create_a = (MFunction) ctxt.getOrElse("$create_a", JA.CREATE_NEW);
      this.a = create_a.apply();  
      ... 
    }
    
    
  } 
	

Every type is translated into an instantiation function. Type redeclaration is translated into a modification of this function.

Type Evaluation

Modelica contains rather complicated type-expressions:

In particular, there is no specific order of type evaluation specified in Modelica.

Modim evaluates types lazily:

  case class NamedType(name : List[String], 
  		expr : TExp, 
  		context : Either[NamedType, Map[String, Type]], 
  		sort : Sort = Class, 
  		actualParams : Map[String, Type] = Map()) extends Type
  		

Compile Modelica & and Simulate the Result

Nice, but how do you simulate?

Simulation is not the main topic of this talk, but a few hints:

  • Equations are higher-order functions taking an unknown and yielding a real-valued function over time.
  • Currently, composition is just "collect them in a list"
  • Causalisation & Index reduction are handled at startup
  • Every expression is compiled to code and some symbolic informations are kept additionally.
  • Integrators are pure-Java implementations from apache.commons.math3

Facts & Figures

A few facts and figures

Modim (Modelica Incremental Modules) is a toolchain for the separate compilation of Modelica models

Current Modules

Instantiation Performance

model Faculty "recurses n! times"
  constant Integer n;
  
  Faculty[n] faculties(each n = n - 1) 
    if (n > 1);
  
  Real root if n == 1;
end Faculty;

This model is an instantiation stress-test:

Compiled to Java we can instantiate an insane amount of instances:

nvariablesinstancestime
1 1 1 15ms
2 2 3 20ms
3 6 10 1
4 24 41 2ms
5 120 206 10ms
6 720 1237 60ms
7 5040 8660 308ms
8 40320 69281 476ms
9 362880 623530 873ms

Conclusion

Future Work

/

#

Thank you for your attention!

Interested?
https://mlcontrol.uebb.tu-berlin.de/redmine/projects/modim
Questions?