2017 06 28_meeting - lbl-srg/soep GitHub Wiki

Date: June 28, 2017, 10am-11am Pacific Times

The purpose of this meeting is to coordinate the Modelica OS integration for SOEP.

Join from PC, Mac, Linux, iOS or Android: https://lbnl.zoom.us/my/mwetter

Or iPhone one-tap (US Toll): +14086380968,6614042296# or +16465588656,6614042296#

Or Telephone:

Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll) Meeting ID: 661 404 2296 International numbers available: https://lbnl.zoom.us/zoomconference?m=_h5BuJ686mPy3rWEyKf4NROxLaeOV5J8

Kyle suggest to try again to have the room heat balance implemented in E+ in order to reuse that data structure. Michael said that for efficiency, robustness and to implement error control, we require

• the room air heat and mass balance (temperature or enthalpy, humidity and contaminants) to be exposed as an ODE, as we outlined in Spring 2016.
• once we solved the room heat balance implementation, we also need to have an E+ object to which we can couple radiant systems so we can model the fast dynamics in Modelica.

Kyle likes to try the room heat balance refactoring with Mark until the end of this fiscal year.

Michael said for the HVAC integration, either way works, as long as we have have an ODE exposed and can do any time step. The gaps, for both paths, are

1. if the Modelica room model is used, it will require work for

• displacement ventilation,
• shading calculation (calling out to E+)
• moisture buffering in the envelope
• Window model integration (in particular for windows that require bi-directional spectral distribution function)
• better scalability of ODE solvers and faster translation of large envelope models

As a benefit of using the existing Modelica room model, we already have a CFD model that can optionally be used, and we have a cleaner architecture. Other benefits include that simulation can start at any time, can be reinitialized easily for MPC, FDD, for emulators and other use cases etc.

2. if the legacy E+ heat balance is used, it will require work for

• refactoring the room heat/mass balance into an ODE (Edwin and Stuart started, and we have a design and requirements outlined from Spring 2016),
• an efficient coupling of E+ with Modelica, possibly through a dll (we have a specification of the required functions from Spring 2016) rather than the currently used sockets
• an object that allows assigning surface temperatures so that we can couple radiant systems, such as radiant slabs http://simulationresearch.lbl.gov/modelica/releases/v4.0.0/help/Buildings_Fluid_HeatExchangers_RadiantSlabs.html
• exposing control signals such as for windows and lights, because this is much easier, more flexible and standardized if Modelica is used rather than EMS
• exposing output variables that are needed for controls
• ensuring that the CTF time step is adequate (as there is no error control on this time step)

Next is for Amir to see if he wants to authorize Kyle and Mark to work on the legacy room model refactoring.

We discussed how to link Modelica and OS, and went through an example VAV model.

The path forward that we collectively suggested was

• HVAC and control data model will be in Modelica syntax, which is parsed/manipulated, for example through JModelica
• Preconfigured HVAC and control systems will be added to the Buildings library that can be manipulated easily through OS
• A GUI for Modelica authoring that allows switching between graphical and textual representation need to be integrated in OS
• OS will use Modelica model and tunnel through it using JModelica to understands its structure (components, parameters etc.)
• there will be an osm file plus a Modelica file, where the Modelica file contains all the HVAC and control information

1. Amir to decide on whether Kyle and Mark should work on room model refactoring.

1. Amir to check whether minimum viable product go/no-go date is 8/30 (as in LBNL AOP) or 9/15 (as in ORNL AOP).
2. Jianjun to make pull request for scaleable benchmark models.
3. Jianjun to share benchmark with Modelon.
4. Thierry to compile new requirements for FMI-QSS and coordinate with Stuart and Modelon.
5. Kyle to prepare OS measures in order to move forward with how to design OS-Modelica API.
6. Edwin to work on CTF implementation.