-
Notifications
You must be signed in to change notification settings - Fork 39
2018 05 09 WP1.2 BOPTEST Toolchain Working Group
Continuation from Meeting 1.
- Recap of Last Meeting
- (If possible) Overwrite Block by PNNL
- Software Stack and Architecture
- Testcase Prototype by LBNL
- Requirements Discussion
- Documentation
Topic: BOPTEST Toolchain
Time: May 9, 2018 8:00 AM Pacific Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://lbnl.zoom.us/j/440752361
Or iPhone one-tap : US: +16699006833,,440752361# or +16465588656,,440752361# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 558 8656 Meeting ID: 440 752 361 International numbers available: https://zoom.us/u/b466HOsEv
- David Blum,
- Iago Cupeiro
- Krzysztof Arendt
- Filip Jorissen
- Sen Huang
- Javier Arroyo
- Lisa Rivalin
- Roel De Coninck
-
Edit to last meeting's minutes: All low-level control signals should be exposed by emulator developer and to the extent possible, default control signals should be put in place by emulator developer.
-
Sen presented development of signal override block using tcp socket exchange.
- Motivation of work was Voltron application, but signal driver could be exchanged for BOPTEST implementation.
- Implemented with switch between u1[] and u2[], priorities as in BACnet, highest priority given to valid override signal.
- Can embed block at any level of model hierarchy, thereby eliminating need for input signal propagation to high-level model.
- Two concerns by Filip: 1) Computation time: python process has to be called each time and 2) Time synchronization with MPC. 1) can be mitigated by implementation of block in C and 2) can be mitigated by a simulation control process.
- One concern by Krzysztof: implementation may already be too advanced since we want to keep writing a signal, i.e. we do not need the functionality to start/stop writing a control signal. This functionality is allowed by block as developed, as a user need only write a valid signal to the block's socket.
-
Dave presented development of prototype testcase implementation with model, test control, and rest api scripts packaged into Docker container along with Ubuntu computing environment and required software packages Python 2.7 and JModelica/pyfmi. Docker container deployed to localhost port of host machine. Demonstrated simple test model simulation with P controller and reporting of energy and max discomfort KPIs. Further discussions/conclusions:
- Create modelica template / standardized interface to generalize test case control script and add any required blocks for KPI calculation.
- JModelica pyfmi FMU simulation interface can be used.
- Solver options should probably be set by the emulator developer.
- Communication interval should be available to be set by end user. Number of communication points for calculation of KPI could be standardized.
- Dependencies such as weather data have to be supported (corresponding files have to be included into docker).
- Proposal to use perfect weather (and internal load) predictions now since it is hard to get or make realistic weather predictions.
-
Development requirements document started to summarize and formalize these conclusions.
- Sen and Dave to discuss docker implementation further and integrate socket communication
- Dave to work on putting prototype code on github repo (it has been posted here: https://github.com/ibpsa/project1-boptest)
- Filip to work on Modelica model template