Distributed building performance simulation : a novel approachto overcome legacy code limitationsCitation for published version (APA):Trcka, M., Hensen, J. L. M., & Wijsman, A. J. T. M. (2006). Distributed building performance simulation : a novelapproach to overcome legacy code limitations. HVAC&R Research, 12(suppl. 1), 621-640.https://doi.org/10.1080/10789669.2006.10391198

DOI:10.1080/10789669.2006.10391198

Document status and date:Published: 01/01/2006

Document Version:Accepted manuscript including changes made at the peer-review stage

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:openaccess@tue.nlproviding details and we will investigate your claim.

Download date: 28. Mar. 2020

Distributed Building Performance 1

Simulation - a Novel Approach to 2

Overcome Legacy Code Limitations 3

4

5

ABSTRACT 6

This paper describes the development as well as implementation strategies for distributed simulation 7

of building systems by run-time coupling of existing software. The approach differs from the traditional 8

way of developing software, where additional models are added by incorporating new modules in an 9

existing program. This paper focuses on the actual coupling mechanism. A case study is presented which 10

illustrates the need and potential of the approach. The conclusion is that a distributed simulation 11

environment is more flexible, practical, and powerful than the sum of the individual software programs. 12

INTRODUCTION 13

The traditional (manual) methods for designing heating, ventilation and air-conditioning (HVAC) 14

systems are being surpassed by simulation tools because: 15

buildings become more and more complex in terms of shape, lay-out, functionality and services; 16

requirements for flexibility and adaptability increase; 17

modern building standards and codes are performance based rather then prescriptive; i.e. addressing 18

questions such as “how many hours per year will the temperature rise above a certain value?” and 19

“what will be the annual energy consumption per square meter floor? 20

Advances in hardware and software have resulted in a flood of building simulation tools. However, 21

each tool is applicable only to a subset of the overall problem, and is limited both in scope and resolution. 22

The majority of tools are legacy codes often originating from the seventies. On the whole they are domain 23

specific, not reusable, large, complex monoliths that are difficult to maintain, but still useful. 24 Previously (Hensen 1991; Hensen and Clarke 2000) it has been argued that in the area of system 25

simulation there is still enormous amount of work to be done. System modeling and simulation capabilities 26

develop very slowly and take up an enormous amount of resources (time-wise and financial). An efficient 27

way forward would be to share developments and to reuse existing component models. An overview of 28

how this can be done is given in (Hensen et al. 2004). One way would be on the product model level, either 29

by sharing (Lockley et al. 1994) or exchange (Bazjanac and Crawley 1999) of product information. Even 30

though a common product definition model eases the use of simulation tools, it addresses only part of the 31

overall problem. Reuse can also take place on the level of physical process models. This can be realized on 32

source code level (program integration) or in a more generic way by expressing the models in a neutral 33

format, such as Neutral Model Format - NMF (Bring et al. 1999) that is now integrated in Modelica (Tiller 34

2001). 35 Both data and process model reuse follow a traditional approach, where all component models are 36

brought together in a monolithic stand-alone simulation program. The integration takes place before run (or 37

execution) time, as shown in the upper part of Figure 1. 38

1 Figure 1 External run time coupling 2

3 This paper introduces the concepts, background and core issues of process and data reuse by run-time 4

exchange of information between legacy simulation environments. In general terms, this approach is 5

recognized in literature as Distributed Simulation (DS), in which context the domain existing (legacy) 6

software is referred to as Commercial Off-the-Shelf (COTS) simulation software. The aim of the current 7

work is to resolve the communication between various HVAC component or system simulation software 8

packages. The goal is to define the coupling methodology in terms of content and frequency of the data 9

exchange. 10

DISTRIBUTED SIMULATION 11

Opposed to the driving motivation for parallel simulation, which is decreasing the simulation 12

execution time, the main motivation for distributed simulation is to integrate several separate simulations 13

(federates) into a single simulation (federation). Each sub-system is modeled in appropriate software and 14

simulated, potentially, using different computers (Figure 2), while intermediate results are communicated 15

over the network during execution time. The possibility to model various interdependent aspects over a 16 wide range of applicability and resolution allows much greater flexibility in the use of building energy 17

simulation. 18

19 Figure 2 Distributed modeling and simulation 20

21

Compared to the traditional approach, DS may offer several advantages (Boer 2005; Ganse 2005; and 1

Fujimoto 2005): 2

reusability of already existing (legacy) COTS software; 3

combination of heterogeneous technologies; 4

collaborative model design and development process; 5

information hiding; 6

scalability and fault tolerance; 7

geographically distributed components; 8

reducing model execution time & more available memory. 9

Distributed simulation breaks boundaries between different simulation environments and by that 10

introduces the potential to “pool resources”, i.e. to use the best simulation model available without being 11

limited to those available “locally”. 12

State-of-the-art in general 13

There are two widely used architectures for distributed computing: client-server and peer-to-peer. In 14

the former architecture, simulation is executed on server machines, to which clients can log on from remote 15

sites. The latter architecture does not have servers. The simulation is executed across many machines – 16

peers. In our case DS does not necessarily involve more than one computer; it suffices if there are at least 17

two executables (federates) that exchange information in the federation run-time. Distributed simulation 18

requires communication between processes (applications) or interprocess communication (IPC). Figure 3 19 (partially taken from (McGregor 2005)) shows the IPC taxonomy. 20

21

22 Figure 3 Interprocess communication (IPC) taxonomy (McGregor 2005) 23

24 An overview of most commonly used IPC protocols is given in (Yahiaoui et al. 2003). Buss and 25

Jackson (1998) compare three architectures for distributed computing: HLA (High Level Architecture), 26

CORBA (Common Object Request Broker Architecture) and RMI (Remote Method Invocation) and 27

distinguished three basic elements of distributed architectures as shown in Table 1. 28

29

Table 1: Elements of distributed architectures (HLA, CORBA, and RMI) 30 Distributed architecture Object interface language Object manager Naming service 31

HLA OMT RTI Federation execution 32 CORBA IDL ORB DII 33

RMI Java UnicastRemoteObject and Naming Java classes Registry Java class 34 35

RMI uses its native implementing Java language for object interface language, while HLA and 36

CORBA define their own separate interface specifications that are distinct from their implementing 37 languages, object model template (OMT) and interface definition language (IDL), respectively. The object 38

manager is a backbone through which objects on all machines communicate, while the naming service is 39

the mechanism by which clients discover the available objects on the server during the computation run-40

time. RMI is language specific and suitable for use with newly developed applications. Both, CORBA and 41

HLA are concerned with legacy applications, possibly developed in different languages. However, CORBA 1

as well as the majority of the IPC mechanisms represented in Figure 3 except HLA were developed to 2

facilitate communication between applications in general and not between simulations in particular. 3

Therefore CORBA is not ready-made for use with simulation packages, since additional management of 4

time and data exchange is required. 5

CORBA has been exploited in many projects in industry. For example, NASA Glenn Research Center 6 (GRC) program, within NASA’s High Performance Computing and Communication (HPCC), is 7

developing a large scale, detailed simulation environment for design analysis of aircraft engines, called the 8

Numerical Propulsion System Simulation (NPSS) (Follen et al. 2001; and Sang et al. 2002). Based on 9

CORBA, the NPSS reuses legacy FORTRAN codes for many scientific and engineering applications The 10

NPSS environment focuses on three modeling aspects: integrating engine components, coupling of multiple 11

disciplines (aerodynamics, structural mechanics, heat transfer and combustion), and engine component 12

zooming at adequate level of fidelity. 13

The US Department of Defense (DoD) puts a lot of effort in developing higher-level architectures for 14

distributed simulation. This resulted in a standardized protocol (Aggregate Level Simulation Protocol – 15

ALSP), and in the High Level Architecture (HLA) which is the current state-of-the-art in distributed 16

simulation. HLA became in 2000 the IEEE (Institute of Electrical and Electronics Engineers) standard for 17

distributed simulation (1516). 18 Today, HLA is mostly used within the defense community for military training simulators (Li et al. 19

2005; and Wilcox et al.2000) and in multi-player gaming (Wilcox et al. 2000; Pollini and Innocenti 2000). 20

However, some initial steps have been taken in order to adopt the standard in industry (Boer 2005 and 21

Strassburger 2001). The industry domains that have so far tried to exploit the advantages of HLA, include 22

supply chain simulation, digital factory simulation, traffic simulation, and similar. Although some attempts 23

to use HLA in civil applications have been made, there is also an ongoing discussion whether or not the 24

approach is suitable outside the defense community. Taylor et al. (2002) argues that the HLA complexity 25

that suites defense community requirements might be in excess of relatively simple data exchange 26

requirements in major industries, and questions the appropriateness of HLA implementations away from its 27

original domain. Boer (2005) states that projects in industry are much smaller than military projects and 28

that most industry projects will not benefit from HLA, considering the associated costs. Boer (2005) argues 29 that industry requires a less complex solution. Along the same lines, (Taylor et al. 2002) argues that HLA 30

in industry is only a solution that is looking for a “fantasy” problem but did not find one yet. 31

32

However, the implementation of either CORBA or HLA for distributed building systems simulation 33

mainly raises difficulties when interfacing the building simulation domain legacy tools. The BPS tools are 34

manly written in Fortran for which no object interface language (IDL, OMT) mappings have been defined. 35

Much time and extra materials are necessary to overcome this difficulty as discussed in (Follen et al. 2001; 36

and Yahiaoui et al. 2004). 37

By implementing a less complex IPC and formulizing the time management mechanism we believe 38

that distributed simulation in the domain of building performance simulation can push the technology 39

limits, enabling more flexible use of available legacy tools. 40

Distributed building performance simulation 41

In the field of building performance simulation, some software-specific DS work has been done in 42

order to integrate high-resolution light simulation, involving ESP-r and Radiance (Janak 1997), or to 43

integrate computational fluid dynamics, involving ESP-r and Fluent (Djunaedy et al. 2003). The coupling 44 between TRNSYS and COMIS (Dorer and Weber 1997), EnergyPlus and COMIS (Huang et al. 1999), 45

EnergyPlus and MIT-CFD (Zhai 2003), EnergyPlus and DeLight etc., are not implemented as external. 46

TRNSYS and EnergyPlus incorporate additional domain tools by converting them into the new programs’ 47

subroutines, i.e. types. This is what is called by internal coupling. 48

Other work focused on integrating HVAC simulation. TRNSYS developers introduced a new type 155, 49

defined as MATLAB connection. The latter application is launched at every TRNSYS time step as a 50

separate process. The type 155 communicates with the MATLAB engine through a Component Object 51

Model (COM) interface. Any MATLAB command (including Simulink features) can thus be run within a 52

TRNSYS simulation (CSTB 2003). The similar approach is implemented in TRNSYS coupling with EES. 53

TRNSYS is able to execute EES at each time step to solve a given set of equations (Keilholz 2002). 54

A link between EnergyPlus and TRNSYS was used before EnergyPlus obtained its own photovoltaic 1

component model (TESS 2003). EnergyPlus communicated product model data concerning photovoltaic 2

(PV) arrays to TRNSYS. TRNSYS was then automatically launched during an EnergyPlus simulation to 3

determine the performance of the PV array before returning control back to EnergyPlus. EnergyPlus waited 4

for TRNSYS to complete, and recuperated the output files that TRNSYS generates during its run and 5

incorporated them into its native output-reporting format. Windows API calls were used for the 6 communication. This process doesn’t involve communication on a time step basis, so it does not constitute 7

DS as described in the introduction. Recently, the link between EnergyPlus and Spark has been developed. 8

Individual HVAC components in EnergyPlus can be modeled with SPARK problems allowing the use of 9

SPARK stand-alone HVAC models in the place of the native EnergyPlus models (Curtil 2004). 10

The above range of efforts indicates the need for integration in the BPS domain. However, until now. 11

the research is inconclusive. There exists no general standardized framework for integration of building 12

performance simulation environments. 13

COUPLING DECISION METHODOLOGY 14

The use of building simulation should be problem-led rather than tool-led. Due to the increasing 15

requirements in terms of knowledge and skills, as well as increasing computing resources, it is generally 16

advisable to obey Einstein’s principle “a model should be as simple as possible, but no simpler.” In the 17

current context this means that the starting point should be the lowest possible model resolution and 18

complexity level that satisfy required accuracy of performance indicator(s) of interest; e.g. as in Table 2. 19

Choosing the system model for a specific purpose is still more an art than an engineering discipline (Forbus 20

1996, Moody 2005). However, there are some rational processes that can be applied for model 21 development (Trcka et al. 2006b). The processes can be based on a checklist form or they can include some 22

quantified qualities to validate the chosen modeling abstraction level. The use of a checklist, bounding 23

abstractions and (differential) sensitivity analysis has been recognized (Trcka et al. 2006b) as a potential 24

checking procedure for definition of decision-making criterion of modeling abstraction level. 25

26

Table 2 Potential questions/problems in design and maintenance of HVAC systems 27 Ref. number Design question 28 1 Maximum load calculation 29

2 Inquire about comfort condition 30 3 Energy consumption - gross 31 4 Energy consumption - global 32

5 Fuel consumption 33 6 Component effect on building energy performance 34

7 Fault detection and diagnosis 35 Optimization of the control 36

37 A decision-making procedure is schematically shown in Figure 4, in which the numbers correspond to 38

the questions/problems in Table 2. Each has its own minimum resolution level, which does not necessarily 39

have to be sufficiently accurate in any specific case. 40

1 Figure 4 Flow chart of the decision-making methodology 2

3

For example, if information about maximum temperature were required (question 2), pure conceptual 4

system modeling would initially be the minimum resolution level. If from the checking procedure (shaded 5

area in Figure 4) turns out that the uncertainty of the model gives a rise to unacceptable inaccuracies of the 6

performance parameters, the level of system modeling should be one higher on the resolution scale, as 7

indicated. The checking procedure can be performed by applying either bounding abstraction test or a 8

differential sensitivity analysis (Trcka et al. 2006b). 9

However, it may happen that no model exists for one or more system components in a particular 10

simulation environment. Going to a higher level of complexity and implementing external coupling is quite 11

demanding. That is why the checking procedure is also important to justify such decision. Again, defining 12 the range of change or bounding of coupled variables, and comparing their influence on the change of the 13

values of performance parameters of interest would facilitate the decision-making process. However, such 14

definition of checking procedure does not represent influence of transient changes of coupling variables, 15

and at its best can bound the qualities of interest. Therefore, a simpler check for necessity is adopted in this 16

paper as follows. 17

Justifying external coupling of HVAC component models 18

It is obvious that external coupling of HVAC component models is justified only if: 19

the model for a required component does not exist in the base program, or 20

the existing model is not adequate for the specific study, or 21

the component is a real building and/or system. 22

If justified, there are potentially two distinct ways of running the simulations of the base and the 23

external programs: they can be run-time coupled or sequentially coupled. The sequential solution means 24

that once one simulation is finished its output will be redirected to the input of another program. The run-25

time coupled approach requires run-time exchange of coupled data between the simulations. 26

Figure 5 shows possible configurations in terms of necessity for coupling of the subsystems. Only in 27

special cases a sequentially coupled approach will be sufficient. Most cases will require a coupled 28

approach. 29

30

1 Figure 5 External coupling necessity: “-” – inadequate approach for specific schema; “+” – applicable 2

approach for specific schema; “o” – refers to an approach that is applicable for specific schema, but more 3

complex and does not bring extra benefits compared to its alternative. 4

5

In open systems, if the coupling data are constant, or if they vary only as a function of the first 6 subsystem model and its input, then the system can be analyzed decoupled (sequentially coupled). This is 7

not the case if the coupling data changes not only as a function of the first subsystem model and its input, 8

but also by what is going on in the second part of the system (e.g. a controllable fluid flow inducer is placed 9

in the second subsystem and consequently influences the flow in the upstream subsystem). 10

Further, in closed-loop configurations, there is inherent feed back between subsystems. It doesn’t 11

matter whether the loop is closed by the working fluid or due to control signals. There will be dynamic 12

interactions between the components and thus run-time coupling is required in these cases. 13

RUN-TIME COUPLING 14

The work reported here pioneers mechanisms on which building performance simulation frameworks 15

could be based. 16

Data-to-be exchanged 17

The minimum number of variables that defines the thermodynamic state of a working fluid is 18

theoretically known from Gibbs phase rule. These variables together with a variable that quantifies a flow 19

uniquely determine the coupling set of variables among components in a HVAC system. However, in many 20

HVAC component modeling approaches, the mass flow is a known quantity and thus very often there in no 21

need to consider pressure drop. 22

For moist air as the working fluid, the temperature and first and second phase mass flows are to be 23

exchanged between programs. In case of water as the working fluid, temperature and mass flow will be 24

sufficient. More discussion on this subject including the quality of the coupled variables can be found 25 elsewhere (Trcka et al. 2006a). 26

In case of control loops where the sensed and the actuated variable are not in the same program, it is 27

also necessary to communicate these variables between the coupled programs. 28

The internal synchronization procedure requires the knowledge about simulation time progress, and in 1

the case the synchronization is managed in that way (see section on synchronization), a time stamp variable 2

needs to be transferred between the coupled programs. 3

Different mechanisms 4

The current work is based on prototypes using specific building simulation environments, such as ESP-5

r, TRNSYS and EnergyPlus, as well as some smaller standalone component model implementations such 6

as EARTH. However, the research outcomes such as exchange mechanisms and associated knowledge 7

should be software and platform independent and are thus more widely applicable. 8

Depending on the context, transient behavior of HVAC components can be regarded as dynamic, 9

quasi-static or steady-state. This distinction is important for the choice of coupling mechanism. In case of 10 dynamic behavior it is important to keep track of the evolution of the results over time. 11

Figures 6 and 7 show two different coupling mechanisms. Figure 6 illustrates a coupling mechanism 12

for a discontinuous-running external program (or federate). The base program invokes the external program 13

and waits until that is finished before it continues itself. This mechanism is straightforwardly applicable for 14

steady-state component models. However, the output of a transient simulation model is also a function of 15

the components’ state at the previous time step. Since the discontinuously coupled program is restarted 16

every time step, it does not have the information about component’s state from the previous time step, and 17

thus for consistent dynamic evolution of the simulation results, the components state history needs to be 18

externalized. 19

20 Figure 6 External coupling mechanism for a discontinuous running external program 21

1 2

Figure 7 External coupling mechanism for a continuous running external program 3

4

Figure 7 illustrates the coupling mechanism for a continuous running external program. Both programs 5

run in parallel and exchange data in a certain user-predefined manner. This mechanism is more suitable for 6

transient component models, since the relevant state history is internally managed. 7

COUPLING QUALITATIVE ISSUES 8

Synchronization 9

Maybe the most important issue when discussing distributed simulation is time synchronization. To 10

enable distributed simulation, components need to exchange data at run-time and to synchronize their local 11

(simulation) clocks. Building performance simulations are normally in the time domain, where each time 12

advance made by a program is of some fixed duration of simulation time. It is obvious that all information 13

to be exchanged must have a time stamp. Federates should not receive information with a time stamp older 14

than its current simulation time. Federates need to know whether all required information for the current 15

simulation time step has been received. No federate should proceed to the next time step unless it received 16

all data relevant for the current time step from other coupled federates. 17

18 There are two main approaches for synchronization (Fujimoto 2003) as follows. 19

Conservative – in which precautions are taken to avoid processing data out of time stamp order, i.e. 20 execution mechanism avoids synchronization errors. 21

Optimistic – which does not necessary avoid synchronization errors, but rather use a detection 22

mechanism and recovery approach, known as roll-back. Because it needs a state saving mechanism, 23

enabling roll-back in an existing simulator requires major re-engineering (Page et al. 1999).. 24

We distinguish internal and external time management approaches. Internal time management 25 indicates that the synchronization checking procedure is coded within federates themselves. In that case, 26

the time stamp is recognized as an additional variable to be exchanged. On the other side, the 27

synchronization can be compassed within the inter process communication (IPC) mechanisms, applying 28

blocking mode, for example. This is what is called by external coupling. In the prototypes presented in this 29

paper the conservative approach is externally implemented. 30

31

Coupling strategy 1

In the run-time coupling approach each application runs separately, interacting with other applications 2 through its boundaries. There are two different external run-time coupling strategies: 3

quasi-dynamic coupling (Zhai, 2003), or loose coupling (Struler, et al., 2000), or ping-pong coupling 4

(Hensen, 1999) and 5

fully-dynamic (Zhai, 2003), or strong coupling (Struler, Hoefligeret al., 2000), or onion coupling 6

(Hensen, 1999). 7

In the former, distributed models run in sequence, where each model uses the known (from the 8

previous coupling time step calculation) output values of the coupled model. The feedback between the 9

programs is lagged for one coupling time step. Accuracy as well as stability constraints limit the simulation 10

time step length in case of this strategy. Shorter the coupling time step, lesser the influence of the lagging. 11

The latter coupling strategy requires that models iterate within each time step until the error estimate falls 12

within a specified predefined tolerance. This improves the feed back, and as such it allows longer time 13

steps for the same accuracy, but it requires an iteration procedure to ascertain user defined convergence 14

criteria. 15

For coupling to a steady state component in a discontinuous manner, the employment of iterations does 16

not pose additional issues. However, the situation is different for the continuous mechanism in any case, as 17 well as for discontinuous mechanism applied for coupling to a transient component model (results depend 18

on the simulation time evolution). It is either synchronization management issue, or history data 19

management issue, or both that require a roll-back or time step rewind of the coupled program or the state 20

history, if iterations are engaged, and thus increasing the effort for the code adjustments significantly. 21

Before the decision on the coupling strategy is made, its influence on the simulation results was 22

investigated for different coupling time steps. 23

24

25 Figure 8 Simple HVAC network modeled in distributed fashion 26

27 For the study a simple HVAC network was used as shown in Figure 8. Two models of the same 28

systems were constructed. First model is a single monolithic ESP-r model of the whole system, while the 29

other is a distributed model where two parts of the system are modeled in two coupled ESP-r models. To 30

assess the sensitivity of coupling strategy, the simulation output of the monolithic (one-program) model 31

(i.e. assumed to be fully-dynamically coupled) is compared with the simulation output of the distributed 32

model (quasi-dynamically coupled). Several simulations were performed changing the length of coupling 33

time step, i.e. the frequency of data exchange among programs. 34

35

1

2 Figure 9 Influence of coupling strategy on zone temperature calculation with different coupling time 3

steps 4

5

The results in Figure 9 show that if the exchange frequency is high enough, the results for both 6

coupling strategies are similar. However, if the coupling frequency is reduced, the difference between the 7

strategies increases. For example, if the coupling time step is increased to ten minutes, oscillation that 8

appears due to the particular combination of simulated system and control parameters and simulation time 9

step are much larger than if the models do not iterate. With further reduction of the coupling frequency, the 10

difference with regard to the oscillating amplitude between the strategies is less apparent, but the phase 11

shift due to the time delay between federates is still present. 12

From the example, one can conclude that with an appropriately chosen coupling- as well as simulation 13 time step the differences between strategies are small. The loosely (quasi-dynamic) coupled simulations 14

will produce the same quality results as strongly (fully-dynamic) coupled ones. As the starting point for the 15

prototypes elaborated in this paper, and for reasons of simplicity, the fully dynamic approach is only 16

applied with discontinuous mechanism, used for coupling to steady state component models, while the 17

quasi-dynamic approach is used in general,. 18

Inter vs. intra time step data exchange 19

In terms of system component modeling two main approaches can be distinguished: input-output based 20

(each component is represented by an input/output relationship), and conservation equation based (each 21

component is described with time-averaged discretised heat and/or mass conservation statements which are 22

combined to form a plant system matrix, and which are solved simultaneously for each simulation time step 23

using either an implicit, explicit or mixed numerical scheme). Advantages and disadvantages of these 24

approaches are addressed elsewhere (Hensen 1996). 25

External coupling will result in different time step variable exchange depending on which approach is 26

used, as shown in Figures 10, 11 and 12. The circles represent the component state and its output at a 27

specific moment in time. The arrows indicate the information flow, which (in terms of location) follows the 28 fluid flow; i.e. from sending to receiving component. The grey boxes indicate the placement of the external 29

component in the overall model. 30

1 Figure 10 Inter and intra time step data exchange with an external component assuming that the base 2

program uses a fully implicit numerical scheme 3

4

When the base federate uses a fully implicit numerical scheme, a plant system matrix is solved at each 5

time step. However, when an external component is interconnected its dynamical and physical behavior is 6

unknown. Therefore, it is not possible to uniquely define its dependencies with other parts of the system 7 and only an explicit determination of temperature, first and second phase mass flows as calculated by the 8

external program can be used. 9

Further, if the exchange of data takes place before solving the system matrix, the thermodynamic state 10

of the incoming connection for the future time step of the component is still to be solved. This means that 11

the values of the variables that describe the thermodynamic state of the incoming connection, calculated for 12

the last time step, will be forwarded to the external federate. Based on these values the external program 13

performs the calculation and sends the data back to the base program. 14

Inter-programs time step variable exchange will disturb the original intra-time step variable exchange 15

of the base program that uses an implicit numerical scheme (Figure 10). 16

However, if an explicit numerical scheme is used (Figure 11) the external coupling will keep the 17

original intra time step data exchange consistent. The same applies for input-output based component 18

modeling approach (Figure 12). 19

20 EXTERNAL

COMPONENTESP-R

COMPONENT

ESP-R

COMPONENT

Time

stepping

t-Dt

t

ESP-R

COMPONENT

21 Figure 11 Inter and intra time step data exchange with an external component assuming that the base 22

program uses a fully explicit numerical scheme 23

24

t

INTERNAL

COMPONENT

INTERNAL

COMPONENT

EXTERNAL

COMPONENT

INTERNAL

COMPONENT

25 Figure 12 Inter and intra time step data exchange with an external component assuming that the base 26

program uses an input-output based approach 27

28 However, coupling time steps, which are sufficiently small for the chosen coupling strategy will 29

diminish the discrepancy between inter- and intra- time step variable exchange schemas and ensure the 30

stability and accuracy of the results. 31

IMPLEMENTATION 32

In order to prototype the above, additional features had to be developed for legacy domain tools, e.g. 33

for ESP-r, TRNSYS and EnergyPlus. The following discussion is limited to changes within the ESP-r 34

software as an example. 35

Additional components have been developed within the ESP-r simulation environment in order to 36

implement and test coupling of continuous and discontinuous running external models of either air or water 37

systems (Figure 13). Instead of additional components, additional connections (in ESP-r terminology) 1

could have been used as well. From the solution point of view both approaches are identical. However in 2

case of connections, it would be very important to take care of the order in which the connections would be 3

defined. 4

The mechanism for the discontinuously running external program uses intermediate files. In case of the 5

continuously running external program, data transfer is via so-called named pipes. In both cases it would be 6 possible to use other inter-process communication (IPC) mechanisms as well. 7

In case of the named pipes IPC, process blocking and synchronization is provided as part of the pipe 8

services. For IPC mechanisms, which do not provide this service, a time-stamp variable could be added to 9

the set of exchanged data for checking and synchronization purposes. 10

Figure 13 shows the process of variables exchange and places where original code had to be altered to 11

accommodate the requirements for run-time exchange of selected variables. The figure shows main 12

subroutines involved in simulation of an HVAC system model. We will address only the subroutines which 13

code had to be adjusted to accommodate the coupling. 14

15

16 Figure 13 External coupling implementation in ESP-r within one time step 17

(MZPADJ, CONTRL, MZPMSU, and MZNASS are ESP-r-specific subroutines) 18

19 CONTRL subroutine determines system control status based on most recent available results. To 20

enable the exchange of control data, “fictive” control components and additional control low were 21 constructed. The role of the new control low is simple. It copies relevant information from its source and 22

transfer it to the coupled program. “Fictive” components are only used to enable the standard 23

system/control definitions in ESP-r., and do not have any influence on the solution. 24

MZPMSU subroutine sets up the system equations in a matrix form. It calls components’ subroutines 25

that generate matrix coefficients and locate them in the system network matrix. Two new component’s 26

subroutines were constructed (for each coupling mechanism), one as an air-loop component and the other 27

as water-loop component. The components interface the coupled program and send/receive data to/from it. 28

ESP-r model does not need to have any knowledge about a coupled subsystem simulation model. If 29

coupling time step differs from (greater then) the simulation time step employed internally, the coupled 30

variables are kept constant, and equal to last transmitted values, during coupling time step calculations. 31

32

33

TEST CASE STUDY 1

As an illustration, consider the greenhouse with air recirculation through an earth-to-air heat exchanger 2 from (Ghosal, et al. 2004) shown in Figure 14. The objective here is to assess the energy saving potential of 3

the ground-coupled heat exchanger consisting of buried pipes. 4

The greenhouse itself is modeled in ESP-r, which currently lacks a model for an earth-to-air heat 5

exchanger. EARTH, a program that models and simulates earth-to-air heat exchanger is run-time coupled 6

to overcome this deficiency. ESP-r and EARTH are continuously coupled through named pipes 7

implementing quasi-dynamic coupling strategy and conservative, externally implemented synchronization 8

procedure. The EARTH model takes into account the dynamics of the ground storage. Using the continuous 9

coupling mechanism the history state data do not have to be externalized. New ESP-r component that 10

interfaces external program sends the information about the working fluid state and its flow through the 11

named pipe. On the other side of the named pipe, the external program, i.e. EARTH waits for the 12

information, and when it is received the program performs calculations. i.e. evolves in simulation time for 13

one coupling time step (that does not have to be equal to the simulation time step). The simulation results 14 are then transferred to ESP-r, again through the pipe. As mentioned earlier, named pipes have services that 15

provide synchronization procedure. Read and write operations to a named pipe are blocking, by default. If a 16

process reads from a named pipe and if the pipe does not have data in it, the reading process will be 17

blocked. Similarly if a process tries to write to a named pipe that has no reader, the writing process gets 18

blocked until another process opens the named pipe for reading. 19

20 Figure 14 Greenhouse coupled to an earth to air heat exchanger 21

22

Some simulation results are presented in Figure 15. These are for three one-day simulations (this is 23

only for demonstration purpose, as the dynamics of the ground heat storage itself are not visible for such 24

short simulation time) using climate data for New Delhi, India: one without coupling the external 25 exchanger, and two coupled simulations with either 350m3/h air volume flow rate and 50m pipe length 26

(design 1) or 700 m3/h air volume flow rate and pipe length 120m (design 2). The programs’ simulation 27

time steps equal to coupling time step and its value is kept to one hour. 28

As expected, the air temperature in the greenhouse varies less when it is coupled to the earth-to-air heat 29

exchanger. The variations are smaller with design 2. The greenhouse is heated during the night and cooled 30

during the day. For higher volume flow rates the difference in temperatures can be as high as 7 degrees 31

Celsius. 32

1 Figure 15 Air temperature profiles: ambient temperature, zone temperature for free floating conditions, 2

zone and outlet temperatures from ground coupled heat exchanger for design 1 and 2 3 4

The variations of the outlet temperature of the ground coupled heat exchanger depend on a specific 5

heat exchanger design and variations of the temperature within the zone. The heat exchanger and the 6

greenhouse are strongly coupled and only by coupled simulation these interactions can be taken into 7

account. 8

The heating/cooling potential of the exchanger is shown in Figure 16. It is calculated from the 9

difference in temperature inside the house and temperature at the outlet of the heat exchanger. As can be 10

seen, it depends on the design and varies over the day. In the early and late hours the greenhouse is heated 11

by the earth to air heat exchanger and in the mid day it is cooled down. 12

1 Figure 16 Change in ventilation heat capacity provided by the ground heat exchanger, calculated on the 2

basis of difference in zone and outlet temperature of the exchanger 3

4

IN CONCLUSION 5

The external run-time coupling approach promises to be very flexible in several respects. Current 6

limitations of non-shared developments in HVAC component modeling can be easily overcome as the 7

various parts of a building with systems configuration can be simulated in different environments. 8

Additionally, a varied level of detail of a simulation models can introduce better correlation: fidelity in 9

obtained results vs. simulation goals as well as the improved behavior of the simulation models that can 10

have varied time management schemes. 11

We recognized the potential of distributed simulation use in the building performance simulation and 12

explored its benefits. It may be argued that a simulation environment, able to address all the questions 13

which may come up in the design, operation and maintenance of HVAC systems, is like a giant puzzle. We 14

see the work presented here as a small part of this puzzle, which aims to enable the communication 15 between existing tools and in doing so will enable a more flexible use of simulation. 16

However, an extra effort is required to allow legacy tools to interface other (legacy) tools. The 17

approach undertaken in this paper was to construct separate ”interface“ components in each environment. 18

Through the interface components, coupled programs are able to exchange relevant information. Further, 19

the communication is done employing one of the IPC mechanisms. The same IPC mechanism has to be 20

employed by the coupled programs, as well as the sending components has to have knowledge of what data 21

is being received, i.e. mass flow, temperature, control related data, etc. Therefore, a standard protocol is 22

required for external coupling implementation in general. Mostly due to the waiting procedure, employed 23

by the prototypes, the distributed simulation requires longer execution time compared to the monolithic 24

simulation. 25

This paper presented coupling strategies implemented in a prototype. The advantages and 26 disadvantages of each were considered. The implementation of the working prototype has been 27

demonstrated on an example case study. 28

29

30

31

32

REFERENCES 1

Bazjanac, V. and Crawley, D. B. 1999. “Industry foundation classes and interoperable commercial software 2

in support of design of energy-efficient buildings”, in proc. 6th International IBPSA conference, 3

Kyoto, Japan, pp. 661-667. International Building Performance Simulation Association. 4

Boer, C. A. 2005. “Distributed simulation in industry”, PhD thesis, Erasmus University Rotterdam. 5

Bring, A, Sahlin, P, and Vuolle, M. 1999. “Models for building indoor climate and energy simulation”, a 6

report of task 22: Building energy analysis tools, Stockholm, International Energy Agency Solar 7

Heating & Cooling Programme. 8

Buss, A. H. and Jackson, J. 1998. “Distributed simulation modeling: a comparison of HLA, CORBA, and 9

RMI”, 1998 Winter Simulation Conference, pp. 819-826. 10

CSTB. 2003. “Type 155 - a new TRNSYS type for coupling TRNSYS and Matlab”. 11

http://software.cstb.fr/articles/18.ppt, accessed: December, 2005. 12

Curtil, D. 2004. personal communication 13

Djunaedy E., Hensen J.L.M. and Loomans M.G.L.C. 2003. “Towards external coupling of building energy 14

and air flow modeling programs”, in ASHRAE Transactions, , vol. 109:2, pp. 771-787, American 15

Society of Heating, Refrigerating, and Air-Conditioning Engineers, Atlanta, GA. 16

Dorer, V. and Weber, A., 1997. “ Multizone Air Flow Model COMVEN-TRNSYS; TRNSYS Type 157”, 17

EMPA 175, CH-8600 Dübendorf, Switzerland, for IEA-ECB Annex 23 18

Forbus K.D. 1996. “Qualitative reasoning”, The Qualitative Reasoning group, Institute for the Learning 19

Sciences, NorthWestern University, Evanston, IL, USA, DRAFT: Chapter for the CRC handbook of 20

computer science. 21

Fujimoto, R. M. 2003. “Distributed simulation systems”, 2003 Winter Simulation Conference, pp. 124-134. 22

Fujimoto, R.M. 2005. “Parallel and distributed simulation - introduction and motivation”, Georgia Institute 23

of Technology, College of Computing. 24

http://www.cc.gatech.edu/classes/AY2003/cs4230_fall/Lectures/01-intro%20(8-20-02).ppt, accessed: 25

December 2005. 26

Follen, G., Kin, C., Lopez, I., Sang, J., and Townsend, S., 2001. “A CORBA-based development 27

environment for wrapping and coupling legacy scientific codes”, 10th IEEE International Symposium 28

on High Performance Distributed Computing, pp. 22-31. 29

Ganse, A. 2005. “Distributed processing”, University of Washington, Seattle. 30

http://staff.washington.edu/aganse/presentations/EIS_Distributed_Systems.ppt, accessed: December 31

2005. 32

Ghosal M.K., Tiwari G.N., and Srivastava N.S.L., 2004. “Thermal modeling of a greenhouse with an 33

integrated earth to air heat exchanger: an experimental validation” in Energy and Buildings, vol. 36, 34

no. 3, pp. 219-227, Mar. ’04. 35

Hensen J.L.M. 1991. “On the thermal interaction of building structure and heating and ventilating system”. 36

PhD thesis, Eindhoven University of Technology. 37

Hensen J.L.M. 1996. “Application of modelling and simulation to HVAC systems”, in proc. 30th Int. Conf. 38

MOSIS '96, Krnov, Technical University of Ostrava (CZ). 39

Hensen J. L. M. 1999. “A comparison of coupled and de-coupled solutions for temperature and air flow in 40

a building” in ASHRAE Transactions 105, pp. 962-969 41

Hensen J.L.M., Clarke, J.A. 2000. ”Building systems and indoor environment: simulation for design 42

decision support”. Architecture (International Conference on Design and Decision Support Systems in 43

Architecture & Urban Planning), pp. 177-189. Eindhoven University of Technology. 44

Hensen J.L.M., Djunaedy E., Radosevic M., and Yahiaoui A. 2004. “Building performance simulation for 45

better design: some issues and possible solutions”, proc. 21st International Conference PLEA. Passive 46

and low energy architecture, pp. 1185-1190, Eindhoven University of Technology. 47

Huang, J., Winkelmann, F., Buhl, F., Pedersen, C., Fisher, D., Liesen, R., Taylor, R., Strand, R., Crawley, 48

D., Lawrie, L., 1999. “Linking the COMIS multi-zone airflow model with the EnergyPlus building 49

simulation program”. Proc. 6th International IBPSA Conference, Kyoto, Japan, International Building 50

Performance Simulation Association. 51

Janak, M. 1997. “Coupling building energy and lighting simulation”, vol. 2, pp. 307-312. proc. of Building 52

Simulation '97. 53

Keilholz, W., 2002. “TRNSYS World-wide”. The journal of the International Building Performance 1

Simulation Association, ibpsaNEWS, Vol. 12. No 1. 2

Li, N., Wang, Z., Liu W.H., Peng, X.Y., and Gong, G.H., 2005, “Research on construction and 3

interoperability of complex distributed simulation system”, Lecture Notes in Computer Science, vol. 4

3398, pp. 131-140. 5

Lockley, S. R., Rombouts, W., and Plokker, W. 1994. “The COMBINE data exchange system”, First 6

ECPPM Conference, Dresden. 7

McGregor, D. 2005. “Moves 3500 - network communication in simulation”, The Moves Institute, Naval 8

Postgraduate School. http://www.movesinstitute.org/~mcgredo/mv3500/lectures/Lecture1.ppt, 9

accessed: December 2005. 10

Moody, D.L., 2005. “Theoretical and practical issues in evaluating the quality of conceptual models: 11

current state and future directions”, Data & Knowledge Engineering, vol. 55, no. 3, pp. 243-276. 12

Page, E. H., Nicol, D. M., Balci, O., Fujimoto, R. M., Fishwick, P. A., L'Ecuyer, P., and Smith, R. 1999. 13

“Panel: Strategic directions in simulation research”, 1999 Winter Simulation Conference, pp. 1509-14

1520. 15

Pollini, L. and Innocenti, M., 2000. “A Synthetic Environment for Dynamic Systems Control and 16

Distributed Simulation”, IEEE Control systems magazine, vol. 20, no. 2, pp. 49-61. 17

Sang, J. C., Follen, G., Kim, C., and Lopez, I., 2002. “Development of CORBA-based engineering 18

applications from legacy Fortran programs”, Information and Software Technology, vol. 44, no. 3, pp. 19

175-184. 20

Strassburger, S., 2001. “Distributed simulation based on the high level architecture in civilian application 21

domains”, PhD thesis, der Otto-von-Guericke Universitat, Magrdeburg. 22

Struler, E. de, Hoefliger, J., Kale, L. V., and Bhandarkar, M. 2000. “A new approach to software 23

integration frameworks for multi-physics simulation codes” in Proc. of IFIP TC2/WG2.5, Working 24

conference on architecture of scientific software, pp. 87-104. Ottawa, Canada. 25

Taylor, S. J. E., Bruzzone, A., Fujimoto, R. M., Ping Gan, B., Strassburger, S., and Paul, R. J. 2002. 26

“Distributed simulation and industry: potentials and pitfalls”, pp. 688-694. 2002 Winter Simulation 27

Conference. 28

TESS. 2003. EnergyPlus - TRNSYS PV http://www.tess-inc.com/tess/eplus.htm, accessed: December 29

2005. 30

Tiller M.M. 2001. ”Introduction to physical modeling with modelica”, Kluwer Academic Publisher, 31

Norwel, Massachusetts. 32

Trcka (Radosevic), M, Hensen, J.L.M., and Wijsman, A.J.Th.M., 2006a. “Integrated building and system 33

simulation using run-time coupled distributed models”, ASHRAE Transactions in press. American 34

Society of Heating, Refrigerating, and Air-Conditioning Engineers, Chicago, Illinois. 35

Trcka (Radosevic), M and Hensen, J. L. M. 2006b. “Performance prediction of a building with 36

underground thermal storage using distributed simulation approach”, submitted for 17th Air-37

conditioning and Ventilation Conference, Prague, CZ, 2006. 38

Wilcox, P. A., Burger, A. G., and Hoare, P., 2000. “Advanced distributed simulation: a review of 39

developments and their implication for data collection and analysis”, Simulation practice and theory, 40

vol. 8, no. 3-4, pp. 201-231. 41

Yahiaoui, A., Hensen, J., & Soethout, L. 2004. “Developing CORBA-based distributed control and 42

building performance environments by run-time coupling”, in proc. ICCCBE-X 10th International 43

Conference on Computing in Civil and Building Engineering in Weimar, International Society for 44

Computing in Civil and Building Engineering, pp. 86 (8 pages on the CD). 45

Yahiaoui, A., Hensen, J. L. M., and Soethout, L. 2003. “Integration of control and building performance 46

simulation software by run-time coupling”, Proc. 8th International IBPSA Conference, Rio de Janeiro, 47

Brazil, pp. 1435-1442. International Building Performance Simulation Association. 48

Zhai, Zhiqiang. 2003. “Developing an integrated building design tool by coupling building energy 49

simulation and computational fluid dynamics programs”, PhD thesis, Massachusetts Institute of 50

Technology. 51

52

53

LIST OF CAPTIONS FOR FIGURES 1

Figure 1 2 External run time coupling 3

4

Figure 2 5

Distributed modeling and simulation 6

7 Figure 3 8

Interprocess communication (IPC) taxonomy (McGregor 2005) 9

10 Figure 4 11

Flow chart of the decision-making methodology 12

13 Figure 5 14

External coupling necessity: “-” – inadequate approach for specific schema; “+” – applicable approach 15

for specific schema; “o” – refers to an approach that is applicable for specific schema, but more 16

complex than its alternative and does not bring extra benefits. 17 18

Figure 6 19

External coupling mechanism for a discontinuous running external program 20

21

Figure 7 22

External coupling mechanism for a continuous running external program 23

24 Figure 8 25

Simple HVAC network modeled in distributed fashion 26

27 Figure 9 28

Influence of coupling strategy on zone temperature calculation with different coupling time steps 29

30 Figure 10 31

Inter and intra time step data exchange with an external component assuming that the base program 32

uses a fully implicit numerical scheme 33

34 Figure 11 35

Inter and intra time step data exchange with an external component assuming that the base program 36 uses a fully explicit numerical scheme 37

38 Figure 12 39

Inter and intra time step data exchange with an external component assuming that the base program 40

uses an input-output based approach 41

42 Figure 13 43

External coupling implementation in ESP-r within one time step 44

(MZPADJ, CONTRL, MZPMSU, and MZNASS are ESP-r-specific subroutines) 45

46 Figure 14 47

Greenhouse coupled to an earth to air heat exchanger 48

49 Figure 15 50

Air temperature profiles: ambient temperature, zone temperature for free floating conditions, zone and 51 outlet temperatures from ground coupled heat exchanger for design 1 and 2 52

53 Figure 16 54

Change in ventilation heat capacity provided by the ground heat exchanger, calculated on the basis of 1

difference in zone and outlet temperature of the exchanger 2

3