Protocol Telecon 2015-10-07

[PRemmen]

Date: 07.10.2015 17:00 CET

Participants:

• Tobias Maile
• Jun Cao
• Reinhard Wimmer
• Matthis Thorade
• Peter Remmen

These are some points I took away from our discussion + a comment from my side. Please feel free to add/edit something or to comment my statement.

Discussion about what should be exposed to PythonAPI:

• Question from Tobias: is the structure of StaticAPI in #68 (https://github.com/EnEff-BIM/EnEffBIM-Framework/tree/issue68_StaticAPIv2/Generic_API/StaticAPI_0.0.1) sufficient to deal with Modelica Code Generation? Answer: Yes, for printing out mapped information, this StaticAPI structure/information is sufficient. To show/add/edit information of the SimModel/SimXML itself, these information are not sufficient. Therefore acces to SimXML Data needs to be provided in both directions (getter / setter). However, first the focus is on providing the user mapped data.
• Jun is currently working on providing the SimModel Binding Framework he did in C++ to Python using the Boost technology. This includes all SimModel classes. A small technical description how this will look like on Python side is shown in issue #74. The Mapped Objects from the old API (Component and Property) or other new mapped objects could also be passed through the API with Boost.
• Tobias suggests to implement the propsal of the StaticAPI in issue 68 on the C++ side, as these are mapped information and the actual mapping takes place in C++.

Addition/Comment from my side: This is possible, but to create valid Modelica Code all the information that are currently in the StaticAPI have to be in the C++ framework, too. This requires more information (at least) 1. from Mapping Rules (e.g. Connectors of Model object, Controls) and 2. from an analysis of the SimXML (e.g. a: Connections between physical models, b: parent/child realtionships). To 2a: Some of these physical connection we will probably get from the SimXML directly , other connection can be handeld in the Python side (for example the proper connection of radiator and zone), if we have, name and function of the Modelica Connector through the API/MappingRules. If we don't have these information, we need to add these on Python side (which basically means: Library specific model information in Python). I am okay with both options. To 2b: From my understanding parent/child relationships can be created by parsing the refID (see issue74)

Next Meeting on Thursday(?)/Friday(?) 17:00.

Proposed Agenda:

• Show concept of Modelica Connectors/Connections in the Use Cases to synchronize the understanding of needs.
• Make proposals (or decisions?) about what information is taken from where (Mapping Rules, SimXML analysis, Python Processing).
• Talk about Mapping Rule conversion to XML file

[ReinhardWimmer]

Hi, here is a comment from my side for the mapping rules methodology, as an additional Information. The mapping rules are pointer between the SimModel schema and the Modelica libraries in addition to that, transformation algorithms will be defined to translate this information. I will add all parameters, including the definition of the connectors of the inspected components. The mapping rules are not developed for defining physical connections for a Modelica model.

[PRemmen]

The mapping rules are not developed for defining physical connections for a Modelica model.

Agree, this is something for step 2 SimXML analysis.

[thorade]

The following screenshot shows the use case 1.1 in Dymola:

The lines represent a connect equation, when hovering the mouse over the line a popup shows the corresponding connect equation. In this case, it shows connect(flowTemp.y, boiler.T_set).

During symbolic processing, all connect equations will be replaced by a normal equation like: flowTemp.y = boiler.T_set for potential variables and sum(pump.port_b.m_flow, boiler.port_a.m_flow) = 0 for flow variables. Connectors can be created to pass information around between objects; i.e. they are the objects interface to everything outside. Sometimes the best choice for defining objects and their interfaces is obvious, e.g. for fluid loops or for electrical loops, sometimes there is no best choice, e.g. for the connection between a wall object and an airvolume object.