co-simulation between detailed building energy performance ... · co-simulation between detailed...

Co-Simulation between detailed building energy performancesimulation and Modelica HVAC component models

Andreas Nicolai1 Anne Paepcke1

1Institut for Building Climatology, Faculty of Architecture, TU Dresden, Germany,[email protected]

AbstractWe discuss the application of the FMI Co-Simulationtechnology to building energy performance simulation,where detailed physical building models are coupledto Modelica-based HVAC component and plant models.First, we describe the generation process of the build-ing FMU from our stand-alone building simulation pro-gram NANDRAD and sketch out internal algorithms forFMI version 2 capabilities. Then, coupling scenariosare described and physical interface conventions are pre-sented. Usability is addressed by automatic generation ofbuilding-model specific adapters and wrappers. The build-ing FMU and plant FMUs are then simulated together us-ing different Co-Simulation master algorithms. Finally,based on simulation results and performance analysis weconclude with recommendations on suitable master algo-rithm options and specific features of suitable buildingFMUs.Keywords: FMI, Co-Simulation, Energy, Building Simula-tion, HVAC System, Physical Interface, Master Algorithm

1 IntroductionBuilding energy performance simulation is a technologyused by planners and building designers in the planningprocess. A typical usage scenario includes evaluation ofdifferent options regarding building envelope construc-tion, HVAC systems and control strategies. Currently,available simulation tools, such as EnergyPlus TRNSYS(Klein et al., 1976; Dols et al., 2014), IDA-ICE (Sahlinet al., 2004) and our own development NANDRAD (Nico-lai and Paepcke, 2012; Paepcke and Nicolai, 2014) (inC/C++) are concepted as stand-alone tools. Modeling andsimulation of integrated modern buildings requires flex-ible plant and equipment models, which are often case-specific. Extending the source code of existing buildingsimulation models is often only possible by original modeldevelopers and also very difficult and time consuming.

Alternatively, Modelica as one example for a model-ing language can be used to express such equipment andcontrol systems. There are a number of libraries provid-ing suitable components for modeling building systems,for example the Annex60-based libraries AixLib, Build-ingSystems, Buildings and Idias (Wetter et al., 2013; Wet-ter, 2009; Nytsch-Geusen et al., 2013; Sahlin et al., 2004)

or the GreenBuilding library1. However, modeling the en-tire building with sufficient physical detail in Modelicaalone is not meaningful for several reasons:

• larger building complexes may involve many zones,constructions, facade elements, thermal storagemembers resulting in thousands of differential equa-tions,

• Modelica code may become huge and may causeproblems with the generic Modelica solvers, evensymbolic analysis may be extremely slow,

• modeling the building in Modelica without suitableBIM-style data import or code generation will notbe possible for realistic buildings, it is too time-consuming and thus too expensive, and

• manual connection of many building componentswith corresponding equipment and control modelsmay be extremely time-consuming and error-prone.

For practical purposes, planners and engineers will notaccept a procedure that involves creation of such com-plex models with current Modelica user interfaces, alone.There are, however, tools under development that as-sist with prototyping Modelica-based building and equip-ment models, for example TEASER2. However, limita-tions with respect to the detail of the building model andsimulation efficiency persist.

1.1 Benefits of Simulation Coupling within theBuilding Energy Simulation Context

The use of stand-alone simulation tools or Modelica-onlybased building modeling may not be a satisfying strategy.Instead, a hybrid approach appears meaningful:

• using existing building simulation software tailoredto the building engineering user group, prefere-ably Building Information Model (BIM) preprocess-ing software packages (DesignBuilder3, BIM-HVAC

1Green City/ SimulationX – Planungstool,http://www.ea-energie.de/de/products/←↩green-city-simulationsbibliothek-2-2

2TEASER - Tool for Energy Analysis and Simulation for EfficientRetrofit, https://github.com/RWTH-EBC/TEASER

3https://www.designbuilder.co.uk

DOI10.3384/ecp1713263

Proceedings of the 12th International Modelica ConferenceMay 15-17, 2017, Prague, Czech Republic

63

tool4, etc.) with database support, graphical repre-sentation of the building, and input error control withautomatic generation of input data to building sim-ulation engines (e.g. IDF-files for EnergyPlus, ornandrad-files for NANDRAD), and

• use of Modelica and suitable libraries by HVACsystem planners to model building equipment(heater/chiller/ventilation systems) and required con-trol strategies.

Joining both models in a coupled simulation will com-bine also the benefits of both modeling approaches. Withthe FMI standard a unified methodology and technical de-scription for coupled simulation is available. With respectto the two described operation modes ModelExchange andCo-Simulation, we prefer the latter variant that allows in-dividual FMUs to use their own dedicated solver engines.However, it can be expected that the Co-Simulation ap-proach and gained flexibility implies a simulation over-head and performance penalty. In the remainder of thearticle we always refer to Co-Simulation according to theFMI standard when discussing coupled simulation.

1.2 Envisioned Usage of Co-SimulationWe envision two suitable scenarios of combining a dedi-cated building energy simulation FMU with one or moreHVAC component FMUs created with Modelica. In thefirst scenario, the user will model the equipment systemin Modelica and import a previously generated buildingFMU into the modeling environment, connect it to theModelica components and run the simulation within theEnvironment (Figure 1).

Alternatively, HVAC component or control models maybe designed with Modelica and than exported by the mod-eling tool into FMUs. These are then combined withthe building FMU and simulated by an alternative Co-Simulation master. This approach allows prefabricationof HVAC component sub-models.

1.3 Co-Simulation RequirementsA central requirement for the application of Co-Simulation is that obtained results are of a similar ac-curacy as if the entire model would be calculated stand-alone. Accuracy shall be defined in this respect such thatthe global error, i.e. the difference between numerical so-lution and true solution is bounded to a defined limit. Inpractice, within each integration step the local error is con-trolled. Every FMU should implement such an error con-trol algorithm to be considered a consistent model.

In the building energy simulation side, this demand re-stricts the choice of suitable simulation tools, for exam-ple, older simulation engines like EnergyPlus and TRN-SYS do not implement such an error testing procedure.Our building simulation models THERAKLES and NAN-DRAD (Nicolai, 2013; Nicolai and Paepcke, 2012) belong

4http://www.building-engineering.de

to a class of modern solvers that use dynamic time stepadjustment schemes based on local error estimates, withthe advantage of maintaining required accuracy while im-proving simulation speed whenever possible (Hindmarshet al., 2005). This is an important feature, since differ-ent building equipment may be active during different an-nual seasons and may enforce different time integrationregimes. For example, heating systems are turned off dur-ing summer, and if air conditioning is not used, simulationcan speed up since no interaction with actively controlledequipment occurs. Simulation time steps typically varybetween 1 second and 30 minutes in annual simulations.

The requirement on error control made for FMUsshould also be fulfilled by the Co-Simulation master,which effectively needs to adjust communication intervalsizes. When separating control and equipment systemsfrom the building’s thermal response in a Co-Simulationscenario, the use of larger communication intervals maycause stability and accuracy problems. Such problems canbe avoided by choosing a sufficiently small time step size.In realistic simulation cases it is generally not possible topredict the allowed maximum of the communication stepsize. Also, using a fixed tiny communcation step size leadsto inacceptable long simulations and would limit the ad-vantage of performance optimized FMU-internal solvers.Therefore, a master algorithm which supports error/sta-bility control and dynamic adjustment of communicationstep sizes is desirable. This, in return, requires FMI Ver-sion 2.0 capabilities of the slaves, in particular the get andset state functionality (FMI, 2014).

Note, that an error control algorithm within a Co-Simulation master will also detect and compensate, by re-ducing communication step size, potential numerical in-stabilities, again leading to excessive and inacceptablesimulation times. Phenomena of instability may growwith increased coupling strength of FMUs interface quan-tities and often arising from the choice of the model inter-face.

2 Choice of the FMU InterfaceThe separation of a complex building energy simulationmodel into subcomponents is not trivial. A natural choicefor separation of the entire model into FMUs may be tokeep the passive building and its physics regarding in-teraction with climate and user loads within the buildingsimulation FMU. All active components such as heating,cooling, ventilation and associated equipment and controlmodels will be in one ore more HVAC-FMUs. In this ar-ticle we use a single FMU with all HVAC equipment andcontrol models written in Modelica.

2.1 Building Simulation FMU Input/OutputVariables

One option for a flexible interface would be to export allrelevant states like temperatures and solar radiation loadsfrom the building simulation FMU, and import calculated

Co-Simulation between detailed building energy performance simulation and Modelica HVAC componentmodels

64 Proceedings of the 12th International Modelica ConferenceMay 15-17, 2017, Prague, Czech Republic

DOI10.3384/ecp1713263

Figure 1. Usage Scenario 1: Building simulation FMU (NANDRAD) imported into Modelica environment (SimulationX)

heating/cooling loads from the HVAC FMUs. This inter-face can be considered a very universal interface, sinceany kind of heating/cooling loads can be modeled and im-ported as energy source to each thermal zone’s energy bal-ance. The interface defines for each thermal zone an ex-port of mean air and operative temperature and input ofconvective and radiative thermal load.

The building simulation FMU includes databases forclimatic loads and user behavior and related equipmentschedules5. Hence, climatic data and schedules are ad-ditionally exported via the FMU interface. This allowsconsistent treatment of climatic input data in building andequipment models. Part of the scheduled user loads arealso hot and cold water demand as well as user-relatedelectric power consumption.

2.2 Convenience Adapters and WrappersThe interface definition allows exporting and importingzonal quantities. Considering typical buildings of morethan hundred conditioned zones, a large number of in-put/output variables need to be connected to the plantFMU. Even if the FMI standard would allow usage of vec-tor variables, the manual connection of exported temper-atures to the various input ports on the plant side wouldnot be expedient and may lead to errors that are difficultto identify and track.

Also, when importing a building simulation FMU intoa Modelica development environment the graphical repre-sentation of the inserted FMU with hundreds of ports isnot suitable for practical use. Therefore, we utilize helpercomponents that assist with mapping native FMU inter-

5Typically, such schedules and databases are part of the buildingmodel definition and will be generated/collected within the BIM pro-cess

face quantities to Modelica library ports and buses.Different helper components are used depending on the

usage scenario:

• When the building FMU is imported into the Mod-elica environment, the FMU is encapsulated intoa Modelica wrapper model, which internally holdsthe FMU and connects to the native FMU interface.On the outside it provides port and bus connectorsmatching the corresponding library interfaces, in ourcase the GreenBuilding climate, electrical and HVACbuses (see Figure 2, we use the HVAC, HotWater andElectrical port of the GreenBuilding library). Thiswrapper is therefore specific to each building6 and tothe interfaced library.

• When the plant model is to be exported from Mod-elica into a stand-alone Co-Simulation FMU, theadapter (Figure 3) is used instead. It provides thesame library-specific connectors as the wrapper, butdoes not connect to the building FMU. Instead, itexports and imports exactly the counterparts of thebuilding FMU interface variables . When exportingthe Modelica model, only these connectors becomepart of the FMU interface. Also, the connector coun-terparts are identically named to the building FMUinterface quantities, which greatly simplifies auto-mated connection between plant and building FMUconnectors7. The graphical annotations of zonal con-

6The native interface of the FMU changes with the number of ther-mal zones, or their IDs, and so does the wrapper component.

7Similarly, when importing a building FMU into a Modelica envi-ronment an automated matching of connectors between FMU and wrap-per/adapter model would be possible. Unfortunately, none of the cur-rently available modeling environments supports such a procedure.

Session 4B: Buildings I

DOI10.3384/ecp1713263


65

nectors with same quantities but different zone refer-ences are arranged on top of each other, thus keepingthe adapter symbol compact.

Figure 3 does not show the actual connector names,but rather a physical description and associated unit(see (Paepcke et al., 2016) for a complete specification).

2.2.1 Adapter/Wrapper Configurations

The use of wrappers/adapters is a compromise betweenflexibility of the building model interface and easy-of-usewithin Modelica environments. The current specificationof our adapter/wrapper Modelica component is special-ized of interfacing all building zones with exactly oneHVAC system model in Modelica. For other situations,the adapter/wrapper models may look different. Yet, theprinciple approach to provide FMU-independent connec-tors for the remainder of the Modelica model appears to bea promising way to avoid connecting to individual FMUinput/output variables directly.

3 Parametrization and Export ofNANDRAD FMUs

3.1 Configuration for FMU ExportWhen NANDRAD is executed as stand-alone building en-ergy simulation model, for example to compute annual en-ergy demand and comfort criteria, it uses a set of inputfiles with the building model (BIM) and database elements(material data, constructions, climatic data, etc.). The in-put data include definitions of all zones and their heatingand cooling requirements, which enables an ideal heatingand cooling load calculation.

When NANDRAD is used as building simulation FMUto simulate a realistic heating/cooling system, all condi-tioned zones need to be connected to the heating cycleor to the electrical grid of the plant model. All zonesthat are part of the interface and import/export variablesare given different usage scenarios, for example, heatingscenario or electrical usage scenario. This information isthen used during export to generate required import/ex-port quantities and also create the internal data structures

GreenBuilding HVAC Port

GreenBuilding HotWater Port

GreenBuilding Electrical Port

Figure 2. Modelica wrapper encapsulates NANDRAD FMUand provides collector ports for climate, HVAC and electricalquantities

that map FMU input/output variables to existing internalvariables. Selecting the usage scenarios and selecting thecorresponding zones is part of the FMU preprocessing.

3.2 Export procedureThe export procedure involves several steps:

• NANDRAD is run as stand-alone simulation to gen-erate auxiliary information needed for parametriza-tion of the HVAC/plant model, for example the heat-ing/cooling design day calculation.

• The NANDRAD solver initialization is used to gen-erate the variable dependency information, which isstored in the modelDescription.xml file.

• The modelDescription.xml is composed (in-cluded data for ModelExchange and Co-Simulationand the FMI v2 functionality).

• All referenced databases are collected. All inputfiles, the pre-compiled NANDRAD dynamic library(with implemented FMI functionality), and addi-tional dependent libraries8 are copied. Finally, theFMU archive is created.

• Modelica wrapper and adapter models (.mo files)are generated individually for the current buildingproject.

• A report including zone naming, dimensions, uniqueIDs and heating/cooling design loads is written to beused during configuration of the HVAC componentmodel, and for automatic Modelica model generationscripts.

During export, compilation of source code is not neces-sary and the model initialization and the design day calcu-lation are usually very fast, except for large buildings withseveral hundred of zones. The auxiliary files are providedseperately from the generated FMU.

8Depending on the target platform, different libraries are copied.Currently, one NANDAD FMU holds only binaries for one platformWin32, Win64, Linux64, Darwin64 at a time.

Temperature [K] Relative Humdity [1] Direct solar radiation [W/m2] Diffuse solar radiation [W/m2] Long wave radiation [W/m2] Air pressure [Pa] Wind direction [Rad]… (4 more components)

Exported climatic data (weather data file content)

Mean air temperature [K] Zone #...Operative temperature [K] Zone #...

Cooling setpoint [K] Zone #...Heating setpoint [K] Zone #...

Convective thermal load [W] Zone #...Radiative thermal load [W] Zone #...

Electrical power consumption [W]

Domestic water setpoint [K] Zone #...Domestic water mass flow [kg/s] Zone #...

Domestic water temperatur [K] Zone #...

GreenBuilding HVAC Port

GreenBuilding HotWater Port

GreenBuilding Electrical Port

Figure 3. NANDRAD adapter provides Modelica collectorports as well as input and output variables identically named asthe building FMU ports



DOI10.3384/ecp1713263

Modeling modern complex integrated buildings willrequire much more data being commonly used by thebuilding simulation model and HVAC system model.Hereby, the procedure of using BIM-data for consistentparametrization of all model components is desirable andan ongoing research issue.

4 NANDRAD FMU Calculation Func-tionality

4.1 State-based model evaluation and time in-tegration in NANDRAD

When the building simulation engine NANDRAD wasdeveloped at the IBK, its design was heavily influencedby the first version of the FMI for ModelExchange stan-dard. The entire physics evaluation is encapsulated withina state-based model object, whose state changes only bymodification of the time point or conservative quantites(solution variables). After spatial discretization of all par-tial differential equations within the building model, alarge sparse system of coupled ordinary differential equa-tions is assembled. The time integration is then performedusing our own integration framework, which incorporatesthe SUNDIALS:CVODE solver (Hindmarsh et al., 2005).Internally, the CVODE integrator is called by the frame-work for each integration step at a time. It selects/pre-dicts a suitable integration time step, performs a modifiedNewton iteration9 and upon convergence or error test fail-ure reduces integration step until an acceptable solution isfound. Note, since integration step sizes are exclusivelydetermined by the integrator engine, synchronization withcommunication intervals needs to be adressed.

Figure 4 illustrates the architecture of the stand-aloneNANDRAD solver. The physical model implementa-tion is encapsulated in a model object which has simi-lar access functions as the ModelExchange specificationsrequire. Therefore, the ModelExchange FMU interfaceimplementation is only a thin layer around our physi-cal model. Our integration framework calls one of thesupported time integration methods in a step-wise man-ner. This core loop, which also signals successful steps(stepCompleted()) and tells the model to write in-terim outputs (writeOutputs()), is partially replacedby the Co-Simulation master.

4.2 Implementation of the doStep functional-ity

When NANDRAD runs as a simulation slave, the time in-tegration is now interrupted at the end of communicationinterval and control is returned to the master. Since in-ternal integration steps may not match interval end, wechoose to limit the internal integration step size so that thecommunication interval is not exceeded. However, this

9Within each Newton iteration the large sparse equation system issolved using a Krylov-subspace method with NANDRAD-specific pre-conditioner.

may lead to situations, wherein the last integration step be-fore end of communication interval is much shorter thanprevious integration steps10.

An alternative to limiting the last integration step wouldbe to allow the integrator to take its natural step size. Inthe case of CVODE, the solution at communication in-terval end could be easily obtained by backward interpo-lation. The CVODE integrator could now be re-startedwith that interpolated solution in the next communicationinterval. However, such a restart would destroy the his-tory within the multi-step BDF method, effectively forcingCVODE to restart integration from first order with verysmall time steps. This approach leads to inacceptable sim-ulation times and cannot be recommended.

4.3 Retrieving and restoring the FMU stateThe aforementioned functionality is sufficient for exe-cuting NANDRAD as FMI for Co-Simulation version 1.However, as soon as the Co-Simulation master is usingan iterative or error controling algorithm, the slaves mustbe repeatedly set back in time (see, for example (Claußet al., 2017)). The master needs to retrieve and restoreeach FMU’s state.

Within NANDRAD the internal state is stored in severalsolver components:

• State of the integrator (time point, state variables andNordsieck history array, counters, control variables)

• State of linear equation system solver, in case of GM-RES only control variables

• state of Jacobian, since with modified Newton algo-rithm it is only infrequently updated

• state of preconditioner (part of Jacobian matrix andin case of ILU preconditioner also the factorized rep-resentation)

• integral model states (integral outputs, state of hys-teresis loops etc.)

The data structures are typically very fragmented. Theserialization implementation within NANDRAD creates acontinuous memory array and then copies all data mem-bers into the array, hereby advancing an insertion pointerafter each copy operation. With the use of C macro def-initions, the entire serialization, deserialization and sizecomputation functionality is only coded once, thus ensur-ing binary compatibility and improving code maintenance(Nicolai and Paepcke, 2016).

Additionally, the ability to serialize the entire state ofmodel and integrator into a continuous memory block en-ables implementation of the fmi2Serialize() andfmi2Deserialize() functions.

10Drastic changes in time step sizes typically lead to invalidation ofJacobian matrix information, with the related overhead of re-composingand factorizing the Jacobian.


DOI10.3384/ecp1713263


67

Integrator Implementation Physical Model ImplementationsetTime(t)

init(model)

step()

t()

solves ODE system of type ydot = f(t,y)

implicit solver with Newton-Raphson iteration

Solver Control System

Implements core integration loop: calls step() function in Integrator, also manages output schedules

control functions

query functions

y0()

t0()

tEnd()

implements physical model equations and the computation of the system function f(t,y)

state of object changes only through calls of control functions

n()

setY(y)

ydot()

yOut(t_out)

stepCompleted(t,y)

writeOutputs(...)

Corresponds to FMI ModelInterface

To be replaced by Co-Simulation Master

Figure 4. Core components of the NANDRAD stand-alone solver.

4.4 Integration of FMU inputs and outputs inthe NANDRAD building model

The physical model of NANDRAD is internally imple-mented by means of interconnected state-based model ob-jects. We allow a single model object calculation to de-pend on other model results. For example, room air bal-ance is encapsulated in a single model object that requestsheating and cooling load as input quantities. In turn, thepower of controlled heating and cooling elements reactson thermal response of the zone. In complete, NANDRADowns several model objects with arbitrary interconnec-tions that form an unstructured graph. Indeed, the statesof all these models must be updated in the correct orderwhenever a solver state change is registered. For this pur-pose we cluster the model graph into nodes with cyclic andsequential connections first and order it afterwards duringinitialization process. As a result, all model objects appearstacked with respect to their evaluation chronology. Thisstrategy guarantees all internal states to be current when-ever an update is necessary because of changes of solverstates or solver time.

This modeling concept can be easily extended to FMUinputs and outputs. In detail, we encapsulate all FMUquantities into an FMU import and an FMU export modelobject. The export model transfers all required outputvariables from the building model towards the FMI. Theimport model caches FMI input quantities, such as heat-ing and cooling loads, and provides them just like calcu-lation results to other internal model objects. This struc-ture enables the model initialization to sort FMU inputsand outputs to the correct position inside the model objectgraph. For evaluation of all models depending on FMU in-put we store the position of the FMU import model objectwithin the graph. In the case of update due to FMU inputchanges only the corresponding dependent nodes of the

model graph are taken into account. This allows a modelevaluation/update with only small computational effort.

To achieve good simulation performance we follow theconcept of lazy evaluation: the call of fmi2SetReal()does not enforce an update of dependent building modelobjects but temporarily fills a data container. Only at thebeginning of each communication step the container val-ues are copied and the model evaluation is triggered. So,during each communication interval the model results aswell as FMU outputs are consistent to the FMU inputs.

5 Application CasesThe procedure of creating and parametrizing building andequipment models and exporting FMUs has been testedwith three application cases of different scales: an officeroom (1 conditioned zone, 383 ODEs in the building sim-ulation part), a family row-house (2 heated zones, 502ODEs in the building FMU) and a large appartment com-plex (178 conditioned zones, 23220 ODEs in the buildingFMU).

In this article we will only look at the first case and dis-cuss the observed behavior with respect to the differentCo-Simulation master algorithms employed. Note, it isgenerally possible to reduce the number of ODEs, whichmostly result from spatial discretization of envelope/inte-rior constructions, by adjusting the grid-generation param-eters. As with most spatial discretization techniques, sucha variation should be complemented by sensitivity studieswhich are beyond the scope of the article. In the test casewe selected medium-fine discretization settings, leading tothe reported number of elements.

5.1 Office Room Model SetupIn this model, the office is represented by four enclosingwall/floor constructions, where internal walls with samebehavior are lumped into one. The only external wall



DOI10.3384/ecp1713263

faces west and contains a large window. The old con-struction is made from massive lime sandstone (simplifiedas single layer construction) with poor thermal insulationproperties. The HVAC system operates with ideal controlfor a heating and cooling demand calculation, dynamicdaily schedules and low setback temperature on weekends.During the week, schedules distinguish between daytimeand nighttime use (occupied/not-occupied). Correspond-ing thermal loads are computed by the plant model andimposed onto the room energy balance. Infiltration is con-sidered with standard settings. Since the heating systemis modeled in an idealistic way. The interaction betweenroom response and heating system is very strong, leadingto stiffly coupled system.

5.2 Reference Solution and Verification Proce-dure

Initially, for this problem a Modelica-only solution ex-isted, yet with simplified building representation. Theresults of this calculation can be used for plausibilitytests (Figure 5).

A correct reference solution with detailed buildingphysics can be obtained using the ModelExchange-functionality of the building FMU and the Modelica-basedequipment model. Generation of a correct reference solu-tion depends on the following assumptions:

• building FMU correctly implements the ModelEx-change interface and internal room physics,

• ModelExchange master correctly implements timeintegration with error checking,

• Modelica model is correctly solved within the envi-ronment.

As Modelica simulation environment and ModelExchangemaster we use the SimulationX11 software, which has acomprehensive quality testing procedure to ensure correct-ness of Modelica and FMI master implementation. Ourown NANDRAD implementation is tested against stan-dard and customized dynamic test scenarios, and alsocompared to the thermal room model THERAKLES12.

Given these testing procedures, we are confident thatthe results of the ModelExchange calculation will be cor-rect and can be used to evaluate the quality of the Co-Simulation runs.

5.2.1 ModelExchange Reference Simulation

A first step in generating this reference solution was to ex-port the NANDRAD model as FMU for ModelExchange.Since NANDRAD exports a single FMU with both Co-Simulation and ModelExchange specification, the same

11https://www.simulationx.de12See http://bauklimatik-dresden.de/therakles.

THERAKLES was used in the test case as plugin alternative toNANDRAD and gave the same results for this single-zone modelproblem.

Real time [d]

Air

Te

mp

era

ture

[C]

0 5 10 15 20 25 30

19

20

21

22

23

Modelica StandAlone

ModelExchange

Figure 5. Comparison of reference ModelExchange solutionwith Modelica-only variant, using SimulationX for both simula-tions

FMU is used for later Co-Simulation testing. The FMUwas imported into SimulationX (version 3.7), connectedmanually to the plant model and simulated with the Simu-lationX internal solver (CVODE solver, sparse Jacobian).

The fully coupled ModelExchange simulation is a fairlysmall problem and was simulated in acceptable time. Theresults were then compared to the stand-alone simplifiedModelica variant and showed good agreement (Figure 5).We also did not expect much difference, since the single-layer constructions with high thermal conductance will bereasonably well approximated by the mean thermal resis-tance approach used by the Modelica model.

For the office room model, we use the ModelExchangereference solution for the subsequent Co-Simulation tests.However, for larger buildings (more than one hundredzones) the procedure of using ModelExchange for sim-ulation fails, because already the symbolic analysis takesexcessive time. For example, in the case of the appartmentcomplex the symbolic analysis was not yet finished afterthree days.

5.3 Co-Simulation VariantsFor the Co-Simulation approach, we exported the Mod-elica plant model from SimulationX into an FMU forCo-Simulation, version 2, hereby using the CVODE inte-grator option and numerical Jacobian generation method.Then, we ran the coupled simulation between the plantand building simulation FMUs with MASTERSIM13. Wedeveloped this open-source Co-Simulation master imple-mentation specifically for testing and evaluation of build-ing simulation applications.

5.3.1 Non-Iterating Gauss-Jacobi with Fixed Step-Size (only FMI v1)

The most trivial approach to Co-Simulation is the useof the Gauss-Jacobi algorithm without iteration and fixed

13http://mastersim.sourceforge.net


DOI10.3384/ecp1713263


69

Real time [d]

Air

Te

mp

era

ture

[C]

0 5 10 15 20 25 30

19

20

21

22

23

GaussJacobi 10 min

GaussJacobi 1 min

ModelExchange

Figure 6. Gauss-Jacobi, non-iterating, fixed communica-tion step sizes (ModelExchange results from SimulationX, Co-Simulation results calculated with MASTERSIM)

time step. This algorithm does not require any FMI v2features and is thus the most compatible.

For the office room case the simulation was done witha fixed communication step size of 10 and 1 minutes. Forboth variants, stability problems appear. Figure 6 showscomputed room mean air temperatures for the first weeksof the annual simulation.

The two Co-Simulation variants are plotted vs. the ref-erence solution and clearly show unphysical oscillations,even at times when heating setpoints are constant. Sourceof the problem is the delayed reaction of the plant FMUon changes in room air temperature. Whenever the roomtemperature crosses the setpoint temperature during thecourse of the communication interval, the plant loop con-tinues calculating based on outdated information. Specif-ically, when room temperature increases above setpointtemperature, the heating system still provides heat to theroom based on previous room air temperature informa-tion. During cooling, the heating system remains off fortoo long, allowing the room air temperature to drop belowthe setpoint temperature. As expected, reducing the com-muncation step size also reduces magnitude of observedoscillations.

Using SimulationX as Co-Simulation master with sametime steppings gave nearly identical results compared toMASTERSIM. Thus, we have confidence in correct be-havior of the building and HVAC system FMUs.

5.3.2 Non-Iterating Gauss-Seidel with Fixed StepSize(only FMI v1)

An attempt at improving the solution was made by usingthe Gauss-Seidel algorithm, again with fixed step size andno iteration. Hereby, the building FMU is been given up-dated plant FMU results when integrated in the same step.Figure 7 shows a comparison between a Gauss-Seidel andGauss-Jacobi simulation using the same communicationstep size.

Real time [d]

Air

Te

mp

era

ture

[C]

0 5 10 15 20 25 30

19

20

21

22

23

GaussJacobi

GaussSeidel

ModelExchange

Figure 7. Comparison of non-iterating Gauss-Jacobi and Gauss-Seidel calculation for a fixed communication step of 1 minute(Co-Simulation cases done with MASTERSIM)

Despite the notable improvement, even Gauss-Seideldoes not provide sufficiently accurate results. Loweringthe time step will of course improve results, but at the costof reduced simulation performance. In practical applica-tions the user would have to guess the communication in-terval and refine it in the case of stability/accuracy prob-lems. Recognizing incorrect results may not always beeasy, especially since for realistic application scenarios areference solution does not exist. Therefore, it would bedesirable to automatically adjust the time step such thatresults are within acceptable tolerances.

5.3.3 Adaptive Communication Step Size

We implemented the step-doubling technique inMASTERSIM as adaptive communication step method(Clauß et al., 2017). Clauß discusses such an ap-proach within in context of FMI Co-Simulation. Theerror tests uses the weighted root mean square normof all communicated real variables. When this al-gorithm is used, all FMUs must have the capabilitycanGetAndSetFMUstate and formally implementversion 2 of the FMI standard. The algorithm beginswith storing the current FMU states, followed by a fullcommunication step calculation. The results are cached,FMUs are set back and two subsequent communicationsteps of half length are computed. The result of the singlestep and the double-step calculation are used as a measurefor the local truncation error. With this approach, eachstep, even if successful, requires 3 FMU evaluationscompared to one FMU evaluation without error test.

Three simulations cases were run: Gauss-Jacobi andGauss-Seidel methods, each with only one evaluation (noiteration), and the last with Gauss-Seidel allowing three it-erations. All tests were done with a relative tolerance andan absolute tolerance of 10−5. The latter may be impor-tant since thermal loads, the output variables of the plantFMU, can go down to zero.



DOI10.3384/ecp1713263

Real time [d]

Air

Te

mp

era

ture

[C]

0 5 10 15 20 25 30

19

20

21

22

23

GaussJacobi

GaussSeidel noniterating

GaussSeidel iterating

ModelExchange

Figure 8. Comparison of non-iterating Gauss-Jacobi and Gauss-Seidel calculation variants with adaptive communcation stepsizes (Co-Simulation cases done with MASTERSIM)

When time step sizes fall below 1 s, iteration is dis-abled. This is a fallback criterion in MASTERSIM in or-der to avoid useless iterations in case of encountered dis-continuities. Changing this value may also change per-formance of the simulation, but not impact accuracy ofresults.

Figure 8 shows the results obtained with variable stepsizes for non-iterating cases. The results are now withinthe requested tolerance limit and are, with very few ex-ceptions, nearly identical to the ModelExchange variant.The simulation time, however, has increased substantiallycompared to the incorrect fixed step variants.

Table 1 shows the statistics obtained from the threecases. For the first two cases iteration is not used, henceno convergence failures were recorded. Error test failuresoccurred about three times more frequent for the Gauss-Jacobi variant, which resulted in a drastic reduction of av-erage time step sizes and similar increase of simulationtime. The step sizes were sometimes reduced drasticallyto 10−7s. Figure 9 illustrates the strong variations in timestep. For the Gauss-Jacobi simulation, the time step variespermanently over several orders of magnitude. For allvariants, when the heating system has been turned off at0.75 d (6:00 pm), the time steps increase again up to theallowed maximum of 15 minutes. This is important forincreasing overall simulation performance.

Interesting is the comparison between iterating andnon-iterating Gauss-Seidel. Apparently, even with threeiterations often a situation is encountered, that Gauss-Seidel cannot resolve. In these cases time step sizes werereduced due to convergence errors, which in turn reducedthe number of error test failures. With this stability-dominated simulation case, use of the iterating Gauss-Seidel approach is not meaningful.

Real time [d]

Co

mm

un

ica

tio

nS

tep

Siz

e[s

]

0.5 0.55 0.6 0.65 0.7 0.75 0.8

102

101

100

101

102

103

104

GaussJacobi

GaussSeidel noniterating

GaussSeidel iterating

Figure 9. Illustration of step-size variation with adaptive timestep methods within the first day of simulation.

6 Summary and ConclusionWe presented the tasks necessary to successfully run acoupled building energy performance simulation using theFMI standard. We discussed the physical interface be-tween plant and building FMU, the process of generatingthe building FMU itself and its internal interface imple-mentation. In realistic cases buildings may have a largenumber of conditioned zones, resulting in many input andoutput variables. Therefore, we presented an approach forimproving usability by automatically generating Modelicahelper components. Further, we showed one example ap-plication for a single zone model and tested different Co-Simulation algorithms for accuracy and simulation perfor-mance.

In the test case we used an ideal heating system. Thestrong coupling between building and plant FMU causedstability problems for fixed-step solvers. These could becontrolled by use of an adaptive communcation time step,based on local error estimates. The non-iterating Gauss-Jacobi method performed poorly compared to the non-iterating Gauss-Seidel method. Iteration, tested with thecase of Gauss-Seidel, did not improve simulation perfor-mance. Without iteration, stability problem were detectedby the error test, with iteration these stability problems of-ten caused conversions failures. In either case communca-tion step sizes were reduced. However, in all variants theerror test and communcation time step adjustment methodyielded results of acceptable quality.

In our test case, the iterative Gauss-Seidel methodfailed frequently due to stability problems. Therefore, us-ing Gauss-Seidel or Gauss-Jacobi iteration is not mean-ingful for such strongly coupled cases.

The observed behavior and conclusions drawn from thesimulations are of course only an indication of general be-havior. In particular, the ideal plant model and controlmethod in conjunction with a strong thermal response ofthe building are definitely an extreme case. Still, success-


DOI10.3384/ecp1713263


71

Table 1. Simulation statistics obtained with adaptive step simulations

Method Comm. Steps Error Test Fails Convergence Fails Simulation Time

ModelExchange — — — 54 minGauss Jacobi non-iterating 1984803 590539 — 25 minGauss Seidel non-iterating 827616 146637 — 10 min

Gauss Seidel iterating 1595677 4003 809681 28 min

ful simulation was possible by use of time step adjustment,and the method and approach itself is suitable for generalapplication.

To achieve this, the following requirements on FMUand master simulator must be fulfilled:

• the solvers within the building and plant FMU mustimplement an error test procedure to give consistentresults,

• the FMUs must implement FMI standard version 2with capability to set and get their states, and

• the Co-Simulation master must support communica-tion time step adjustment based on local error esti-mates.

It has to be noted, though, that our conclusions are spe-cific to the idealistic HVAC system used and observationsmay be different when dealing with detailed HVAC sys-tem models for modern integrated buildings.

For practical applications, overall simulation perfor-mance remains a crucial criterion. Considering the stilllong simulation times when applying Co-Simulation, fur-ther work is required with regard to finding suitable physi-cal interfaces, choice of master algorithms and algorithmicparameters.

AcknowledgementsWe gratefully acknowledge the support and funding re-ceived from the German Federal Ministery for Eco-nomic Affairs and Energy in the research project “En-Tool:CoSim” #03ET1215A F-002792.

ReferencesFMI 2.0 Standard, 2014. Functional Mock-up Interface for

Model Exchange and Co-Simulation.

Christoph Clauß, Kristin Majetta, and Richard Meyer. Appli-cation of Richardson Extrapolation to the Co-Simulation ofFMUs from Building Simulation. In Proceedings of the 12thinternational Modelica Conference, 2017.

William.S. Dols, Wang Liangzhu, Steven J. Emmerich, andBrian J. Polidoro. Development and Application of an Up-dated Whole-Building Coupled Thermal, Airflow, and Con-taminant Transport Simulation Program (TRNSYS/CON-TAM). Journal of Building Performance Simulation, 8(5):326–337, 2014.

Alan C. Hindmarsh, Peter N. Brown, Keith E. Grant, Steven L.Lee, Radu Serban, Dan E. Shumaker, and Carol S. Wood-ward. SUNDIALS: Suite of nonlinear and differential/alge-braic equation solvers. ACM Transactions on MathematicalSoftware, 31(3):363–396, 2005.

Sanford A. Klein, William A. Beckman, and John A. Duffie.TRNSYS - A Transient Simulation Program. ASHRAE Trans-actions, 82(1):623–633, 1976.

Andreas Nicolai. Physikalische Grundlagen des ther-mischen Raummodells THERAKLES, 2013. URLhttp://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa-102112.

Andreas Nicolai and Anne Paepcke. Die Gebäudesimula-tionsplattform NANDRAD - Physikalisches Modell, Umset-zungskonzept und Technologien im Überblick. In Proceed-ings of the BauSIM 2012, 2012.

Andreas Nicolai and Anne Paepcke. Transformationder Gebäudeenergiesimulation NANDRAD mit variablemZeitschrittlöser in eine FMU für Co-Simulation. In Proceed-ings of the BauSIM 2016, 2016.

Christoph Nytsch-Geusen, Jörg Huber, Manuel Ljubijankic,and Jörg Rädler. Modelica BuildingSystems – eine Mod-ellbibliothek zur Simulation komplexer energietechnischerGebäudesysteme. Bauphysik, 35(1):21–29, 2013.

Anne Paepcke and Andreas Nicolai. Anlagenregelung in ODE-Systemen am Beispiel der thermischen Raum- und Gebäudes-imulation. In Proceedings of the BauSIM 2014, 2014.

Anne Paepcke, Torsten Schwan, and Andreas Nicolai.Schnittstellen für die Co-Simulationskopplung zwischenGebäude- und Heizungsanlagensimulation. In Proceedingsof the BauSIM 2016, 2016.

Per Sahlin, Lars Eriksson, Pavel Grozman, Hans Johnsson,Alexander Shapovalov, and Mika Vuolle. Whole-buildingsimulation with symbolic DAE equations and general pur-pose solvers. Building and Environment, 39:949–958, 2004.

Michael Wetter. A Modelica-based model library for buildingenergy and control systems. In Proceedings of the 11th IBPSAConference, 2009.

Michael Wetter, Christoph van Treeck, and Jan Hensen. IEAEBC Annex 60: New generation computational tools forbuilding and community energy systems. Technical report,Lawrence Berkeley National Laboratory, 2013.



DOI10.3384/ecp1713263

co-simulation between detailed building energy performance ... · co-simulation between detailed...

Documents