ESP-r Cookbook Dec 2010

THE ESP-r COOKBOOK

Strategies for Deploying Virtual Representations

of the Build Environment

Jon William Hand B.Sc., M.Arch., PhD

Energy Systems Research UnitDepartment of Mechanical EngineeringUniversity of Strathclyde, Glasgow, UK.

2 December, 2010

COPYRIGHT DECLARATIONThe copyright of this publication belongs to the author under the terms of theUnited Kingdom Copyright Acts as qualied by the University of StrathclydeRegulation 3.49. Due acknowledgement must always be made of the use of anymaterial contained in, or derived from, this publication.

This document is designed to be printed in one of the following formats:Tw o pages per sheet of A4 or B4 paperAt 85% scale on A4 paper (wide margins for notes)At 100% scale on A5 or B5 paper

It is designed to take less space on the screen than the previous edition.

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . vAcknowledgements . . . . . . . . . . . . . . . . . . . vi1 Introduction . . . . . . . . . . . . . . . . . . . . . 1

1.1 Tactical approaches . . . . . . . . . . . . . . . . . 41.2 The client specication . . . . . . . . . . . . . . . 61.3 Design questions . . . . . . . . . . . . . . . . . 81.4 Model planning . . . . . . . . . . . . . . . . . . 91.5 Model coordinates . . . . . . . . . . . . . . . . . 101.6 How the building is used . . . . . . . . . . . . . . . 141.7 Environmental controls . . . . . . . . . . . . . . . 181.8 Model composition . . . . . . . . . . . . . . . . . 21

2 Building a model . . . . . . . . . . . . . . . . . . . 232.1 Review of climate patterns and databases . . . . . . . . . . 272.2 Locating constructions for our model . . . . . . . . . . . 322.3 Zone composition tactics . . . . . . . . . . . . . . . 342.4 Model topology . . . . . . . . . . . . . . . . . . 51

3 Geometry alternative inputs . . . . . . . . . . . . . . . . 543.1 To the keyboard . . . . . . . . . . . . . . . . . . 553.2 Clicking on a bitmap . . . . . . . . . . . . . . . . 593.3 Examples of approaches to take . . . . . . . . . . . . . 60

4 3D Modelling . . . . . . . . . . . . . . . . . . . . 654.1 Modelling approaches . . . . . . . . . . . . . . . . 664.2 Steps to create a roof space . . . . . . . . . . . . . . 70

5 Schedules . . . . . . . . . . . . . . . . . . . . . 775.1 Scheduled air ows . . . . . . . . . . . . . . . . . 815.2 Importing operation schedules . . . . . . . . . . . . . 81

6 Climate data . . . . . . . . . . . . . . . . . . . . 846.1 Importing climate data . . . . . . . . . . . . . . . . 866.2 Dening seasons and typical periods . . . . . . . . . . . 876.3 Climatelist entries . . . . . . . . . . . . . . . . . 91

7 Zone environmental control . . . . . . . . . . . . . . . . 957.1 Introduction . . . . . . . . . . . . . . . . . . . 957.2.1 Abstract representations . . . . . . . . . . . . . . 957.2.2 Abstract example . . . . . . . . . . . . . . . . 97

7.3 Zone control laws . . . . . . . . . . . . . . . . . 997.4 Exploring building control issues . . . . . . . . . . . . 1017.4.1 Basic (ideal) control . . . . . . . . . . . . . . . 1017.4.2 Interpreting control predictions . . . . . . . . . . . . 106

7.5 Controls implementing boundary zones . . . . . . . . . . 111

8 Thermophysical resolution . . . . . . . . . . . . . . . . 1168.1 Shading and insolation . . . . . . . . . . . . . . . . 1168.2 Shading predictions . . . . . . . . . . . . . . . . . 1198.3 Radiation view factors . . . . . . . . . . . . . . . . 121

9 Preparation for simulation . . . . . . . . . . . . . . . . 1299.1 Integrated performance views . . . . . . . . . . . . . 1319.2 Results libraries and reports . . . . . . . . . . . . . . 1369.3 XML output directives . . . . . . . . . . . . . . . . 1409.4 XML user interactions . . . . . . . . . . . . . . . . 144

10 Understanding performance predictions . . . . . . . . . . . . 14910.1 The res module . . . . . . . . . . . . . . . . . . 14910.1.1 Enquire about . . . . . . . . . . . . . . . . . 15110.1.2 Environmental systems reporting . . . . . . . . . . . 15310.1.3 Casual gains . . . . . . . . . . . . . . . . . 15310.1.4 Zone energy balances . . . . . . . . . . . . . . . 15410.1.5 Surface energy balances . . . . . . . . . . . . . . 15510.1.6 Hours above and below . . . . . . . . . . . . . . 15610.1.7 Energy delivered . . . . . . . . . . . . . . . . 15710.1.8 Condensation reports . . . . . . . . . . . . . . . 159

10.2 Timestep reporting . . . . . . . . . . . . . . . . 16010.3 Graphic reporting . . . . . . . . . . . . . . . . . 16110.3.1 Variables against time . . . . . . . . . . . . . . 16110.3.2 Fruency bins . . . . . . . . . . . . . . . . . 16210.3.3 3D surface plots . . . . . . . . . . . . . . . . 16310.3.4 Variable vs variable graphs . . . . . . . . . . . . . 164

10.4 Methods for exploration of data sets . . . . . . . . . . . 16511 Flow networks . . . . . . . . . . . . . . . . . . . . 168

11.1 Limitations of Scheduled Flow . . . . . . . . . . . . . 16811.2 Fluid Flow Networks . . . . . . . . . . . . . . . . 16811.3 Building blocks . . . . . . . . . . . . . . . . . 17011.3.1 Flow components . . . . . . . . . . . . . . . . 17111.3.2 Flow connections . . . . . . . . . . . . . . . . 172

11.4 Steps in creating a network . . . . . . . . . . . . . . 17411.5 A simple network . . . . . . . . . . . . . . . . . 17611.6 To the keyboard... . . . . . . . . . . . . . . . . . 17911.7 Calibrating ow models . . . . . . . . . . . . . . . 18311.8 Flow control . . . . . . . . . . . . . . . . . . 18611.9 To the keyboard... . . . . . . . . . . . . . . . . . 18811.10 Window representations . . . . . . . . . . . . . . 19111.10.1 Component selection . . . . . . . . . . . . . . 194

11.11 Schedules vs networks . . . . . . . . . . . . . . . 19611.12 Hybrid ventilation . . . . . . . . . . . . . . . . 20211.13 Limitations of Network ow models . . . . . . . . . . 206

12 Detailed ow via CFD . . . . . . . . . . . . . . . . . 20813 Plant . . . . . . . . . . . . . . . . . . . . . . . 211

13.1 Using a network to represent mechanical ventilation . . . . . . 21213.2 Dening containments . . . . . . . . . . . . . . . 21813.3 Finishing off the model and testing . . . . . . . . . . . 21813.4 Moving from ideal demands to thermal zone demands . . . . . 22113.5 Links to zones and controls . . . . . . . . . . . . . . 225

14 Working procedures . . . . . . . . . . . . . . . . . . 23014.1 How can the vendor help? . . . . . . . . . . . . . . 23114.2 Responsibilities within simulation teams . . . . . . . . . . 23214.3 Classic mistakes . . . . . . . . . . . . . . . . . 23214.4 Planning simulation projects . . . . . . . . . . . . . 23414.5 Team manager . . . . . . . . . . . . . . . . . . 23614.6 The quality manager . . . . . . . . . . . . . . . . 23714.7 Simulation staff . . . . . . . . . . . . . . . . . 24014.8 The mentor . . . . . . . . . . . . . . . . . . . 24414.9 The domain expert . . . . . . . . . . . . . . . . 24614.10 Infrastructure . . . . . . . . . . . . . . . . . . 24814.11 Support staff . . . . . . . . . . . . . . . . . . 24914.12 Staff productivity . . . . . . . . . . . . . . . . 25014.13 Tool selection . . . . . . . . . . . . . . . . . . 25114.14 Summary . . . . . . . . . . . . . . . . . . . 252

15 Model Quality . . . . . . . . . . . . . . . . . . . . 25415.1 How can the vendor help? . . . . . . . . . . . . . . 25415.2 Responsibilities within simulation teams . . . . . . . . . . 25515.3 Model planning . . . . . . . . . . . . . . . . . 25815.4 Complexity . . . . . . . . . . . . . . . . . . . 26015.5 Multi-criteria assessments . . . . . . . . . . . . . . 26115.6 Semantic checks . . . . . . . . . . . . . . . . . 26415.7 Team Checklists . . . . . . . . . . . . . . . . . 26815.8 Simulation outputs . . . . . . . . . . . . . . . . 27415.9 The model contents report . . . . . . . . . . . . . . 27915.10 Summary . . . . . . . . . . . . . . . . . . . 289

16 Install Appendix . . . . . . . . . . . . . . . . . . . 29117 Version Appendix . . . . . . . . . . . . . . . . . . . 299

17.1 Text mode . . . . . . . . . . . . . . . . . . . 29917.2 Legacy X11 graphics . . . . . . . . . . . . . . . . 30217.3 GTK+ graphics . . . . . . . . . . . . . . . . . . 304

18 ESP-r capabilities . . . . . . . . . . . . . . . . . . . 30718.1 General modelling features . . . . . . . . . . . . . . 30818.2 Zone Loads . . . . . . . . . . . . . . . . . . . 30918.3 Building envelope and day-lighting . . . . . . . . . . . 31018.4 Inltration ventilation and multi-zone air ow . . . . . . . . 311

18.5 Renewable energy systems and electrical systems . . . . . . . 31218.6 Ideal environmental controls . . . . . . . . . . . . . 31318.7 Component based systems . . . . . . . . . . . . . . 31418.8 Environmental emissions . . . . . . . . . . . . . . 31518.9 Climate data . . . . . . . . . . . . . . . . . . 31518.10 Results reporting . . . . . . . . . . . . . . . . . 31618.11 Validation . . . . . . . . . . . . . . . . . . . 317

ABSTRACTThis Cookbook uses the general purpose simulation suite ESP-r as a platform toexplore strategies for deploying virtual representations of the built environment toanswer questions posed in the real world of design and research groups.The Cookbook talks about translating client questions into virtual representationsthat are no more and no less complex than is required for the task. It talks about re-discovering the power of pencils and paper and it dares to mention the word method-ology. And discovering valuable patterns in the clutter and then learning the art ofresponding to what if questions. And since the author is professionally paranoid youmight pick up some new denitions of the word QA.Almost all of the strategies presented can be applied to the task of creating elegantvirtual representations in other simulation suites. Readers might alert their col-leagues to take a peak.

v

ACKNOWLEDGMENTS

This book could have been completed only within the exceptional group envi-ronment of the Energy Systems Research Unit of the University of Strathclydein Glasgow Scotland. Where else could an architect compose tens of thousandsof lines of source code and then use the resulting virtual edice to explore andsupport the design process and then turn the process on its head to return to thewritten page to explore strategies of its use.The author would also like to acknowledge the time which Samsung Construc-tion allowed the author during a period of secondment in Seoul.

vi

Chapter 1

INTRODUCTION

1 Introduction

The design process proceeds on thebasis of the beliefs the design teamholds about how the current design sat-ises the needs of the client. Sketchesindicating interactions of heat and lightand the movement of air are statementsof belief. Simulation can be used to testthe beliefs of the design team.For example, some Architects andEngineers operate on the assumptionthat buildings constantly requiremechanical intervention. Is thisassumption true? Rather than assumethat buildings do not work, let’s testhow often buildings work well enoughto satisfy occupant requirements with-out intervention.Many design methods focus onextreme conditions and ignore whathappens at other times. What is thecost of this? Instead of ignoring transi-tion seasons, let’s explore the nature ofthe building’s response to these tran-sient climate patterns and, by under-standing the pattern of demands, deviseenvironmental control regimes whichwork well in part-load and intermittentscenarios.Some design methods assume thatchanges dictated by value engineeringhave little or no impact on systems andcontrol response or running costs orcomfort. Folk-lore suggests there is

considerable risk in this assumption.Although we can test whether a partic-ular design variant alters performancecriteria that are important to the client,the process of undertaking such assess-ments has a cost. We need criteria toguide us in determining when a designvariant warrants attention, how wemight approach such assessments, howbest to employ numerical tools, how tointerpret the performance data and thentranslate what we learn into the realworld.Learning how to use simulation toolsfor design decision support and forresearch has tended to follow threepaths - the mentor path, the workshoppath and the there-be-dragons path.The mentor path works exceedinglywell and is an efcient, if not particu-larly inexpensive way of gaining theskills and tactics needed to apply simu-lation to real-time projects.Workshops are another successfulapproach to simulation training. Two orthree days of initial sessions, supple-mented by advanced topic workshopsand the occasional email allows manypractitioners to productively use simu-lation. Both of these approaches relyon personal contact with an expert anditerations of demonstration, followedhands-on experience and dialogue forskills acquisition.

1

Many practitioners rely on mentoringand workshops to keep them up to dateas tools evolve and for exploring newfacilities. Documentation tends to lagthe evolution of simulation tools andmany lesser-used tasks may not be welldocumented or documented in waysaccessible only to geeks.What you are reading now (and thecompanion Cookbook Exercises isaddressed primarily at those who aretaking the path of confronting the drag-ons. It has also been used to supportworkshops in conjunction with theexercise volume.The Cookbook strives to be generic inits discussion. As the title suggests,where specic examples are neededthey are based on the ESP-r suite.Some blocks of text apply only to ESP-r and occasionally you may notice thefollowing icon...

If you are reading this from the pointof view of another application skipdown a few paragraphs.The Cookbook also includes sections ofinterest to technical support staff anduber-geeks. These are marked with thefollowing icon...

If you have downloaded one of the pre-compiled ESP-r distributions for Linux(most distributions), Mac OSX, Win-dows (native GUI), Cygwin (emulationunder Windows) from the ESRU website <http://www.esru.strath.ac.uk> oracquired the source from the sourcecode control repository via the uber-

geek command (on one line):svn checkout https://esp-r.net/espr/esp-r/branches/development_branch

and compiled your own version. Mostof the instructions needed to get aworking distribution can be found onthe download page. Additional instruc-tions are included with the source andthere are discussion lists that mightprovide additional clues.

And the ESP-r download pages do notreally tell you much about what to doonce you have ESP-r on your com-puter. This statement is probably appli-cable to most other vendors. Of coursethere are web based tutorials and exer-cises as well as manuals that approachtelephone directory proportions.Most vendors went through a phasewhere they believed that web basedtutorials would supplant mentoring andworkshops. From the author’s perspec-tive, web pages work less well than thementor/workshop paths. The Cookbookis an attempt to bridge this gap. Itev olves, as does ESP-r itself, fromobservations of practitioners who areattempting to support real-time designassessments of real-world issues.Simulation tools almost always arrivewith a range of example models of twobroad types - abstract models whichare composed so as to illustrate seman-tics and syntax and those modelsderived from consulting projects whichfocus on specic building performancedesign issues. The rst type is oftenused by novices to get used to the sim-ulation tool, the second type for thosewho are looking for examples of best

2

practice models. Vendors do not alwaysmake clear which is which.Example models contain a wealth ofinformation for those who know whatthey are looking for, for those who arepersistent or for those who are usingthem as reference materials within thecontext of a workshop or in mentorbased training. For these users examplemodels can act as:• a mechanism for exploring the tool

(e.g. where do I nd out informationabout environmental controls, thecomposition of walls)

• to explore the sequence of tasksrequired to run an assessment andrecover specic performance metrics

• to explore incremental changes inthe description of the model and theperformance implications of suchchanges

Creating a model from scratch underclose supervision and with commen-tary on the approach taken does reducethe frequency of encounters-with-dragons. In ESRU workshops almostall participants rst model works cor-rectly the rst time it is simulated.What you are currently readingexpands on existing workshop materi-als and years of mentoring, recast forthe resolution of the printed page.The goal is not simply to act as a dic-tionary or reference but as a guide tohow to approach realistic design deci-sion support in real time, deliveringreal information and still have time fora cup of coffee at the end of the day.This document is based on the premissthat readers will already have an intu-ition about the physics of buildings and

environmental systems. A future revi-sion is planned for those who are lessopinionated. And for readers who areusers of other tools there will be muchof value even if the details of imple-menting the methods differs. Whoknows, someday there may be an Ener-gyPlus Cookbook and an EE4 Cook-book.

A word about ESP-r versionsESP-r is under active dev elopment. Onany giv en day there may be a halfdozen commits of code or documenta-tion or updates to exemplar models tothe repository. This Cookbook ev olvesat a slower pace. This 2008 versionhas been revised to match the evolvedinterface of ESP-r but that match islikely to be imperfect. Interface entitiesand paths such as Model Management-> browse/edit/simulate ->composition -> geometry &attribution may have a differentsyntax. If you don’t nd a match,please look around for something simi-lar.You may also notice is that some inter-face related gures in the Cookbooklook different from what you see on themonitor. There are currently three dif-ferent interfaces for ESP-r. There isthe traditional X11 interface which hasits roots in the world of UNIX andLinux. There is an almost completeport of ESP-r to a graphic library calledGTK. GTK is implemented on a dozenoperating systems and this allows ESP-r to be run as a native Windowsexecutable. It also has a more familiarlook and feel and once the port is com-plete it will be the primary interfaces toESP-r. The third interface is a pure-text

3

interface which tends to be used forscripted production work or to enableESP-r to act as a background enginefor other software. Look in the VersionAppendix to see typical dialogues fromthe different interfaces.With the exception of le browsingfacilities, the command sequenceneeded to undertake most tasks isalmost identical across each of theinterfaces. Where facilities differ youmay see one of the following icons fol-lowed by specic instructions...

1.1 Tactical approachesDepending on your personal prefer-ences, getting acquainted with a simu-lation tool either begins with exploringexisting models (in ESP-r these arecalled exemplars) or in the context ofcreating a model from scratch.If you are taking the from scratch routegrab a note-pad and some sketch paper.The following sections explore howyou can use ESP-r to arrive at a work-ing simulation model and a growing setof simulation skills. If you are using adifferent simulation suite keep reading.Tactics can almost always be applieduniversally.Lets begin by deciding what kind ofmodel we are going to make and thenplan the work so that it ts ourresources. This is a tactical approachto simulation which concentrates onthe art of making concise models toanswer our clients questions without

delaying the design process.The rst table is a powerful dragonslayer. Clients ask us questions - butwhat are the questions we ask our-selves as we plan and then composeour virtual worlds?

4

Table 1.1 Initial tactics:

Design Question Simulation questionsWhat do we want to knowabout the design?

What thermophysical issues should be addressed by themodel?

How do I know if thedesign works?

What performance can I measure to inform my judgements?What level of model detail is required for this?

How might the design fail? What boundary conditions and operating regimes would bea reasonable test?

How do I match the infor-mation I have with therequirements of the tool?

What is the essence of the design in terms of form, compo-sition, operation and control?What essential interactions need to be represented?What facilities can be employed and what skills are neededto use them?

Is our approach ok? Can I sketch out my model and explain it to others?

Are the performance pre-dictions credible?

What assessments need to be undertaken to gain condencein the model?What is expected of a best practice design?

How can I deliver the mostvalue for my client?

What else would clarify how the design works?How might the design and the model evolve during thedesign process?What would I do now to make it easier to work with thismodel again after a four month delay?

Without tactics we will miss out on thevalue-added aspects of simulationwhich cost us little to implement butdeliver substantial benets. A tacticalapproach keeps you in charge of thesimulation tool.Simulation models have a contextwithin which they are created andev olve. In the next section the clientsspecication and design questions formthe context. From this we decide whattype of model(s) the specicationimplies as well as the assessment(s)that need to be done to answer the

clients questions or further our researchgoals. The plural is intentional - realprojects are iterative and models eitherev olve or spawn the next generations ofmodel.

5

1.2 The client specificationThe following section provides thespecication of our rst project. It isdesigned to allow an exploration of thebest-practice choices made while plan-ning simulation projects.

No matter what simulation tool youare using, there is always more thanone approach to a given task. Work-shops typically use sequences thatare known to work. Mentors willencourage you to explore alternativeapproaches. Enlightened managersallocate time for such explorations.

This initial simulation project is part ofa general practitioner’s ofce. Theclient specication is intentionallyterse so as to demonstrate typical deci-sions made by simulation teams inpractice. Clients have beliefs abouthow buildings work and simulation isone approach which can be used toconrm or refute such beliefs.Figure 1.1 shows a plan and section(looking from the east) of the generalpractitioners ofce. The reception has aat roof and the examination room hasa sloped roof with a skylight to thenorth.Figure 1.2 is a wireframe perspectiveview (looking from the south-west).Note the strip windows on the north ofthe reception and the two strip win-dows on the south facade.

4.0

7.0

3.0 x 0.75

1.5

1.0

1.53.0 x 0.75 3.0x0.75

4.0

3.0

2.0

0.75

2.1 3.0

1.580%

Section looking west

4.0

Figure 1.1 Plan and section of generalpractitioner ofce.

Figure 1.2 Wire-frame view of generalpractitioner ofce.

Figure 1.3 is a colour rendering (look-ing from the south-west) which wascreated by exporting the ESP-r model

6

to Radiance.

Figure 1.3 South-west view of generalpractitioner ofce.

Figure 1.4 is a view from the north-west through the examination room.The white surfaces represent wallswhich are partitions to a portion of thebuilding which has not been includedwithin the model.

Figure 1.4 North-west view of generalpractitioner ofce.

This project represents a portion of ageneral practitioner’s ofce. Focus-ing initially on a portion of a buildingis a powerful strategy and one whichis applicable to almost all simulationtools.

The client indicates that this medicalpractice has a brisk turn-over of clientsand that, on average, there are two peo-ple in the examination room during thehours of 9h00 to 16h00 on weekdays(200W sensible, 100W latent). Thereception area serves other portions ofthe building which are not included inthis model and there might be up tove people. Lighting in the receptionis 150W during the hours of 8h00 to19h00 and there are no small powerloads in either room for purposes ofthis model.The heating set point is 20°C and thecooling set point is 23°C between 9h00and 17h00 on weekdays with frost pro-tection (15°C) on weekends. Theclient has no specic opinion as to howthis is to be achieved.ESP-r, unlike some simulation suites,includes both ’ideal zone controls’ andcomponent based descriptions of envi-ronmental systems. In this exercise wewill start with a minimalist ’ideal’description and assume that both heat-ing and cooling are assumed to bedelivered convectively. ESP-r demandsan initial guess at the heating and cool-ing capacity, but otherwise we willmaintain our focus on demand sideissues.

7

Questions to ask about auto-sizefunctions:a) what boundary condition(s) andoperational regime(s) are associatedwith peak conditions?b) what method(s) are used to assessintra-component dependencies ascomponents are sized?c) what criteria are used to determinewhich sub-optimal set of componentsizes works best?d) what criteria might you use to con-rm the suggested sizes?

Components might seem unambigu-ous. Be sceptical until you can con-rm that they match your expecta-tions.

Back to our initial model. Even the bestof buildings have inltration. There is adiscussion about air ows in a latersection. For now lets use an initialengineering assumption that there willbe 0.5 ac/hr inltration at all hours.

1.3 Design questionsThe client wants to know what the typ-ical demands for heating, heatingcapacity, thermal comfort in the winterand summer, whether it is likely tooverheat and if the daylight distributionis ok.To answer these questions we require amodel which represents the general

form, composition and use as describedin the client specication. The modelneed not be particularly detailed andour goal is to maintain the volume ofthe spaces as well as the orientation,area, distribution of mass and generalshape of the room surfaces.Review Table 1.1. If the client askeddifferent questions the nature of theassessments might well be different.So, what sort of assessments willaddress the question of typical heatingand cooling demands, capacity andcomfort? If we weren’t thinking tacti-cally we might run an annual simula-tion and then get bogged down in scan-ning the predictions for useful informa-tion.

A tactical approach limits the quan-tity of information we have to deal soboth the model and its performance iseasier to understand and the QA bur-den is reduced. Lets look rst onseasonal patterns to highlight perfor-mance issues. Computers mayprocess a year in seconds but QAstaff costs are greater.

The key initial objective is to supportour own understanding of performanceby looking at patterns in a limited setof data and so be able to spot glitchesin our model as well as opportunitiesfor improvements to the design (or theclients specication) as soon as possi-ble.Value added: The client did not ask forit, but it takes little extra effort to check

8

for typical spring and autumn perfor-mance might provide useful feedbackto the design team.Another tactic is to dene performancemetrics (e.g. what can we measure inour virtual world) early in the process.Some metrics e.g an energy balancewithin a zone, might contribute to ourown understanding of the design andother metrics e.g. thermal comfortmight be useful to report to others inthe design team.ESP-r workshops typically devote asmuch time to exploring building per-formance issues as is spent on modelcreation. Simulation suites which donot include an interactive explorationfacility will include a descriptive lan-guage to specify what performancemetrics are to be captured during eachassessment - so learn that language!The metric for heating and coolingdemands is kWhr (integrated) over theweek and for capacity the metric isdiversied kW (the peak capacityrequired for this portion of the build-ing). Just to be sure that the pattern ofdemand is reasonable we will want tograph this. In addition to a table ofdemands and capacity we mightinclude the graph in our report if itproves of interest.Resultant temperature is a commoncomfort metric. A frequency bin ofresultant temperatures during the occu-pied periods would inform the clientabout the distribution of comfort. Forour own use, we also want to check thenumber of hours over 24°C and graphthe temperatures, we might includethese in our report if they prove inter-esting.

To answer the question about day-lighting we can look at daylight factorsacross a grid in each of the rooms. Tobuild a model that will answer ques-tions of thermal and lighting perfor-mance we need to decide how muchgeometric resolution if required. In thecase of daylight factors the level ofdetail needed for the thermal assess-ment should sufce. If glare was to beassessed the model would need toinclude additional visual geometricdetails. Later on we will consider tac-tics that anticipate probable futuredesign performance questions.

QA tip: Write down these decisions,we will want to review them as theproject progresses to make sure weare working to-the-plan.

1.4 Model planningGet out your grid paper and note padsand keep the laptop lid closed for now.Pre-processing information and sketch-ing the composition of our model willlimit errors and make it easier for oth-ers to understand what we intend tocreate, and, after we have made it, tohelp check that it is correct. This ruleapplies whether we are going to importCAD data or use the in-built CADfunctions of our simulation tool.It also saves time and removes anothersource of error if we convert the impor-tant horizontal and vertical dimensions(such as those shown in Figure 1.1) tomodel co-ordinates and include them inour planning sketches. This avoidsjumping between a keyboard and a cal-culator during model denition as wellas helping in QA tasks

9

User friendly software does notreduce the need for planning orrobust QA. If anything, it is evenmore important to guard againstneedless complexity. Lets call thisavoiding the dark side.

An exercise related to model planningis included in the Cookbook Exerciseswithin Exercise 1.

1.5 Model Co-ordinatesNovice practitioners often proceedunder the assumption that geometricinput consumes the bulk of theirproject time. Seasoned simulationistsknow that geometry takes about a thirdof their project time and they evolvestrategies to help them limit the timespent on creating and checking geo-metric entities (so they will have thetime and attention to leverage value-added opportunities that might arise).An experienced user can generate mod-els with scores of thermal zones that ttogether correctly the rst time. Suchskills can be acquired over time. Weare going to walk before we run, andour initial goal is to create a correctthree zone model for the doctors ofce.In workshops nine out of ten partici-pants create models which simulatecorrectly the rst time. If asked, mostare able to re-create this model withminimal support and in 25-35% lesstime. So even though an experienceduser will out-pace a novice, goodworking practices ensure that even

novices can produce useful models.The approach we take to create theform of the model is as dependant onthe questions we wish to address withthe model as it is on the specics of thebuilding blocks and input facilities thatare offered by the simulation suite.• questions about general comfort and

energy demands at peak and moder-ate climate conditions require only amoderate geometric resolution e.g.correct volume of the space, approx-imate location of doors and windows

• questions related to comfort at a spe-cic location require higher geomet-ric resolution, especially if surfacetemperatures are likely to be varyacross a surface

• question related to visual comfortwill require higher geometric resolu-tion for facades and may require thatfurniture within rooms and outsideobstructions be accounted for

• questions related to the distributionof air temperature within a physicalspace may require that it be repre-sented by more than one thermalzone or that it include a CFD domain

• questions related to passive solarperformance may require a higherlevel of geometric and constructiondetail to assess the impact of massand the distribution of solar radiation

Each of these issues require that werst consider the physics underpinningthe assessment. Second we must searchthe available model building blocks forrelevant entities. Lastly we must con-sider what resolution to apply thoseentities within our model.

10

For example, a passive solar designwill be sensitive to heat stored in thefabric of the room as well as details ofglazing in the facade and in partitionsto adjacent rooms. The surface temper-atures in a sun patch might be substan-tially elevated. To nd out where thesun falls in the room at different timesof the year we might create a roughmodel and then check what we can seein a wire-frame view at different timesof the year. Our goal would be to ndout if we need to subdivide surfaces tobetter reect the temperature differ-ences in insolated and un-insolatedportions. We can then make a variantof the zone with higher geometric reso-lution and compare the predicted sur-face temperatures.As a general rule the design of modelsshould ensure that the volume of the airis close to the correct value just as wewant to ensure that the surface area iscorrect and that mass within the roomsis appropriately distributed.In the doctors ofce the windows arenot large and the questions are generaland so the exact location of the win-dows is not critical (but it costs usnothing to place them accurately).The dimensions shown in Figure 1.1should be straightforward to represent.Looking closer, there is no thicknessindicated so the criteria used to arriveat the dimensions is unclear. If youwere tasked with determining dimen-sions from information supplied by aclient a set of rules would be useful.• Where the volume of the space is

large with respect to the thickness ofthe facade and where the complexityof the facade is low it is common to

measure from the inside face of exte-rior walls.

• Measuring partitions at each face iscommon where the co-ordinates aretaken from CAD drawings and at thecentre line during the sketch stage.

• Ceiling voids or raised structuraloors with little or no air movementare often represented as layers of airin constructions. Where airmovement is likely or there are sig-nicant heat gains within the voidthey may be better represented as aseparate thermal zone.

• As ceiling (below) to oor (above)distances increase it makes sense totake the height co-ordinates literallyand geometrically separate levelswithin buildings.

There are ESP-r exemplar modelswhich have the zones on each side of apartition in the same plane and otherexemplars have zones separated inspace. In most simulation tools it is amatter of personal preference becausethe heat ow between zones is estab-lished by specic directives partn_corin office is connected with partn_off incorridor which are separate from thegeometric denition.Most simulation tools represent geom-etry as polygons and separately repre-sent their composition. Wire-framedisplays often present models as hav-ing walls of little or no thickness. Formodern (thin) construction the wire-frame display may provide an imagethat allows us to forget that real wallshave thickness.

11

Consider the modern ofce construc-tion in Figure 1.5 there will be little orno change in predictions whether thecentre line or the actual location inspace is used. Given that there aredoors in the partition there is a strongcase for adopting the centre line toavoid visual confusion.

Figure 1.5 Plan of a modern building.

At the other extreme, historical build-ings can have exterior walls and parti-tions which vary in thickness and aresubstantially different from the thick-ness of doors. In Figure 1.6 the insideand outside faces are multi-faceted theshape of the window surround inu-ences the distribution of light withinthe room. Some partitions are thinenough to be treated as centre lines andothers suggest a separation of the ther-mal zones.

Figure 1.6 Plan of a historic building.

Translating the historical plan into amodel required a number of decisionsto represent in one dimensional heatow paths a building which is a sub-stantially three dimensional heat owproblem. The result, shown in Figure1.7, substantially retains the volumeand positions of the spaces rather thanthe exterior form of the building. Thinpartitions are taken to the centre line.Some plan detail has been omitted andminor spaces amalgamated into adja-cent rooms.Having sketched on an overlay whatwe wanted to transcribe, the actual cre-ation of the initial extruded form of therooms was accomplished in a matter ofminutes via a click-on-bitmap facility.

12

Figure 1.7 Model of a historic building.

The geometry at the window heads andsills was then adapted and the doorsinserted. When attributing the surfaces,the associated construction wasselected to account for the local crosssection.A further discussion about options forinterpreting complex three dimensionaldesigns into appropriate models can befound in Chapter 4.The Cookbook is concerned with theart of composing models which arespecically adapted to the needs of thedesign process. Not all projects are asdemanding as the historic building.There is also an art to creating modelswhich are t for the sort of generalquestions posed in the doctors ofce.While planning a model we might askourselves:• would patterns of temperature and

heating change if the volume of thespace was off by the width or a wall?

• would more sunlight enter the roomif a window was lowered by 5cm?

• is it necessary to include the frameof the window?

• is it necessary to include the furni-ture within the rooms?

Essentially our concern is to ensurethat the uncertainty in the model isconstrained to the point where it wouldbe unlikely to change a design deci-sion. Each of the above bullet pointscould, in fact, be tested by creatingmodel variants and then looking at theperformance differences. There aremany simulation groups who haveundertaken such parametric studies toarrive at their rule set. For this initialexercise the rule is keep it simple.The X axis in ESP-r is towards the Eastand the Y axis is towards the North.Most users nd it convenient to keeptheir model in positive co-ordinatesand to dene their model using cardi-nal orientations and later rotate andtransform the model to reect condi-tions at the site.Figure 1.8 shows critical co-ordinates(X,Y) derived from Figure 1.1. To sim-plify our task let us assume that the ori-gin of the model is at the lower left cor-ner of the examination room. The criti-cal vertical points to record on yournotepad are 0.0 (ground), 2.0 (windowsill), 3.0 (ceiling), 4.5 (top of slopedroof).

13

Taking the time to gather and conrmcritical co-ordinates in the plan andsections before going to the keyboardis a key technique in getting-it-right-the-rst-time.

Figure 1.8 Critical dimensions takenfrom the plan.

1.6 How the building is usedOur next stage in the planning processis to deal with how the building is used(schedules of occupants, lighting, smallpower). The client specication mustbe transformed into schedules. Experi-enced user will either sketch the dayschedules or record the time and valuesfor each casual gain data for each daytype just like they did for the co-ordi-nates.Just as dening an appropriate level ofgeometric detail is important, sched-ules can be crafted to test a number ofperformance characteristics within a

single assessment. Why bother?Because a few minutes effort can giveearly clues of how buildings may failand how the building fabric and its sys-tems respond.Another reason to bother is that "allstaff are here all the time and copymachines have a constant queue oftelephone directory length reports" isnot usually how buildings are used. Itmight be a secondary question to askwhen testing risk to have such anextreme as an alternative, but not as theprimary operational regime.The examination and reception spaceshave a simple schedule of occupancywhich includes some diversity. Forexample, there is a lunch hour andthere is a ramp-up and ramp-down ofgains at the start and end of the day torepresent cleaning staff in the morningand stragglers at the close of work. Inboth cases there are periods during themorning and afternoon with full loadsso that capacity issues and the potentialfor overheating are addressed.ESP-r represents internal (casual) gainsas a schedule which applies to eachdened day type. By default there areweekdays, Saturdays and Sundays. Forthis exercise lets stick with a default setof day types.You can lump all casual gains togetherfor denition and reporting purposes oruse up to three separate types of casualgains. Typically the rst type is foroccupants, the second is for lights andthe third is for small power (equip-ment).Each of the days has one or more peri-ods associated with each type of casualgains. Periods must not overlap and

14

should cover the entire day (0h00 to24h00. Each period has a sensible load(W), a latent load (W) as well as thefraction of the sensible load which isradiant and convective.In the reception occupant sensiblegains are 80W from 7h-8h, 240W from8h-9h and 12h-14h and 400W from9h-12h and 14h-17h. For purposes ofthis exercise occupant latent loads inthe reception are assumed to be half thesensible loads. Consider though whatmight be happening in such spaces.What is the latent gain from severalcups of tea or a boiling kettle?For purposes of this exercise we willtreat all casual gains as having a 50%convective component. In a real projectyou would use values appropriate tothe type of occupant, light or smallpower device.The notes eld allows space for record-ing assumptions and the intent of thedata. Such notes help others decode thenumbers within the schedules and arean essential part of QA. If the notementions how many people or light x-tures this could be used to subse-quently scale the data.

During model planning sketch thepattern of the various casual gains foreach of the day types indicating thedifferent periods and the magnitudeof the gains. This information canthen be used when inputting data aswell as during model checking.Sketches save time. Try it for the datadescribed above and compare thiswith Figure 1.9 for the reception andFigure 1.10 for the examinationroom.

This overview of how the building isused will be your reference material formuch of the discussion of workingpractices in Chapter 5.If you want to explore a variety ofschedules for different building types,browse through the exemplar modelsand focus on how schedules aretreated. Although not discussed in theCookbook there are additional optionsfor dening schedules of greater com-plexity. For example, there is a shorttime-step data facility which allowscasual gains to be specied at eachtime-step.

15

Figure 1.9 Proles for reception.

16

Figure 1.10 Proles for examination.

17

1.7 Environmental controlsThe Cookbook advocates a fast-tackstrategy to establish:• patterns of heating and cooling

demand over time,• the frequency of extreme conditions,• the frequency of minimal demand,• what might happen if heating or

cooling failed,• what might happen if heating or

cooling was critically undersized,• how often will the building work sat-

isfactorily without mechanical inter-vention.

Such early indicators are valuable toother members of the design team.Deriving them may also result in well-founded opinions about demand sideimprovements and likely environmen-tal control regimes.Section 1.1 it did not include a speci-cation for an environmental controlsystem other than the set points to bemaintained. Even if the brief had beenspecic it might not be well foundedand would need to be evaluated.Each simulation suite implements envi-ronmental controls via one or morearbitrary conventions:• Ideal control laws which dene what

is sensed e.g. dry bulb air tempera-ture, control logic that responds tothe sensed condition and some formof actuation e.g. the injection of uxat some point in the model. Usuallythere are a limited number of param-eters that can be set by the user andsuch controls tend to be applied toindividual thermal zones.

• Ideal system descriptions whichdene a generally recognized pattern(e.g. VAV terminals with a perimetertrench heater), via high-level param-eters which are then associated witha number of thermal zones in themodel. Depending on the simulationtool there will be a different nitelist to select from.

• Libraries of detailed system compo-nents e.g. fan coils and valves, whichcan be assembled by the user into avariety of environmental systems asrequired and linked with controlcomponents and logic.

• Templates which dene an environ-mental control system from detailedcomponents. The template expand alimited number of descriptive termsinto scores, if not hundreds of com-ponents of a known topology, typi-cally including control componentsand control logic. Templates oftenuse a high level language to supportthe creation of component networks.

Software vendors have had mixed luckwith each of these approaches. Fromthe user perspective each has pros andcons.• Ideal zone controls can mimic any

number of real systems but presentusers with a mix of abstract termse.g. radiant/convective splits andbehavior e.g. proportional/integralaction rather than physical devices.Frustratingly, ideal zone controlsoften ignore the parasitic losses andelectrical demands that many practi-tioners are interested in.

• Ideal systems, often only roughlyapproximate what the practitionerhas in mind. Vendors have reacted

18

by adding more variants and/or pro-viding additional input parameters.The chat lists for tools are full ofpractitioners confronted by the blackart of tweaking an existing system tomimic a different design variant.Occasionally the mimicry takes onelements of a farce.

• Libraries of components are, inmany ways a reaction to the con-straints of pre-dened system lists.Opinionated practitioners are able tobe specic and evaluate alternativedesigns and explore many moreaspects of system performance.Unfortunately detailed descriptionsare tedious to set-up, difcult to cali-brate and can approximate a blackhole if they need debugging. Fewinterfaces or QA reports are able tocommunicate fully the attributes andrelationships within a network ofcomponents. Somewhat to the sur-prise of software vendors, there arepractitioners that lack the back-ground, opinions or tenacity neces-sary to create systems from scratch.

• Which brings us to component net-works created from templates. Theyoffer the detailed performance char-acteristics of components with mostof the tedium removed. Whereas theolder ideal systems approach mighthave expanded a score of user inputsinto a score of equations to besolved, the template approach cangenerate a network of scores, if nothundreds of components, and gener-ate thousands of lines of description.Clearly the author of a templatewould have an advantage in under-standing the resulting network

composition and using it to supportthe design process. For others whohave any level of curiosity about anewly created system the QA impli-cations are substantial. Does theinterface support understanding ofwhat was created? If the practitionerneeded to adapt or revise the param-eters within components within sucha network what methodology mightthey use to ensure this was done cor-rectly?If you think your tool only offersdetailed components, look closer tosee if there are abstract componentsavailable. In the early stage of designthey may be more than adequate.

ESP-r supports the following optionsfor environmental controls within amodel:• Ideal zone controls (to be covered in

this section)• Ideal systems expressed as ideal

zone controls with additional param-eters to support post-processing ofadditional performance data e.g. uelosses, fan power. There is no inter-face to this facility and it is not sup-ported on all computing platforms (ashameful state of affairs)

• Detailed system components,optionally in conjunction with massow network components and elec-trical power networks (to be coveredin a later section)

At this point, many practitionerswould, no doubt, feel compelled tojump into the details of their usualenvironmental control system. Round-ing up the usual suspects is the antithe-sis of a strategic use of simulation.First, establish patterns of demand.

19

Second, explore options quickly bydelaying specicity and detail in envi-ronmental control systems. Deliveringinformation quicker and with lesseffort than our competitors is a goodbusiness plan.Actually, many simulation tools makeit difcult not to be specic in the earlystages of a simulation project. Vendorssell Wizards that offer scores of pre-dened system templates which expandinto networks of wondrous detail.Wo w, so much from so little work (andit didn’t crash so it must be a gooddesign)! Vendors have less to sell withan abstract ’purchased air’ option orideal zone controllers.So what approach to take? Here is a listof questions which might help identifywhether a network of system compo-nents is suitable at the current stage ofthe design process:• Do we hav e sufcient information to

generate a network?• What performance indicators of the

network and/or components are weinterested in?

• Can we explore broad-brush ’what-if ’ questions?

• Can we tweak component detailsduring the detailed design phase?

• Are the physics within an idealizedcontrol or abstract component suf-cient to explore a design issue? E.g.mimicking a radiant cooling systemwith ’purchased air’ might be tortur-ing the physics.

• What form of tool-generated docu-mentation is available to support QAtasks?

• How does one validate a template-based system design? Is a systematicexploration of templates and compo-nents possible?

• Does the interface support detailedmodications of an initial template-based design?

• Does the interface support sufcientvariants of an ideal control to allow adesign team to pose relevant what-ifquestions?

• What support is available to movefrom an abstract representation toone with a higher resolution?

Since the focus is on learning aboutpatterns of demand, an abstractdescription of the system is all that isrequired. ESP-r’s ideal zone controlssupports abstract descriptions of howheat or cooling is generated.For purposes of this exercise an idealzone control will characterize theresponse of a convective heating andcooling system to the client’s setpoints. We do not know the capacity, sowe will make an initial guess (say4KW heating and 4KW cooling) andsee how well that matches thedemands.Once these patterns are known ourexperience might suggest a sub-set ofapproaches. We can then explore dif-ferent types of control logic and beginto be specic about the equipment thatwould be appropriate.If the environmental controls have aschedule this should be recorded inmuch the same way as occupancyschedules. Indeed, there are oftendependencies between occupancy pat-terns and environmental controls that

20

should be resolved at the planningstage.If there are options for the type of sys-tem or the control actions which can beapplied, ESP-r can accept alternatecontrollers which can be tested in sub-sequent assessments with little addi-tional effort.

1.8 Model compositionThe client has not specied what thebuilding is to be made of. We are goingto have to select placeholders from anexisting database until such time asthere is a clearer denition. Given thebuilding type most professional prac-tices will have available a number oflikely constructions.The following general types of con-structions will be required for thebuilding discussed in section 2.3:• an exterior wall• an internal lightweight partition• double glazing for the windows• a oor which includes some ground

layers• a ceiling for the sloped roof of the

examination room which also acts asa roof

• a ceiling for the receptionOne of our initial tasks will be toreview the current contents of the con-struction and materials databases tolocate existing entities which may beused as well as decide which ones canbe adapted via copy and edit and whichneed to be added.An example of the steps needed to dothis are included in the Cookbook

Exercises within Exercise 5.This completes the planning phase andour next task is to create a model whichmatches the requirements set out in theplanning stage.

21

Chapter 2

BUILDING A MODEL

2 Building a model

With planning complete we can takethe client’s specication and oursketches and notes and begin a newproject. If you are using another simu-lation tool adapt your keystrokes andnd equivalent facilities to create yourmodel.There are several exercises in theCookbook Exercises volume whichfocus on this Chapter. Look at Exercise2 as you start to create your model andcomplete Exercises 3-6 to ensure thedatabases are prepared with the entitiesyou will need to build your model.Interface interactions and typing areshown in typewriter text.

First select a folder for your model.Consider appropriate access privileges,how models will be archived and howmodels might be shared. A discussionof such issues can be found in theInstall Appendix.Give one of the following sets of com-mand depending on the operating sys-tem your are using:

The following sequence willtake you to your home folderand start up the ESP-r ProjectManager:cdesp-r

Use Windows Explorer to selectC:\Esru\Models or another folderthat is not deeply nested and whichhas a minimum of spaces in the path.In the C:\Esru\Models folder thereis an esp-r.cmd le which willstart-up the ESP-r project manager.

Figures 2.1 thru 2.4 illustrate (via theX11 interface) the steps we are goingto take. Those using a GTK basedinterface will be asked the same ques-tions, in the same order.Our tasks is to create a new model soselect menu option Model Manage-ment -> create new

23

Figure 2.1 First steps in creating a new model.

24

Figure 2.2: Folders to be created.

Figure 2.3: Further registration tasks.25

A dialogue will open at the bottom ofthe project manager which will ask youfor a root name to use when creatingthe model and its folders (Figure 2.1).For this exercise lets use doctor_ofce.This root name will also appear inmany of the model les so choosesomething which is short and clear.You hav e the choice of placing yourmodel les within a single folder or astandard set of folders. The singlefolder choice might be appropriate fora simple model. Since ESP-r separatesmodel information into a number ofles the standard approach is to usemultiple folders to hold different typesof information. For example, informa-tion about controls is held in a ctlfolder and zone related information isheld in a zones folder. For this exer-cise choose standard. You will be askedfor a descriptive title for the modelwhich is included in reports and abovethe wire-frame view.There is a text log le associated withthe model where you can keep track ofwho does what and when. You mightalso include in it a summary of theassumptions that you are making (incase someone asks). QA tasks are somuch easier if you take a fewmoments documenting your model.Notice in Figure 2.3 that the Longi-tude difference? dialogue showsa pop-up help message. All dialoguesand menus have contextual help. Whenin doubt use the ? button.

Figure 2.4: Model management menu.

26

2.1 Review of climate patterns anddatabasesAt this point we have registered a newsimulation project (the terms projectand model are often used interchange-ably in ESP-r). There are a number oftasks that we want to complete beforewe begin to dene the form and com-position of the general practitionersofce. This section and Exercise 3 inthe Cookbook Exercises are concernedwith the following tasks:• Find a climate le and typical cli-

mate periods for our assessments.• Review construction and materials

databases.• Select or create places holders for

constructions and materials.The Cookbook advocates the use ofshort climate sequences for model cali-bration and focused explorations. Forexample, a Monday morning start-upafter a cold weekend can tell us muchabout the characteristics of a building.Do peak summer demands coincidewith the hottest day or is it a functionof several hot days in sequence? Thereis no point in using an annual assess-ment to address such issues and, moreimportantly, great advantage to front-loading simulation tasks so that modelsare calibrated as soon as possible.The following discussion includes cli-mate data search techniques for identi-fying an appropriate week in winterwith a cold weekend and a summerweek with a sequence of warm days.

To work with climate databases, selectthe menu option Model Management-> Database Maintenance and in

the options shown in Figure 2.5 selectthe annual climate option.Once a database is selected then thereare a (mostly) common set of taskswhich are available (see Figure 2.6).Some databases include functions toconvert between binary and ASCII ver-sions. Databases which require fre-quent random access typically have abinary form. ASCII versions are usefulfor transport between computers.For climate databases there are alsooptions to convert EnergyPlus EPWles and Korean MET ofce les toESP-r format le.Assuming ESP-r was installed cor-rectly, you will now be presented witha list of known climate les (see Figure2.7). Adding additional sets is a sepa-rate topic.For purposes of this exercise we wantto select an existing climate data le.Choose the Birmingham IWEC cli-mate, look at the summary in the textfeedback area and conrm the selec-tion. The ESP-r climate module (clm)will start, and your rst task is to con-rm the climate le name in the initialdialogue.The ESP-r climate module (clm) pro-vides facilities to explore climate datasets via graphs, statistics and patternanalysis facilities (see Figure 2.8). Ourinitial task is to use these facilities tobetter understand the climate patternsin Birmingham and identify usefulassessment periods.

27

Figure 2.5 List of ESP-r databases.

Figure 2.6: Typical options for databases.

28

Figure 2.7: Available climate sets.There are a number of options undersynoptic analysis (Figure 2.9) whichare useful for nding climate patternswith which to test our building.To generate a statistical report as inFigure 2.10, rst select the climate datayou wish to analyze e.g. dry bulbtemperature and then the type ofanalysis e.g. maximum & minimumand then the reporting frequency e.g.day/week/month. Near the bottom

of the is an option find typicalweeks.

This facility works as follows:• the average & total heating and cool-

ing degree days (HDD & CDD) andsolar radiation are determined foreach season,

• for each week, average HDD &CDD and solar data is found andcompared with the seasonal valuesand the week with the least deviation(using user supplied weighting fac-tors) is reported. For this climate andwith the default heating and coolingbase temperatures the best-t weeksstart on 27 Feb, 10 April, 19 June, 5Oct and 4 Dec. Write these datesdown and then go review these peri-ods by graphing and/or gatheringstatistics about them.

• The climate module provides severalways of looking at the data so seewhich ’view’ tells you the most!

The provision of different views of theclimate data can assist in locating pat-terns within the climate data andanswering different questions thatclients might pose.Time spent exploring this module canprovide critical clues as to patternswithin a climate that may be used inthe design process.

29

Figure 2.8: Clm module opening menu.An example is the graph of tempera-tures over the year (Figure 2.11) withthe current seasons indicated across thetop of the graph. There are a number oftimes when it is below freezing, but thegraph indicates that these tend to bebrief. This might support the use ofbrief performance assessments for win-ter heating demands and capacity. Italso indicates scope for testing whethera design might be optimized to copewith brief rather than extended coldperiods.

Figure 2.9: Synoptic analysis.Another example is Figure 2.12 wherethe psychometrics of the outside airhave been plotted over the whole yearfor the same location.Most companies who regularly deploysimulation will have evolved proce-dures for selecting climate data for spe-cic design assessments. The acquisi-tion of climate data is covered in a laterchapter.

30

Figure 2.10: Weekly statistics.

Figure 2.11: Annual plot of temperatures.

31

Figure 2.12: Annual psychrometrics.

2.2 Locating constructions for ourmodelOur next task is to do a quick review ofavailable constructions so that we willbe able to attribute our model as wecreate it. You will want to look at Exer-cise 4 which focuses on a review ofmaterials which may be needed and thesteps required to take an existing mate-rial and create a variant which is appro-priate for the current project. Exercise5 will give you practice at the review ofconstructions as well as in adaptingexisting constructions and creating newconstructions. The exercise uses thestandard ESP-r constructions database.If you are working with a different setof databases the process is the same butyou will have to adapt the details to t.

It is possible to congure ESP-r to loadan initial set of databases that areappropriate for a given region andbuilding type (see Install Appendix).Typically material and constructiondatabases are managed at a corporatelevel but ESP-r also allows model spe-cic databases and possible workingpractices are also discussed.So, return to Model Management ->database maintenance -> con-structions select the current (e.g.standard) database and note the list ofconstructions (see Figure 2.13) anddetails (see Figure 2.14) of those youmight associate with this new model.One tactic, if you don’ t nd what youare looking for, is to make a projectcopy of one of the standard databasesand then add in place-holder construc-tions. A place-holder is a named con-struction which either does not have afull set of thermophysical properties or

32

uses an approximation. This can beassociated with the surfaces in themodel and later, when the actual infor-mation is available it can be updatedand all of the surface which use it willtake on the revised properties.

Figure 2.13 List of available construc-tions in database.

Figure 2.14 Construction data.When you complete Exercise 5 add toyour project notes the names of theexisting and new constructions whichyou wish to associate with your model.This saves time and reduces the chanceof error!

33

2.3 Zone composition tacticsBefore we begin dening our zones letsreview tactics. For purposes of thisexercise we are going to use the in-built CAD facilities. We are going touse these facilities tactically so as tominimize the number of keystrokes andavoid errors. Later on you can adaptthe techniques for even greater ef-ciency. Here are the tactics:• plan for maximum re-use of existing

information• use information on your planning

sketches and notes• take opportunities to embed docu-

mentation in the model• giv e entities meaningful names and

use attribution early-on in the pro-cessing

• learn the tool well enough to use in-built facilities to copy, edit and trans-form

The order we dene a model can allowus to build new zones from portions ofadjacent zones. In this exercise if webegin with the reception we can makeuse of this information when creatingthe examination room.If we take the information from ourplanning sketches rather than improvis-ing or using a calculator, we will makefewer errors, we will be less likely toloose track of where we are when thephone rings and we will be less likelyto nd we need two more surfaces thanthe interface allows.ESP-r has numerous places where youcan document your assumptions. Ofcourse you would never want to usesuch facilities because you never loose

scraps of paper and you alwaysremember the assumptions you madeabout that model four months ago andyour clients solicitor will never ask youto prove you followed procedures orused the correct values for that com-puter lab.A surface in a simulation model is notjust a polygon, it has a name, it is madeof something, it has specic boundaryconditions and it must conform to the(virtual) laws of physics. QA gets a loteasier if something that looks like adoor in a wireframe image, is nameddoor and is composed of a door type ofconstruction. The tactic is for theseattributes to reinforce each other so it iseasy to notice if we get somethingwrong and to be able to easily focus onthe correct portion of our model.

Defining the receptionReturning to the Model Managementmenu nd the *preferences menuoption and set ESP-r to use the mostrecent geometry le format as in Fig-ures 2.4 and 2.15. The option labelledupgrade files -> scan andupdate all zones sets the prefer-ence.Next we want to traverse the menustructure to focus on the geometry of anew zone as shown in Figures 2.16 -2.18. Select Model Management ->browse/edit/simulate -> compo-sition -> geometry & attribu-tions. Since there are no existingzones you will be asked whether youwant to input dimensions or loadexisting (ESP-r), load exist-ing (CAD) or cancel. Choose toinput dimensions, name the zone

34

e.g. reception is a good choice.

Figure 2.15: Browse/Edit prior toadding zones.

Next you will be asked to describe thiszone - so lets paraphrase of the clientsdenition.The next dialogue asks whether wewant to start with an rectangularplan, polygon plan, general3D, bitmap. For purposes of thisexercise select polygon plan andnd your sketch which corresponds toFigures 1.1 and 1.8.This type of input requires the height(in real space) of the oor (0.0m) and

ceiling (3.0m).How many walls? Figure 2.17 indicatesan additional point at X=4.0 and Y=7.0where there is a break in the wall. Tothe West of this break the wall is a par-tition which faces another portion ofthe building which we are not going tobother to dene. To the East of thispoint the wall faces the outside. Weneed to dene two walls along thenorth side of the reception and so thetotal number of walls that we are goingto extrude from the oor plan is 7.

The arrows shown in Figure 2.17indicate the ordering of the walls.Remember this rule: when extrudinga oor plan proceed anticlockwise.Write down the critical co-ordinatesrst and don’t answer the phone.

In this case we will start with 0.0,4.0and then 4.0,4.0 etc. around to 0.0,7.0(we need not repeat the initial point).When the walls co-ordinates have beendened you have the option to acceptthem. If you are in any way worriedabout having made a mistake, say noand you will have a chance to checkand edit the data.The Rotation angle? dialogueallows you to dene co-ordinates in acardinal orientation and then rotate toreect site conditions. You can alsoperform transforms and rotations later.To skip the rotation, leave the rotationangle at zero in Figure 2.18.

35

Figure 2.16: Zone name, description, shape.

36

Figure 2.17: List of plan coordinates.

Figure 2.18: Steps required for extrusion.

37

Figure 2.19: And here is what it look like!

Figure 2.20: Initial list of co-ordinates.

38

Figure 2.21: Initial list of surface edges.Once you accept the points the projectmanager display will update to what isshown in Figures 2.19 and 2.20 with alisting of the vertex associations in Fig-ure 2.21 are several things to noticeabout the graphic feedback and thecommand options.• Items in the menu which start with a

character can be selected and thosethat start with a blank in the rst col-umn are reporting derived values(which will be updated as you mod-ify the model).

• Under the graphic feedback area (ofthe X11 interface) are a number ofbuttons for altering the viewpoint,altering the size of the graphic feed-back area and controlling the image.The latter allows you to turn on and

off names and vertices and the siteorigin. Spend a few moments explor-ing this. The GTK+ interfaceincludes a pro-forma for adjustingviewing parameters (see Version Ap-pendix)

• The text feedback shown in Figure2.19 includes a synopsis of thegeometry of the zone and a list ofthe attributes and derived values foreach of the surfaces. This report isdesigned to complement the wire-frame image and you will notice thatthe word UNKNOWN shows upmany times so there is still somework to be done!

• You will notice that the surfaceshave been given names like Wall-1and Base-9. These are unambiguouswithout being particularly helpful.

Doors and windowsIn ESP-r, windows and doors should beincluded as surfaces in a model if theyare thermally important. A tacticalapproach also includes windows anddoors if they make it easier for othersto understand the model. The doorprobably falls into the latter category -we save time because we will not haveto explain why we hav e omitted it.Essentially a surface is a window ordoor if you decide it is and give it aname that reminds you of this decision.This is somewhat different than othersimulation tools so it is worth review-ing the rules:• any surface in a model can be glaz-

ing or a door with the exception thata transparent surface cannot be usedfor a back-to-back connection repre-senting mass within a zone

39

• their shapes are constrained only bynormal polygon rules

• if glazing has no frame there is norequirement that it be a child ofanother surface

• doors and glazing can be boundedby more than one surface (e.g. glaz-ing could have a frame on the leftand top and right but adjoin a span-drel panel on the bottom edge)

• the base of a door (or glazing) canbe at oor level or it can have araised sill

• door and window composition canbe any valid construction (e.g. doorscan be transparent or opaque andwindows can be opaque even thoughthat would tend to confuse others)

• if you want to represent the adja-cent-to-frame portion of glazing dif-ferently from the centre glass thenyou can either adjust the thermo-physical and optical properties orcreate two separate glazing surfaces

In ESP-r, solar radiation will passthrough any surface which has an opti-cal attribute set. This is the case forsurfaces facing the outside as well assurfaces which are acting as partitionswith another zone. A construction canuse glass as a material and will con-sider the glass as opaque if it ismatched to an OPAQ UE optical prop-erty.Thermophysically a door is treated likeany other surface in ESP-r. Surfaceswith an optical property will transmitand absorb solar radiation but are oth-erwise treated as any other surface.Other simulation tools may treat doorsand windows as simplied entities e.g.

a solar heat gain fraction might be usedrather than explicitly treating the radia-tion and convention from glazed sur-faces.You hav e several choices in the treat-ment of window frames. You canexplicitly represent frames as one ormore surfaces in the zone. A framemay wrap around the glazing or youcan take an abstract approach and lumpall of the framing facing one directionin a room into a single surface.You also have sev eral choices for glaz-ing. If the accurate positioning isimportant then create zones withexplicit representations. If you onlyrequire that the area and orientation ofthe glazing is important then you couldchoose an abstract approach and lumpall of the glazing of one type and orien-tation into a single surface.One issue which you may wish to con-sider is the relative size of surfaces in azone and the interactions between sur-faces:• if a large pane of glass is used in a

room with small surfaces (e.g.explicit blinds) then you may wish tosubdivide the glass

• if you are calculating view-factorsthen small dimensions may confusethese calculations - a frame 20mmwide around a large glazing or doorsurface may not get enough gridpoints for an accurate calculation.

• if you are interested in local comfortthen you should consider increasingthe geometric resolution in the por-tion of the zone where comfort isbeing assessed.

40

• if the impact of solar distribution isimportant (e.g. a passive solardesign) then you may want to subdi-vide the oor and the major thermalmass to account for the patches ofsunlight as well as using explicit rep-resentations of glazing.

In ESP-r, air passes between roomsONLY if you dene an air ow sched-ule or create an air ow network. It isoptional to include a door, grill or win-dow surface at the air movement entitylocation. Such visual clues may help toclarify a model.

If your ESP-r model is going to beexported to an application which hasa different set of rules for windowsand doors then also take those rulesinto account (if possible). For exam-ple, Energy Plus requires glazing tobe a child surface of an opaque par-ent surface so ensure that glazing inESP-r models are also representedthis way. Test various approaches tond which works best.

Our next tasks (shown in Figures 2.22 -2.27) is to insert a window into Wall-3and Wall-5 and a door into Wall-2. Theinterface provides a way to make arectangular ’hole’ in an existing sur-face and place a new surface into thathole. The original (parent) surfacewraps around all sides of the child sur-face.In Figure 2.22 there are a number ofoptions for creating new surface. Youwill use these options frequently so it isworth the time to explore them to

identify which of the variants might beused in different situations. The inter-face also provides an option to insert adoor into a surface. It does this bywrapping the existing surface aroundthe sides and top of the door.In both cases you will be asked to pro-vide an offset and a width and height ofthe rectangle to be inserted. The offsetis from the lower left corner of theexisting surface (looking from the out-side). These inbuilt facilities supportthe insertion of rectangular child sur-face. There is no specic requirementin ESP-r that doors and windows mustbe rectangular. If the design includesan arched opening or a round windowyou can do this (but the surface willhave to be made of a number ofstraight segments).According to Figure 1.1, the window inWall-3 starts 2.0m above the oor andis centered in the wall. So the offset Xis 0.5m and the offset Z is 2.0m and thewindow size is 3.0m x 0.75m (see Fig-ure 2.24). The same offsets and sizeapply to the window to be inserted intoWall-5. The door is 1.5m from the edgeof Wall-2 and is 1.0m wide (see Figure2.26). No height is given in the speci-cation so lets assume 2.1m.Beginning with the window in Wall-3,select surface list and edges ->add/insert/copy/extrude_fromand then choose inserted into asurface -> within surface.Notice there are also options to insert asurface as percentage of parentsurface.

41

Figure 2.22: Options for creating surfaces.Provide the dimensions from the para-graph above and the proposed locationof the window will be shown on thewireframe. If it is not ok you can re-enter the data, otherwise a new surfacewill be added and the existing Wall-3which started out with 4 edgesbecomes a 10 edge surface whichwraps around the new surface. You willbe asked to name the new surface(south_glz or something similar) andpick a construction for it (there is anentry dbl_glz in the constructions data-base).A recent addition to ESP-r is the con-cept that surfaces have a usageattribute (Figure 2.23). Code compli-ance tasks are assisted if we identifythe WINDOW as a code compliantfacade. Work is underway to use theseusage attributes when exporting ESP-rmodels. A future version of ESP-r willalso make use of an opening typeattribute (Figure 2.25) to help form airow network (currently they are only

used for documentation.

Figure 2.23: Use for window.Repeat this process for the window inWall-5. Remember that you can rotatethe wire-frame viewpoint to get a betterview of your work.For the door, use the inserted intoa surface->at base option. Wall-2is 4m wide and if the door is to be1.0m wide (this is a medical facility)then the offset for the door will be1.5m in Figure 2.26. When you havedone this the display should look likeFigure 2.27.What might you look for in the inter-face at this point? The wire-frameimage complements the text in thereport below. The wire-frame and thereport are designed to be used together.For example, a surface in the wire-frame might look ok but the reportindicates it is facing the opposite direc-tion. The data included in the text feed-back area report is similar to thatincluded in a model QA report (dis-cussed later).

42

Figure 2.24: Size and offsets for window.

Figure 2.25: Window opening type.

Figure 2.26: Door dimensions.

Figure 2.27: Reception after the addition of windows and doors.

Of course, at this point all of the initialentities have default names and many

of their attributes are UNKNOWN.Surface attribution is what we will turnour attention to in the next section.

43

Completing attributionTactically, we would prefer that othersnd it easy to understand our models.If we can also reduce errors and speedQA tasks we have a winning combina-tion. One successful pattern of modelattribution is to begin with the namesof the surfaces so that subsequentselection tasks and reports take lessmental effort. Of course if you want todo it the hard way...

Figure 2.28: Surface(s) attribution.As shown in Figure 2.28, the surfaceattributes menu includes an*attribute many option (this uses alist selection dialogue described in theVersion Appendix). You have a choiceof attribution types name, composi-tion, boundary condition,Select name and you will be asked todened the name of each of theselected surfaces (note the surface ishighlighted in the wire-frame drawing).After attributing the names the display

will be updated as in Figure 2.29.

To name something is to own it.

Tactically we want to take possessionof our models. Giving entities names isa key step especially if it helps thedesign team. The pattern used in thisroom is one of many possible patternsand the rule is roughly:• names like oor, ceiling, entry_door

have almost instant recognition• if the oor or ceiling is represented

by several surfaces then append aunique identier e.g. oor_a, oor_bor oor_1, oor_2 (but the lattermight be misinterpreted)

• walls that face the outside mightindicate which way they face vianorth_wall, east_wall but if a modelmight be rotated such names can beconfusing so front_wall is better

• partitions can be named based on thezones on each side e.g.kitchen_partn, coridor_partn, someprefer partn_a, partn_b.

The pattern above uses the name togive a clue about the location and com-position of the surface. Note: ESP-r islooking for unique combinations ofcharacters, so other languages are ok aslong as the ASCII character set is used.

44

Figure 2.29: Surface naming.45

Typically adding construction attribu-tions, for those surfaces that you havean opinion about, would be the nexttask. Use the list of useful construc-tions you wrote down when you werereviewing the databases). Where sev-eral surfaces have the same construc-tion use the *attribute manyoption. Otherwise select the surfaceyou wish to attribute as in Figure 2.30where all of the attributes of the sur-face are reported on and are availablefor editing. After you have selected theconstructions the interface will looklike the second part of the Figure.Skip boundary conditions for themoment - there is an automatic processto assign this attribute later in theprocess.The point of careful attribution is thatthe combination of the graphic imageand surface attribution ensures that themodel is correct. If something calleddoor is composed of concreteand you see it as a horizontal in theimage someone is likely to notice!

Figure 2.30: All the attributes of a sur-face and list.

46

Figure 2.31: Initial box shape of examination room.

Adding the examination roomThe examination room is rectangular inplan, but has a sloped roof and it sharespartitions with the reception. There area number of approaches to creating thiszone:• start with a simple shape and evolve

it• use the co-ordinates and link them

together to form the surfaces of thezone

For purposes of this exercise we aregoing to start with a simple shape (abox) and transform it into the nalshape. For additional practice look atExercise 9 in the Cookbook Exercisesvolume. The transformation is goingto involve changing two coordinates toelevate the roof, deleting a couple of

surfaces and then copying surfacesfrom the reception. For purposes of thisexercise it is an efcient approach andit will give you a chance to work with arange of transformation facilities.Referring back to Figures 1.2 and 1.8the initial box has an origin of 0.0, 0.0,0.0 and a width of 4m (East along theX axis) and depth of 4m (North alongthe Y axis) and is 3m high.So return to Model Management ->browse/edit/simulate -> compo-sition -> geometry & attribu-tions. Select the option to add azone via input dimensions.You will be asked for a name (sayexamination) and a description (saysomething like examination room withdoctor and one patient during ofcehours). You will be offered a choice ofinitial form and this time choose

47

rectangular plan.

You will be asked for the origin (0.00.0 0.0) and dimensions (4.0 4.0 3.0)and orientation (0.0). The result isshown in Figure 2.31.To make the roof sloped we need toalter the Z value of vertex 7 and 8 to4.5m.

If you cannot see the vertices inthe X11 version select image con-trol and toggle the vertices option.In the GTK version use the pulldown view tab and toggle the ver-tices option.

Select the vertex coordinates menuoption and pick vertex 7 and 8 andchange the Z value to 4.5m. As you dothis the wireframe image will beupdated (see Figure 2.32).

Figure 2.32: After editing vertices.ESP-r has a rule: every surface has oneboundary condition. So what is theboundary condition for Wall-2 andWall-3? How does this compare to theinitial sketch in Figure 1.2? The exami-nation room has partitions adjacent to

the reception zone as well as externalwalls and clear-story glazing.One quick way to make this transformby rst deleting both Wall-2 andWall-3. The place to do this is the sur-face list & edges -> add/delete/ copy/ extrude_fromoption. After you delete these surfacesthe wireframe image will look like Fig-ure 2.33.

Figure 2.33: After deleting surfaces.Our next task is to add surfaces to thezone by copying the relevant surfacesfrom the reception zone. Figure 2.34shows the available options. We will beusing several of these as we progress,rst select copy surface fromanother zone. A list of knownzones is presented (select reception)and then select surfaces part_a part_band door.You are then presented with a set oftransform options for these copied sur-faces. These options allow you to re-use existing surfaces in many wayswithout having to get out a calculator.

48

Figure 2.34: Copy options.There is a rule in ESP-r:

the order the edges of a surfaceare dened in tells ESP-r which isthe outer face of the surface.

For example, part_a in reception hadan azimuth of 180°. We need to reversethis and we select the invert option.You will be asked to conrm thischoice for the other two surfaces thatyou copied. You will also be asked if itis ok to update the edges of some of theexisting surfaces to take account of thenew vertices that have been included(say yes). After copying the surfacesyour model should look like Figure2.36.Our next task is to ll in the upperexternal portion of examination. Wealready have most of the informationwe need. One of the surface additionoptions is from existing vertices. Wemust supply the vertices for the trian-gular shaped surface on the East side ofexamination.

Figure 2.36: Examination room afterpartitions and door have been copied.

Another ESP-r rule is:If you see the outside face of asurface in the wireframe denethe edges anticlockwise from thelower left corner. If you see theinside face of the surface in thewireframe then dene the edgesclockwise.

From this rule vertices 6 9 7 are ofinterest. Do the same for the wall onthe upper North face. In the wireframewe see the inside face so the verticesare 9 10 8 7. This will become theframe around the clear-story windowso name this surface something likenorth_frame.Our nal task is to insert the clear-storyglazing. Select the inserted into asurface -> as percentage optionand give 80%. This will centre theglazing in the surface and is a quickapproach when the exact position ofthe glazing is not an issue. Attribute theglazing with dbl_glz.

49

Follow the steps you used in the rstzone to complete the attribution of thecomposition of the surfaces that stillhave UNKNOWN attributes and togive names. Notice that there are fewersurfaces requiring attribution. Copiedsurfaces will be partially attributed.You should see something like 2.37after you have completed the attribu-tion.

Figure 2.37: Examination room before

and after attribution.Now look back at your initial sketches.Is the model that you created correct?Look again...isn’t there supposed to bea window in the south wall?

50

2.4 Model topologyHaving completed the form of thezones there remains the task of den-ing the boundary conditions whichapply to each surface in the model.There is an automated process for thisand our next task is to use this facility.For additional practice complete Exer-cise 10 in parallel with reading thissection. Go to Zones composition-> surface connections &boundary (see Figure 2.38). Theoption you will want to select (afterreading a bit further) is check viavertex contiguity but rstclick on the ? help option and readabout the facilities.

Figure 2.38: Topology options withinthe project manager.

The topology facility scans the poly-gons of a model looking for surfaces invarious zones which are close matchesin terms of shape and position andmakes inferences from this to completethe boundary condition attribute ofeach surface. You control the toleranceand the extent of the search parametersand if the tool is unsure of what to do itwill pause and ask for conrmation(Figure 2.39).

Figure 2.39: Topology checking conr-mation options.

One by-product of checking modeltopology is that it checks every surfacein your model in sequence so it makesa great way to review your model. Ifyou periodically invoked the topologyfacility (say after adding two zones)you will have a chance to review themodel at the same time it is searchingfor matches to the new surfaces youhave added.Up to this point the strategy has been tofollow working procedures which help

51

us to create correct models. How do weknow they are correct? One of thesteps in checking the quality of ourmodels is to generate a QA report andthen review this against our initialsketches. Exercise 12 of the CookbookExercises volume is all about QA andthis point in the model creation processis an appropriate time to complete thatexercise.In order to run a simulation, each zonein a model must include full thermo-physical data for each layer in eachsurface. To practice creating these zoneles read and complete Exercise 14 ofthe Cookbook Exercises volume. Ifyour initial zone geometry is properlyattributed the task of creating thesezone les will only take a moment foreach zone.

52

Chapter 3

GEOMETRY ALTERNATIVE INPUTS

3 Geometry alternative inputs

ESP-r offers several options for geo-metric input: creating rectangular bod-ies, extruding oor plans, working withpolygons, clicking on points on a grid,clicking on points on a bitmap image(e.g. site plan, building plan or ele-vation) or importing CAD drawings.It is up to you to select the approach ormix of approaches which are appropri-ate for your skills and for the modelyou wish to create. In planing yoursimulation tasks consider the regularityof the plan, the quality of the bitmapimage and the level of clutter in theCAD le. A plan with a 1.3m x 1.7mrepeating pattern will not easily twithin ESP-r’s griding options. A bit-map with only a few pixels per metrewill be difcult to accurately selectpoints on and a CAD model thatincludes thousands of extra surfaces forfurniture might be a good candidate forconverting into a bitmap. Also considerwhether you might use the facilitiesdiscussed in this section to acquire crit-ical points on curved elevations and innon-rectilinear plans.This section focuses on clicking onpoints on a grid with the goal of creat-ing the same model as the rst exer-cise. Later there will be examplesshown of using images from historicalrecords and maps as the source ofpoints in a model.

If you are using the Native windowsgraphic interface or the GTK versionof ESP-r on any platform this alterna-tive graphic input facility is not yetavailable.

The planning stage for re-creating thedoctor ofce is essentially the same:• review the available information• establish the level of detail required• sketch the model (use your previous

sketch)• identify critical dimensions and/or

points on the sketch• decide on the sequence of zone and

surface creationBegin with a review the model fromthe rst exercise and nd your notesfrom the previous exercise. The overalldimensions of the model are 8m (east-west) and 7m (north-south). Cornersfall on a 1m grid. The exemption is thewindows and doors but these will beadded later. For this exercise use a0.5m grid for generating the zones.As with the rst exercises, the identi-cation of critical dimensions, perhapsby marking on an overlay of your ini-tial sketch, is also a key step for thisalternative mode of input. You will be

54

shifting your attention between thesketch and the screen so you will wantto nd ways to record your progress.In this exercise you will extrude bothzones in sequence and then use the nor-mal geometric manipulation facilitiesto make the examination roof slopedand add the windows and doors intoeach zone. Typically one would want tocreate a sequence of zones (or even awhole model) in one session.A skilled user might expect an averagerate of one surface every few secondsand might input a couple of dozenzones in one session. This exercise isintended to help you acquire the skillsneeded to use the click-on-grid facility.It will likely take you several iterationsto acquire the necessary habits.Before using your keyboard and mousehave a read of the next pages and lookat the gures. There are multiple stepsinvolved. Those who plan their workand then implement the plan withoutinterruption have the best chance ofsuccess.

3.1 To the keyboard...Begin this new project by exiting anyopen versions of esp-r. Return to whereyou keep your models and then invokeesp-r.To create a new model following thesame process as you initially used:• select Model Management ->create new with gp_grid as theroot name.

• accept the folders for this new modelll in the high level description ofthe project

• ll in the site dataAfter the site details have been enteredselect browse/edit/simulate ->composition-> geometry &attribution.

Select dimensional input and providethe name and a description for the rstzone (reception).

Lets start clicking...To use the click on grid approach togeometry denition choose the bit-map option. This opens up an initial(blank) command window as shown inFigure 3.1 which allows you to selectone of several pre-dened grids or tosupply your own bitmap (scanned froma document or created from a CADtool).

Figure 3.1: Opening menu of click-on-bitmapBefore selecting the grid le, adjust thesize of the graphic feedback area to becloser to square. You might also use

55

the window manager to resize theProject Manager so that you haveplenty of room to work. This will pre-vent you having to ’pan-around’ thegrid as you work.For this exercise select the largefor griding option and accept thesuggested le name in the dialoguebox. This option gives 23 horizontaland 17 vertical so considering each tickis 0.5m will give plenty of space.The initial grid requires further infor-mation in order for you to use it as abasis for creating new zones:• identify the origin (X=0.0, Y=0.0)

typically slightly in from the lowerleft corner - say at the left + mark.

• dene the scale of the grid by draw-ing a line of a know length. If eachof the + are 1.0m apart draw a linefrom the left + to the fourth + andgive the distance as 4.0.

Figure 3.2: Origin and scale and gridIf you plan to dene zones whichextend into the negative X or Y dimen-sion you would adjust the position ofthe origin to reect this. Note that youcan pan to the right and/or upwards asnecessary but you cannot pan any far-ther left or down after you set-up the

initial origin.Now that the scale is dened the ’real’grid can be overlaid by selecting thegriding option (choose 0.5m) and thenturn on the snap-to option.The mode >> menu option (Figure 3.3)lists a number of choices for enteringdata points. The rst two options areuseful for topographic/site data. Theoor plan extrusion option is equiv-alent to the oor plan extrusion used inthe initial exercise to create the recep-tion zone. However, this time ratherthan typing in coordinates, you will beclicking on points on the grid you cre-ated.

Figure 3.3: Which input modeOnce you have selected the oor planextrusion input mode (see Figure 38)set the oor elevation to 0.0 and theceiling elevation to 3.0 (to match Fig-ure 1.2)Just before starting to dene points it isworth noting that you are able to inter-rupt the input process and move arounda bitmap.

56

Use the start option to begindening points in the same order youused in the previous chapter. Start atthe grid nearest x0.0, y4.0 and thenx4.0, y4.0 etc. until you reach x0.0,y7.0 (see Figure 3.4) after which youwill type the character e to end theinput.With the snap-to option you only needto click near the point and it will snapto the nearest grid. If the snap-to optionis off the Project Manager will acceptthe actual point where you click.If you make a mistake or the pointsnaps to an incorrect grid point thenimmediately type the character d todelete the last entry (multiple deletesare possible.After you have signalled the end ofpoints for the initial zone (by typingthe character e) you can save the zonedata (if you did it correctly) or tryagain if you are not satised. Whilesaving the zone data, an additional leis created to hold the ’topology’ of themodel and you can safely accept thele name offered for conrmation.A new option create another zonewill be displayed in the menu once theinitial zone is saved. This can be usedas many times as required to extrudezones (using the current oor and ceil-ing height attributes). In the currentexercise the examination room needs tobe added. It has the same initial oorand ceiling height as the reception zoneso those attributes need not be altered.When you are ready, select the cre-ate another zone option andsupply a name and description for theexamination room.

Note that three of the corners of theexamination room are at the same gridpoints as used by the reception andunless you specify otherwise, thosecoordinates will be used. Note also thatthe edges of the reception are still visi-ble so that it is easy to create newzones adjacent to (including above orbelow) prior zones. Since you areextruding a oor plan you will proceedanti-clockwise from the origin typingthe character e when you have done allfour corners.When you started clicking on each sub-sequent zone, a message is included inthe text feedback to remind you of thekeyboard control options. When yousignal that you have nished selectingpoints for the examination room (bytyping the character e) you will be pre-sented with options to save or repeatthe zone denition.As the examination room is the lastzone, exit from the click-on facility andyou will be presented with a wireframeview of the zones you have created(Figure 3.6). These zones still requiresurface attribution as well as the addi-tion of doors and windows and raisingthe roof in the examination room. Suchtasks can be accomplished by using thegeometry & attribution facilities intro-duced in the previous chapter. And thiswould also be a good time to revisitExercise 12 in the Cookbook Exercisesvolume, generate a QA report andcompare it with the original model.

57

Figure 3.4: Just before nishing the rst zone.

Figure 3.5: After nishing the second zone.

58

Figure 3.6: Another view of extruded model.

3.2 Clicking on a bitmapA variant of the click-on-grid approachis to supply your own bitmap (plan/sec-tion/elevation/site-plan) and click onpoints found in that image to create oneor more thermal zones.In Figure 3.7 an UK Ordnance Surveymap has been converted into an X11bitmap le and used with the click-on-bitmap facility to create ground topog-raphy surfaces to associate with amodel. Note that the solid lines (repre-senting the contours selected) is anapproximation of the contours on themap because ground representationssupports several hundred surfacesrather than several thousand surfaces.The option used to within the bitmapfacility were points with dif-ferent Z.

Figure 3.7: Using a contour map bit-map le.

Several tactical warnings should begiven:• try a small portion of a map until

you are comfortable with convertingsuch contours into surfaces.

• there is an automated triangulationfacility but many users report thatcomplex arrays of points can be

59

problematic.• using a click on bitmap approach is

no excuse for skimping on the plan-ning of your model!

It is far to easy (bitter experience) toget carried away with the clicking and• include more complexity than neces-

sary• get lost while doing the clicking• collect points in such a way that the

time taken to post-process the sur-faces is greater than that associatedwith the clicking.

So ALWA YS...• mark-up your image with indications

of the critical points you want tocapture and the bounds of the zonesyou will be creating,

• if you have bitmaps for more thanone level make sure you can keepthe points in-register and that thescale can be set-up to be equivalent,

• sketch your model in three dimen-sions so that you can plan how parti-tions between zones work,

If you have ceilings and/or oors thatare not level there are several possibleapproaches, some of which will saveyou time and some will not. Experi-ment with constrained models to seewhat approach to the click-on-bitmapworks best for you. Keep a note ofwhat works so that you can follow thistactic when confronted with a similarproject in the future.

3.3 Examples of approaches to takeOnce you have the requisite skills itshould be possible to create substantialmodels with some speed. In the

examples below there were two issues -creating models which the client wouldrecognize and also models which cap-tured the spacial characteristics of thebuilding.An example of using a scanned imageto import information that is only avail-able in hard-copy form (no CAD data).The theatre shown in was initially con-structed in the mid seventeen hundredsand the last set of drawings availablewere from the mid nineteen seventies.It is also notable in that almost nothingis rectilinear.The mode in Figure 3.9 was initiallycomposed by clicking on a set of pointsfrom Figure 3.8 which were placed indummy zones. Surfaces and pointsfrom those dummy zones were thenused to build up the model zones.There was a detailed plan of the zoningworked out prior to the use of the click-on-bitmap facility. Even with this, con-siderable care was required and post-processing and reconciliation of thepartition surfaces was required. This isan example of what can be accom-plished by an experienced user and isjust the sort of project which would becruel and unusual punishment for anovice.

60

Figure 3.8: Bitmap image from historic building.

Figure 3.9: Bitmap image from historic building.

The model in Figure 3.10 and 3.11 waslargely composed by a clicking on amix of Ordnance survey maps, oldplanning documents and drawings. Themodel, including zone geometry, shad-ing obstructions and ground

topography was created and initial sim-ulations commissioned within 12 hoursof the completion of the simulationplanning phase. It would have beenfaster, but one drawing was off-scaleand several zones had to be adjusted tobring them into alignment.

61

Figure 3.10: Layout of a museum and park.

Figure 3.11: Rendering of a museum and park.

If you want additional practice (highlyrecommended) try to complete Exer-cise 11 in the Cookbook Exercises vol-ume. It describes a four zone model tocreate. See how much time it takes youto create that model. There is no

exercise that explores clicking on aplan image from a CAD tool - make upyour own exercise!These facilities are useful for manymodels and the fact that they hav e notbeen ported to the GTK interface is alimitation which needs to be addressed.

62

The next chapter approaches the topicof model geometry from a differentperspective.

63

Chapter 4

3D MODELLING

4 3D modelling

Figure 4.1 Section and view of house

65

The geometric forms discussed thus faruse polygons as the building blocks ofour virtual built environment. Whilemodern (thin) constructions, such asthose used in Figure 1.5 are oftenapproximated by conventional poly-gons, historical buildings (see Figure1.6) and the thick walls and insolationseen in Figure 4.1 highlight the limita-tions of this convention.Focusing on Figure 4.1, there are sev-eral aspects of the section which needto be considered during the planningand creation of models:• the thickness of insulation is sub-

stantial and at the edge is somewhatless thick

• the wall section comprises a numberof material types

• there is an overhang which will actto shade the facade of the building

• the overhang is thermally isolatedfrom the air within the roof space

• the overhang forms a boundary forthe upper section of the wall.

• there appears to be an air spacebelow the tiles which is separatefrom the air within the roof space.

• the portion of the roof with thetapering insulation is in direct con-tact with the layer of wood belowthe tiles

• it is not clear from the sectionwhether the roof space is well venti-lated.

• the area at the top of the insulationlayer is somewhat different from thesurface area at the ceiling.

The list of bullet points could be muchlonger. We need strategies for rankingthermophysical issues and decidingwhat needs to be included in ourmodel(s).

4.1 Modelling approachesThe geometric and compositional reso-lution of a simulation model dependson the questions being asked and theresources available. Some thermo-physical relationships may require sim-plication and other might not be pos-sible to represent within our model. Allvirtual environments are abstractions.Simulation tools support one or morelevels of abstraction for each of thedomains they solve. Options allowexperts freedom at the cost of a steeplearning curve for novices.A tactical approach to simulation usesthe planning phase to constrainoptions. The following is one possibleranking of what to preserve whileabstracting a design into a model:• the volume of air• the slope of the roof• the location of mass within the roof• the surface area in contact with the

airA low resolution model might treat theoverhang as a solar obstruction andignore the different thickness of theinsulation. It might assume the air iswell mixed within the roof space (i.e.there is no temperature stratication).It would also not explicitly representthe overhang as a boundary conditionfor the upper portion of the wall.A medium resolution model might sub-divide the surfaces to represent full

66

thickness and the partial thicknessinsulation and extend the roof zone toallow it to form a boundary at theupper wall section.A high resolution model might repre-sent the overhang portion of the roof asa separate zone or zones because therewill be times when the air temperaturein the overhang is different from that ofthe main section. A high resolutionmodel would have an upper and lowersection so that the temperature near thepeak of the roof can be different fromthe air adjacent to the insulation layer.By default, ESP-r assumes one-dimen-sional conduction. The thickness of theinsulation in Figure 4.1 poses a chal-lenge in comparison to a suspendedceiling. Do we choose to ignore theceiling thickness when dening geom-etry? Use of physical co-ordinateswould help to preserve the volume ofthe roof space and the surface areasand takes more time to describe.Many example models distributed withESP-r appear to ignore the thickness ofpartitions while other example modelsindicate a separation between rooms.Such differences are typically relatedto the method of data input. Geometrydigitized from CAD drawings will haverooms separated in space. Zone geome-try created from dimensioned data orsketches may tend to have partitions atthe centre line of walls and the innerface of a facade.The good news is that such differencestypically have little or no impact onpredicted performance. The solverknows from the thermophysical com-position of the partition whether or notthe two faces are separated in the co-

ordinate system or lie in the sameplane. There are exceptions which arecovered elsewhere.If the user is constrained in time, theuser could form the base of the roofspace by copy and invert the existingceiling surfaces and then create thesloped roof above that (see Figure 4.2).This approach results in a model that iscrude visually. The surface of the roofis at the correct slope, but the height ofthe building is not correct.

Figure 4.2: Constrained model

Given a bit more time the user couldadd a number of perimeter surfaces soas to raise the roof (at the expense ofan inaccurate air volume) as in Figure4.3. Such trade-offs might not alter theoverall performance of the building butmay be useful to make the model lesscrude visually.

67

Figure 4.3: Variant placing roof at cor-rect height

To move from treating the ceiling as ageometrically thin plane towards amodel that uses explicit coordinatesrequires an additional step. The initialcopy and invert of surfaces is followedby a surface transforms (along the sur-face normal). This facility, and severalother types of rotation and transformare available in the interface (see Fig-ure 4.4). If you nd it difcult to see allof the lines or labels in the wireframeview use the GTK view facility torotate or highlight portions of themodel (see Figure 4.5).If there is a gap between the roof zoneand the occupied zone (as in Figure4.6) this might be visually confusing tosome users and their clients (if theESP-r model was exported to Radi-ance). This gap could be lled with anappropriately sized solar obstructionblock.

Figure 4.4: Surface transform options

Figure 4.5: Wire frame control dialogue.

Figure 4.6: Variant using coordinates.

68

The above approach might be a reason-able thermophysical representation. Itis, none-the- less quite abstract forusers expecting a CAD representation.To approximate the 3D geometry of anactual roof requires that the initialcopy, inv ert, transform of the ceilingpolygons is followed by the addition ofsurfaces to represent the roof overhangas in Figure 4.7.

Figure 4.7: Variant extending overhang.

Note that the surfaces forming theoverhang do not (in the current ver-sion) shade the wall. Shading requiresthe use of shading obstruction blocks(as included in the earlier gures).And this more-explicit approach intro-duces a problem for the occupiedspace. The overhang, as drawn in thebuilding section is in contact with theupper portion of the wall. The geome-try of the walls should be adapted tosub-divide the wall into surfaces thatface the outside and surfaces whichconnect to the overhang. Clearly this

would be tedious to retrot into theexisting zones shown in Figure 4.1.As mentioned in the introduction, theair within the overhang could be at adifferent temperature than the roofspace. If such temperature differenceswere an issue, the overhang could berepresented as a separate zone as inFigure 4.8. This overhang zone couldwrap around the main roof space zone(one overhang zone could represent theoverhangs on the North, South, Eastand West. Again the existing wall willhave to be revised to represent the con-nection to the outside and the connec-tion to the overhang.One could be pedantic and argue thatthe temperature of the North overhangmight differ from that of the Southoverhang and require separate zones.Few users would be confronted byprojects where such detail is warranted.

Figure 4.8: Variant with separate over-hang zone.

69

Investing resources to increase modelresolution is a decision that should notbe made lightly. Some differences inperformance predictions can be subtlerather than dramatic. A user whowishes to explore this could denevariant models at different levels ofresolution to test the sensitivity of pre-dictions.

4.2 Steps to create a roof space

A tactical approach to simulation re-uses existing entities where possible.This roof is one example of using theexisting ceilings to compose the baseof the roof space. Experienced usersplan their work for maximum re-use!

A low resolution model of a roof spaceover the occupied rooms shown in Fig-ure 4.1, and making use of the existingceiling surfaces, and which follows thepattern of Figure 4.2 has the followingcritical dimensions:

• the height at the peak of the roof4.35m

• the lower face of the ceiling 2.35m• the width of the overhang 0.6mThe following sequence will minimizekeystrokes and limit the risk of error.Other sequences are possible - so tryvariants until you evolve a sequencethat works for you.Enter the menu browse/edit/simu-late -> composition -> geome-try & attribution menu andselect each of the existing zones and

review their contents and ensure thatthe ceiling surfaces are attributed (tosave time in later steps).Next in the geometry & attribu-tion menu selectadd/delete/copy. After electingto add a zone, select input dimen-sions and enter a name such asroof_space as well as a descriptionto clarify to others the intent of thiszone.Because most of the initial surfaceswill be borrowed from the existingzones it saves time to use the general3D option for the initial shape.The initial X Y Z position of the rstsurface is not applicable so just acceptwhatever is included in the dialoguebecause this surface will be deletedlater on. Ignore the warning about thevolume of the zone being zero.An initial wire-frame image with a sin-gle surface will be displayed (see Fig-ure 4.10). Your rst task is to go intothe surface list & edges menuand select + add/insert/copy sur-face. Use the copy surface(s)from another zone option severaltimes to form the base of theroof_space zone. It does not matterwhat order you copy the surfaces aslong as your work pattern avoids dupli-cation and ensures that all of the ceil-ings are copied.

70

Figure 4.9: Occupied rooms in house (to place roof over).

Figure 4.10: Initial dummy surface in roof_space.

71

Figure 4.11: After import and inversion of a surface.

Figure 4.12: roof_space with imported ceilings.

Figure 4.13: roof_space with two ridge vertices.

72

Figure 4.14: Zone with roof surfaces.

Figure 4.15: Better QA via combined wireframe and text report.

When you select a surface in anotherzone you will be asked if there are anytransforms to apply. The key transformis ’invert’ which takes the polygondened in the other zone and reversesthe order of the edges so that it facesthe correct way within the roof_space.

For each surface being copied, the wireframe view is updated to show theother zone as an aide to selecting thecorrect surface. It helps if the surfacesin such lists are clearly named.Remember to select the ’invert’ optionas seen in Figure 4.15. After the rstcopy the roof space will look like

73

Figure 4.10.

Figure 4.15 The invert dialogue.

During the import you might nd asource surface with a duplicate name.You will be asked to specify a newunique name. Tactical hint: if you fol-low a clear naming strategy, subse-quent tasks will go faster. At somepoint remember to remove the initialdummy surface. When all of the ceil-ings have been imported theroof_space will look like Figure 4.11.Each surface name provides a clue asto what is on the other side of the ceil-ing. Typically, each imported surfacewill require between 5 and 10 secondsfor an experienced user and if there arename clashes it might require 20 sec-onds per import.There are a number of steps which youcan take at this point which will pre-vent the propagation of errors. Forexample, the wire frame image willhave open circles drawn at each vertexthat is referenced once - so open circlesare to be expected at the borders. Thewire frame image will have solid cir-cles at vertices not referenced by anysurface. You will see four such circlesin the wire frame - these are orphanvertices associated with the initial

dummy surface. It will save time andlimit confusion if you exit from theSurface topology menu and gointo the vertex coordinates menuand identify vertex 1, 2, 3 and 4 forremoval.While you are in the Vertices inmenu take a note of the Z values. Thecurrent position of the surfaces is at2.35m. We want the ridge of the roofto be 2m above this point. The roof isa hip type and the dimension fromsouth to north is 7.2m so the so theridge will start 3.6m from the East andWest and South edge of the buildingfacade. These two coordinates arethen:• left ridge point X=3.6, Y=3.6,

Z=4.35• right ridge point X=15.77, Y=3.6,

Z=4.35For a gable roof the X co-ordinatewould not be altered to form a pair oftriangular walls. The next step is to ’+add’ two more vertices to theroof_space zone. The result shouldlook like Figure 4.13 (look for v17 andv18).The next step is to compose the South,East, North and West surfaces of theroof by creating new surfaces made upof existing vertices. With reference toFigure 4.14• south surface should include vertices

9 14 18 17 1 and 2.• east surface should include vertices

15 16 18 and 14.• north surface should include vertices

6 7 17 18 16 12 and 13.

74

• west surface should include vertices8 1 17.

There are patterns in the above deni-tions. What are they?• Each surface is dened in an anti-

clockwise order (looking from theoutside)

• the rst edge is horizontal and thesecond edge is not horizontal

• intermediate vertices (e.g. 2 and 9and 15 etc.) are included in the list

The rst edge horizontal rule isrequired by the shading and insolationanalysis. Look at the surfaces in any ofthe simple exemplar models and youwill see this pattern. With simpleshaped surfaces there is usually onlyone edge along the base of a wall andfor such surfaces the normal rule of’start from the lower left edge goinganti-clockwise’ applies. In this casebecause there are several edges insequence so the rule has to be adapted.If you miss out one of the intermediatevertices (e.g. vertex 15 along the eastfaade) ESP-r will detect a mismatchand warn you to check the polygonedges.If you followed these steps, the inter-face should look like Figure 4.14. Anexperienced user will require about 10seconds to create a new surface fromexisting vertices and will also be dou-ble checking that data glitches arecaught early and corrected before pro-gressing to the next task. Practice untilyou feel condent with the technique!Notice the enclosure: properlybounded message at the top of themenu. This signals that all of the edgesin the zone are following the rules of

syntax and order and that the zone iffully bounded by polygons.A further check could be done by turn-ing on the surface normal arrows in thewire frame drawing (in the X11 inter-face this is found in the ’wire-frame’button and in the GTK interface theoption is within the pop-up dialogue(as in Figure 4.5).Almost nished. Now is a good timeto contrast the visual information in thewire frame with the zone & surfacedetails report (see Figure 4.14).The few seconds that it takes to gener-ate this report and review it with thewire frame will typically save tens ofminutes later.Having created the polygons and giventhem names, the next task is to attributethe surface composition. A copied sur-face already has inherited attributes’.The new surfaces of the roof are par-tially attributed at this point.Remember that there is a automatedprocess which looks at the co-ordinatesof each surface to nd thermophysicaladjacency. It may be quicker thanattributing each surface in theroof_space manually. Generate a QAreport and check the contents beforeyou continue.

75

Chapter 5

SCHEDULES

5 Schedules

The form and composition of a modelis one part of the simulation process.Many users think they hav e almostcompleted their work when the geome-try is done. Far from it, buildings arealmost always places where people arecoming and going and lights are beingturned on and off and all manner ofelectrical devices are found.Usually we lack both the detailed infor-mation and the resources to undertakean exhaustive denition. It is, however,in our interest to dene the essentialcharacteristics of what goes on in abuilding and learn from the perfor-mance patterns that emerge sufcientclues to imagine the circumstanceswhere the building would performpoorly.ESP-r supports zone operational char-acteristics in terms of weekdays andtwo separate weekend days (typicallylabelled as Saturday and Sunday).Work is underway to implement moreday types but for this exercise lets stickwith the basics. It is also possible todene unique values for each time-stepof a simulation, but lets not go thereyet. Casual gains (e.g. people, light,small power) are one operational char-acteristic of a zone and schedules ofinltration (air from the outside viaintentional sources such as fans orunintentional sources such as cracks in

the facade) and ventilation (air fromanother thermal zone) and there are alimited number of controls you canimpose on inltration and ventilationschedules.What are casual gains in ESP-r? Thelower portions of Figures 1.9 and 1.10show the attributes of the casual gains -each has a day type (Wkd/Sat/Sun) acasual gain type label(Occupt/Lights/Equipt) a period (starthour and end hour) a sensible andlatent magnitude, and for the sensibleportion the fraction of the gain which isradiant and the fraction which is con-vective. The convective and radiantfraction defaults should be adjusted toreect the properties of specic lightttings and occupants.Just before creating a schedule beaw are that groups who frequently workwith a particular building type willlikely have historical data as well asprior models which could contain use-ful patterns of occupancy and smallpower use. There are several tech-niques for helping to re-use such infor-mation and this will be covered later inthis section.To giv e you more practice with creat-ing zone schedule also have a look atExercise 13 in the Cookbook Exercisesvolume.

77

For the current building a brief descrip-tion was given in the ’How the buildingis used’ section, specically Figure1.10 and 1.11. Re-read that section.Also look at Figure 53 for receptiondata. Before we dene the operationalcharacteristics of the reception andexamination room within the ProjectManager a bit of planning will (youguessed it) save time and reduce thechance of errors later on.In the reception there is ’one staff andup to 3 visitors with 10W/m2 lightingand 1 50W’ From the gure it is clearthe occupancy changes throughout theday (ramping up from 7h00 and with adip for lunch and almost nothing hap-pening after 17h00) but the lights areon during ofce hours plus some timefor cleaning staff (8h00-19h00). In theexamination room there is one staff andone visitor with 10W/m2 lighting and 1100W computer ’. From the gure it isclear that occupancy varies during theday and that both lights and smallpower (labelled as equipment) are onfrom 8h00-19h00 and nothing happenson the weekend.Why bother with varying the occu-pancy during the day? Several reasons- full time peak loads usually do nothappen in reality so a bit of diversity ismore realistic, reducing the load duringa lunch hour allows us to checkwhether the building is sensitive tobrief changes in gains and the ramp-upjust before ofce hours and the ramp-down after ofce hours approximatestransient occupancy. The peakdemands are long enough to indicatewhether heat will tend to build up inthe rooms. Such patterns will also

exercise the environmental system andperhaps provide an early clue as to therelationship between building use andsystem demands. Quite a lot of valuefor a few minutes thought at the plan-ning stage.In the reception the peak occupant sen-sible gain is 400W and in the examina-tion room the peak is 200W equating to100W per person. The latent magni-tude is roughly half the sensible value.Such assumptions, if documented,really do help clarify the numbers heldin the le and can speed up later QAtasks.One of the rst questions you will beasked when you begin to dene theoperational characteristics of zones isthe number of periods for each daytype and the start time of each period.For weekdays the reception has 8 occu-pant periods and 3 periods for lightingand 3 periods for small power. Accord-ing to Figure 1.9 the occupant periodswould start at 0, 7, 8, 9, 12, 14, 17 and21 hours. On Saturday and Sundaythere are zero periods.In the Project Manager go to ModelManagement - browse/edit/simu-late -> composition -> opera-tional details. Select the zonereception and you will be presentedwith an initial le choice with anoption to browse for an existing lewithin your model (you could use thisif you have sev eral rooms which usethe same pattern). The le name is sug-gested based on the name of the zone.Accept the suggested name and thenyou are presented with a number ofoptions for how to dene the schedules(Figure 5.1).

78

Figure 5.1 Options for generating schedules.

For this exercise we will use thestart from scratch option.You can also import patterns fromother existing zones in your model aswell as from zone operation les thathave been placed in a standard ’pat-tern’ folder.You will be reminded about planningyour schedules (do read this because itis a useful reminder). And then foreach of the day types you will be askedfor the number of periods for occu-pants, lights and small power. This willbe followed by dialogues which ask forthe start hour of each of the periods foreach of the casual gain types (get thisfrom your notes).Do the same for for Saturdays and Sun-days. You are now presented with themenu in Figure 5.2.

Figure 5.2 Opening zone operations menu.Fill in the description of the zone oper-ations using words and phrases whichwill clarify what is happening (note theX11 editing box has < > arrows so youcan scroll to a more text). Next selectoption c to ll in the rest of the casualgain period details. You will be pre-sented with a menu with period datawhich you need to ll in based on yournotes.As you were lling in the period datayou will note that you have a choice ofunits. From the notes occupants areWatts, lighting would be 3.75 W/m2 ifwe used that unit (the notes say 150Wand the oor area is 40m2), and smallpower as Watts.After you have dened the magnitudeof the sensible and latent gains andaccepted the default radiant and con-vective split you should see somethinglike Figure 5.3.

79

Figure 5.3 Weekday casual gains.

Figure 5.4 Weekday inltration schedules.

Using the information on your notesyou could also dene the casual gains

80

for the examination room.

5.1 Scheduled air flowsEarly in the design process buildingdetails may not support a detaileddescription of how air moves withinbuildings or how tight the facade mightbe so engineering approximations areoften used. The brief didn’t actuallymention anything so an initial assump-tion needs to be made. In an actualproject discussions would be madewithin the design team to quantify thisgure. For purposes of this exerciselets have a rather leaky facade andassume that the doors are closedbetween the reception and examinationroom.We can represent this with one periodeach day covering the 24 hours with avalue of 1 ac/h inltration and no ven-tilation (see Figure 5.4). Use theadd/delete/copy importflow option and select add for allday types. Later we might decide tolower the inltration rate to see if thebuilding is sensitive to an upgrade inthe quality of the facade.Other sections of the Cookbook outlineoptions for treating air movement viamass ow networks which can assesspressure and buoyancy driven owsbetween thermal zones or via Compu-tational Fluid Dynamic Domains.

5.2 Importing operation schedulesCreating zone operations from scratchis time consuming so many users willcollect their best zone operation pat-terns and store them in the pattern

folder (located with the training mod-els).If you have already lled in the sched-ules for the examination room repeatthe process but change the name of thele slightly so as not to mess up yourprior work. When the selections in Fig-ure 5.1 are shown pick air andgains < from pattern and alist of les will be shown. Select one ofthem (remember which one) and lookat the summary and answer the ques-tions about air ow and then aboutcasual gains. Since it does not knowthe volume or the oor area associatedwith the pattern le it needs informa-tion from you. If the author of the leyou are getting the pattern from wasreally clued-up such information wouldbe included in the documentation.You will have a opportunity to edit thedocumentation and this is you chanceto ensure that what is included in yourmodel is clearly dened, especially ifyou need to scale some of the values.Figure 5.5 is the result of importing apattern le. Such patterns can bealtered easily - note that the peak valuefor occupants and lighting and smallpower are each 100W. To upscale thesmall power for use in your currentzone would require only that you selectthe scale existing gainsoption and provide a scaling factor.

81

Figure 5.5 Imported pattern le data.

Once a model includes the zone geom-etry and the thermophysical data lesand the schedules of use it is possibleto run a simulation. If you think youare at this point then have a look atExercise 15 in the Cookbook Exercisesvolume and see if you can assess yourmodels performance. If you have notdened environmental systems then theassessment will be based on a free oatassumption.

82

Chapter 6

CLIMATE DAT A

6 Climate data

ESP-r has a number of facilities whichallow us to scale our models andassessments - so we get, for example,annual heating and cooling for a wholebuilding without simulating every dayof the year or every oor of an ofcebuilding. These facilities evolved overtime based on observations about howpractitioners adapted their models andthe assessments they commissioned tot within their computational and staffresources.For many building types there is astrong correlation between predictionsover one or two typical weeks in eachseason and seasonal heating and cool-ing demands. This can be demonstratedby commissioning short period assess-ments and full season assessments andlooking at the relationship between thetwo performance predictions. Commis-sioning full season assessments todetermine scaling for a building doestake time and so alternative methodswere investigated. Over scores ofprojects it emerged that there wererelationships in the climate data thatcould be used to identify suitable shortassessment periods. The key to thiswas in the practitioners denition ofthe extent of each season and searchcriteria for typical periods.For many readers seasons are demar-cated by four month intervals or by

notes in a reference guide. If we pauseto consider what constitutes winter inHong Kong we might conclude that itis triggered by something other thantemperature. The start of spring mightbe a day on a calendar but often thereare cultural clues such as cherry blos-soms which trigger changes in how wedress and how we operate our build-ings. Astute practitioners leveraged thisinsight when they reviewed their cli-mate data.Before we had access to computerswhich supported numerical simulationsimplied methods such as heatingdegree day (HDD and later coolingdegree day CDD) methods were used.We observed that practitioners oftendid a quick check of HDD and CDD tojudge, for example the onset of demandfor environmental controls or the likelyperiod that the building might beallowed to free oat with minimal lossof comfort.To nd out if such indicators were apossible shortcut to explicit seasonalassessments we looked at the ratiobetween short/seasonal HDD and theproject assessments and found similari-ties. A better t was possible if solarradiation was taken into account.

84

Figure 6.1 Season HDD, CDD, Radiation summary.

Figure 6.2 Winter t criteria.

The method embedded in the ESP-rclimate module codies the manualtechniques and is illustrated in the

listing Figures 6.1-6.3. Climate data isscanned week by week for the averageHDD and CDD for each day and thetotal for each week as well as the daily

85

mean direct and diffuse solar radiation.To allow ne-tuning of the scan theuser can provide weighting factors forHDD, CDD and solar radiation as wellas the base temperature for HDD andCDD. The weekly data are then com-pared with the average and total valuesfor the season and the week with theleast deviation is suggested as the bestt.Model calibration exercises that usesuch best-t weather patterns in eachseason can provide a reality checkwhich is both constrained in computa-tional time but sufciently focused forstaff to notice patterns that would notbe evident in a worst day winter/sum-mer assessment.To make it easier for practitioners touse selected weather patterns climatedata sets can be supplemented withinformation about seasons (early-yearwinter, spring, summer, autumn, late-year winter in the Northern Hemi-sphere, early-year summer, autumn,winter, spring later-year summer in theSouthern Hemisphere) as well as typi-cal assessment periods.

6.1 Importing climate dataTo better understand how this worksour rst task is to install a new climatele and specify the days in each seasonand then use clm facilities to discovertypical assessment periods in each sea-son. After this we will derive scalingfactors for heating, cooling, lighting,small power etc. demands to use in ourmodel.Downloading a new climate data setfrom a United States DoE web site (onone line)

<http://apps1.eere.energy.gov/buildings/energyplus/cfm/weatherdata.cfm>. The siteoffers US locations, Canadian Loca-tions and International Location. Letschoose an international location -Geneva Switzerland. The le for thissite is CHE_Geneva_IWEC.zip. Down-load it and save to a convenient loca-tion and unpack the zip le. One of theles will be CHE_Geneva_IWEC.epw.Most current EPW les can beimported directly into the ESP-r clmmodule.

For Linux/Mac/Unix use acommand window, go to thelocation of the EPW le andissue the command (as oneline): clm -mode text-file CHE_Geneva_IWEC-act epw2bin silentCHE_Geneva_IWEC.epw.

This creates a new ESP-r climate leCHE_Geneva_IWEC. The messageerror reading line 1 is some-times seen when doing the conversion,but does not usually affect the conver-sion. The command given to the clmmodule includes the name of the newbinary climate le to be created afterthe key word -le. The words -actepw2bin silent tells it to under-take the conversion without furtherinteractions.

86

For the Native Windows version youwill have to start up the clm.exe mod-ule interactively and provide a newESP-r climate le name and providethe name of the EPW le in theimport option.

To check that the conversion worked,invoke the clm module with the newle or use the le browser to locate thenew le:clm -file CHE_Geneva_IWEC

If the conversion was correct youshould see the linesClimate data: GENEVA CHE46.2N 8.9W: 1984 DN

in the text feedback area of the inter-face. And for good measure try tograph temperatures and solar radiation.If there is an issue with the le thenopen it in a text editor (nedit is used inFigure 6.3). There are several changesyou might need to make in the le.Line 6 might include a # characterbefore the WMD number and thisshould be replaced by a blank characterso it is not treated as a comment. SomeEPW les have a blank line at the endof the le (line 8769). Remove thisline, save the le and try importingagain. Further instructions for workingwith EPW les will be found in theESP-r source distribution in the climatefolder.

6.2 Defining seasons and typicalperiodsOur next task is to dene the days asso-ciated with each season. There are anynumber of approaches one might take.For this exercise we will use a combi-nation of looking at the patterns oftemperatures over the year and thesolar radiation. In the climate modulechoose graphical analysis from themenu options. Then pick dry bulb tem-perature and draw graph to get a dis-play similar to that in Figure 6.4.The axis at the bottom of the graph isweeks. There are extreme low tempera-tures in weeks 4, 9, 46 and 52. There isa late cool period in week 12. In week14 it reaches 22°C. The warmest periodis between week 26 and week 32.Another way to look at climate infor-mation is to look at weekly heating andcooling degree days. To to this selectsynoptic analysis and then choose drybulb temperature and then degree daysand then weekly. Take the default baseheating and cooling temperatures Thiswill produce a table as Figure 6.5.

87

Figure 6.3 Editing of EPW le.

Figure 6.4 Annual dry bulb temperatures.

The average heating degree days isroughly 15.0 for the rst nine weeksand then drops to roughly 8.0 (exceptfor week 13). Weeks 27 to 34 havecooling degree days between 10 and23. This follows the same pattern asseen in the graph. If we set a winterheating degree day cut-off point of 12and a summer cooling degree day cut-

off of about 10 then the denition ofseasons is straightforward.Before we actually set the dates, notethat 1 January is on a Sunday and thestart of each subsequent week is also aSunday. Later, when we search for typ-ical weeks they will begin on a Sunday.Some practitioners prefer to run assess-ments that begin on Mondays and endon Sundays. If we wanted to enforce

88

that preference what we need to do isto change the year of the climate set sothat January happens on a Monday(e.g. 2001). This change can be foundin the edit site data menuoption of the main clm menu. Oncethis is changed, return to synoptic anal-ysis and ask for the weekly degree daytable again.

Figure 6.5 Heating and cooling degree days.Using these cut-offs the seasons are as:• early-year winter 1 January - 11

March• spring 12 March - 24 June• summer 25 June - 26 August• autumn 27 August - 18 November• late-year winter 19 November - 31

December.

To record this information go to themanage climatelist option onthe main menu. You will be presentedwith the options shown in Figure 6.6.What is shown are initial default datesfor seasons and typical periods whichyou will need to update. If the menustring item and the menu aidare not clear then start by editing themenu selection and documentationtext.For example the menu aide memoircould be Geneva CHE was source fromUS DoE. Menu option c is the full pathand name of the climate le that ESP-rwill access after it has been installed inthe standard location. For the le wehave been working with this is/usr/esru/esp-r/climate/CHE_Geneva_IWEC. Menu option d isa toggle which tells ESP-r whether thele is ONLINE or OFFLINE. Set thisto ONLINE. If it is OFFLINE then oth-ers will not see this le.The section of the menu under seasonsallows us to edit the beginning andending date of each season. Afterdening each season we can then usethe scan climate for best-t weeks tosearch for weeks that are closest to theseasonal average conditions. Noticethat in this case, each season begins onthe same day of the week. You couldalso dene seasons that do not start atthe same day of the week.

89

Figure 6.6 Menu for creating a cli-matelist entry.

The criteria for heating and cooling arebased on a combination of heating andcooling degree days and solar radia-tion. For example, the seasonal aver-age weekly heating degree days andcooling degree days (102 and 0 forearly year winter) as well as the solarradiation (11.05). It will then look forthe week with the least deviation afterconrming the weighting we want togive to heating DD, cooling DD andradiation. These are initial set to 1.0 togive an equal weighting (but you canchange this if you want). It nds thesmallest deviation (0.14) for the week

eight which starts on Monday 19February. This method can result in agood estimate of the energy use over aseason although it will be less accuratefor worst case peak assessments.Use the scan climate for best-bit weeks option to search for thetypical weeks. After conrming eachof the seasonal suggestions the inter-face will updated as in Figure 6.7.andselecting the graph ambient T andseasons option the graph should looklike Figure 6.8.

Figure 6.7 After editing climatelist entry.

90

Figure 6.8 Seasons of the year.

6.3 Climatelist entriesThe nal tasks are to record this infor-mation via the list/generate/editdocumentation option initializeoption and then use the save optionto write out the data to a le. It willgive it a name based on the original cli-mate le with a .block extension. Theblock of text that was generated islisted below. It needs to be pasted intothe so-called climatelist le. There isan edit option. Also open the block le,check the entries and to add any textyou want to have displayed to users (inthe *help_start to *help_end).Insert the text (carefully) between anexisting *help_end and *item line andsave it. Don’t forget to copy your

newly created climate le to the stan-dard folder. The next time ESP-r isused the new climate le should beavailable and the seasons and typicalweeks should be registered.Before closing the clm module, it isuseful to save the ESP-r climate datainto an ASCII format le. Do this viathe export to text file option ofthe main menu. Accept the default lename CHE_Geneva_IWEC.a and theperiod. The climate leCHE_Geneva_IWEC should be placedin the standard folder (e.g./usr/esru/esp-r/climate) and the ASCIIversion CHE_Geneva_IWEC.a shouldbe kept as a backup in case the binaryclimate le becomes corrupted. Again,on some systems, you may have to askadministrative staff to copy to le to

91

/usr/esru/esp-r/climate (or wherever thele climatelist is located on yourmachine).*item*name GENEVA - CHE*aide GENEVA - CHE was sourced from US DoE*dbfl*avail OFFLINE*winter_s 1 1 11 3 19 11 31 12*spring_s 12 3 24 6 27 8 18 11*summer_s 25 6 26 8*winter_t 19 2 25 2 17 12 23 12*spring_t 21 5 27 5 1 10 7 10*summer_t 6 8 12 8*help_startClimate is GENEVA - CHELocation: 46.25N 8.87W : 2001Month Minimum Time Maximum TimeJan -6.8 @ 4h00 Fri 26 11.1 @16h00 Sun 14Feb -5.8 @ 7h00 Tue 27 11.7 @16h00 Wed 7Mar -2.7 @ 7h00 Tue 27 16.8 @16h00 Sat 10Apr 1.4 @ 7h00 Wed 11 22.4 @16h00 Wed 4May 1.6 @ 4h00 Tue 8 25.5 @16h00 Tue 15Jun 7.7 @ 1h00 Tue 19 29.0 @16h00 Mon 25Jul 10.5 @ 4h00 Thu 5 32.1 @16h00 Mon 9Aug 7.1 @ 4h00 Thu 30 31.4 @13h00 Wed 22Sep 8.3 @ 7h00 Fri 7 27.6 @16h00 Sat 22Oct 0.1 @ 7h00 Wed 31 21.1 @13h00 Mon 1Nov -4.1 @ 7h00 Sun 25 14.7 @16h00 Fri 2Dec -4.0 @22h00 Mon 31 9.8 @13h00 Mon 17Ann -6.8 @ 4h 26 Jan 32.1 @16h 9 Jul 10.4---Seasons & typical periods---Winter season is Mon 1 Jan - Sun 11 MarTypical winter week begins Mon 19 FebSpring season is Mon 12 Mar - Sun 24 JunTypical spring week begins Mon 21 MaySummer season is Mon 25 Jun - Sun 26 AugTypical summer week begins Mon 6 AugAutumn season is Mon 27 Aug - Sun 18 NovTypical autumn week begins Mon 1 OctWinter season is Mon 19 Nov - Mon 31 DecTypical winter week begins Mon 17 Dec*help_end

It might also be necessary to importclimate data from a le that does notconform to the EPW standard. Theother le format that ESP-r under-stands is its own ASCII version. If pos-sible convert your climate data into aformat similar to that dened below:*CLIMATE# ascii climate file# defined in: CHE_Geneva_IWEC.a# col 1: Diffuse solar horiz (W/m**2)# col 2: Ext dry bulb T (Tenths DEG.C)# col 3: Direct normal solar (W/m**2)# col 4: Wind speed (Tenths m/s)# col 5: Wind direction (clockwise deg north)

# col 6: Relative humidity (Percent)GENEVA - CHE # site name2001,46.25,-8.87,0 # year lat ...1,365 # period (julian days)* day 1 month 10,-24,0,10,250,810,-18,0,8,250,850,-14,0,7,250,880,-14,0,5,240,900,-15,0,12,240,910,-17,0,19,240,930,-18,0,26,240,900,-14,0,17,240,9011,-10,0,9,240,9081,-6,53,0,0,8994,1,361,3,0,89155,9,130,7,0,9177,16,0,10,240,9272,18,0,12,240,9255,20,0,13,240,9230,22,0,15,240,926,19,0,12,240,930,15,0,8,240,930,12,0,5,320,930,7,0,7,320,920,3,0,8,320,910,-2,0,10,310,920,-5,0,10,310,920,-7,0,10,310,92* day 2 month 10,-10,0,10,260,920,-12,0,8,260,920,-13,0,7,260,920,-15,0,5,10,910,-20,0,5,10,910,-25,0,5,10,910,-30,0,5,360,91. . .

The comment lines (start with # ) areoptional. Notice also that there arelines that start with * day. These arecalled day demarcation lines and theyare also optional (the clm module willask you if there are day demarcationlines included in your le).The rst line of the le should be*CLIMATE and the next non-commentline is interpreted as the site name (upto 40 characters are used).The site name line is followed by asite-data line. Included on the line2001,46.25,-8.87,0 # year lat, ...

where the rst token is the year, thesecond token is the latitude (positive

92

degrees is Northern hemisphere andnegative degrees is Southern hemi-sphere), the third token is the degreesfrom the climate data site to the nearesttime meridian and the last item is azero if the solar data was measured asdirect normal solar and the value 123 ifthe solar data was measured as globalhorizontal.The line after site-data is assumed tocontain two numbers which dene theperiod of the climate le. Normally cli-mate data begins on the 1st of Januaryand ends on the 31st of December. Ifyour import le is for a shorter periodthen the other hours of the year willhave zero data.Notice that data are all integers andthey are comma separated. You canuse a space to separate data if that ismore convenient. The column ordermust follow the pattern shown above.The integer values for diffuse solar,direct solar, wind direction and relativehumidity are converted directly into thenearest Watt, degree or percentage.Take care with the dry bulb tempera-ture and wind speed. -18 becomes -1.8degrees and 8 becomes 0.8 m/s.

93

Chapter 7

ZONE CONTROLS

7 Zone controls

7.1 IntroductionAs stated at the beginning of TheCookbook, the use of simulation cantest the beliefs of the design team. Thedesign of environmental controls isparticularly rich in beliefs. For exam-ple:• Some Architects and Engineers

operate on the assumption that build-ings constantly require mechanicalintervention. Is this assumption true?

• Many design methods focus onextreme conditions and ignore whathappens at other times. What is thecost of this?

• Some design methods assume thatchanges dictated by value engineer-ing have little or no impact on sys-tems and control response or runningcosts or comfort. Is this a low-riskassumption?

The Cookbook approach limits the costof design by ensuring that such ques-tions are dealt with as early as possible.It also provides opportunities to noticepatterns that lead to breakthroughs.

Understand options for controlling abuilding by observing how it workswithout mechanical intervention.Focus on demand side management -exploring architectural options andalternative operational regimes.Focus on transition seasons and envi-ronmental controls that can ef-ciently cope with part-loads andintermittent demands.Discover patterns that stress thebuilding and explore how interven-tions that mitigate the extremes canbe integrated with the results of theprior steps in the methodology.Re-check demand-side managementoptions and iterate as required.

7.2.1 Abstract representationsIn ESP-r, environmental control sys-tems can be represented as either ideal-ized zone controls or as a network ofsystem components (often called aplant system within the interface). Thechoice of which approach to take isdependent on the stage of the designprocess, how much detail is needed toassess performance and how muchinformation is available. There is alsothe issue of time. Control based on sys-tem components tends to take longer to

95

setup and can be more difcult to cali-brate.The rst step in understanding howESP-r deals with idealized zone con-trols is to decode the jargon. The inter-face does not present you with a list ofentities such as perimeter trench floorheating. What you see are choicesrelating to:• what is sensed e.g. temperature,

humidity, radiation, ux• where is the sensor e.g. zone air

node, within a construction, within acomponent

• what control logic is applied to thesensor signal at different times of theday

• what action is taken e.g. ux injec-tion or extraction,

• where is the point of interaction e.g.zone air node, within a construction,within a system component

(schedule)

Sensor (location) Actuator (location)

Control Law

Figure 7.1 sensor - law - actuator.Together these form a control loop.Zone control loops in ESP-r areabstract. Control engineers would viewthe approach as idealized because thereare no time lags in the control systemalthough there may be lags in responsedue to heat storage etc.

• heat injections and extraction arebased on user supplied capacityranges rather than performancecurves and fuel ow rates.

• there are no attributes such as thespacing of ns in a fan coil unit,rather you dene the location andthe radiative and convective splitassociated with the actuator.

• performance is in terms of uxadded or extracted at the point ofactuation. Parasitic electrical useand part load efciency is a post-processing task.

There are basic controllers which canbe used to identify demand patterns.Other controls represent real-worldscenarios such as equipment with mini-mal cycle times or multiple stages ofcapacity.Typically a number of zone controlloops are specied for the building,each one having a unique index. Theseloops are then linked to one or morebuilding zones. Zone control loops canexhibit near-real-time response. With aone minute time-step, the response of aPID controller to a step change indemand may demonstrate many of theartefacts which would be observed in areal control device. A controller whichis critically undersized can provideuseful clues as to whether the buildingis capable of absorbing brief extremesin boundary conditions or building usepatterns.In buildings where air movement isimportant models may require a mix ofzone controls and air ow controls.This is especially true in buildings withhybrid ventilation systems.

96

ESP-r’s abstract approach was initiallydesigned for exibility and the abilityto represent the performance character-istics of a number of environmentalcontrol systems at an early stage of thedesign process. In a European context,where there are few standardapproaches to environmental controls,such exibility was pragmatic.If one were to look at the code of simu-lation tools which do not use discretecomponents to represent environmentalcontrols, one would see that their sys-tem template descriptions are beingtranslated into instructions which areroughly equivalent to the control loopsof sensors, control logic and actuatorsused in the ESP-r’s zone controls.You are asked to manually dene whatother tools infer from high leveldescriptions. So what is this processlike and how does it compare with acomponent based approach (see Chap-ter 13)?

7.2.2 Abstract exampleImagine that you wanted to test theidea of a oor heating system whichwas capable of injecting ˜40W/m2 intothe middle of the top layer of the oorslab during ofce hours and whichsensed the air temperature of the roomas in Figure 7.2. Your other optionmight be to use radiators in the room.Although the boiler and thermostatmight be the same, the two choicesrequired different components and dif-ferent controls. We could either denenetworks of components for the twodesigns or we could represent theirgeneral characteristics via sensor - law

- actuator denitions.The component based approach iscomplicated by the dozens of possiblecombinations of boiler, pump and heat-ing circuit layout and is burdened bythe need to attribute each of the com-ponents. At an early design stage suchdetails are a distraction from what isessentially a high level decision. Anabstract approach allows us to delayour investment in detail. It also allowsus more time to understand the patternsof demand and thus make moreinformed decisions during the detaileddesign stage.

zone_node

Sensor (location) Actuator (location)

Control Law(schedule)

window

Figure 7.2 representing an abstractoor heating system.

The data required by a control loop isas in Figure 7.3. In the case of oorheating the sensor location is at the airnode of the zone, the schedule is a free-oat at the start and end of the day with

97

a ramp-up period in the morning priorto the occupied period. The controllaw during the occupied period couldbe a basic controller with 4kW of heat-ing capacity and a set-point of 20°C.The actuator is in a specic layer of theoor surface of the zone. During thesimulation 4kW will be injected untilthe room air temperature reaches 20°Cand then a reduced ux will be injectedto maintain the set-point.Although it is abstract, it has many ofthe characteristics of a oor heatingsystem. Both the time lag and thealtered radiant environment of theroom are part of the simulation. If theresponse is not optimal then alteringthe control attributes allows designvariants to be checked. For example, ifthe response is slow, the position in theslab of the heat injection could beraised by re-dening the location of theactuator.Once the required characteristics of theoor heating system have beenassessed then these can be used in thedetailed design stage if the resourcesand goals of the project warrant it.The down side of this abstractapproach is that some performance cri-teria are not available and some aspectsof the thermophysical response aresimplied. For example the time takenby a real system to alter the tempera-ture of the working uid is absent. Theminimum time-step for a zone controlis one minute so systems that respondin the order of seconds are not wellrepresented. There are some controlregimes which cannot be represented -e.g. a chilled ceiling would be con-trolled both for the room temperature

but limited so as not to cause conden-sation. Some control combinationsfound in BEMS are difcult, if notimpossible to represent.

Actuator (heat

Control Law

Algorithm/logic

Control data

Timing data

Capacity, set points

periods, start times

Sensor (deg C@ air point) injection @ floor)

Figure 7.3 data requirements.

Delaying details until after we see thepattern of demand and interactionwith an abstract environmental con-trol can help us make informedchoices of system type and compo-nents.Conventional approaches force us tobe specic before we have reachedan understanding of supply anddemand patterns.Testing via abstract representationsincreases the chance that environ-mental controls and buildings are bet-ter matched.

Readers who are working with othersimulation environments may also haveoptions in how they approach environ-mental controls. There are almostalways options to delay detail.

98

7.3 Zone control lawsThe following is a summary of themost often used control laws.• basic control is an ideal controller

which will exactly maintain a set-point if it has sufcient capacity.This is often used to identifydemand patterns. The attributes are:maximum and minimum heatingcapacity, maximum and minimumcooling capacity, heating and cool-ing set-point. Humidity control isoptional and is achieved via mois-ture injection or dehumidication ata maximum g/s rate. There is anoption to relax temperature controlin order to maintain humidity con-trol.

• free float disables control for theperiod. There are no attributes forthis controller.

• fixed injection or extract implementsa control with a xed heating orcooling rate if the logic requests anON state. Many heating and coolingdevices are not able to adjust theiroperation and respond to transientconditions with an ON/OFF controlaction. This controller is sensitive tothe simulation time-step (whichshould be modied to represent theresponse of the device). Theattributes of this control are heatinginjection, heating set-point, coolingextraction and cooling set-point.

• basic proportional control is an pro-portional controller which workswithin in a throttling range andoptionally implements PI controlwith an integral action time or a PDcontrol (dangerous) with a derivativeaction time or a full PID

specication. This control can be asunstable as a badly tuned real con-troller. The attributes are: maximumand minimum heating capacity, set-point and throttling range, maximumand minimum cooling capacity,cooling set-point and throttlingrange. Integral and derivative timesare optional.

• linkage with plant component is azone controller that is used in con-junction with a plant component net-work to identify interactionsbetween the plant network andzones. The attributes of this controlare the component in the networkand the node of the component andthe type of coupling. If the airstream of the system componentsinteracts with a zone then the sourcecomponent and down-stream com-ponents are identied.

• multi-stage with hysteresis imple-ments a staged controller in whichadditional capacity is brought on-line if the set point is not reached.There are three stages for heatingand three stages for cooling. Theattributes include a heating and cool-ing set-point as well as a delta tem-perature for heating and coolingcapacity changes.

• separate ON/OFF flux is a controllerwhich implements a heating-on-below and heating-off-above logic aswell as a cooling-on-above and cool-ing-off-below strategy. This approxi-mates a classic thermostat responsepattern. The attributes are heatingand cooling capacity as well as twoset-points for heating and two set-points for cooling.

99

• temperature match (ideal) imple-ments a controller which willattempt to match the evolving tem-perature at another location or aweighted temperature at severallocations. This is useful in validationor calibration studies where recordedboundary conditions need to bematched. To represent a well venti-lated roof space, a control can heator cool the roof space to match thecurrent ambient temperature.Another example is to force anabstract boundary zone for a ceilingvoid to match the current tempera-ture of a fully dened ceiling voidfound elsewhere in a model. Theattributes are a maximum and mini-mum heating and cooling capacity,the number of sensors to pay atten-tion to and their locations.

• temperature match (ON/OFF)implements a controller which willattempt to match a temperature atanother location via an ON/OFFcontrol action. Attributes are similarto the above control.

• optimal start implements an optimalstart heating controller whichattempts to reach a desired tempera-ture at a specied time. This con-troller works by trying one scenarioand if it fails it re-winds the simula-tion to the start of the day and thenattempts a different scenario. It canbe operated with a 4h00 start or auser dened start or a start timetested by iteration. The attributes areheating capacity and set-point, thedesired time of arrival, minimal timedifference and temperature differ-ence for testing.

• multi-sensor controller is designedto implement a control in one loca-tion based on actions taken inanother location. An example of thisis to represent a HVAC system as amixing box which is controlledbetween a range of temperatures inorder to control conditions inanother zone linked to it via an airow network. Another use of thiscontrol is to abstractly represent aoor heating system as a geometri-cally thin thermal zone into whichheat is injected in order to controlthe temperature of an occupiedspace. The attributes of this con-troller are minimum and maximumheating and cooling capacity, heatingset-point, cooling set-point and num-ber of auxiliary sensors and theirlocations.

• slave capacity controller implementsa common residential control strat-egy where a thermostat in one partof a residence controls the operationof HVAC in other rooms. Typicallysuch controls, if not carefully bal-anced, will result in poor control insome of the slave zones. Severalcontrol loops are required to imple-ment a master-slave control in abuilding. One control loop repre-sents the master control and there isone slave control loop for each ofthe slave zones. The attributes of thecontroller are the index of the con-trol loop that represents the mastercontroller and the slave heatingcapacity and slave cooling capacity.

• variable supply temperature imple-ments a controller for a constant vol-ume air supply rate which adjusts

100

the supply temperature to maintain aroom set-point. This controller isabstract (it is not part of an explicitair ow network). Details of the per-formance are available if the simula-tion trace option is invoked. Theattributes are maximum supply tem-perature, minimum supply tempera-ture, air ow rate, room heating set-point, room cooling set-point.

• VAV with CAV heating implements acontroller which uses VAV for cool-ing and CAV for heating. This con-troller is abstract (it is not part of anexplicit air ow network). The con-troller assumes a constant supplytemperature and uses a terminal re-heat. It is intended for early designstage studies of VAV characteristics.Details of performance are availablevia simulation trace functions. Theattributes are reheat capacity, airsupply temperature, room set-point,maximum air ow rate, minimum airow rate.

7.4 Exploring building control issuesThe ESP-r distribution includes exem-plar models which implement variouszone control regimes. Example modelsare a good starting point for exploringthe use of zone controls as well asunderstanding interactions betweenbuildings and environmental controls.After selecting an exemplar and study-ing the documentation, run assessmentsat different times of the year to charac-terize the temporal response of thebuilding and controls.Remember, an exemplar model con-tains one expression of the attributes of

a control loop. Attributes can beadjusted to better approximate thecharacteristics of environmental con-trols. Sometimes performance is bestunderstood by altering the controldescription and looking at how pre-dicted performance evolves.

Explore controls with simple modelsbefore implementing them in fullscale models or using them in con-sulting or research projects.Spend time with the results analysismodule. Look at a range of perfor-mance metrics and forms of report-ing.Those who have experience will belooking for conrmation of expecta-tions, whether it needs calibration oris unsuitable.

Working practices in simulation groupsshould ensure that each likely controlis tested and notes on their use isrecorded so that it can be available forreview during the planning stage.

7.4.1 Basic (ideal) controlLet’s hav e a look at the zone controlfacilities by exploring an examplemodel which uses a combination offree-oat and basic controllers. Themodel conguration le is cellu-lar_bc/cfg/cellular_bc.cfg andin the list of exemplar models it is inthe technical features menu asthe rst item.

101

Project: base case model of two adjacent cellular offices

manager_b manager_a

coridor

Figure 7.4 Basic mechanical ventila-tion system.

The intent of this environmental con-trol is to heat each of the rooms to 19Cduring ofce hours and 15C at othertimes of weekdays. On Saturday thetiming is different and after 17h00 thetemperature is allowed to free-oat. OnSundays there is only a frost protectionheating to maintain 10C and an over-heat control which cools the room ifthe temperature goes over 30C. Thereis 2500W of sensible heating capacityand 2500W of sensible cooling capac-ity and no humidity control.The control loop that implements thisspecication has a number ofattributes. These are held in a le in themodel and both the interface and themodel contents report uses a standardreporting convention to describe con-trol loops (see next report fragment):

102

The model includes ideal controls as follows:Control description:Ideal control for dual office model. Weekdays normal office hours,Saturday reduced occupied hours, Sunday stand-by only. One person peroffice, 100W lighting and 150W small power.

Zones control includes 1 functions.this is a base case set of assumptions

The sensor for function 1 senses the temperature of the current zone.The actuator for function 1 is air point of the current zoneThe function day types are Weekdays, Saturdays & SundaysWeekday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heating set-point 15.00C cooling set-point26.00C.

2 6.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heating set-point 19.00C cooling set-point24.00C.

3 18.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heating set-point 15.00C cooling set-point26.00C.Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heating set-point 15.00C cooling set-point26.00C.

2 9.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heating set-point 19.00C cooling set-point24.00C.

3 17.00 db temp > flux free floatingSunday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min heating capacity 0.0W. Heating set-point 10.00C cooling set-point30.00C.

Zone to control loop linkages:zone ( 1) manager_a << control 1zone ( 2) manager_b << control 1zone ( 3) coridor << control 1

The contents report parses the dataassociated with each control loop andexpresses this as a short statement.Some abbreviation is needed becausethe length of each statement is con-strained. The use of abbreviations alsohappens in the interface - there is not

enough room to display many words sothe menu presents numbers and echoesthe longer phrases in the text feedbackarea.Each control loop is divided into sec-tions that describe the sensor and actu-ator as well as data for each period ineach day type. What you might notice

103

is that there is repetition of the capacityinformation at each period. The datastructure allows all attributes to changeat each period although most modelsonly alter set-points. Notice that onSaturday, the last period of the dayuses a different control law to signal achange from controlled to free oatingconditions.The last item in the report is the link-ages between the dened control loopsand the zones of the model. In this caseone control loop is dened and the pat-tern it represents is used in all of thezones of the model. Note that thedescription of the sensor and actuatorin the above control loop uses thephrase in the current zone.The column in Figure 7.5 marked daytype allows the user to implementdifferent control actions based on theconcept of day types. A hospital emer-gency room is a classic example of asingle day type. Often it is convenientto treat weekends differently fromweekdays and ESP-r offers this option.Day types can be used to dene, forexample, a different control pattern foreach day of the week, but doing this fora period longer than about ten days isimpractical.Work is underway to link the conceptof day types to the calendar of themodel. A holiday day type could thenbe assigned to specic days of the cal-endar.To explore how this basic controlappears in the interface go tobrowse/edit/simulate -> con-trols -> zones and the interfacewill look like Figure 7.5

There are menu items for describingthe included controls, linking speciccontrols to specic zones in the modeland managing the controls (add/deleteetc.), checking controls and saving thecontrol denition to le. As with otherfacilities in ESP-r, documentation is anintegral part of the model. Workingpractices should enforce documenta-tion to set the context of the manyarrays of numbers that make up controlloop denitions.

Figure 7.5 Top level zone control menu.

There is a centre section of the menuwhich allows access to the specics ofthe each control loop. On rst glance itis difcult to make sense of the num-bers and abbreviations. The three num-bers under the sensor location col-umn and the actuator locationcolumns dene the specic locationbased on user selections. Selecting thecontrol law brings up the choice ofsensor details, actuatordetails, period of validityand period data.

104

Each control loop has one dened loca-tion for its sensor (although some con-trol laws will supplement this deni-tion) and one location for the actuator.There are a number of choices for azone control loop sensor (shown inFigure 7.6). Once you select the choiceand answer some supplemental ques-tions the three indices are generated.

Figure 7.6 Sensor choices.

There are two choices senses cur-rent zone db temp and sensestemp in a specific zone whichneed clarication. Some controls aregeneric and could be referenced bymany zones in which case the formerchoice is used. If you have a controlthat senses conditions at a specic sur-face then the latter is needed. There aresome control laws that also require thata specic zone be identied for thesensor and actuator location.Some models will be able to usegeneric control loops and other models

will require separate control loops withspecic location information for sen-sors and actuators.And you can also dene control loopswhich are not linked to any zone in themodel, but which are available as alter-natives to link to at a future point intime.The references temporal fileitem allows you to associate a sensorwith time-step based data.There are fewer choices for the actua-tor of an ideal control. Unlike otherdomains which might control twophase ow or a damper position, a zonecontrol either adds or removes uxfrom a node within the simulation solu-tion matrix as shown in Figure 7.7.

Figure 7.7 Actuator choices.

Periods (Figure 7.8 and 7.9) aredened by their start time and the con-trol law to use during the period. Con-trol logic is used until there is a subse-quent period statement or until the endof the day (which ever comes rst).Some control laws have few attributesand other have upwards of twentyattributes.

105

Figure 7.8 Control periods.

Figure 7.9 Control period details.

7.4.2 Interpreting control predic-tionsThe winter performance of this modelshould indicate rooms are controlledduring ofce hours and a set-back tem-perature is maintained overnight with afree oat from late Saturday till earlyMonday. Most of these expectationsare conrmed in the performance dataincluded in Figure 7.10.Note that the set-point in the twoofces is maintained or slightlyexceeded on most days and the nighttime temperature drifts down to the set-back. The corridor is warmer than theheating set-point and even reaches thecooling set-point for a few hours.There are two deviations in the controlwhich need to be explained. Why isWednesday sufciently warm in theroom to reach the cooling set-point andshould the free-oat condition on Sun-day coincide with the warmest pre-dicted temperatures in addition to theexpected coldest temperatures?

106

Figure 7.10 Winter performance predictions.

Figure 7.11 Winter performance predictions.

107

Figure 7.12 Winter heating and cooling peak statistics.

Figure 7.13 Winter heating and cooling energy delivered.

Strategies for what-else-do-I-look-atare covered in Chapter 10. Essentially,we are looking for something that ishappening at the same time that mightcause the thermophysical state that weare trying to explain. Those with expe-rience will have opinions as to theusual suspects.In the case of this model, the light-weight construction and the large areaof glazing would suggest that one ofthe usual suspects for overheating issolar radiation. The graph in Figure7.11 shows that there is a peak solaroccurrence that coincides withWednesday and Sunday. One mightconclude that these ofces are sensitiveto solar gains.If we want to evaluate the capacityrequired in these rooms we can use theSummary Statistics ->

heat/cool/humidify reportwhich is reproduced in Figure 7.12.The information in this report shouldbe used in conjunction with the graphin Figure 7.10 when considering thecapacity needed. The statistics providea value and a time of occurrence. As inmost buildings the peak condition hap-pens at different times in differentrooms. The total is a diversified totalwhich is based on the simultaneouspeak rather than a summary of the indi-vidual peaks.The graph is important because theshape of the response of the environ-mental control allows us to better inter-pret the statistics as well as providingan early clue as to likely equipmentchoices or architectural interventions.The heating pattern is an early morningpeak which rapidly decreases. Thecooling demand is also a brief peak

108

which decreases over sev eral hours.In this case there not a sustaineddemand for either heating or cooling.The graph indicates a classic patternfor which there are several classic solu-tions.The other report which may be of inter-est is the integrated energy demandwhich is found in the Enquire about-> energy delivered report (Fig-ure 7.13).In this report the heating and cooling isexpressed in kWhrs and the number ofhours that heating and cooling wereactive. Those with experience will belooking for options to deal with inter-mittent system use. There are stand-bycosts and start-up costs which mayneed to be considered. Where the aver-age rate of delivery is considerably dif-ferent than the peak then there are anumber of classic solutions whichexperienced practitioners will want tobegin to consider.If we turn our attention to a typicalspring week we nd that in Figure7.14, there are few hours that heating isrequired (briey on Wednesday morn-ing and Friday morning) and, depend-ing on the temperature outside, quite afew hours when cooling is required inall rooms.The graph in Figure 7.14 indicates thatthere are only brief requirements forheating and there is a short timebetween the demand for heating andthe demand for cooling. This posesseveral issues for the design team. Anexperienced practitioner might con-sider several alternative scenarios forspring:

• disabling heating other than as afrost protection on days that startabove 5C.

• altering the area of glazing to limitthe solar radiation entering the room

• adding an outside shading device tomoderate solar radiation falling onthe facade

• adding internal mass to the room toreduce the rapid change in tempera-ture.

The temperature pattern in the corridoris also instructive. The rise in tempera-ture after the control period indicatesthat there is excess heat stored in thefabric of the corridor. On warm days(say above 15°C) the subsequent daynds the corridor temperature justbelow the cooling set-point. It is likelythat this pattern will also be found inthe summer and thus cooling will berequired from the start of business.Once a model exists the marginal costof testing ideas tends to be low. It takesonly moments to run focused simula-tions. It also only takes moments to usethe results analysis module to generateand capture a sequence of graphs. Suchpatterns of performance can be valu-able feedback to the design process.In the early chapters of the Cookbookthe planning process included a reviewof climate patterns and if the selectedperiods are included in the model thenit is easy to re-run assessments as thedesign and the model evolve. Experi-enced practitioners use such techniquesto support interactive explorations.

109

Figure 7.14 Spring performance predictions.

Figure 7.15 Spring switch from heating to cooling.

110

7.5 Controls implementing bound-ary zonesOne of the strategies of the Cookbookis the use of focused models. Modelswhich represent a portion of a buildingare predicated on robust boundary con-ditions. A classic case is an ofcebuilding with a suspended ceilingwhich acts as a return plenum andwhich has gains from ducts and pipesand lighting ttings. Below the occu-pied level is likely to be another ceilingplenum.The temperature in the ceiling voidswill tend to deviate from the air tem-perature of the occupied space. Thusthe standard boundary condition ofdynamic (similar) which isoffered by ESP-r is less accurate thanthe boundary conditions provided by afully described zone.Indeed, if the design question focusedon whether a night purge of the ceilingvoid might provide useful structuralcooling, the boundary condition abovethe suspended ceiling is critical.One technique to reduce the number offully dened zones is to dene anabstract representation of the lowerceiling void as well as the upper occu-pied space as in Figure 7.16.If the occupied space and the ceilingvoid above it are well represented wecan use a control law to force the lowerceiling void to follow the predictedtemperature of the well representedceiling void. We can dene anothercontrol which takes the mean tempera-ture of the manager_a and man-ager_b rooms and conditions the

upper low-resolution occupied space tofollow the predicted temperature of thedened occupied space.The approach is as follows:• Create a basic (ideal) controller for

the occupied space manager_awhich is the same as that used in theprevious example.

• Create a variant of the manager_acontroller for manager_b whichuses a smaller dead-band.

• Create a control law forfloor_below which uses an idealtemperature match controllerwhich pays attention to the currenttemperature in ceiling_above andforces floor_below to the sametemperature.

• Create a control law for bound-ary_up which uses an ideal tem-perature match controller whichpays attention to the current temper-atures in manager_a and man-ager_b and forces boundary_upto the mean temperature.

To demonstrate the temperature match,the temperature in boundary_up isshow in Figure 7.17 as the mean of thecurrent temperatures in manager_aand manager_b. The use of amean temperature of several rooms forthe boundary condition above the slabis one approach. If there are substantialdifferences in temperature expected itmight be necessary to create multipleupper boundary zones. For those whoare attempting to push the boundariesof simulation such exibility may beuseful.

111

Figure 7.16 Bounding control logic.

The summary report of the controls are listed below:

Control description:Ideal control for dual office model. Weekdays normal office hours,Saturday reduced occupied hours, Sunday stand-by only. One person peroffice, 100W lighting and 150W small power. Tighter set-points formanager_b (so the mean control in boundary_up works).

Zones control includes 4 functions.The floor_below zone is controlled to the temperature of the suspended ceilingzone (to act as a boundary). The boundary_up zone is controlled to the meantemperature of manager_a and manager_b.

The sensor for function 1 senses the temperature of the current zone.The actuator for function 1 is air point of the current zoneThe function day types are Weekdays, Saturdays & SundaysWeekday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C.

2 6.00 db temp > flux basic control

112

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 19.00C cool set-point 24.00C.

3 18.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C.Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C.

2 9.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 19.00C cool set-point 24.00C.

3 17.00 db temp > flux free floatingSunday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 10.00C cool set-point 30.00C.

The sensor for function 2 senses dry bulb temperature in floor_below.The actuator for function 2 is the air point in floor_below.There have been 1 day types defined.Day type 1 is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux senses dry bulb tem

match temperature (ideal): max heat cp 2000.W min heat cp 0.W max cool cp 2000.W minheat cp 0.W Aux sensors 1. mean value @senses dry bulb T in ceiling_abv. scale 1.00offset 0.00

The sensor for function 3 senses dry bulb temperature in boundary_up.The actuator for function 3 is the air point in boundary_up.There have been 1 day types defined.Day type 1 is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux senses dry bulb tem

match temperature (ideal): max heat cp 2000.W min heat cp 0.W max cool cp 2000.W minheat cp 0.W Aux sensors 2. mean value @senses dry bulb T in manager_a. & senses dry bulbT in manager_b.

The sensor for function 4 senses the temperature of the current zone.The actuator for function 4 is air point of the current zoneThe function day types are Weekdays, Saturdays & SundaysWeekday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 16.00C cool set-point 26.00C.

2 6.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 20.00C cool set-point 23.00C.

3 18.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 16.00C cool set-point 26.00C.Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C.

2 9.00 db temp > flux basic controlbasic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 19.00C cool set-point 24.00C.

3 17.00 db temp > flux free floatingSunday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control

113

basic control: max heating capacity 2500.0W min heating capacity 0.0W max coolingcapacity 2500.0W min cooling capacity 0.0W. Heat set-point 10.00C cool set-point 30.00C.

Zone to control loop linkages:zone ( 1) manager_a << control 1zone ( 2) manager_b << control 4zone ( 3) coridor << control 1zone ( 4) floor_below << control 2zone ( 5) ceiling_abv << control 0zone ( 6) boundary_up << control 3

Figure 7.17 Mean temperature in boundary_up zone.

In summary, the exibility of zone con-trol loops has both costs and advan-tages. There are currently no wizards toautomate the process so some tasks aretedious. Care and attention to detail isneeded to ensure that the control logicis working well under a variety of oper-ating regimes.The advantage of a exible approach isthat the facility can support the earlyexploration of novel design ideas. Itmay also reduce the complexity ofother aspects of the model and support

scaling of focused model predictions.And by delaying the requirement forspecic details it may allow for abroader exploration of design ideasduring the early design stages.

114

Chapter 8

THERMOPHYSICAL RESOLUTION

8 Thermophysical resolution

In ESP-r there are essential elements ofthe model description which must existfor the simulator to be invoked. Theserelate to the form and composition ofthe model, schedules of occupancy,lighting and small power and option-ally environmental control systems.And the tag-line for ESP-r has longbeen:

functionality follows descriptionThis chapter discuss optional facilitiesto alter the thermophysical resolutionof a model so that, for example, radia-tion exchange is represented explicitlyor convective heat transfer is evaluatedby an alternative computationalapproach.There are many such choices availablewithin simulation tools. They are typi-cally invoked by including additionaldescriptive terms in the model and/oradditional directives to the numericalengine. They are often treated asoptional facilities because there areresource (computing and staff time)implications in invoking them.The user is confronted with the need tounderstand the functionality of suchfacilities. This chapter will provide anoverview of optional facilities availablewithin ESP-r. And, because this is TheCookbook, we are going to balancefunctionality with methods for deciding

when additional thermophysical resolu-tion is required, techniques to deter-mine the resources needed and thenback to methods for taking advantageof the additional information.ESP-r, like other simulation tools isover-functional. It is also a general toolthat can be coerced to carry out eithersomething close to magic or end uplling up hard disks for little or no ben-et to the simulation team. Tool-drivenpractitioners push buttons because theyexist. Readers of the Cookbook mightbe more inclined to be selective in theirbutton pressing.

8.1 Shading and insolationOne thermophysical extension to ESP-ris to replace the default assumptionthat solar radiation enters rooms and isdiffusely distributed within the zonebased on the area and absorption char-acteristics of the surfaces with a tem-poral distribution based on ray trackingcomputations. These are termed inso-lation calculations and are based onuser directives (held in the zone geom-etry le) and carried out by the ishmodule.Another extension is to adjust theassessment of radiation falling on thebuilding facade to take into accountsolar obstructions. Solar obstructionsinitially were constrained to rectangu-lar bodies (dened as an origin,

116

rotation about the Z axis and length,width and height dimensions). Thisbasic type has been extended to allow asecond axis of rotation (i.e. a tilt direc-tive) as well as allowing the coordi-nates of the eight corners of the initialbox shape to be individually edited.The exemplar modeltraining/simple/cfg/bld_sim-

ple_shd.cfg includes a number ofsolar obstruction types which togetherrepresent an adjacent building and atree (Figure 8.1).

Figure 8.1: Room with collection ofsolar obstructions.

The interface for dening shadingdirectives and solar obstructions isfound in the zone geometry menu insolar dist. & calc directivesand solar obstruction.

Any zone which has surfaces whichface the outside can include an insola-tion calculation and any zone whichalso has solar obstructions dened caninclude shading calculations. Thedirectives menu is shown in Figure 8.2

Figure 8.2: Shading & insolation directives.The middle section of the directivesmenu instructs calculations for shadingand insolation to be done for all appli-cable surfaces in the zone. Applicablesurfaces are surfaces which conrm tothe standard rules - shading only onsurfaces which face the outside andinsolation sources must be transparentoutside facing surfaces. There are sev-eral places in the interface where shad-ing and insolation analysis may berequested. The rst is within the direc-tives menu, the second is in the Zonecomposition -> options ->shading & insolation.

Shading calculations are dependant onthe zone composition as well as themodel location and if either of thesechange you are offered the option ofre-calculating shading.

117

Lets look at the solar obstructionswhich are included in Figure 8.1 viathe solar obstructions menu(Figure 8.3)

Figure 8.3: Solar obstruction menu.The upper portion of the menu sets thegridding resolution for solar calcula-tions. This defaults to a grid of 20 x 20points placed on each surface in thefacade. Some complex surfaces, e.g. athin frame around a window, mightrequire a ner grid in order for shadingto be properly calculated.The centre portion of the menuincludes a list of solar obstructions.Each has a short name for purposes ofidentication (they must be uniquewithin the zone) as well as a composi-tion. The composition name is used if

the model is exported to a visual simu-lation tool such as Radiance. Thelower portion of the menu supportsmanagement functions as well as pro-viding direct access to the shadingdirectives menu.The data which dene basic solarobstructions are available by selectingan obstruction. The data for blk_1 isshown in Figure 8.4.

Figure 8.4: Simple obstruction detail menu.There are several options for editingthe origin of the block as well as itssize. It is also possible to apply one ortwo rotations to the block. The optionto convert to general polygonsallows you to further customize anexisting obstruction block to representmore complex shapes.

118

An example of a complex shape is theblock named tree which began as asimple shape and then the upper cor-ners were edited (see Figure 8.5).

Figure 8.5: Tree shaped obstructiondetail menu.

8.2 Shading predictionsOnce shading obstructions and shadingdirectives are dened for a zone thecomputations can be undertaken. Theseare carried out by the ish module asshown in Figure 8.6.The primary selections are calculateshading and shading synopsis orshadow image for shading and thecalculate insolation and inso-lation synopsis for insolation. Ifyou toggle the sky type to non-isotrop-ic the computational time increasesquite a bit. Recent versions of ESP-ralso support the calculation of diffuse

shading.If you request shading you are asked toconrm the period of the assessment(typically month one to month twelve).In the X11 interface you will see somefeedback as the calculations progressbut in the GTK interface the process islargely silent until it is complete (thescreen does not seem to refresh asoften with GTK). You can then ask fora shading synopsis (see Figure 8.7).After shading has been calculated theinsolation analysis can be invoked (itneeds to take account of the shadinganalysis data). The insolation calcula-tions also grid the model surfaces anddetect, for each source of insolation,the percentage of entering direct radia-tion that falls on each of the surfaces ofthe room. This information is recordedin the shading predictions le for use insimulations.You can ask for a synopsis of the inso-lation patterns (see Figure 8.8). Therst column is the time, the second col-umn is the calculated shading, the thirdcolumn includes the names of the sur-faces that were insolated at that timeand the fourth column provides theassociated percentage of the radiation.

119

Figure 8.6: Shading module.

And you can also conrm visually thepatterns of shading by requesting aview from the sun at a specic time ofday and day of the year (Figure 8.7).The screen capture below is for 10h00on a typical day in January. What yousee if what-the-sun-sees. What youcannot see is in shade. This type ofview is also available from the ProjectManager!

Figure 8.7: Visual conrmation of shading.

120

Figure 8.8: Synopsis of shading.

8.3 Radiation view-factorsAlthough many users are familiar withthe idea of convective heat transferbetween the air in a room and the sur-faces surrounding the room, the long-wave radiant transfer between surfacestends to get much less attention. Somepractitioners consider that radiantexchange is of minimal concern in wellinsulated buildings.Those who are working with buildingsor systems where radiant transfer isconsidered important will nd the fol-lowing discussion of interest. Firstly,radiant transfer between surfaces ispart of every simulation assessment

carried out by ESP-r. It is part of theenergy balance] of each surface at eachtime-step of the simulation. Many sim-ulation tools treat long-wav e radiantexchange explicitly but these featuresare largely hidden from the user. InESP-r there are points for user interac-tion and options that allow detailedcomfort assessments.The default assumption in ESP-r is thatlong-wav e radiant exchange betweensurfaces in rooms is diffusely distrib-uted based on the emissivity of the sur-faces and their area. This assumption isappropriate for highly cluttered spacesor where comfort is not an assessmentcriteria.As rooms depart from simple rectangu-lar shapes the diffuse distributionassumption becomes less valid. If radi-ant heating systems are employed thedefault assumption is inappropriate aswould be the case if detailed thermalcomfort is of interest. Sometimes wemay simply want more information.For example, if there is explicit internalmass in the room or if sunlight falls onlightweight constructions then wemight want to see if other surfaces areimpacted.The functionality follows descriptionapproach used elsewhere in ESP-rapplies to the computational resolutionof radiant exchanges within rooms. Ifthe default assumption is not appropri-ate for your model then you canrequest for an explicit calculation ofhow much each surface sees the othersurfaces in the room (and manage thesevalues thereafter).View-factor computations are currentlycarried out in a utility module which

121

uses ray-tracing calculations. Theresults of the calculations are recordedinto a zone view-factor le (typicallywith the le ending vwf). During thesimulation the current temperature ofeach zone surfaces is used with the cal-culated or area-weighted view-factorsto evaluate the radiant transfer withinthe room.The computing resource required isroughly in line with the number of sur-faces in the zone. An eight surface boxwill take a few seconds and a room atthe current geometric limits then one ortwo minutes might be required. Howmight one know if these calculationsare justied? One approach would beto create a virtual experiment usingidentical rooms with and without cal-culated view-factors and spend timeconsidering the differences in the per-formance predictions which result.In projects where thermal comfort is ofparticular interest ESP-r provides facil-ities to dene block shaped radiant sen-sors within a room and to calculatehow much that sensor views the othersurfaces in the room. This informationis used in the results analysis module togenerate radiant asymmetry values.To demonstrate the surface view-factorcalculations and the denition of radi-ant sensors lets look at a simulationmodel for a private room in a hospital.Tw o competing designs of radiant heat-ing panels in room were under consid-eration. One design was claimed to beless costly to install (rectangular unit atthe facade) and the other design wasclaimed to provide better comfort forthe doctor and patient (radiant heat bet-ter distributed in the room and a lower

temperature required).

Figure 8.8: Radiant panel room model.The model (Figure 8.8) was designedas a classic side-by-side virtual experi-ment. The resolution of the model wasdictated by the thermophysical charac-teristics of the entities within the roomsand possible interactions. The designwas also dictated by the need to com-plete the model while the client wasavailable to supply details and so theextent of the initial model was carefullyconsidered.The critical performance metrics werethe comfort for a tall doctor standing atthe window and for the patient in thebed as well as the frequency the panelswere on and how well they were ableto control temperatures within theroom on moderately cold days. In sup-port of this two radiant sensors weredened in each room - one at the loca-tion of the patient’s head and the othera doctor standing near the window(Figure 8.9).

122

Figure 8.9: Locations of radiant sensors.In both rooms the bed was representedas internal mass, the radiant panelswere represented via a thin-zoneapproach and the ceiling plenum aboveand below the rooms were representedas rooms. Diversity was included in theschedules for each zone and in particu-lar the heat output of clinical lightingduring the doctor’s visit was included.The adjacent wards were assumed to beat the same temperature as the roomsbeing investigated. The temperature ofthe upper ceiling void is criticalbecause heat leakage from the panelwas likely to result in a warmer void.This approach would allow changes inthe thickness of upper insulation to bestudied. The lower ceiling void wascontrolled to the same temperature asthe upper ceiling void in order to forma representative boundary condition inthe patients room.

Figure 8.10: Thin-zone radiant panel.The thin-zone approach (Figure 8.10)treats a heat generation device explic-itly as a zone rather than a system com-ponent. Briey, a zone is created whichrepresents the shape of the radiantpanel and the lower surface is metaland the upper surface is an insulatedmetal panel. High heat transfer coef-cients are set within the thin zone sothat any heat injected into the air willbe transferred to the surfaces. Thisapproach was used because setting upsystem components would haverequired additional time and the poten-tially simpler injection into a ceilingconstruction could not be used becauseit was located between two zones (arather irritating and persistent limita-tion). For purposes of this assessmentthe approach was seen to represent theexpected panel temperatures andresponse time while the explicit shapeof the panel surfaces worked well inthe subsequent detailed comfort assess-ments.The left patient room includes an "L"shaped heating panel 400mm wide and

123

the right patient room uses a rectangu-lar panel 600mm wide at the facade.The panels were controlled via a multi-sensor controller which regulated theroom temperature to 21° C based onallowing the thin-zone to rise to 74° C.To reect the response time of the heat-ing circuit the simulation time-step wasset to one minute. After composing themodel calibration assessments wererun to tune the heat injection so that itmatched the expected panel surfacetemperatures.Surface long-wav e view-factors werecomputed for the patient rooms. It wasnot considered necessary to computeview-factors within the radiant panelzones (the high heat transfer at the sur-faces would tend to limit temperaturedifferences). The Project Managerinterface after the computations werecompleted is shown in Figure 8.11The primary selections for most userswould be Calculate zone or MRTview-factors and if there were anyradiant sensors then the Add a MRTsensor requests the origin and size ofthe sensor. Note that existing sensorsare not drawn in the wireframe unlessyou actually select that item to edit.Once you have the sensors denedrequest the calculation and a utilitymodule will be passed the relevantinformation and provide the optionsseen in Figure 8.12.The options you may be interested inare grid division and patchdivision which dene the density ofthe gridding which is used in the calcu-lations. The default is 10 and with thisdefault the computational time is con-strained. If the zone has small surfaces

or surfaces with small dimensions thedefault may not be adequate. You willbe notied if this is the case if somesurfaces have a view-factors that sumto a value which is not close to 1.0. Ifthis is the case you can re-set the gridand patch divisions and try again.Remember to request both calculationsbefore you exit the utility application.When you return to the Project Man-ager you will be asked whether youwant to use the newly computed val-ues.Overall the model was up and runningduring the visit to the clients ofcesand the predictions and ne tuningwere carried out with feedback fromthe client. Assessments indicated thatboth designs resulted in substantiallysimilar comfort levels for the doctor aswell as the patient (see Figures 8.13and 8.14).There was a slightly increased risk ofradiant asymmetry discomfort for thecase of the 600mm wide panel design.It was also clear, howev er that the600mm wide panel was ON more oftenand tended to work at a higher temper-ature than the 400mm wide panelapproach.

124

Figure 8.11: Prj interface to view-factors.

Figure 8.12: View-factor calculation interface.

Another nding was that a 70-74° Cworking uid is often not required androom comfort can often be maintainedat panel temperatures of 40-60° C.

125

Figure 8.13: Predicted temperatures in left zone.

Figure 8.14: Predicted temperatures in right zone.

126

Figure 8.15: Predicted dissatised in both zones.

8.4 Convective heat transfer regimesThis section will be completed at alater date.

127

Chapter 9

PREPARATION FOR SIMULATION

9 Preparation for simulation

In ESP-r the model description caninclude a number of directives aboutthe nature of the numerical assessmentsto be carried out as well as where tostore the performance predictions foreach of the analysis domains. There area number of reasons to embed suchinformation in the model:• decisions made in the planning stage

can be recorded• working practices are made explicit• support for subsequent automation

and production tasks• to allow performance predictions to

be re-generated at a later date• information embedded in a model is

safer than scraps of paperThe idea of simulation directive setscame about because a highly compe-tent user of ESP-r was asked by a clientto re-run a historical project to extractsome additional information. The ar-chive of the model was found and thenotes about the project were scannedand the simulation was re-run but thepredictions had changed. A straightfor-ward task became complicated andfrustrating.What had changed? Where did the faultlie? Had the model become corrupted?Had the numerical engine changed in away that would cause different

predictions? Eventually the causal fac-tor was found to be the number of pre-simulation days that were used. Thatparticular value had not been recordedin the project notes.And thus it became clear that thedescription of the model would bemuch more robust if it included adescription of the specic assumptionsand directives used by the simulationengine.This simplies the task of carrying outproduction runs and reduces thechances of errors. It also supports theidea of implementing the plan. If, atthe planning stage, the team decide thatspecic weeks will be a good test ofbuilding performance the facilitymakes it very easy to implement thetest. In the Project Manager these pref-erences are managed in theBrowse/Edit/Simulate ->Actions -> Simulate -> simula-tion presets menu. The currentvalues for the active simulation presetare included in the upper portion of theSimulation Controller menu(Figure 9.1).

129

Figure 9.1: Simulation parameter sets.Menu options include:• set name - identifying tag for the

simulation e.g. winter, june or mon-soon

• start-up days - pre-simulation periodused to condition the model from itsinitial state. The initial value isbased on a scan of the model compo-sition. Users can increase it toimprove model stability during theinitial hours of an assessment orreduce it to improve run-times.

• zone time-steps/h - the solution fre-quency and how often data arerecorded (see discussion below).

• plant time-step/(bldg ts) - the systemcomponent solution frequency as amultiplier of the zone time-step.This should reect the nature of the

components and the control appliedto them (see discussion below).

• result save lev el - denes how muchinformation is recorded (see discus-sion in section 9.2).

• period of simulation - start and enddate of the simulation (one day towhole year)

• zone results - the le name to holdzone performance data

• ow results - the le name to holdmass ow performance data

• plant results - the le name to holdsystem component performance data

• moisture results - the le name tohold the moisture states

• electrical results - the le name tohold power performance data

Simulation time-steps dictate the fre-quency of the numerical solution and inESP-r this can range from one minuteto one hour. Clearly your choices willhave an impact on the time it takes torun the simulation, the size of the per-formance data les that are generatedduring the simulation as well as thespeed with which performance data canbe extracted (and its temporal detail).The frequency should also reect thenature of the building composition andthe control applied within zones aswell as the types of system componentsused and the control applied to them.If, for example, you use an ON/OFFcontroller which has a response time ofaround a minute then a 15 minute time-step is going to result in a VERYSTICKY CONTROL. If you have an airow network with large openingsbetween rooms you would expect that

130

the ow between the rooms will tend tomoderate the temperature differencesbetween the two zones. A simulationwith a 30 minute time-step can result inun-natural differences in temperaturesbetween adjacent rooms which are thenresolved via the ow solution as a brieftyphoon. It may be necessary to runassessments a different frequencies tond out an appropriate compromise.File names for the result les areincluded in the simulation parametersets so that each run generates knownle names. This reduces confusion andis helpful for automation of simulationwork. For example it is possible toissue a command in the form: bps-file hospital.cfg -p monsoonsilent which will run the hospitalmodel using the simulation parametersassociated with the concept monsoonand create the specic results les andit will to this silently.A group in Denmark once commented

we have two kinds of winterweather patterns that we alwayscheck - the cloudy windy (but notso cold) storm and the very coldbut sunny.

For these observant users there is nosingle worst day and not even a singleworst week and they want to embedthis knowledge into their working prac-tices and into their models so that it isreally easy to ensure these checks aremade.

9.1 Integrated performance viewsObservant design teams also tend tohave a checklist of performance indica-tors that they want to be continuallyreminded of as they evolve their

designs so that the un-intended conse-quences of their latest brilliant ideasare exposed. Others would describethis as multi-criteria assessments andthis is supported in ESP-r via a facilityknown as the Integrated PerformanceView (IPV).IPV directives describe what we wantto measure and where we want to mea-sure it and what assessment periods arerequired. Directives are held in themodel conguration le. These direc-tives are similar to the meters imple-mented in other tools. The difference isin the information content and formatof the requested data. Each request fora performance data type (e.g. zoneresultant temperature, solar enteringthe zone in Figure 9.2) results in a sta-tistical report, tabular data and a sum-mary (because different users recog-nize patterns in different forms).

Figure 9.2: IPV performance metricsset interface.

The following performance metrics canbe included in IPV directives:• zone resultant temperature• zone dry bulb temperature• zone relative humidity• zone inltration load

131

• zone ventilation (from other zones)load

• zone casual gains (all)• zone solar radiation entering from

outside• zone solar radiation absorbed in

roomThis list might be extended to includeother data types selectable within theresults analysis module.There is a separate selection processfor requesting information on environ-mental systems demands (Figure 9.3).The facility allows you to identify setsof zones which you want to associatewith a concept - for examplesouth_offices might include 15 separatezones for which one aggregate report isrequested.

Figure 9.3: IPV demands set interface.It is also possible to specify a multi-plier for environmental systemsdemands. For example, a specicperimeter ofce in your model mightbe representative of a dozen ofces anda scale of 12 could be applied to theperformance of the specic ofce whenderiving the overall performance of thebuilding. This is a particularly usefulfeature of an IPV.

After the performance metric sets andenvironmental demand sets have beendened the task turns to the nature ofthe assessments to be run. An IPV hasthe concept of the following kinds ofassessments:• single annual (or use dened) assess-

ment• three assessments (winter, transition,

summer) which can be a typicalweek in each season or all days ineach season

• ve assessments (winter starting 1Jan, spring, summer, autumn, winterending 31 Dec) which can be a typi-cal week in each season or all daysin each season

The IPV denition also supports theidea of scaling performance predic-tions. If you selected a typical weekthen you have the option to undertakethe same kind of search-for-best-t-weeks as is done in the ESP-r climatemodule.Once the best-t-weeks have beendetermined you have the option to usethe HDD/CDD/solar ratios (as in theclimate module) to determine an initialscaling for heating and cooling. Thevalues for lights are scaled by the ratioof days in the short simulation to thatof the whole season (Figure 9.4).

132

Figure 9.4: IPV interface with ve typ-ical assessments.

Once the IPV directives hav e beendened the information is saved to themodel conguration le and the deni-tion of simulation parameter sets areupdated to match that of the IPV direc-tives. You may then use the Inte-grated Performance View direc-tive in the Simulation menu to auto-matically run the required assessmentsand, optionally to extract the requestedperformance metrics (and their statis-tics and tabular and summary sub-reports) to a so-called IPV report.These simulations will also generatethe standard results les which can beinterrogated interactively for

information not available with the IPVreport itself. Many users make use ofthe framework of the IPV to automatethe production of simulation runs. It isalso useful for large models where asingle simulation would generate aresults le greater than one gigabyte(which tends to be the limit for robustresults sets).If you ask to extract data then theresults analysis module will be invokedwith a command line that directs it toextract the requested data. If there aremultiple assessments then the reportswill be conated and an overall sum-mary will be produced. The overallsummary takes the data from each sea-son and the seasonal scaling factorsincluded in the IPV denition in orderto arrive at annual performance.If your project involves energydemands that are not directly derivedfrom the zone descriptions such as liftsand domestic hot water the IPV willscan a so-called demands le (alsofound in the model context menuand include it in the IPV report.A sample of an IPV report for the col-lection of zones named ofces isincluded in Figure 9.5. Diversiedcapacity is the instantaneous peakwhile the distributed capacity is thepeak in each zone added together. Andthe integrated demand does what itsays on the tin.

133

. . .*assessment, 1,cellular_shd 1st winter run

*report,70,diversified,capacity,offices*title,Diversified capacity,W*format,table,1,7*fields,Heating

CoolingLighting (unctld)Lighting (ctld)FansSmall PowerHot water

*data,1034.4,767.8,0.0,0.0,0.0,0.0,0.0*end_report

*report,70,diffuse,capacity,offices*title,Diffuse capacity,W*format,table,1,7*fields,Heating

CoolingLighting (unctld)Lighting (ctld)FansSmall PowerHot water

*data,1034.4,767.8,0.0,0.0,0.0,0.0,0.0*end_report. . .*report,70,demand,integrated,offices*title,Integrated demand,kWhr*format,table,1,7*fields,Heating

CoolingLighting (unctld)Lighting (ctld)FansSmall PowerHot water

*data,32.99,4.65,0.00,0.00,0.00,0.00,0.00*end_report. . .

Figure 9.5: IPV data processed for displayThere are comfort reports embedded inthe output as well. The data in Figure9.6 is for a collection of rooms calledocup_zones. The format of the fre-quency report is not particularly humanreadable - it contains the same infor-mation as is found in the results analy-sis frequency bin reports.

*report, 6,distribution,comfort,ocup_zones*title,Resultant temperature,degC*format,frequency,12,5,12.0,2.0,30.0*fields,range

distributionpercent

cumulative_distribcumulative_percent

*data0,<12.0,0,0.0,0.0,0.01,12.0-14.0,0,0.00,0,0.002,14.0-16.0,4,1.96,4,1.963,16.0-18.0,19,9.31,23,11.274,18.0-20.0,91,44.61,114,55.885,20.0-22.0,43,21.08,157,76.966,22.0-24.0,27,13.24,184,90.207,24.0-26.0,20,9.80,204,100.008,26.0-28.0,0,0.00,204,100.009,28.0-30.0,0,0.00,204,100.0010,30.0-32.0,0,0.00,204,100.0011,>32.0,0,0.0,0.0,0.0*end_report

*report, 6,stats,comfort,ocup_zones*title,Resultant temperature,degC*format,table,1,3*fields,maximum,minimum,average*data,25.727,14.552,20.266*end_report

Figure 9.6: IPV comfort reportsAnother metric that was requested wasthe inltration into the set of zonesnamed inl_zones (see Figure 9.7).This is typical of the data included forsuch metrics.

*report,11,stats,Infil,infil_zones*title,Infiltration load,W*format,table,1,7*fields,maximum,minimum,average

diversified_max,distributed_maxdiversified_min,distributed_min

*data,-62.752,-88.499,-40.327,0.000,-62.752,-176.673,-178.132

*end_report

Figure 9.7: IPV report on inltrationAnother format of report is a time-steplisting for a typical day in the season.Figure 9.8 is such a listing for the heat-ing demand for the collection of zonesnamed ofces. The rst column is thejulian day of the year and the fractionof the day (12h00 equals 0.5). Thiscould be cut and pasted into a spread-sheet for display.

*report,70,demand,per_unit_time,offices

134

*title,Energy Demand per Unit Time,W*format,tabular,24,7*fields,Time

Heating,Cooling,LightingFans,Small Power,Hot water

*data38.0208,76.0,0.0,0.0,0.0,0.0,0.038.0625,365.7,0.0,0.0,0.0,0.0,0.038.1042,342.8,0.0,0.0,0.0,0.0,0.038.1458,299.6,0.0,0.0,0.0,0.0,0.038.1875,286.3,0.0,0.0,0.0,0.0,0.038.2292,413.2,0.0,0.0,0.0,0.0,0.038.2708,973.8,0.0,0.0,0.0,0.0,0.038.3125,862.6,0.0,0.0,0.0,0.0,0.038.3542,649.2,0.0,0.0,0.0,0.0,0.038.3958,521.5,0.0,0.0,0.0,0.0,0.038.4375,396.9,0.0,0.0,0.0,0.0,0.038.4792,298.6,0.0,0.0,0.0,0.0,0.038.5208,249.4,0.0,0.0,0.0,0.0,0.038.5625,220.1,0.0,0.0,0.0,0.0,0.038.6042,177.9,0.0,0.0,0.0,0.0,0.038.6458,169.2,0.0,0.0,0.0,0.0,0.038.6875,246.6,0.0,0.0,0.0,0.0,0.038.7292,331.7,0.0,0.0,0.0,0.0,0.038.7708,36.9,0.0,0.0,0.0,0.0,0.038.8125,2.9,0.0,0.0,0.0,0.0,0.038.8542,54.8,0.0,0.0,0.0,0.0,0.038.8958,137.8,0.0,0.0,0.0,0.0,0.038.9375,196.7,0.0,0.0,0.0,0.0,0.038.9792,231.8,0.0,0.0,0.0,0.0,0.0*end_report

Figure 9.8: IPV timestep reportAt the end of the IPV report is a sum-mary of performance which has beenseasonally-scaled and zone-scaled andwhich include non-zone demands. Thiskind of report (see Figure 9.9) is onlyavailable within the IPV.

*Summary

*report,98,energy,performance,aggregate*title,Integrated demand,kWh/mˆ2.a*format,table,1,6*fields,Heating,Cooling,Lighting,

Fans,Small Power,Hot water*data,20.796,26.027,10.385,0.000,0.000,0.000*end_report

*report,98,energy,building_performance,aggregate*title,Integrated building demand,kWh/a*format,table,1,6*fields,Heating,Cooling,Lighting,

Fans,Small Power,Hot water*data,736.2,921.4,367.6,0.0,0.0,0.0*end_report

*report,74,power,capacity,aggregate*title,Maximum capacity,W/mˆ2

*format,table,1,6*fields,Heating,Cooling,Lighting,

Fans,Small Power,Hot water*data,32.718,37.636,2.379,0.000,0.000,0.000*end_report

*report,74,power,capacity,aggregate*title,Maximum building capacity,kW*format,table,1,6*fields,Heating,Cooling,Lighting,

Fans,Small Power,Hot water*data,1.16,1.33,0.08,0.00,0.00,0.00*end_report

*report76,distribution,thermal_comfort,aggregat*title,Resultant Temperature,degC*format,frequency,9,6,16.0,2.0,30.0*fields,range,winter_early,spring,summer,autumn*data<16,0,0,0,0,016-18,0,0,0,0,018-20,4,2,0,0,420-22,19,2,0,0,2422-24,91,30,0,16,10924-26,43,25,10,16,5926-28,27,62,23,45,228-30,20,83,158,126,6>30,0,0,6,1,0*end_report*end

Figure 9.9: IPV report on inltrationNote that the raw data is expected willbe interpreted for display via a thirdparty application (see Figure 9.10).Users should keep in mind that the IPVhas similar risks to any prior-specica-tion scheme. If it does not include arelevant range of topics for the currentproject it will fail as technique forenforcing multi-criteria assessments.Many of the exemplar models thatcome with the ESP-r distributioninclude IPV descriptions. Use them toexplore the facility!

135

Figure 9.10: IPV data processed for display

9.2 Results libraries and reportsESP-r differs from other simulationtools in how it records performancedata and subsequently supports accessto that data. The simulator includesoptions for recording performance met-rics as comma separated timestep datain text les, as XML reports, as sum-mary reports or as elds withinbespoke results database les.One of your choices prior to invoking asimulation in the project manager orwithin the simulator is to set the so-called save level. For many users,

simulations are invoked with directivesthat involve the creation of the bespokeresults database les for each solutiondomain (zone ux, mass ows, electri-cal power ow, detailed system compo-nents, computational uid dynamics).For these users, the ESP-r results anal-ysis module is their gateway to under-standing the thermophysical state ofthe model.Each save level species a pre-denedset of performance data to be written.The following is a synopsis for each:Save lev el 0 - a text report is generatedby the simulator if the user requests itafter the assessment has been run. A

136

sample of this report (for one of theexemplar models and an annual simu-lation) is shown in Figure 9.11.Save lev el 1 - zone heating/cooling,zone control point temperature, zonedry bulb temperature into bespokebinary le. This is the smallest bespokebinary le and has minimal overheadwhen generated but is rarely usedbecause of its limited contents.Save lev el 2 - zone heating/cooling, thezone dry bulb temperature, zone con-trol point temperature, surface insideface temperatures, inltration, ventila-tion, surface convective heat transfer atinside faces, casual gains (radiant, con-vective, latent), solar entering room,solar absorbed in zone, solar absorbedat inside face and outside face of eachsurface, relative humidity, latent load,linear thermal bridge ux.This le has somewhat higher overheadwhile it is being written and alsoresults in a somewhat larger bespokebinary le. This save lev el is useful forgeneral investigations that do notrequire nodal temperatures or energybalance reports.Save lev el 3 - in addition to save lev el2 data elds this save lev el includesadditional records which hold the tem-peratures at each node of each surfacein the model. This is useful for plotingtemperature proles within construc-tions.Save lev el 4 - in addition to save lev el2 data elds this save lev el includesadditional records which hold the uxpaths which represent the zone energybalance as well as surface energy bal-ances. This is the default save lev eland although it generates a larger le it

provides the most exibility for ad-hocinvestigations.Save lev el 5 - used by the Hot3000home rating interface from NaturalResources Canada (H£K) as well as inthe formal testing procedures used bythe ESP-r development community.An example of the H3K le is shownin Figure 9.12. It is clearly a variant ofthe save lev el zero le with additionaldata elds.The specic contents of the XML lewhich is generated are determined by ainput.xml le which is assumed to belocated in the model conguration lefolder. Possible patterns in theinput.xml le are discussed in section9.3.Save lev el 6 - this is a relatively com-pact XML report which includesmonthly data summaries. It is used byseveral third party tools to access pre-dictions from ESP-r. It is also usedwhen ESP-r is being used to run UKNational Calculation Method assess-ments for code compliance purposes.Portions of a save lev el six le areshown in Figure 9.13.The rst token in each line is the modelconguration le name, the secondtoken is either the zone name or a keyword (e.g. Total_DHW), the tokenssuch as MH1 stand for monthly heatingjanuary, MC2 would be monthly cool-ing february. Key words such asz_DHW_Month_1_MJ andz_DHW_Month_1_kWh are zonemonthly kWh or MJ for a specictopic.

137

Performance assessment reportResults library cellular_bc_save0.txtClimate file /Users/jon/esru_jwhn/esp-r/climate/clm67Configuration file cellular_bc0.cfgConfiguration descr base case model of two adjacent cellular officesPeriod Sun-01-Jan to Sun-31-Dec Year 1967

Zone max air T (occurrence) min air T (occurrence)manager_a 30.00 [email protected] 10.00 Sun-01-Jan@ 4.25manager_b 30.00 [email protected] 10.00 Sun-01-Jan@ 4.25coridor 30.00 [email protected] 13.68 Sun-01-Jan@ 7.75

Zone max heat (kW) max cool (kW) heating (kWhr) cooling (kWhr)manager_a 0.79 Mon-09-Jan@ 6.75 -1.76 [email protected] 271.9 -797.9manager_b 0.79 Mon-09-Jan@ 6.75 -1.76 [email protected] 271.9 -797.9coridor 0.32 Mon-09-Jan@ 7.25 -0.58 [email protected] 10.5 -480.9

All zones:Max_Temp 30.0 in manager_a on [email protected]_Temp 10.0 in manager_a on Sun-01-Jan@ 4.25Max_Heat 0.8 in manager_b on Mon-09-Jan@ 6.75Max_Cool -1.8 in manager_a on [email protected]

Total heating requirements 554.3 (kWhr) 1995.6 (MJ)Total cooling requirements -2076.64 (kWhr) -7475.9 (MJ)

Monthly metrics:Month Heating Cooling Heating CoolingMonth (kWhr) (kwhr) (MJ) (MJ)Jan 164.5 -11.4 592.1 -41.0Feb 76.8 -38.7 276.4 -139.3Mar 25.0 -179.1 90.0 -644.7Apr 24.8 -118.2 89.1 -425.5May 2.8 -274.8 10.1 -989.2Jun 0.0 -323.3 0.0 -1163.9Jul 0.0 -433.4 0.0 -1560.3Aug 0.0 -409.6 0.0 -1474.7Sep 2.4 -124.7 8.5 -448.9Oct 9.1 -120.3 32.8 -432.9Nov 101.4 -28.4 365.0 -102.1Dec 147.6 -14.9 531.5 -53.5

Figure 9.11: Save lev el zero reportPerformance assessment reportResults library HC_no-ISO.bresClimate file /usr/esru/esp-r/climate/uk_gatwick_iwecConfiguration file HC_no-ISO_temp.cfgConfiguration descr Comparison model for hc ISO 15099 w/o .htc file (default hc-s)Period Tue-09-Jul to Mon-15-Jul Year 1991

Zone max air T (occurrence) min air T (occurrence)TheSpace 26.05 [email protected] 24.00 Thu-11-Jul@ 5.75hungCeiling 27.17 [email protected] 24.85 Sat-13-Jul@ 6.45TheChannel 39.50 [email protected] 14.90 Thu-11-Jul@ 4.05mixBottom 32.30 [email protected] 11.98 Thu-11-Jul@ 3.95mixTop 37.91 [email protected] 15.65 Thu-11-Jul@ 4.15

Zone max heat (kW) max cool (kW) heating (MJ) cooling(MJ)TheSpace -0.29 Tue-09-Jul@ 0.05 -1.00 [email protected] -0.1 -257.2hungCeiling 0.00 Tue-09-Jul@ 0.05 0.00 Tue-09-Jul@ 0.05 0.0 0.0TheChannel 0.00 Tue-09-Jul@ 0.05 0.00 Tue-09-Jul@ 0.05 0.0 0.0mixBottom 0.00 Tue-09-Jul@ 0.05 0.00 Tue-09-Jul@ 0.05 0.0 0.0

138

mixTop 0.00 Tue-09-Jul@ 0.05 0.00 Tue-09-Jul@ 0.05 0.0 0.0

All zones:Max_Temp 39.5 in TheChannel on [email protected]_Temp 12.0 in mixBottom on Thu-11-Jul@ 3.95Max_Heat 0.0 in hungCeiling on Tue-09-Jul@ 0.05Max_Cool -1.0 in TheSpace on [email protected]

Total heating requirements -0.1 (MJ)Total cooling requirements -257.21 (MJ)

Monthly metrics:Month Heating (MJ) Cooling (MJ)Jul -0.1 -257.2

********BUILDING INFORMATION********

********SYSTEMS INFORMATION*********

FAN, HRV, AND PUMP ELECTRIC ENERGYMONTH FAN_ENERGY MJ HRV ENERGY MJ GSHP_PUMP MJ GCEP_PUMP MJ

JUL 0.0000 0.0000 0.0000 0.0000TOTAL ELEC ENERGY 0.0000 0.0000 0.0000 0.0000

**********ZONE INFORMATION*********

Zone( 1) TheSpaceMonth Aver.Temp (oC) Solar Extern(MJ) Solar Intern(MJ) Sol Abs Trans(MJ)Jul 24.1167 0.0000 217.4513 5.0579... Sol Abs Opq.(MJ) Casual Rad. (MJ) Casual Conv. (MJ) Fndtn Losses(MJ)

203.4809 0.0000 0.0000 0.0000

Zone( 2) hungCeilingMonth Aver.Temp (oC) Solar Extern(MJ) Solar Intern(MJ) Sol Abs Trans(MJ)Jul 25.6227 0.0000 0.0000 0.0000... Sol Abs Opq.(MJ) Casual Rad. (MJ) Casual Conv. (MJ) Fndtn Losses(MJ)

0.0000 0.0000 0.0000 0.0000

Zone( 3) TheChannelMonth Aver.Temp (oC) Solar Extern(MJ) Solar Intern(MJ) Sol Abs Trans(MJ)Jul 22.7131 692.8182 8.9125 172.7284... Sol Abs Opq.(MJ) Casual Rad. (MJ) Casual Conv. (MJ) Fndtn Losses(MJ)

224.6422 0.0000 0.0000 0.0000...

SDHW DataMonth Tank Elec (kWhr) Tank Fuel (kWhr) Solar Gain (kWhr) Pump Elec (kWhr)JUL 0.0000 0.0000 0.0000 0.0000

Total 0.0000 0.0000 0.0000 0.0000

Figure 9.12: Save lev el ve H3K report

Case_ID,Zone_ID,key,Valueretail_unit_not.cfg,sales_area,z_DHW_Month_1_MJ, 205.723retail_unit_not.cfg,sales_area,z_DHW_Month_1_kWh, 57.145retail_unit_not.cfg,sales_area,z_Lights_Month_1_kWh, 11602.7retail_unit_not.cfg,sales_area,z_DHW_Month_2_MJ, 185.815retail_unit_not.cfg,sales_area,z_DHW_Month_2_kWh, 51.615retail_unit_not.cfg,sales_area,z_Lights_Month_2_kWh, 10448.1. . .retail_unit_not.cfg,sales_area,z_DHW_Month_12_MJ, 205.723retail_unit_not.cfg,sales_area,z_DHW_Month_12_kWh, 57.145retail_unit_not.cfg,sales_area,z_Lights_Month_12_kWh, 11541.0retail_unit_not.cfg,sales_area,z_DHW_MJ, 2422.226retail_unit_not.cfg,sales_area,z_DHW_kWh, 672.841

139

retail_unit_not.cfg,sales_area,z_DHWkWhperm2, 1.019retail_unit_not.cfg,sales_area,z_ReqLight_kWhm2, 206.404retail_unit_not.cfg,sales_area,z_Aux_Month_1_kWh, 1804.083. . .retail_unit_not.cfg,sales_area,z_Aux_Month_12_kWh, 1804.083retail_unit_not.cfg,sales_area,z_hrs_operation, 4200.000retail_unit_not.cfg,sales_area,z_Auxiliary_kWhm2, 32.801retail_unit_not.cfg,sales_area,Overh_PercentOcc_Above27, 18.223retail_unit_not.cfg,storage,z_DHW_Month_1_MJ, 0.000retail_unit_not.cfg,storage,z_DHW_Month_1_kWh, 0.000retail_unit_not.cfg,storage,z_Lights_Month_1_kWh, 187.4. . .retail_unit_not.cfg,storage,z_DHW_Month_12_MJ, 0.000retail_unit_not.cfg,storage,z_DHW_Month_12_kWh, 0.000retail_unit_not.cfg,storage,z_Lights_Month_12_kWh, 184.9retail_unit_not.cfg,storage,z_DHW_MJ, 0.000retail_unit_not.cfg,storage,z_DHW_kWh, 0.000retail_unit_not.cfg,storage,z_DHWkWhperm2, 0.000retail_unit_not.cfg,storage,z_ReqLight_kWhm2, 6.457retail_unit_not.cfg,storage,z_Aux_Month_1_kWh, 287.556. . .retail_unit_not.cfg,storage,z_Aux_Month_12_kWh, 285.897retail_unit_not.cfg,storage,z_hrs_operation, 4140.000retail_unit_not.cfg,storage,z_Auxiliary_kWhm2, 10.098retail_unit_not.cfg,storage,Overh_PercentOcc_Above27, 5.045retail_unit_not.cfg,Total_DHW,t_DHW_kWh, 672.841retail_unit_not.cfg,Total_DHW_per_mˆ2,t_DHW_kWhperm2, 0.673retail_unit_not.cfg,Total_lighting,t_light_kWh, 138422.000retail_unit_not.cfg,Total_lighting_per_mˆ2,t_light_kWhperm2, 138.422retail_unit_not.cfg,Total_Auxiliary_Energy,t_aux_kWh, 25082.238retail_unit_not.cfg,Total_Auxiliary_per_mˆ2,t_auxiliary_kWhperm2, 25.082retail_unit_not.cfg,sales_area,MH1, 4.334retail_unit_not.cfg,sales_area,MC1, 0.000. . .retail_unit_not.cfg,sales_area,MH12, 4.495retail_unit_not.cfg,sales_area,MC12, 0.000retail_unit_not.cfg,sales_area,integrZAHforFloorArea, 11686.840retail_unit_not.cfg,sales_area,integrZACforFloorArea, -56970.551retail_unit_not.cfg,storage,MH1, 15.775retail_unit_not.cfg,storage,MC1, 0.000. . .retail_unit_not.cfg,storage,MH12, 15.576retail_unit_not.cfg,storage,MC12, 0.000retail_unit_not.cfg,storage,integrZAHforFloorArea, 23314.041retail_unit_not.cfg,storage,integrZACforFloorArea, 0.000

Figure 9.13: Save lev el six report

Each option for recording building andsystem performance during a simula-tion must be matched by a procedure toextract useful information. For sav elevels two, three and four this will pri-marily be the results analysis modulediscussed in Chapter 10.

9.3 XML output directivesXML and CSV reports which are gen-erated based on instructions in aninput.xml le which is assumed to belocated in the same folder as the modelconguration le if the user hasselected save lev el 5 or 6. Comma sep-arated data is simply dumped into col-umns in a text le and relies on post-processing by the user.

140

XML reports benet from the addedstructure of XML and thus is moreammenable to post-processing tasks.The formal testing of source codechanges relies on XML reports to iden-tify differences in predictions. XMLreports are, by their nature much moreverbose than the equivalent csv le andrely on the user for post-processing.The simple input.xml le in Figure9.14 was taken from one of the stan-dard source code testing models.

<?xml version="1.0" encoding="UTF-8"?><configuration><hierarchy>tree</hierarchy><dump_all_data>true</dump_all_data><time_step_averaging>false</time_step_averaging>

</configuration>

Figure 9.14: Minimal input.xml ledumping everything

This le is short and includes a direc-tive to dump_all_data and thus createsan extensive output based on the com-plete XML data dictionary e.g. the datatypes within the simulation process thatare able to be exported via XML proto-cols. Note that only a subset of the sim-ulation variables have XML protocolsenabled.Figure 9.15 includes a portion of a datadictionary which was generate by thesimulator for a model. Figure 9.16 isthe header of the csv le for a simplemodel with the dump_all directive andindicates the nature of the (potentiallyhundreds) of data items. The singlelong header line has been warped sothat the data elds can be seen. This isfollowed by the initial columns of data,each row is one timesetep.

If we are not interested in everythingthe phrases in the out.dictionary leabove provide the syntax for ne-tun-ing the output. For example if wewanted to discover what informationwas available at the air node of zoneswe might search for this using the pat-tern matching tool grep (see Figure9.17).This indicates that there are three zonesthat the simulator has detected and itcan report on relative_humidity or tem-perature. Thus if we wanted atimestep listing of the air temperaturesin each of the rooms in the model wecould adopt the following conventionsin the input.xml le in Figure 9.18.The zone_* is a wild card in Figure9.18 allows matching for multiplezones. The day and time variables areuseful for plotting the temperatures.This yields the focused report withseven columns of data in Figure 9.19

141

Building/Ground_Reflectivity: Reflectivity of the ground forsolar radiation dimensionless

Climate/SnowDepth: Depth of the snow on the ground cm

building/all_zones/energy_balance/net: Energy balance inbuilding (Gains + Plant interaction - Loads; all zones). (W)

building/all_zones/envelope/all_components/heat_loss: Heatlost through all components of envelope (all zones) (W)

building/all_zones/envelope/all_components/net_flux: Netheat lost through all components of envelope (all zones) (W)

building/all_zones/envelope/ceilings/heat_gain: Heat gainfrom surroundings through ceilings (all zones) (W)

building/all_zones/envelope/ceilings/heat_loss: Heat lossto surroundings through ceilings (all zones) (W). . .

Figure 9.15: Portion of the XML data dictionaryBuilding:Ground Reflectivity dimensionless, Climate:SnowDepth cm,building:all zones:energy balance:net (W),building:all zones:envelope:all components:heat loss (W),building:all zones:envelope:all components:net flux (W),building:all zones:envelope:ceilings:heat gain (W),building:all zones:envelope:ceilings:heat loss (W),building:all zones:envelope:ceilings:net flux (W),building:all zones:envelope:floors:heat gain (W),building:all zones:envelope:floors:heat loss (W),building:all zones:envelope:floors:net flux (W),building:all zones:envelope:foundation:heat gain (W),building:all zones:envelope:foundation:heat loss (W),building:all zones:envelope:foundation:net flux (W),building:all zones:envelope:infiltration:heat gain (W),building:all zones:envelope:infiltration:heat loss (W),building:all zones:envelope:infiltration:net flux (W),building:all zones:envelope:walls:heat gain (W),building:all zones:envelope:walls:heat loss (W),building:all zones:envelope:walls:net flux (W),building:all zones:envelope:windows:heat gain (W),building:all zones:envelope:windows:heat loss (W),building:all zones:envelope:windows:net flux (W),building:all zones:insolation:adverse (W),building:all zones:insolation:total (W),building:all zones:insolation:useful (W),building:all zones:internal gains:adverse (W),building:all zones:internal gains:total (W),building:all zones:internal gains:useful (W),building:all zones:supplied energy:cooling (W),building:all zones:supplied energy:heating (W),building:all zones:supplied energy:net flux (W),building:all zones:thermal loads:cooling:total (W),building:all zones:thermal loads:heating:total (W),building:all zones:thermal loads:net (W),building:day:future (day), building:day:present (days),building:day number:future (day), building:day number:present (days),building:hour:future (hours), building:hour:present (hours),building:month (-), building:time:future (hours),building:time:present (hours), building:time step (-),building:zone 01:air point:relative humidity (%),

142

building:zone 01:air point:temperature (oC),building:zone 01:envelope:all components:heat gain (W),building:zone 01:envelope:all components:heat loss (W),building:zone 01:envelope:all components:net flux (W),building:zone 01:envelope:ceilings:heat gain (W),building:zone 01:envelope:ceilings:heat loss (W),building:zone 01:envelope:ceilings:net flux (W),building:zone 01:envelope:floors:heat gain (W),building:zone 01:envelope:floors:heat loss (W),building:zone 01:envelope:floors:net flux (W),building:zone 01:envelope:foundation:heat gain (W),building:zone 01:envelope:foundation:heat loss (W),building:zone 01:envelope:foundation:net flux (W),building:zone 01:envelope:infiltration:air changes per hour (ACH),building:zone 01:envelope:infiltration:heat gain (W),building:zone 01:envelope:infiltration:heat loss (W),building:zone 01:envelope:infiltration:net flux (W),building:zone 01:envelope:walls:heat gain (W),building:zone 01:envelope:walls:heat loss (W),building:zone 01:envelope:walls:net flux (W),building:zone 01:envelope:windows:heat gain (W),building:zone 01:envelope:windows:heat loss (W),building:zone 01:envelope:windows:net flux (W),building:zone 01:insolation:adverse (W),building:zone 01:insolation:total (W),building:zone 01:insolation:useful (W),building:zone 01:internal gains:adverse (W),building:zone 01:internal gains:total (W),building:zone 01:internal gains:useful (W),building:zone 01:supplied energy:cooling (W),building:zone 01:supplied energy:cooling Perm2 (W/m2),building:zone 01:supplied energy:heating (W),building:zone 01:supplied energy:heating Perm2 (W/m2),building:zone 01:supplied energy:net (W),building:zone 01:supplied energy:net Perm2 (W/m2),building:zone 01:surface 01:HCe (W/(m2 K)),building:zone 01:surface 01:HCi (W/(m2 K)),building:zone 01:surface 01:heat flux:above grade:net (W),building:zone 01:surface 01:heat flux:radiation:shortwave (W),building:zone 01:surface 01:heat flux:radiation:shortwave:unit area (W/m2),building:zone 01:surface 01:plant containment flux (W),building:zone 01:surface 01:temperature (oC),building:zone 01:thermal loads:cooling:total (W),building:zone 01:thermal loads:cooling:total Perm2 (W/m2),building:zone 01:thermal loads:heating:total (W),building:zone 01:thermal loads:heating:total Perm2 (W/m2),building:zone 01:thermal loads:net load (W),building:zone 01:thermal loads:net load Perm2 (W/m2),building:zone 02:air point:relative humidity (%),building:zone 02:air point:temperature (oC),building:zone 02:envelope:all components:heat gain (W),building:zone 02:envelope:all components:heat loss (W),building:zone 02:envelope:all components:net flux (W),... (for remaining zones in the model)

0.20000000, 0.0000000, 0.0000000, 139.71202, 0.0000000, 39.904453,... (for the remaining dozens of columns of data)

Figure 9.16: Fragments of matching csv output le

grep -ni air_point out.dictionary181:building/zone_01/air_point/relative_humidity:185:building/zone_01/air_point/temperature:737:building/zone_02/air_point/relative_humidity:

143

741:building/zone_02/air_point/temperature:1293:building/zone_03/air_point/relative_humidity:1297:building/zone_03/air_point/temperature:

Figure 9.17: Searching for patterns in out.dictionary<?xml version="1.0" encoding="UTF-8"?><configuration><apply_style_sheet>true</apply_style_sheet><dump_all_data>false</dump_all_data><enable_xml_wildcards>true</enable_xml_wildcards><hierarchy>flat</hierarchy><link_style_sheet>true</link_style_sheet><output_dictionary>true</output_dictionary><report_startup_period_data>false</report_startup_period_data><save_to_disk>false</save_to_disk><time_step_averaging>false</time_step_averaging><style_sheet>generic_summary.xsl</style_sheet><transform_destination_file>summary_out.csv</transform_destination_file><step_variable>building/day/*</step_variable><step_variable>building/time/*</step_variable><step_variable>building/zone_*/air_point/temperature</step_variable>

</configuration>

Figure 9.18: input.xml with wild cards and focus on zone air temperature

building:day:future (day), building:day:present (days), building:time:future (hours),building:time:present (hours), building:zone 01:air point:temperature (oC),building:zone 02:air point:temperature (oC), building:zone 03:air point:temperature (oC),

37.020832, 37.000000, 0.50000000, 24.000000, 14.642880, 14.654573, 19.864250,37.041668, 37.020832, 1.0000000, 0.50000000, 14.468969, 14.481015, 19.701271,37.062500, 37.041668, 1.5000000, 1.0000000, 15.000001, 15.000000, 19.546917,37.083332, 37.062500, 2.0000000, 1.5000000, 14.999999, 15.000001, 19.402882,37.104168, 37.083332, 2.5000000, 2.0000000, 15.000000, 15.000000, 19.276993,37.125000, 37.104168, 3.0000000, 2.5000000, 15.000000, 15.000000, 19.168110,37.145832, 37.125000, 3.5000000, 3.0000000, 15.000000, 15.000001, 19.065680,37.166668, 37.145832, 4.0000000, 3.5000000, 15.000000, 15.000000, 18.966738,37.187500, 37.166668, 4.5000000, 4.0000000, 15.000000, 15.000000, 18.871716,37.208332, 37.187500, 5.0000000, 4.5000000, 14.999999, 14.999999, 18.780247,. . .

Figure 9.19: out.csv focused on zone air temperature

9.4 XML user interactionsUnlike the denition of the IntegratedPerformance View (IPV) which isdened within the Project Manager thesetup for the H3K reporting is in thesimulator itself in the opening menuwhich is visable after the model hasbeen scanned in (see Figures 9.20 and9.21).

144

Figure 9.20: H3K Reports setupFirst select enable H3K reports andthen you are presented with the full listof options.

Figure 9.21: H3K Reports options

The initial input.xml le after youselect to enable H3K reports and selecta tree structure for the XML and turnon timestep averaging is shown below.The listing shown in Figure 9.22 doesnot specify what data to include in thereport. User editing of the le isneeded.Once dictionary output has beenenabled in the interface, the next timeyou run a simulation with this modelan out.dictionary le and out.xml willbe created. out.dictionary is a aide forusers and out.xml is used by the simu-lation engine.The H3K reporting (save lev el 5)allows for a number of styles of pre-dened output from a generic summaryand generic html based summary to aH3K specic summary or csv le for-mat. These are found in the ESP-r dis-tribution folder xsl:• fc_stylesheet.xsl - a template for fuel

cell models• generic_summary.xsl - a typical

monthly summary report• generic_summary_html.xsl - a typi-

cal monthly summary as html• h3k.xsl - a template for use with

H3K projects• h3k_csv.xsl - a template for csv

reporting of H3K projects• h3k-pretty-print.xsl a html output for

use with H3KOnce you have entered the full path tothe xsl le folder the interface willchange and include specic XSLT for-matting options as in Figure 9.23.

145

input.xml<?xml version="1.0" encoding="UTF-8"?><configuration><apply_style_sheet>false</apply_style_sheet><dump_all_data>false</dump_all_data><enable_xml_wildcards>false</enable_xml_wildcards><hierarchy>tree</hierarchy><link_style_sheet>false</link_style_sheet><output_dictionary>true</output_dictionary><report_startup_period_data>false</report_startup_period_data><save_to_disk>false</save_to_disk><time_step_averaging>true</time_step_averaging>

</configuration>

Figure 9.22: initial input.xml with nothing to write

Figure 9.23: H3K Reports XSLT optionsAfter selecting, for example thegeneric_summary_html.xsl style sheetthe input.xml le is expanded (seebelow):

. . .<style_sheet>generic_summary_html.xsl</style_sheet><transform_destination_file>results.html</transform_destination_file>

</configuration>

A typical html output would look likeFigure 9.24 (but would typicallyinclude more months data).If you return to the simulator SIMULmenu and switch to save lev el 5 (H3Koutput) and run a simulation you willget a <model_root_name>.h3k le. Ifyou switch to save lev el 6 and have aninput.xml le in your model folder youwill get an out.xml and out.csv and an<model_root_name>.txt le.Having discussed the process of settingup a simulation to record what we wantthe next chapter focuses on how wemight use the recorded information tounderstand how a design performs.

146

Figure 9.24 HTML output based on XSLT style sheets.

147

Chapter 10

UNDERSTANDING PERFORMANCE PREDICTIONS

10 Understanding performance predictions

As ESP-r workshops have evolved overthe years a pattern has emerged. Partic-ipants end up spending almost as muchtime in the task of understanding theperformance of models they created asthey did in creating the model. Thissame pattern is also found in simula-tion teams that deliver information thatexceeds client expectations. Under-standing performance predictions iscritical for testing that the semantics ofthe model are correct.Essentially, we inv est our time andenergy in the creation of models inorder to get to the point where we canexplore the temperatures and ux andow that were generated by the simula-tion engine. The better our skills asidentifying patterns and looking at thechain of thermophysical dependencieswithin our virtual world the better wecan reach that AH! point where wecan tell someone else a good storyabout what we have found.ESP-r differs from other simulationtools in that it records the thermophysi-cal state of the model at each time-stepinto one or more random access les(depending on the number of analysisdomains processed by the simulationengine). Some would call these randomaccess les databases. The ESP-r suiteincludes a module res which is able torecover the values of the

thermophysical state and present themin graphical, statistical and tabularform.Other simulation tools tend to write outpre-selected performance data and relyon third party applications to parse andprocess and display such information.This is also the case for the XML andCSV reports of ESP-r.The essential difference in the resultsanalysis module of ESP-r is philoso-phy. In one case you tell the the simu-lation engine exactly what to recordbefore you run the simulation and inthe other case the user directives areessentially delayed until the point ofdata extraction.

Risk: if the simulation engine onlyrecords what you ask it to recordunintended consequences or oppor-tunities may not be identiedRisk: performance data needed forclarication may not be availableand require altering the directivesand re-running the simulationBenet: for standard reports and Iknow what I want user directives andpost processing via third party toolsis efcient.

10.1 The res moduleRes is a tool for interactive exploration.It allows users to create ad-hoc collec-tions of performance metrics and view

149

them in different formats or performstatistical operations on the data anddisplay it in various forms. So, forexample, the temperature at the insideface of a surface can be the subject ofstatistical reports, time-step listings orgraphed.Such facilities are used by practitionersto react to ad-hoc questions and toexplore dependencies within themodel. And, of course, experiencedusers have methodologies of explo-ration which they use to identify unin-tended consequences as well as oppor-tunities.Because the display of graphs andtables and tabular data is optimized forinteractive work it tends not to be suit-able for presentation reports and thetypical approach taken is to export therelevant data in a format that can beprocessed by a third party application.The number of choices in the res mod-ule is extensive so a review of themenu hierarchy is the rst step in mas-tering this tool. The top level choicesare listed in Figure 10.1.

results analysis:1 Select result file2 Select result set3 Define output period4 Select zones-------------------

a Graphsc Time-step reportsd Enquire aboute Plant resultsf Indoor env. qualityg Electrical resultsh CFDi Sensitivityj IPV-------------------

r Report >> silent* Preferences? Help- Quit

Figure 10.1: High level choices in res moduleIf you request a results analysis in theproject manager the res applicationwill be passed the name of the zoneresults le. You have the option ofnominating a different le name fromwithin the application or to start reswith a command line option of a spe-cic results le.A zone results le can contain morethan one period of performance data(e.g. a winter week and a summerweek). If more than one set is includedthen res must be instructed as to whichset to use (option 2 in Figure 10.1).Note that the ow and systems resultsles can only hold a single period.Many users prefer to use separateresults les for different periods (this isthe pattern used by the IPV for sea-sonal assessments, each season gets aunique le name).Many of the menus in res include anoption to dene the output period fromthe whole period of the assessment toselected days of the assessment. Thiswould cause graphs to zoom in or sta-tistics to be generated for the selecteddays.The primary choices for how you wantto view the performance informationare found in choices:• Graphs• Time-step reports• Enquire about (see section 10.1.1).The Plant results choice opens a sepa-rate system results le while the Elec-trical results opens and scans a powerpredictions le and the CFD optionopens and scans a CFD domain

150

specic le.The option IPV is typically not selectedby users because the Integrated Perfor-mance View facility is controlled fromthe project manager via a commandline syntax when res is invoked.

10.1.1 Enquire aboutSeveral classes of statistical report arefound in the Enquire about menu struc-ture shown in Figure 10.2.

Enquire about:2 select result set3 define output period4 select zones-------------------

a summary statisticsb frequency table-------------------

c hours above a valued hours below a value-------------------

f energy deliveredg casual gains distribh zone energy balancei surface energy balncj surface condensationk intrstl condensation-------------------

l monthly gains/lossesm monthly temp. stats-------------------

> output >> screenˆ delim >> normal? help- exit

Figure 10.2: Enquire about choicesThe number of different performancemetrics which are available via sum-mary statistics can be seen by thechoices offered in the Figure 10.3.

Summary statistics:2 Result set3 Display period4 Select zones------------------

a Climateb Temperaturesc Comfort metricsd Solar processes

------------------f Zone fluxg Surface fluxh Heat/cool/humidifyi Zone RHj Casual gainsk Electrical demand------------------

m Renewables/adv. comp.n Network air/wtr flowo CFD metricsp Measured:temporal------------------

> Display to >> screen& Data: as values+ Filter >> none* Time >> 10h30ˆ Delim >> normal? Help- Exit

Figure 10.3: Summary statistics choicesSummary statistics reports take thegeneral form shown in Figure 10.4.The extreme values and time of occur-rence are reported along with the meanand standard deviation for each itemand the last line of the report is theoverall peak and mean.The time of occurrence is a particularlyvaluable part of the report. For exam-ple a peak temperature of 27C duringoccupied hours is likely to be of greaterconcern than the same peak if it hap-pened at 23h00.

151

Lib: cellular_bcwin.res: Results for cellular_bcPeriod: Mon-09-Jan@00h15(1967) to Sun-15-Jan@23h45 : sim@30m, output@30mZone db temperature (degC)

Description Maximum Minimum Mean Standardvalue occurrence value occurrence value deviation

manager_a 23.979 14-Jan@14h15 10.000 09-Jan@00h15 16.598 2.6780manager_b 23.979 14-Jan@14h15 10.000 09-Jan@00h15 16.598 2.6781corridor 24.004 14-Jan@17h15 13.981 09-Jan@00h45 19.639 2.0037

All 24.004 -- 10.000 -- 17.612 --

Figure 10.4: Typical summary statistics report

The sub-sections of the summary sta-tistics are seen in Figure 10.5.Climate choices::a Ambient temperatureb Solar Dir Nc Solar diffused Wind speede Wind directionf Ambient RHg Sky illumunance____________________

? help- exit this menu

Temperature choices::a Zone db Tb Zone db T - ambient db Tc Zone db T - other zone db Td Zone control point Te Zone Resultant Tf Mean Radiant T (area wtd)g Mean Radiant T (at sensor)h Dew point Ti Surf inside face Tj Surf T - dewpoint Tk Surf outside face Tl Surf node T__________________________

? help- exit this menu

Comfort choices::a Predicted Mean Vote (PMV)b PMV using SETc Percentage Dissatisfied (PPD)d Local delta T head-foote Dissatisfied due to floor Tf Diss. warm/ cool ceilingg Diss. wall rad T asymmetry__________________________? help- exit this menu

Select a solar flux metricSolar choices::

a Solar entering from outsideb Solar entering from adjc Solar absorbed in zone__________________________

? help- exit this menu

Figure 10.5: Climate, temperature,comfort and solar choices

Some of these directly match the datatypes set out in section 9.2 and otherssuch as Zone db T - ambient db T andPredicted Mean Vote (PMV) arederived values.The second section of the summarystatistics menu includes zone flux andsurface flux and these expand to theconstituent parts of the zone and sur-face energy balance which were writ-ten into the le store (Figure 10.6):Zone flux options::a Infiltration (from outside)b Ventilation (adj zones)c Occupant casual gains (R+C)d Lighting casual gains (R+C)e Small power casual gains (R+C)f Controlled casual gains (R+Cg Opaq surf conv @extrnh Opaq surf conv @partnsi Tran surf conv @extrnj Tran surf conv @partnsk Total surface conv__________________________

? help- exit this menu

Surface fluxes:a conduction (inside)b convection (inside)

152

c LW radiation (inside)d SW radiation (inside)e radiant casual occupf radiant casual lightg radiant casual equiph contrld casual gainsi heat storage (inside)j plant inj/extr (inside)k conduction (other face)l convection (other face)m long wave > buildingsn long wave > skyo long wave > groundp SW rad abs (other fc)q SW rad incid (other fc)r heat storage (other fc)0 Page part: 1 of 2< index select? help- exit this menu

Figure 10.6: Zone and surface energybalance choices

These zone and surface energy balanceux path reports complement the fullzone and surface energy balancereports (see section 10.1.4) and can beused to detect extreme occurrences.

10.1.2 Environmental systemsreportingThere are several approaches to den-ing environment systems in ESP-r - asideal controls or as detailed systemcomponents. In the results analysis ifyou want to see the environment sys-tem loads you would use theHeat/cool/humidify option. If you useddetailed components then additionalinformation will be available in theplant reporting. The current choicesare shown in Figure 10.7.

Load choices::a Sensible heating loadb Sensible cooling loadc Dehumidification loadd Humidification loade All sensible loadsf All latent loadsg All Sensible + latent load__________________________

? help- exit this menu

Figure 10.7 Heat / Cool / Humidify options.You can report on heating separatelyfrom cooling or conated together.Although in any zone you would notget a controller to simultaneously pro-vide heating and cooling at the sametime-step, there could be heating onone zone and cooling in another zoneat a point in time.The latent loads will be reported if youhave specied humidity control, other-wise the latent loads are zero.

10.1.3 Casual gainsThe reporting of casual gains in zonestakes many forms because casual gainsare made up of sensible and latentcomponents as well as convective andradiative fractions of the sensible gainsand there are (currently) three types ofcasual gains that can be tracked in eachzone. The selection list is shown inFigure 10.8.

Casual sensible and latent:a all sensible (conv+rad)b all sensible convectivec all sensible radiantd all latente occupant (conv+rad)f occupant convectiveg occupant radianth occupant latenti lighting (conv+rad)j lighting convectivek lighting radiantl lighting latentm equipment (conv+rad)n equipment convectiveo equipment radiantp equipment latentq controlled fractionr controlled (conv+rad)0 Page part: 1 of 2< index select? help- exit this menu

153

Figure 10.8 Casual gain options.Currently it is possible to apply controlto lighting casual gains by dening alighting control regime, the details ofwhich are held in a casual gain controlle. The control fraction is supposedto match the output of the lighting con-trol regime.

10.1.4 Zone energy balancesESP-r provides a powerful analysiscapability via zone air node energy bal-ance reporting as well as surfaceenergy balance reporting. If save lev el4 is selected, for each time-step of theperiod for which a simulation is under-taken the individual ux paths whichmake up the air node energy balanceare recorded. A typical report is shownin Figure 10.9.Notice the TOTAL line which reportsthe sum of all gains and the sum of alllosses and these should balance eachother closely (to a Whr) if the model iscorrect.

Zone energy balance (kWhrs) for manager_b

Gain LossInfiltration air load 0.000 -10.600Ventilation air load 0.000 0.000Uncontr‘d casual Occupt 2.430 0.000Uncontr‘d casual Lights 0.000 0.000Uncontr‘d casual Equipt 0.000 0.000Thermal bridge (linear) 0.000 0.000Storage at air point 0.616 -0.627Opaque surf convec: ext 0.106 -1.406Opaque surf convec: ptn 4.285 -8.522Transp surf convec: ext 0.001 -10.344Transp surf convec: ptn 1.132 -0.471Convec portion of plant 23.411 -0.011Totals 31.981 -31.981

Figure 10.9: Zone energy balance reportAn energy balance (from the point ofview of the zone air node) of all of theux entering & leaving the air node

should balance at each time-step of thesim- ulation. The report is an integra-tion of each of the above types of uxover the period of the assessment.A ux is positive if it adds heat to theair node of the zone and is negative if itremoves heat from the air node of thezone. For example, if exterior surfaceswhich are opaque are always colderthan the air temperature then the reportwill include losses for interior surfaces.The details of the ux paths are:• The inltration air load is the kWhr

gain or loss implied by themovement of air from the outside airand the zone. An integrated reportwill often include both gains andlosses. Note that air which leavesthe room and arrives at the outside isnot counted in the zone energy bal-ance. No energy balance is reportedfor the outside environment.

• The ventilation air load is the kWhrgain or loss implied by themovement of air from other zones ofthe model into the room. Air leavingthe room to another zone is reportedin the energy balance of the otherzone.

• Convective gains from occupants,lights and small power devices areseparately reported in the zoneenergy balance report. The radiantcomponent is found in the surfaceenergy balance report.

• Linear thermal bridges dened in thezone are part of the zone energy bal-ance. Although users are able todene a number of linear thermalbridges the aggregate gains or losses(in kWhr) are reported.

154

• Because the starting and ending tem-perature of the air over the period ofthe assessment may be different theenergy balance includes a storageterm for the air point.

• Convection at the inside face of sur-faces of the zone can be signicantux paths and are reported in fourseparate lines - convection at opaquesurfaces which have an exteriorboundary condition, opaque surfacewhich have any OTHER boundarycondition (ground, similar, partition,constant, basesimp), transparent sur-face which have an ambient bound-ary condition and transparent sur-faces which have any other boundarycondition.

Experts considering how to improvethe performance of a design will oftenlook at the zone energy balance forclues. For example to reduce heatingin cold weather they would check tosee what were the biggest losses andthey would focus on the biggest gainsin hot weather.In the above report the losses frominltration and via convection at trans-parent surfaces facing the outside arealmost the same. Is it less expensive tomake the facade more air tight or to putin better quality windows? The energybalance makes very clear thatimprovements to the opaque portionsof the facade will have very littleimpact on the heating demands.

10.1.5 Surface energy balancesA surface energy balance (see Figure10.10) reports ux gains & losses atthe inside face of the surface. For sur-faces which have an exterior boundary

condition, the ‘other-side‘ face energybalance is also reported.An energy balance from the point ofview of a surface of the ux enteringand leaving at each face should balanceat each time-step of the simulation.The report is an integration of each ofthe above types of ux over the periodof the assessment.A ux is positive if it adds heat to sur-face and is negative if it removes heatfrom the surface. For example, if exte-rior surfaces which are opaque arealways colder than the air temp the thesurface energy balance report will indi-cate gains at the inside face.The surface balance includes:• conduction (heat moving through the

construction) at a point just belowthe surface layer (halfway betweenthe surface layer and the next node),

• convection (heat transfer to the air)at the face,

• long-wav e radiation exchange withother surfaces in the room,

• long-wav e radiation from the ’other-side’ face of the surface to to otherbuildings/ the ground/ the sky (if thesurface is facing the outside),

• radiant portion of casual gains fromoccupants/ lighting/ small powerloads,

• heat stored in the construction (at thesame radiant portion of any environ-mental systems associated with zone

There is a TOTAL line which reportsthe sum of all gains and the sum of alllosses and these should balance eachother closely if the model is correct.

155

Causal energy breakdown (Whrs) for part_glaz (10) in manager_a ( 1)Surface is trnsp., area= 4.48mˆ2 & connects to surface 9 in zone 3

Facing manager_aGain Loss

Conductive flux 4985.42 -59.43Convective flux 470.62 -1132.32Long-wave rad int 46.10 -4502.90LW rad ext >bldg -- --LW rad ext >sky -- --LW rad ext >grnd -- --Shortwave rad. 59.00 0.00Occupt casual gn 141.12 0.00Lights casual gn 0.00 0.00Equipt casual gn 0.00 0.00

Controlled casual 0.00 0.00Heat stored 145.79 -153.39Plant 0.00 0.00Totals 5848.05 -5848.04

For surfaces facing the outside the energy balance is reported as follows:Period: Mon-09-Jan@00h15 to Sun-15-Jan@23h45(1967) : sim@30m, output@30m

Causal energy breakdown (Whrs) for spandrel ( 7) in manager_a ( 1)

Surface is opaque MLC, area= 2.70mˆ2 & connects to the outside

Facing manager_a Facing outsideGain Loss Gain Loss

Conductive flux 0.27 -2853.92 3198.10 -354.00Convective flux 1054.75 -80.06 2033.87 -3531.10Long-wave rad int 1395.28 -209.51 -- --LW rad ext >bldg -- -- 342.02 -87.26LW rad ext >sky -- -- 0.00 -7315.40LW rad ext >grnd -- -- 60.73 -1209.33Shortwave rad. 612.81 0.00 6872.32 0.00Occupt casual gn 84.03 0.00 -- --Lights casual gn 0.00 0.00 -- --Equipt casual gn 0.00 0.00 -- --Controlled casual 0.00 0.00 -- --Heat stored 87.40 -90.71 194.55 -203.53Plant 0.00 0.00 0.00 0.00Totals 3234.53 -3234.20 12701.58 -12700.62

Figure 10.10: Surface energy balance reports

And experts would also check surfaceenergy balances to determine whatchange might be appropriate. In theabove case the primary loss in thespandrel is conductive so there is roomfor improvements in insulation levels.As expected the biggest loss for theinside partition glazing is via conduc-tion (the convective exchanges are

constrained by the low air velocity inthe room).

10.1.6 Hours above and belowDuring performance evaluation ses-sions it is common to have questions inthe form "how often is it warmer thanX" or "how often is solar radiation onthat surface more than Y Watts/m2". Toanswer such questions quickly for any

156

of the standard performance metricsthe Enquire about menus have anoption for hours above and hoursbelow. The choices are shown in Fig-ure 10.11.

Hrs above query point:2 Result set3 Display period4 Select zones------------------

a Climateb Temperaturesc Comfort metricsd Solar processes------------------

f Zone fluxg Surface fluxh Heat/cool/humidifyi Zone RHj Casual gainsk Electrical demand------------------

m Renewables/adv. comp.n Network air/wtr flowo CFD metricsp Measured:temporal------------------

> Display to >> screen& Data: as values+ Filter >> none* Time >> 10h30ˆ Delim >> normal? Help- Exit

Figure 10.11: Hours above options

10.1.7 Energy deliveredSome performance questions relate tocapacity and these are typically cov-ered in the summary statistics reports.If the performance question is howoften was heating or cooling requiredand how many kWhr were deliveredduring the assessment period then thereare other choices such as the Energydelivered reports (Figure 10.12) whichprovide this information.There are several items of interest inthe energy delivered report. For eachzone the sensible values for reportedand the total for the included zones is

written at the end of the report. Thehours required may provide evidenceof systems being used at low capacityfor many hours.Another report which includes theenergy delivered is the monthly gainsand losses report (Figure 10.13). Manyusers mistake this as a monthly energybalance report bit it only includes asubset of the information included inthe zone energy balance report.

157

The energy delivered menu offers the following report:Lib: cellular_bcwin.res: Results for cellular_bcPeriod: Mon-09-Jan@00h15(1967) to Sun-15-Jan@23h45(1967) : sim@30m, output@30m

Zone total sensible and latent plant used (kWhrs)Zone Sensible heating Sensible cooling Humidification Dehumidification

id name Energy No. of Energy No. of Energy No. of Energy No. of(kWhrs) Hr rqd (kWhrs) Hr rqd (kWhrs) Hr rqd (kWhrs) Hr rqd

1 manager_a 23.41 117.5 -0.01 1.0 0.00 0.0 0.00 0.02 manager_b 23.41 117.5 -0.01 1.0 0.00 0.0 0.00 0.03 coridor 1.95 22.0 -0.04 3.5 0.00 0.0 0.00 0.0

All 48.78 257.0 -0.07 5.5 0.00 0.0 0.00 0.0

Figure 10.12: Energy delivered report

Lib: cellular_bcwin.res: Results for cellular_bcPeriod: Mon-09-Jan@00h15(1967) to Sun-15-Jan@23h45(1967) : sim@30m, output@30mMonthly selection of gains & losses (to nearest 100Wh).

Zone Period|Transp surf|Opaque surfs|Casual Gain|Infil|Vent| Plant |Solar radiation|in |exter|other|extern|other|conv radnt| | |Heat|Cool|absor |entering|

|facng|facng|facing|facng| | | | | |inside|zone |manager_a Jan -39. 4. -4. -4. 11. 11. -42. 0. 80. -5. 52. 59.

Feb -29. 6. 0. 28. 10. 10. -38. 0. 38. -16. 96. 109.Mar -22. 11. 8. 93. 11. 11. -44. 0. 13. -69. 210. 240.Apr -20. 9. 5. 69. 10. 10. -41. 0. 12. -45. 159. 181.May -9. 12. 11. 116. 11. 11. -38. 0. 1. -105. 228. 259.Jun 2. 11. 12. 118. 11. 11. -30. 0. 0. -124. 208. 237.Jul 12. 11. 15. 139. 11. 11. -20. 0. 0. -169. 225. 256.Aug 8. 12. 15. 140. 11. 11. -25. 0. 0. -161. 233. 266.Sep -11. 7. 5. 56. 11. 11. -25. 0. 1. -43. 117. 133.Oct -17. 9. 5. 64. 11. 11. -33. 0. 5. -43. 141. 161.Nov -30. 6. -1. 16. 11. 11. -39. 0. 50. -12. 66. 76.Dec -37. 5. -3. 2. 11. 11. -43. 0. 72. -6. 50. 57.

manager_b Jan -39. 4. -4. -4. 11. 11. -42. 0. 80. -5. 52. 59.Feb -29. 6. 0. 28. 10. 10. -38. 0. 38. -16. 96. 109.Mar -22. 11. 8. 93. 11. 11. -44. 0. 13. -69. 210. 240.Apr -20. 9. 5. 69. 10. 10. -41. 0. 12. -45. 159. 181.May -9. 12. 11. 116. 11. 11. -38. 0. 1. -105. 228. 259.Jun 2. 11. 12. 118. 11. 11. -30. 0. 0. -124. 208. 237.Jul 12. 11. 15. 139. 11. 11. -20. 0. 0. -169. 225. 256.Aug 8. 12. 15. 140. 11. 11. -25. 0. 0. -161. 233. 266.Sep -11. 7. 5. 56. 11. 11. -25. 0. 1. -43. 117. 133.Oct -17. 9. 5. 64. 11. 11. -33. 0. 5. -43. 141. 161.Nov -30. 6. -1. 16. 11. 11. -39. 0. 50. -12. 66. 76.Dec -37. 5. -3. 2. 11. 11. -43. 0. 72. -6. 50. 57.

coridor Jan 0. -12. 0. -25. 34. 34. 0. 0. 5. -2. 7. 0.Feb 0. -9. 0. -15. 31. 31. 0. 0. 1. -7. 13. 0.Mar 0. -2. 0. 9. 34. 34. 0. 0. 0. -41. 29. 0.Apr 0. -5. 0. -1. 33. 33. 0. 0. 0. -27. 22. 0.May 0. 4. 0. 27. 34. 34. 0. 0. 0. -66. 32. 0.Jun 0. 7. 0. 35. 33. 33. 0. 0. 0. -75. 29. 0.Jul 0. 11. 0. 51. 34. 34. 0. 0. 0. -96. 32. 0.Aug 0. 9. 0. 44. 34. 34. 0. 0. 0. -88. 33. 0.Sep 0. -2. 0. 6. 33. 33. 0. 0. 0. -38. 16. 0.Oct 0. -3. 0. 4. 34. 34. 0. 0. 0. -35. 20. 0.Nov 0. -11. 0. -20. 33. 33. 0. 0. 2. -4. 9. 0.Dec 0. -12. 0. -24. 34. 34. 0. 0. 3. -2. 7. 0.

All zones Jan -78. -4. -8. -34. 55. 55. -85. 0. 164. -11. 111. 118.

158

Feb -57. 4. 1. 40. 50. 50. -76. 0. 77. -39. 205. 218.Mar -44. 20. 15. 195. 56. 56. -89. 0. 25. -179. 450. 480.Apr -40. 14. 11. 137. 53. 53. -81. 0. 25. -118. 340. 361.May -17. 27. 22. 260. 56. 56. -76. 0. 3. -275. 487. 518.Jun 4. 28. 25. 271. 54. 54. -59. 0. 0. -323. 446. 473.Jul 25. 34. 30. 330. 55. 55. -40. 0. 0. -433. 481. 512.Aug 16. 34. 29. 325. 56. 56. -50. 0. 0. -410. 498. 531.Sep -21. 13. 9. 119. 54. 54. -51. 0. 2. -125. 250. 266.Oct -33. 14. 10. 132. 55. 55. -66. 0. 9. -120. 302. 322.Nov -60. 1. -2. 12. 54. 54. -78. 0. 101. -28. 142. 151.Dec -74. -3. -6. -20. 55. 55. -85. 0. 148. -15. 107. 114.

Annual -381. 182. 135. 1766. 656. 656. -836. 0. 554. -2077. 3820. 4066.

Figure 10.13: Monthly gains and losses report

The monthly gains and losses reportincludes the following:• convective surface exchanges for

transparent surface which face theoutside or something not-the-outside

• convective surface exchanges foropaque surfaces which face the out-side or something not-the-outside

• sum of all casual sensible convectivegains

• sum of all casual sensible radiantgains

• aggregate gains or losses associatedwith inltration (air from the outsideeither natural or forced)

• aggregate gains or losses associatedwith ventilation (air exchanges withother thermal zones either natural orforced)

• heat delivered to the zone• cooling extracted from the zone• solar radiation absorbed at surfaces

in the zone• solar radiation entering the zone

from the outside

10.1.8 Condensation reportsIf we know the air temperature and thehumidity as well as the surface temper-ature it is possible to report how oftencondensation would form on surfacesin a room. The report does not saywhether the condensation is a lightmisting or is severe enough to causewater droplets to form, simply thatconditions exist for some degree ofcondensation. There are several optionsthat can enhance the report. Firstly theactual humidity in the room can beused. For tests of sensitivity the usercan also nominate a specic humidityand base the report on that.The condensation report takes twoforms - a summary that includes thenumber of hours of condensation foreach of the surfaces and a detailedtime-step-by-time-step listing of occur-rences for each surface in the zone.These are shown in Figure 10.14.Surface condensation report (summary form):Summary condensation report for: coridorSurface occurrences hoursright 170 85.00wall 167 83.50left 170 85.00ceiling 169 84.50floor 168 84.00door 325 162.50ptn_corid 318 159.00part_frame 273 136.50part_glaz 324 162.00

159

part_frameb 278 139.00door_b 325 162.50ptn_coridb 318 159.00part_glazb 324 162.00filler 170 85.00Total occurrences & hours in coridor 327 163.50

If a time-step condensation listing is requested:. . .

13h15 X X X X X X X X X X X X X X13h45 X X X X X X X X X X X X X X14h15 X X X X X X X X X X X X X X14h45 X X X X X X X X X X X X X X15h15 X X X X X X X X X X X X X X15h45 X X X X X X X X X X X X X X16h15 X X X X X X X X X X X X X X16h45 X X X X X X X X X X X X X X17h15 X X X X X X X X X X X X X X17h45 X X X X X X X X X X X X X X18h15 X X X X X X X X X X X X X X18h45 X X X X X X X X X X X X X X19h15 X X X X X X X X X X X X X X19h45 X X X X X X X X X X X X X X20h15 X X X X X X X X X X X X X X20h45 . . . . . X X . X . X X X .21h15 . . . . . X X . X . X X X .21h45 . . . . . X X X X X X X X .22h15 . . . . . X X . X X X X X .22h45 . . . . . X X X X X X X X .23h15 . . . . . X X X X X X X X .23h45 . . . . . X X X X X X X X .

Surface occurrences hoursright 170 85.00wall 167 83.50left 170 85.00ceiling 169 84.50floor 168 84.00door 325 162.50ptn_corid 318 159.00part_frame 273 136.50part_glaz 324 162.00part_frameb 278 139.00door_b 325 162.50ptn_coridb 318 159.00part_glazb 324 162.00filler 170 85.00Total occurances & hours in coridor 327 163.50

Figure 10.14 Summary and detailedcondensation reports.

Condensation within a construction isalso a topic of concern for some assess-ments. If save lev el 3 is used (nodaltemperatures are recorded) then it ispossible to plot temperature prolesover time as well as identify the pointwhere interstitial condensation wouldoccurr (see Figure 10.15).

<< gure to be added >>

Figure 10.15 Interstitial condensation reports.

10.2 Time-step reportingWhere graphs are good at indicatingpatterns they do not provide sufcientresolution to determine the specic val-ues at a specic time.For each item that is subject to a statis-tical report or might be included in agraph there is another option to viewthe item or a user dened collection ofitems in columns time-step-by-time-step. The interface options for time-step reporting are shown in Figure10.16. The performance metricsoptions should look familiar!

Tabular Output:2 select result set3 define period4 select zones___________________

g performance metricsh special material datai network air/wtr flow___________________formatting...

> output >> screen* time >> 10h30* labels >> multilineˆ delim >> normal? help- exit

Performance metrics:2 Result set3 Display period4 Select zones------------------

a Climateb Temperaturesc Comfort metricsd Solar processes------------------

f Zone fluxg Surface fluxh Heat/cool/humidifyi Zone RHj Casual gainsk Electrical demand------------------

m Renewables/adv. comp.n Network air/wtr flow

160

o CFD metricsp Measured:temporal------------------

> Display to >> screen& Data: as values+ Filter >> none* Time >> 10h30ˆ Delim >> normal! List data? Help- Exit

Figure 10.16 Time-step options.

Time-step listings are also a usefulfacility for exporting data into commaseparated or tab separated columns in ale for processing in a third partyapplication. At the bottom of the menuare options to redirect the output fromthe screen to a user nominated le.There is also a toggle for time to bewritten in an 10h30 form or as 0.4375fraction of the day. The options forlabels on one line (e.g. for inclusion ina spreadsheet) as well as for setting thedelimiter from a space to a tab or acomma allow reports to be more easilyaccepted by 3rd party tools.The listing in Figure 10.17 has the timein the rst column, the outside ambienttemperature in the 2nd column andeach zone resultant temperatures in theremaining columns.# Time-step performance metrics.# Lib: cellular_bc_ann.res:

Results for cellular_bc# Period: Sun-15-Jan@00h15 to

Mon-16-Jan@11h45(1967): sim@30m, output@30m#Time AmbientdbTmp(degC) manager_aResT(degC)

manager_bResT(degC) coridorResT(degC)15.0104,3.15,15.27,15.26,19.8515.0313,2.85,15.21,15.21,19.6915.0521,2.70,15.05,15.05,19.5415.0729,2.70,14.82,14.82,19.4015.0938,2.70,14.66,14.66,19.2715.1146,2.70,14.52,14.52,19.1415.1354,2.58,14.35,14.35,19.0115.1563,2.33,14.20,14.20,18.8815.1771,2.20,14.05,14.05,18.75

15.1979,2.20,13.90,13.90,18.6315.2188,2.20,13.76,13.76,18.5015.2396,2.20,13.64,13.64,18.3815.2604,2.20,13.51,13.51,18.2615.2813,2.20,13.40,13.40,18.1415.3021,2.20,13.29,13.29,18.0215.3229,2.20,13.18,13.18,17.9015.3438,2.20,13.09,13.09,18.1515.3646,2.20,13.01,13.01,18.6815.3854,2.20,12.97,12.97,18.8515.4063,2.20,12.98,12.98,18.9115.4271,2.05,13.03,13.03,19.03. . .

Figure 10.17 Time-step reports.The time-step listing facility can, ofcourse be scripted as can other text-based reporting if you invoke theresults analysis application in textmode at the command line (see section17.1).

10.3 Graphic reportingESP-r offers a number of forms ofgraphic display for data. The high leveloptions are shown in Figure 10.18.

Graph facilities:2 Select result set3 Define output period4 Select zones-------------------

a Time:var graphb Intra-fabricc 3D profiled Frequency histograme Var:Var graphf Network air/wtr flow-------------------

? Help- Exit

Figure 10.18 Graphic report options.

161

Figure 10.19 Example multi-axis graph.

Figure 10.20 Example focused multi-axis graph.

10.3.1 Variables against timeThe Time:var graph includes essen-tially the same list as is found in thetimestep listings and the enquire aboutfacility. It supports ad-hoc creation of

graphs with multiple axis as seen inFigure 10.19. Here twelve days in Jan-uary are graphed with the zone drybulb temperatures of three zones shownalong with the ambient outside temper-ature and the direct solar radiation(from the climate data).

162

It is clear in the graph that on weekdaynights the temperature in the roomsfalls to at 15 degree night set-back tem-perature and at the weekends there is afrost protection setting at 10 degrees.On the initial days of the simulation theroom temperature rises to the coolingset-point and to determine if this wasdue to solar radiation entering therooms the solar radiation plot wasadded to the graph.For days where there is little directsolar radiation the un-conditioned cor-ridor room is cooler when it is cooleroutside and warmer when it is warmeroutside.In Figure 10.20 the user has focusedthe graph on the rst three days of theassessment and restricted the graph tothe manager_a zone and has added intothe graph the inside face surface tem-peratures of all the surfaces in man-ager_a. Most of the surface tempera-tures track within a 3-4 degree range,except for the glazing which getshottest at mid-day and coldestovernight.And the graph is somewhat confusingin that the names of the lines for thesurface temperatures overlap and it isnot all that clear which one is the roomdry bulb temperature. This might be agood reason for switching to the time-step listing report so that the specictemperatures can be seen or even to askfor statistics on surface temperatures.

10.3.2 Frequency binEarlier the discussion pointed out thatthe time of occurrence of extreme val-ues can be important in assessments.

Some users are also interested in thefrequency distribution of values inrooms. For example, regulations mightprescribe the number of hours in thesummer that temperatures are allowedto go above 25 degrees. A frequencybin is a quick way to determine the rar-ity of extremes.In Figure 10.21 is the annual distribu-tion of dry bulb temperatures in themanager_a room. Because the data wasnot ltered by occupancy (e.g. foroccupied hours) there is a range of 10 -30 degrees with a bit over 20% of thetime near 24 (the cooling set-point),16% near 19 (the heating set-point) andabout 10% of the time near 15 degrees(the night setback).Often a frequency bin will demonstratea recognizable normal distribution andthe task becomes to choose points ofsignicance at the upper and lowerboundary of the range. For example, ifthere are 5% of delivered heating isabove 15kW with a peak at 19kW thensome users might explore the possibil-ity of designing for 15kW with anadaptive control scheme.

10.3.3 3D surface plotsAn alternative to a flat graph is a 3Dsurface plot where time is seen on theright axis, days are on the left axis andthe value is shown as a height. In Fig-ure 10.21 the convective casual gainsfor the room manager_a are shown in a3D plot. The dip at mid-day for lunchbreaks can be seen as can the weekendbreaks along the day axis. This is a par-ticularly good form for checking theimpact of lighting controls.

163

Figure 10.21 Example frequency bin.

Figure 10.21 Example 3D plot of casual gains over time.

164

Figure 10.21 Example variable vs variable graph.

10.3.4 Variable vs variable graphsThe correlation between two variablescan be expressed via statistics and it isalso possible to visualize the relation-ships between two variables if they areplotted with the rst variable on oneaxis and the second variable on theother axis. In Figure 10.22 there wouldseem to be a fair correlation betweenthe dry bulb temperature in the roomsand the resultant temperature in therooms. There are occasional deviationsnear 15 and 19 degrees as might beexpected because of the cycling of theheating in the rooms.

10.4 Methods for exploration of datasetsThe discussion thus far has reviewedthe types of information that can beaccessed in the results analysis moduleof ESP-r and shown sample of many ofthe possible reports. Different users

understand performance in differentways and have preferences for informa-tion presentation types and the choicesfor presentation reect this.Those who deliver exceptional valueinto the design process tend to haveexception pattern matching skills aswell as a solid grounding in the under-lying physics of buildings and systems.The ad-hoc nature of interactions in theresults analysis module gives suchusers scope for identifying the underly-ing issues. So in Figure 10.19 the userinitially plotted the room temperaturesand then added the ambient tempera-ture to conrm a sensitivity to the out-side. The need for cooling in Januarywas noticed and the question of ’whatcould make it warm’ lead to a guessthat solar radiation might be the coreissue and so this was added to thegraph. The next step was to look at thesurface temperatures in a typical roomto see what was getting warm. Andone might also follow this with a quick

165

review of the zone energy balances.Pattern matching is a skill that can beacquired. With practice and guidancefrom experienced users novices (andev en Architectural students) to begin torecognize patterns and follow these tolikely causal elements in their designs.It may take a number of iterations toaccomplish this but it is one of themost important of simulation skills.

166

Chapter 11

FLOW

11 Flow

This Chapter focuses on airow model-ling techniques in ESP-r:• overview of network air ow model-

ling;• the art of planning ow networks;• dening and calibrating ow net-

works;• control of ow networks;• project management.At the simplest level, air ow within anESP-r model can be imposed viaschedules of inltration and ventila-tion. For example a user could stipulate0.5 air changes of inltration for alldays and all hours or a schedule thatchanges at each hour for each day type.These schedules may be subjected tocontrol (e.g. increase inltration to 1.5air changes if zone temperature goesover 24° C). Scheduled ow is appro-priate for engineering approximations,initial design studies and basic opera-tional regimes.

11.1 Limitations of Scheduled FlowThe critical word above is imposed.Schedules impose a ow regime whichmay have no basis in the physics ofbuildings. This is particularly true inthe following cases:

• Where there is strong couplingbetween heat and air ow, e.g. stackand wind driven ow

• Where there are highly dynamicvariations in ventilation rate, e.g.natural ventilation

• Where control strategies are impor-tant, e.g. opening or closing win-dows based on temperature and/orwind speed.

If these are descriptive of your designthen consider ow networks as a wayto better represent the dynamics of owinteractions.

11.2 Fluid Flow NetworksFluid ow networks offer considerableexibility in describing a range ofdesigns and the potential to increasethe resolution of models to supportassessments which are dependent onthe movement of mass or ux or powerwithin a model.Rather than imposing ows, a networkdescribes possible ow paths (e.g.doors, cracks, fans, ducting, pipes,valves), points where boundary condi-tions apply (e.g. an opening to the out-side) and locations where measure-ments of ow performance are required(e.g. internal and boundary nodes).ESP-r’s ow network solver dynami-cally calculates the pressure-drivenows within zones and/or

168

environmental control systems that areassociated with the network. The owsat nodes are a function of nodal pres-sures and the connected components’characteristics. The mass balance ateach node is solved using a customizedNewton-Raphson approach. The solu-tion iterates until it converges and thepressure at each node and the massow through each connection aresaved.The solution takes into account thechange in driving forces as conditionswithin the building and boundary con-ditions evolve. Information exchangebetween the domain solvers ensuresthat changes in ow will inuence con-ditions in associated zones, controls,systems and CFD domains within amodel. For example, opening a win-dow on a cool day introduces cool airinto a zone, which depresses the tem-perature of the walls which then altersthe buoyancy forces driving the ow.Although the ow of air in real build-ing continually adapts to conditionsand self-balances, simulation re-evalu-ates conditions at xed intervals. Thusthere is the possibility that differencesin temperatures can build up during thesimulation time step which would notbe observed in real buildings. Thisresults in exaggerated air ows, oroscillating ows, especially for largeopenings between thermal zones. Thusthe choice of simulation time step is atopic worthy of discussion.Those who wish to know more aboutthe solution technique should look atpublications page on the ESRU website. For example, On the Conflation ofContaminant Behavior within Whole

Building Performance Simulation (ASamuel, 2006), Energy Simulation inBuilding Design (J A Clarke 2001),The Adaptive Coupling of Heat and Airflow Modelling Within DynamicWhole-Building Simulation (I Beau-soleil-Morrison 2000), On the thermalinteraction of building structure andheating and ventilating system (J L MHensen 1991) are books or PhD thesiswhich discuss some aspects of owsimulation.An ESP-r model may have one or morede-coupled ow networks - somedescribing building air ow and othersrepresenting ow in a hot water heatingsystem. In models which include sepa-rate buildings the ow network caninclude one or more of the buildings.The solver is efcient and thus, evenwith scores of nodes and components,there is only a slight increase in com-putational time. Assessing thousands oftime-steps of ow patterns in supportof natural ventilation risk assessmentsis one use of ow networks. Flow net-works are often used as pre-cursors toCFD studies.The exibility of ow networks bringsboth power and risk. The discussionthat follows presents methodologies tohelp you decide when networks arecalled for, planing tips for ow net-works and techniques for understand-ing the predicted patterns of owwithin your model.ESP-r differs from some other simula-tion tools in that it asks the user todene ow networks explicitly. Anexplicit description allows knowledge-able users to control the resolution ofthe network as well as the choice of

169

ow components and their details.This approach assumes that the userhas opinions about ow paths as wellas access to relevant information aboutthe ow components used in the net-work. As with the geometric resolutionof a model, creating ow networks isas much an art as it is a science.Scaling up skills and working practicesto cope with the level of complexityfound in realistic projects has tradition-ally been accomplished via mentors orworkshops. This has limited thedeployment of the facility.The Cookbook aims to de-mystify thetopic of ow networks as well as pro-viding hints about where the dragonstend to hide.

11.3 Building blocksThe building blocks we can use todene a mass ow network are ownodes, ow components and ow con-nections. The least complex networkthat the solver will work with includesa zone node and two boundary nodesconnected by two components (seeFigure 11.1).

component

zone_node boundary node

component

boundary node

Figure 11.1: The least complex network.

Flow NodesNodes in a ow network are measuringpoint for pressure, temperature andrate-of-ow. These bookkeeping enti-ties are of four types:

• internal unknown pressure;• internal known pressure (rarely

used);• boundary known pressure (rarely

used);• boundary with wind induced pres-

sure (air only).A ow node has one temperature justas the volume of air associated with athermal zone has one temperature. Typ-ically there will be a one-to-one map-ping between thermal zones and ownodes. Internal nodes can either taketheir temperature from a thermal zoneor they can be dened to track the tem-perature of a specic ow node. Letscall the former real nodes and the latterextra nodes.Wind induced boundary nodes repre-sent wind pressure at one point on thefacade of a building. It is a function ofthe wind velocity, direction, terrain,building height, surface orientation andposition within the facade. Typically, aow network would include a bound-ary node for each location where airmay ow into a building.Good practice places a boundary nodeat the height of each opening to theoutside. If you follow this pattern theprocess of locating ow componentsrepresenting the opening is simplied.

Pressure coefficientsThe jargon we use to express changesin pressure due to changes in winddirection is a pressure coefcient Cp.In ESP-r, Cp values for standard anglesof incidence (16 values to represent360°) for a specic location are held asa set.

170

ESP-r has a database of Cp coefcientsets for different types and orientationsof surfaces derived from the literature.Lets be clear about this, one of thegreatest points of uncertainty in owsimulation is in the derivation of pres-sure coefcient sets. Some groupsreduce this uncertainty by undertakingwind tunnel tests or creating virtualwind tunnel tests via the use of CFD.ESP-r offers a so-called Cpcalc func-tion to generate pressure coefcientsbut it is one of those places wheredragons live.

Wind Speed Reduction FactorsThe ratio of the climate wind velocity(usually at a standard height of 10m)and wind in the locality of the buildingis known as the wind speed windreduction factor such thatV = Vclim x RfRf is calculated from some assumedwind speed prole and accounts fordifferences between wind measurementheight and surrounding terrain (urban,rural, city centre) and building heightand surrounding terrain.Wind proles can be calculated usingthree different models: power-law,LBL, logarithmic.Caution is advised in the use of Rf val-ues as the proles they are derivedfrom are invalid within the urbancanopy. In such cases, it is advisableto use a small value for Rf in cool-ing/air quality studies and high valuesfor inltration heating studies to repre-sent worst case conditions.

11.3.1 Flow componentsFlow components (e.g. fans, pumps,ducts, cracks, valves, orices etc.)describe the ow characteristicsbetween ow nodes. Flow is usually anon-linear function of the pressure dif-ference across the component based onexperimental and analytical studiestaken from the literature.ESP-r has a set of in-built ow compo-nents including ducts, pipes, fans andpumps as well as cracks, orices anddoors. Generic xed volume or massow components as well as quadraticand power law resistance models arealso included. Details of the methodsused are included in the source code inthe folder src/esrumfs. Some com-monly used components (referencenumbers in brackets) are:• Power law volume ow (10) can be

used where ow is well described bya power law

• Self regulating vent (11) is a Euro-pean vent to embed in a windowframe which moderates ow across arange of pressures

• Power law mass ow (15 & 17) canbe used where ow follows a powerlaw.

• Quadratic law volume (20) and mass(25) can be use where ow follows aquadratic t.

• Constant volume ow (30) and massow (35) are abstract representationsof a fan (can be controlled toapproximate variable speeds).

• Common orice (40) can be used foropenings with a user dened dis-charge coefcient

171

• Specic air ow opening (110) has axed discharge coefcient and onlyrequires an area.

• Specic air ow crack (120) is use-ful for openings up to 12mm wide.

• Bi-directional ow component (130)is useful for doors and windowswhich are door shaped where tem-perature and pressure differences canresult in ow in two directions.

• Roof outlet/cowl (211) is based onmeasurements of typical ceramicunits found in Europe.

• Conduit with converging 3-leg (220)and diverging 3-leg (230). There arelots of parameters needed to describethis and dragons live here.

• Conduit with converging 4-leg (240)and diverging 4-leg (250). There arelots of parameters needed to describethis and dragons have been sightedhere.

• Compound component (500) pointsto two components e.g. an openingand a crack with parameters neededfor control actions.

11.3.2 Flow connectionsFlow connections link the nodes andthe components via a descriptive syn-tax that takes the form: boundary node’south’ is linked to internal node’ofce’ via component ’door’.A connection also denes the spacialrelationship between the node and thecomponent e.g. that a oor grill is 1.5mbelow the node. If nodes and connec-tions are at different heights, then thepressure difference across the connec-tion will also include stack effects.

Good practice places a boundary nodeat the height of each opening to theoutside. If you follow this pattern thedelta height is zero for componentsfrom the point of view of the boundarynode.In the upper part of Figure 11.2 is acrack under a door that connects tozones (where the zone nodes are at dif-ferent heights). In the lower part ofFigure 11.2 is a representation of asash window (where there is one owcomponent representing the upperopening and another representing thelower opening. The sash window isassociated with two separate boundarynodes.

sash window

zone_nodezone_node

crack under door

door

!1.5m!1.2m

boundary node

boundary nodezone_node

Figure 11.2: A crack under a door anda sash window.

Some people nd the syntax used todescribe the relationship betweennodes and components a bit of a chal-lenge. Here is one technique that worksfor quite a few users.

172

Imagine yourself at the position ofthe ow node (e.g. in the centre ofthe zones air volume) and lookingat the component. If you are look-ing horizontally then the heightdifference is zero. If you are look-ing up then the height differenceis positive. If you are lookingdown (e.g. to the crack under thedoor) then the height difference isnegative.

For example, if a zone node is at 1.5mabove the ground and the lower win-dow opening is at 1m above the groundand the upper window opening is at2.1m above the ground. Look at thelower window opening from the pointof view of the zone node it is 0.5mbelow the zone node and at the sameheight as the lower boundary node. Theupper window opening is 0.6m abovethe zone node and at the same height asthe upper boundary node.

Path to boundaryThe other rule about creating networksis that every internal node must some-how hav e a path to a boundary node.The solver treats air as incompressible(for all practical purposes) and thesolution is of the mass transfer withinthe network. When the temperaturechanges the volume must change and ifthe pressure has no point of relief thenthe solver breaks.The design of the network must takethis rule into account, especially if con-trol applied to components would havethe effect of totally isolating a node.The risk of breaking the rule increaseswith network complexity so the Cook-book emphasises working procedures

which are robust enough to scale withthe complexity of the models we cre-ate.

Parallel and sequential connectionsFigure 11.3 is a portion of a networkwhich uses a common orice to repre-sent the window when it is opened aswell as a parallel path with a crack. Ifthe window is controlled and open thenthe crack has little or no impact on pre-dictions. When the window is closedthen the crack becomes the connectionto the boundary node.Recent versions of ESP-r support theconcept of a compound componentwhich is made up of, for example, anopening and a crack. The use of com-pound components can simplify ownetworks by reducing the need to par-allel connections.

compound window & crack

zone_node

window crack

window boundary node

boundary node

zone_node

Figure 11.3: A crack & window and acompound component.

173

Up to this point the networks have beenlinked via a single component or com-ponents in parallel. Suppose we wantedto open a window if the temperature atthe zone node was above 22°C ANDthe outside temperature was below19°C. How might we implement theabove AND logic? One technique is touse components in series.

If zone_node is linked to bound-ary_node by component windowand we wish to insert a secondcomponent control it would benecessary to create extra_node,assign it to track the temperatureof zone_node. The new ow com-ponent control should be of a typethat would present little resistanceto ow when open. The existingconnection would be re-denedand the second connection in thesequence would be created as inFigure 11.4. The window compo-nent would take one control logicand the control component wouldtake the second control. The origi-nal window crack connectionwould remain.

extra nodezone_node

window crack

windowboundary node

control

Figure 11.4: Use of additionalnodes and components for control

When control is imposed, considera-tion should be given to adjusting thesimulation time step to take intoaccount the response of the sensor and

ow actuator. If we observe ow ratesoscillating it is usually in indicator thatwe need to shorten the simulation timestep.

11.4 Steps in creating a networkThe ESP-r Cookbook recommends amethodical approach to the creation ofnetwork. It is possible to design net-works of dozens of nodes and compo-nents which work correctly the rsttime. Plan carefully and then imple-ment the plan! Successful practitionersuse the following set of rules:Rule one

sketch out the network either as a 2Dlayout or as a 3D overly of the wire-frame view of the model

Rule twogive informative names to the nodesand components on the sketch anduse these same names when usingthe interface

Rule threeidentify portions of the networkwhere control will be applied

Rule fourif there are likely to be design vari-ants, use overlays on the sketch tolay out alternatives and ensure thatthe sketch provides a summary ofthe intent of the overlay

Rule veif there is room on the sketch includecritical attributes of the components,if there is not ensure you separatelyrecord component attributes beforeyou start on the interface

A good sketch is worth hours ofdebugging - trust us on this!

174

ESP-r does not graphically representthe network (yet). The sketch makes iteasier to interpret the story told by thenames of the nodes and components.When we plan a network we shouldaccount for how ow is induced orrestricted, where control might beimposed as well as where we expectthere to be differences in air tempera-ture within a building.For example, if you believe that aperimeter section of an ofce will oftenbe at a different temperature considercreating a separate zone for the perime-ter. Some practitioners include addi-tional vertices in the model and subdi-vide oor and ceiling surfaces in theirinitial model so that it is easy to subdi-vide a zone at a later stage.Experience indicates that last minutesubdivision of zones can take longerthan one might expect and require timefor testing that has not been budgetedfor.The design of the ow network shouldtake into account what-we-want-to-measure. Typically there is a one-to-one matching of internal nodes andthermal zones. However, if there weremany openings in a room on the eastand to the south facades and we wereinterested in the aggregate ow at eachfacade then we might plan a networkwhich had extra internal nodes asshown in Figure 11.5. In the sketch thewest node and east node nodes taketheir temperatures from zone_node.

boundary node

zone_node

boundary node

boundary node

boundary nodeeast_node

west node

boundary node

boundary node

Figure 11.5: network with extra nodesLinking the nodes and components is acritical step which benets from amethodical approach as well as consis-tent pattern for typical relationships.

A good sketch is still worth hoursof debugging!

In deciding which components to useour initial task is to review the featuresof the available components and con-trol options which can be applied tothem as well as their data requirements.There is also the option of browsingexisting models which include ownetworks and running assessments andreviewing the predictions. A great wayto understand how ow works is totake these exemplar models and sys-tematically adapt the network and/orcontrol description and observe thechanged performance.

175

Window

Node

Crack_under_doof

Crack_at_wingow

examination reception

Figure 11.6: simple network for doctor’s ofce

11.5 A simple networkTo illustrate the process lets create asimple network for the doctors ofcethat you worked on earlier.

Where could air flowAir can ow under the door betweenthe reception and the examinationrooms. When we created the initialzone a decision was made to excludethe door as being unimportant in termsof the overall heat ow in that portionof the building. An entrance to thereception would be place where airwould ow. Does this require that wego back into the geometry and add adoor? Not necessarily.Consider if there was a 5mm crack inthe wall. The handful of missing

mortar would not change the thermo-physical state of the wall, but the airmoving through the crack might benoticed. In ESP-r the description of thezone and the ow network can differ aslong as we remember the intent of thedifference.Air can also ow around the frames ofthe windows. It is difcult to know ifthere are differences in the leakagepaths of the three horizontal windows.For this project lets assume that theyhave the same leakage characteristics.There are three locations on the facadewith these windows - but each can berepresented by the same crack compo-nent. The north window is a differentsize and lets assume that it has a differ-ent leakage characteristic so that needsto be a different component.

176

The next issue is how long is the typi-cal crack and where is it. If we wishedto be pedantic there are cracks at thetop and bottom and left and right ofeach window. For this exercise letsassume the crack is along the centreline of the window and is the samelength as the width of the window.

What kind of window opening?If someone was to open a window thenthere might be ow IF there was some-place for the air to go. A mass ow net-work has limitations when attemptingto represent single sided ventilation. Insome cases it is possible to use a bi-directional component to represent awindow (there are arguments in thecommunity about the validity of suchan approach). If two windows areopened the driving forces are betterrepresented within a mass ow net-work.Depending on the size and physicaldetails of the opening there are severalow components which might be use-ful. And before we look at the compo-nent details it is worth consideringwhether the windows in this doctorsofce will be operated by the staff andwhether they will do this with a pre-dictable logic (e.g. will they open thewindow if it reaches 22°C and willthey open the window fully)?For this project lets start with theassumption that we will eventuallywant to test out a window openingregime that involves opening the win-dows twenty ve percent. We caninclude the relevant components in ourplanning so that they will be easy toinclude at a later date. How the

window operates will determine thetypes of ow components we shoulduse as well as the connections weestablish within the ow network.ESP-r offers a pre-dened windowcomponent which only requires theopening area, it also includes a com-mon orice which requires an area anda discharge factor. If one had the datathe opening could be a polynomial or apower law. A sash window is twoopenings and some users also representa horizontally pivoting window as twoseparate openings. Some windows havean width to height which is similar to adoor and in that case some users maydecide to use a bi-directional ow com-ponent (more on that later). For now,lets use the air ow opening compo-nent and assume that the component iscentered within the window surface.

What kind of extract fan?Air can be induced to ow by anextract fan. And here our choices beginto expand because there are bothabstract and detailed components forthe extractor. And since there are timeswhen the extractor is not required wewill need to control it.Early in the design process our tacticshould be to conrm whether forcedventilation in the doctors ofce willhelp and the magnitude of the owrequired and perhaps the turn-on setpoint. This is most quickly accom-plished via an abstract volume owrate component and a simple controllaw. Once we conrm the general char-acteristics and response of the buildingwe can consider whether a specic fancurve should be applied to the model.

177

What kind of room?What else might require our attention?Looking back at the dimensions of thedoctors ofce the sloped ceiling of theexamination room increases the vol-ume of the space and raises the centreof the air volume in comparison to theexamination room. The earlier decisionto represent the examination room as asingle volume of air which is well-mixed (i.e. at a single temperature)does introduce an element of riskbecause there will be times when theair near the peak of the ceiling is at adifferent temperature to the occupiedportion of the space.Given the initial design brief the singlevolume decision was appropriate. If thequestion becomes occupant comfortand ne-tuning of window opening orextract fan use then a subdivision of thephysical space into multiple thermalzones could be done. For the currentproject lets not alter the zones.When we sketch out the network wewill need names for the nodes and thecomponents (Figure 11.6). At somepoint we must record the attributes ofthe components so that this informationwill be available when we create thenetwork and we will also want to passour notes to the person checking themodel.This is also a good time to get out acalculator and focus the project man-ager on the geometry of the zones sothat we can record the height differ-ences between the nodes and compo-nents. The table below provides severalof the relevant dimensions:

Component names and locations.

node name - type heightreception - internal 1.5mexamination - internal 2.25msouth - boundary 2.375mnorth - boundary 2.375mexam_north - boundary 3.75mexam_extract - boundary 3.0meast - boundary 0.1m

component name - type datalong_win - air ow opening 1.0mˆ2long_cr - crack 5mm x 3.0mdoor_cr - crack 10mm x 0.8mupper_win - orice 1.5mˆ2 0.5 coefupper_cr - crack 5mm x 3.0mextract - volume ow ˜1 air change

node - to - node componentsouth to reception via long_winsouth to reception via long_crnorth to reception via long_winnorth to reception via long_creast to reception via door_crexam_north to examination via upper_winexam_north to examination via upper_crreception to examination via door_crexamination to exam_extract via extract

height differences:long_win is 0.875m above receptionlong_cr is 0.875m above receptionupper_win is 1.5m above examinationupper_cr is 1.5m above examinationdoor_cr is 1.5m below receptiondoor_cr is 2.25m below examination

Which connection comes first?In addition to what we include in thesketch we also need to consider theorder that we link the nodes and com-ponents. The connection associatedwith the extract fan should being at a

178

zone node and end at a boundary nodeso that the ow is outwards. For otherconnections the order is not numeri-cally important.It does help to have a consistent policywith openings to the outside because aow along a connection is reported as apositive number if it is in the samedirection as the connection denitionand negative if it is owing from theend point to the start point. If you con-ceptually consider air entering thebuilding as positive ow then youwould choose to dene connectionswith the outside as beginning at theboundary node and ending at the zonenode.Our task is to record our decisions andattributes on the ow network sketchand then to use the interface to rstdene the nodes and then the compo-nents and then to link the networktogether.

11.6 To the keyboardHaving planned and recorded the infor-mation associated with our network wecan now use the interface to increasethe resolution of the model. In theProject manager look for Model man-agement -> browse/edit -> net-work flow and choose flow net-work (menu) and conrm the sug-gested le name and then choose makenew file and then specify that thenetwork is all air. And you willbe presented with the initial menu asshown in Figure 11.7. At the start thereare no nodes or components or connec-tions and no nodes have been linked tothe zones. The descriptive sequence isto dene the nodes rst and then dene

the components and lastly the connec-tions between the nodes.

Figure 11.7: interface at start of process

Initial nodesSelect the nodes option and allow anauto-generation of the nodes for thecurrent zones. The initial list includesthe two items shown in Figure 11.8.The auto-generate assumes that eachthermal zone will have a node and thezone name is given to the node and thecentre of the zone becomes the heightof the ow node.

179

Figure 11.8: auto-generated nodes

Figure 11.9: adding boundary nodes

Figure 11.10: the completed components

180

Boundary nodesThe next step is to dene the boundarynodes. Do these based on the informa-tion in the table above. For eachboundary node you will be asked tonominate a surface where the openingis found. This sets the orientation ofthe boundary node so that wind direc-tions can be resolved. The centre of thesurface becomes the height of the node.When asked to conrm the heightcheck the notes (aren’t you glad youmade a note of this). You will also beasked about which pressure coefcientset to use and for this exercise select1:1 sheltered wall for each con-nection. The result should look some-thing like Figure 11.9. This is a goodtime to save the network!

ComponentsThe next task is to create the compo-nents. Do this based on the informationin your notes. Each componentrequires a name and, depending on thetype of component, there will be one ormore attributes to dene. The orderyou create the components is notimportant. When you dene theextract fan as a constant volume owrate component note the various waysyou can dene the ow rate. The airchanges per hour is particularly usefulat an early stage so use that (which isequivalent to 0.01667mˆ3/s based onthe volume of the examination room).When the components are completedthey should look similar to that shownin Figure 11.10. Save your networkagain. You may also want to use the

browse network option to review thedata that you have provided.

Connecting nodes and componentsThe next step is to link the nodes andcomponents together to form the net-work. Each connection has an initialnode and component and a secondnode. You are asked to specify theheight difference to the componentfrom the point of view of each node.The order you give is not criticalexcept for the extract fan. Flow in thedirection of the initial to the secondnode is reported as a positive number.It does help to have a consistent patternwhen dening connections. One com-mon pattern for connections whichinvolve boundary nodes - use theboundary node as the initial node sothat ow into the room is reported as apositive number. Some users dene allof the links with boundary nodes rstand then they dene links betweeninternal nodes.Another pattern is in the denition ofheight differences. The boundary nodeswere dened at the height of the open-ing so that the delta height from theposition of the boundary node isalways zero. And if a connection uses acomponent where buoyancy will not bean issue (like the constant volume owcomponent) give zero as the height dif-ference.

181

Figure 11.11: the completed connections7 6 9 1.000 (nodes, components, connections, wind reduction)

Node Fld. Type Height Temperature Data_1 Data_2reception 1 0 1.5000 20.000 0.0000 120.00examination 1 0 2.2500 20.000 0.0000 60.001south 1 3 2.3750 0.0000 9.0000 180.00north 1 3 2.3750 0.0000 9.0000 0.0000exam_north 1 3 3.7500 0.0000 9.0000 0.0000exam_extract 1 3 3.5000 0.0000 9.0000 90.000east 1 3 0.10000 0.0000 9.0000 90.000Component Type C+ L+ Descriptionlong_win 110 2 0 Specific air flow opening m = rho.f(A,dP)1. 1.long_cr 120 3 0 Specific air flow crack m = rho.f(W,L,dP)1. 0.00499999989 3.door_cr 120 3 0 Specific air flow crack m = rho.f(W,L,dP)1. 0.00999999978 0.800000012upper_win 40 3 0 Common orifice flow component m = rho.f(Cd,A,rho,dP)1. 1.5 0.5upper_cr 120 3 0 Specific air flow crack m = rho.f(W,L,dP)1. 0.00499999989 3.extract 30 2 0 Constant vol. flow rate component m = rho.a1. 0.0166670009+Node dHght -Node dHght via Componentsouth 0.000 reception 0.875 long_winsouth 0.000 reception 0.875 long_crnorth 0.000 reception 0.875 long_winnorth 0.000 reception 0.875 long_creast 0.000 reception -1.500 door_crexam_north 0.000 examination 1.500 upper_winexam_north 0.000 examination 1.500 upper_crreception -1.500 examination -2.250 door_crexamination 0.000 exam_extract 0.000 extract

Figure 11.12: the ESP-r ow network le

Take your time to avoid having to re-dene connections. For this exercise

182

there are three sets of parallel connec-tions involving the windows and thecracks. The interface will ask for con-rmation when you dene the parallelconnection. The interface will ask youif you want to auto-generate the con-nections. For this exercise say no.

Hint: as you create the connec-tions, mark your sketch so thatyour progress is recorded. It iseasy to duplicate a connection, orev en worse, to miss out a connec-tion.

Checking your dataThe last step is to conrm the linkagesbetween the ow nodes and the thermalzones. Look for the link nodes andzones option in the interface. Whenyou have completed this it should looksimilar to that shown in Figure 11.11.Save the network again. After exitingthe network menu it is also a good ideato generate a new QA report. Whenlooking at the QA report pay particularattention to the Z values for the compo-nents. If the two Z values differ youmight have made a mistake about thedelta height from each of the nodes.The description of the network is writ-ten to an ESP-r le in the nets folder ofyour model. The le shown in Figure11.12 is for the doctor’s ofce.

11.7 Calibrating flow modelsHaving added a ow network to themodel, lets see if the model will runand then if the predicted air ows makesense. What might we look for? Thewindows are open so we would expectsignicant ows, especially on dayswith some wind where up to one air

change per minute might occur. Wewant to include in our assessment daysthat have a variety of wind speeds anddirections.We might also wish to identify somedays where overheating is likely so thatafter we add controls to the windowsand extract fan we can simulate thesame period when we are looking athow window opening or the use of anextract fan might improve conditions.For the initial assessment, select a sim-ulation period of a week in April andreset the simulation time step to 10minutes.

Figure 11.13: simulation parametersfor a spring assessment

We we ask for an integrated simu-lation a number of checks will be

183

carried out on the model to ensure thatit it both syntactically correct and thatthe model dependencies are correct.During the simulation, if the monitor-ing is turned on (as in Figure 11.14) theinside temperatures is close to ambient(black line) in the reception (wherethere is cross ventilation) with highertemperatures in the examination roomwhere the ow is constrained by thesingle sided ventilation and the crackunder the door. Clearly there is a needto control the opening of windows toprevent chilling of the room.

Graphs and tablesBefore adding control to the ow net-work, have a look at the predictions ofow to see which of the reports orgraphs provide useful performanceinformation. Start of the results analy-sis module and the last simulation pre-dictions will be used.A good place to start is the graphfacilities and the Time:vargraph where we can look at theenergy embodied in the movement ofair. Selecting climate -> ambienttemperature and temperatures ->zone temperature and zone flux-> infiltration will provide anoverview (Figure 11.15). As expectedthe inltration cooling in the examina-tion room is minimal. The inltrationcooling (the energy implication of theair movement) in the reception variesbetween 0W and 1000W. As the tem-perature differences decrease theenergy implication is reduced.And it is also the case that the volumeof ow changes the magnitude of theenergy implication. To look at that we

need to use a different graphing facil-ity. Use the Network flow -> optionand request volume flow rates ->total entering node for the tworooms. The ow rates shown in Figure11.16 should be similar to the patternyou see in your model.Consider that time spent in the resultsanalysis module working out for your-self which reports and graphs help youto understand the patterns of ow as aninvestment. Many a practitioner has becaught out by a cursory inspection ofow data!It is now time to introduce some con-trol into our ow network so that win-dows are only open when appropriate.And if we nd that ows are insuf-cient then some control of the exhaustfan will be added.

184

Figure 6.14: temperatures during spring assessment

Figure 6.15: temperatures and air cooling during spring assessment

185

Figure 6.16: temperatures and air cooling during spring assessment

11.8 Flow ControlAs with ideal zone control, ow net-work control uses a sensor > controller> actuator structure to dene ow con-trol loops. A control loop senses a spe-cic type of data at a specic location,the sensed value is evaluated by a con-trol law and the control actuation isapplied to the component associatedwith a specic ow network connec-tion. A day can be sub-divided intoseveral control periods with differentlaws or control law details. A numberof control loops can be used insequence or in parallel to implementcomplex control regimes.At each simulation time step the owsolver takes the current conditions andpredicts the ow. The ow predictionsare passed to the zone solver whichthen generates a new set of conditions

to be used by the ow solver at the nexttime step.Control logic is tested at each timestep. If we are approximating fast act-ing ow actuation devices then thesimulation frequency should reect thisas far as is possible within the con-straints of the project. Currently a oneminute time step is the highest fre-quency that is supported by ESP-r forthe zone and ow domains.In terms of the doctors ofce, a 10minute time step was used in theuncontrolled version of the model. Thiswill result in a slightly sticky control sowe should pay close attention to thepredictions to see if this is an issue.

Flow sensors and actuatorsIn ESP-r a ow sensor is dened by itslocation and the values which it cansense. These include temperature, tem-perature difference, pressure, pressure

186

difference, ow rates, humidity, etc. atnodes within the network. It is alsopossible to sense temperatures in zonesor climate data.Most ow components are able to becontrolled. Control is expressed as amodication to an attribute of the com-ponent. For example, a control actua-tion value of 0.6 applied to a windowwith an area of 1.0mˆ2 would result inan opening area of 0.6mˆ2.Control is imposed on specicinstances of a component so it is possi-ble to control the south facing windowin the reception using different controllogic from that used for the north fac-ing window.

Flow control lawsThe range of control laws includeson/off, range based and proportionalcontrol as well as a multi-sensor con-trol where the control law can includeAND or OR logic from several sensedconditions.An ON/OFF control has a single setpoint and attributes that determine ifthe control is direct-acting (ON aboveset point) or indirect (ON below setpoint) as well as the fraction of thenominal area to use when ON.A multi-sensor ow control is anON/OFF controller which includes thedenition of more than one sensedlocation as well as and AND or ORlogic to apply. In some cases a multi-sensor ow control can replace a seriesof individual controls (as described inFigure 11.4).Range-based control uses the nominalarea or ow rate of the component - but

switches to an alternative rate/area as afunction of the sensed condition - lowrate if below low set point; mid rate ifabove a mid-range set point; high rateif above maximum set point as isshown in Figure 11.17.

Figure 11.17: overview of range based controlIn terms of the doctors ofce, the initialow network included window owcomponents that represented a full-open state. In reality, occupants wouldprobably open a window only as muchas was necessary. Unlike automaticcontrols, occupants would tend toimplement a sticky control (i.e. theydelay adjustments). What types of

187

control could approximate this?• ON/OFF with ON expressed as a

fraction of nominal opening area -this would be equivalent to closingthe window below a set point valueand open to X percent of nominalarea above this value.

• Proportional control where the per-centage opening area varies betweentwo values. Some occupants wouldnot exercise such ne (and continu-ous) control.

• Range based control could be usedfor a control that reduced the win-dow opening area if the temperaturein the room is close to the heating orcooling set points. In the dead-bandbetween heating and cooling itwould allow natural ventilation cool-ing by rst using the nominal area ofthe window and then additionalopening area if required. It would benecessary to re-dene the nominalarea of the window to representslightly open rather than fully open.

If occupants are manipulating the win-dows then the control periods shouldmatch the occupied period with analternative control law for the unoccu-pied period. Some building may oper-ate a policy of limiting window open-ing after hours to limit the potential forrain damage. If automatic dampers aremanipulating the openings then itwould be necessary to nd a combina-tion of control law and simulation timestep that reected the regime.

Hint: once you specify a ow con-trol loop it can be copied and thenassociated with other ow connec-tions.

For our rst implementation of owcontrol lets use an ON/OFF control foreach of the windows allowing them toopen 25% of their dened area if thetemperature rises over 22°C. We willdene the control once and then copythe control loop and associate it withthe other windows. And lets turn onthe extract fan if the temperature in theExamination room goes over 24°C. Atnight we will keep the windows closedby setting the set point for the windowsto 100°C.

11.9 To the keyboard...First things rst. Make a backup ofyour model. To dene ow controls usethe Browse/Edit -> Controlsnetwork flow and accept the sug-gested control le name. Begin by edit-ing the description line for the owcontrol and give a synopsis of the owcontrols included. Add the rst loopwhich will be used to dene the win-dow opening regime (closed at nightand weekends and open 25% if over22°C) during 8h00-18h00 weekdays(Figure 11.18).

188

Figure 11.18: control loop interfaceprior to adding periods

Figure 11.19: control loop interfaceafter adding periods

Select the ’wkd’ day type and denethe sensor and actuator for the owconnection for the window on the southof the reception (Figure 11.19). Thesensor should be located at the recep-tion ow node. And when asked aboutthe ow actuator pick single flow

connection and then the relevantconnection that uses long_win.Next edit the period data for the ’wkd’.The rst period is unoccupied so use ahigh temperature for the set point. Theinterface should now look like Figure11.20.When lling in the data for Saturdaysand Sundays there is no need to re-dene the sensor and actuator (owcontrol loops use the same sensor andactuator location for all day types andperiods). Once all the day types havebeen dened save the control le. Touse similar logic for the north windowin reception copy the rst loop and re-assign the sensor and actuator. To usethis logic again for the Examinationroom copy the second control loop andre-assign its sensor and actuator. It is agood idea to keep a note of which con-trol loop is for each of the windows.The extract fan is probably a simpledesign with a thermostat that does notknow what day it is. The control shouldreect this by having one day type andone period. This control will sense thetemperature at Examination and act onthe connection related to the extractfan.Update the control le, generate a newQA report and look at the details andyour notes conrm the data.Re-run the simulation with monitoringturned on and you might see somethinglike the Figure 11.21. Temperatures inboth rooms are closer and they are bothwarmer than ambient. In the resultsanalysis tool the ow entering theReception is based on the crack com-ponent because the temperature did notgo above the control set point.

189

Figure 11.20: control loop period details

Figure 11.21: spring simulation progress with controlled windows

Select a warmer period of the year e.g.the rst week in July and conrm thecontrol works. When monitoring thesimulation (Figure 11.22) the Examina-tion seems to peak at 24°C (which hap-pens to be the set point for the extractfan) and there are some rapid changesin the reception near the 22°C tempera-ture point. Because Examination isconstrained by ow under the door it

has almost no air movement until theextract fan turns on.The energy implications of the windowopening is clearly seen if we plot zoneflux -> infiltration in theresults analysis module. The windowsopen briey except for the last daywhere they are open for several hours.The extract fan is also on for brief peri-ods except for the warmest days whereit also runs for several hours.

190

Figure 11.22: warm period with controlled windows

manager_t_b

door

ceiling

floor spandral

glazing

part_glaz

door

ceiling

floor spandral

glazing

part_glaz

low_glz

high_glz

door

ceiling

spandral

part_glaz

bi!glaz

part_frame

part_frame

part_frame

frame

glazing frame

frame

Project: Three offices with different window representations.

manager

manager_bi

Figure 11.23: wire-frame of three test rooms

11.10 Window representationsThis section of the Cookbook is work-in-progress.

The rst exercise used a simple repre-sentation of window openings. Manywindow types require that we adapt theow paths and components. The fol-lowing discussion uses a model with

191

three adjacent zones (Figures 11.23and 11.24) which differ only in thewindow details. The zone named man-ager has a simple window opening andcomponent. The second zone has asash window and uses an upper andlower connection to represent this. Thethird zone has a tall thin window wherebi-directional ow is possible and a bi-directional component is used.In this case we will create an initialmodel in which the windows are intheir open position. Because we maylater add control the network includestwo connections per opening, one forthe window and one for a crack thatcan act as a bypass in case the windowis fully closed. These window andcrack combinations are seen in many ofthe example models. As long as thewindow is open (even partially) thecrack has almost no inuence in thesolution. If the window closes then thecrack ensures that the closed stateallows a constrained ow so the solverdoes not crash. And since windowswhich have no frame-related inltra-tion are rare the crack component is abetter representation of the ow paththan dening a very small orice.

192

bi_ext

g_ext

low_g_ext

hi_g_ext

boundary node

internal node

manager_t_b

Basic network with windows

manager

manager_bi

Figure 11.24: network in three test rooms

• Each zone has a window-crack con-nection to the outside. The crackcomponent (window_crack) is 2.0mx 5mm and is used many times

• Each zone has a door-crack to anadjacent space (which is not geomet-rically dened). This crack compo-nent (door_crack) is 0.8m x 10mmand is used many times

• The adjacent space node should bedened as using the current tempera-ture of the ow node in the manager.

• Manager has one window opening(window1.67) which is 1.67m2 isdened once and used once

• Manager_t_b (with upper and lowerwindows) needs 2 windows(win_up_.884 and win_low_.884)

which are separately dened.• Manager_bi (with a bi-directionalow opening). The component(win_bi) is Xm wide, Ym tall, has adischarge coefcient of 0.6 and thedistance from its base to the adjacentnode is X. Because the distance fromthe base of the door to the adjacentzone node may differ it is necessaryto dene bi-directional componentsfor use in different contexts.

• Boundary nodes are dened at thespecic height of the opening orcrack they are associated with. Thisallows a zero difference in heightbetween the boundary node and thecomponent.

193

8 6 7 1.000 (nodes, components, connections, wind reduction)Node Fld. Type Height Temperature Data_1 Data_2manager 1 0 1.5000 20.000 0. 40.501manager_t_b 1 0 1.5000 20.000 0. 40.501manager_bi 1 0 1.5000 20.000 0. 40.501gl_ext 1 3 1.9500 0. 5.0000 180.00low_glz_ext 1 3 1.1500 0. 5.0000 180.00hi_glz_ext 1 3 2.7500 0. 5.0000 180.00bi_glz 1 3 1.9500 0. 5.0000 180.00adjacent 1 0 0.50000E-01 manager 0. 40.501Comp Type C+ L+ Descriptiondoor_crack 120 3 0 Specific air flow crack m = rho.f(W,L,dP)

1.00000 5.00000E-03 0.800000win_1.68 110 2 0 Specific air flow opening m = rho.f(A,dP)

1.00000 1.68000win_low.84 110 2 0 Specific air flow opening m = rho.f(A,dP)

1.00000 0.840000hi_win.84 110 2 0 Specific air flow opening m = rho.f(A,dP)

1.00000 0.840000bi_win 130 5 0 Specific air flow door m = rho.f(W,H,dP)

1.00000 0.880000 1.88000 0.600000 0.600000win_crack 120 3 0 Specific air flow crack m = rho.f(W,L,dP)

1.00000 5.00000E-03 2.00000+Node dHght -Node dHght Comp Snod1 Snod2gl_ext 0.000 manager 0.225 win_1.68low_glz_ext 0.000 manager_t_b -0.175 win_low.84hi_glz_ext 0.000 manager_t_b 0.625 hi_win.84bi_glz 0.000 manager_bi 0.225 bi_winadjacent 0.000 manager -0.725 door_crackadjacent 0.000 manager_t_b -0.725 door_crackadjacent 0.000 manager_bi -0.725 door_crack

Figure 11.25: ESP-r network le for window opening model

Nodes can be automatically generatedfor each zone; data is inferred from thezone (volume, reference height, etc).Internal nodes are usually at anunknown pressure. Dene the bound-ary nodes to reect the position of theopenings in the facade.Ensure your component names matchthe sketch! A component can be usedseveral places. If control is to beapplied - unique names of componentsand some duplication of componentscan be helpful (e.g. win_low.84 andhi_win.84).Connections should tell a story! Paral-lel connections e.g. an opening and acrack - are useful if control is to be

applied.Hint: mark you sketch as connec-tions are made.

Figure 11.25 is a copy of the com-pleted le which includes the attributesof the nodes and the components andconnections. When you are working onthe network refer back to this listing.

11.10.1 Component selectionWhich window denition works best?• an air ow opening does one-wayow only, so in cases of single-sidedventilation, ow can be restricted;

• a bi-directional component isintended for doors Ð care is neededin using it in locations such as

194

windows;• bi-directional ow can be approxi-

mated with a pair of air ow open-ings. Stack effects are accounted forif heights are correctly dened;

None of the available componentstakes into account high-frequency pres-sure changes which are one drivingforce in single-sided ventilation. Whenan assessment is carried out with thismodel, the simple window opening inthe zone manager results in almost noow. This is an artefact of this compo-nent type - ow is only supported inone direction at each time step. Thelimiting component is the openingunder the door. The ow rates pre-dicted for the sash window and the bi-directional ow component are more inline with expectations.This does not imply that simple owcomponents should not be used. Onlythat they are a poor representation inthe case of single sided ventilation.

195

Figure 11.26: portion of an ofce building

11.11 Schedules vs networksThis section of the Cookbook is work-in-progress.Now we turn to a practical applicationof a network within a portion of anofce building (which includes a recep-tion, conference room, general open-plan ofce and cellular ofce). Exceptfor the cellular ofce, each of the spa-ces are substantially open to each other(the conference room is only occasion-ally closed). The facade is an olderdesign and is assumed to be somewhatleaky.In terms of learning about air ow net-works, the design is a good candidatefor exploring options for conditioningof the space, including forced and natu-ral ventilation.

The client observation that there aremany hours when outside conditionsare suitable for mechanical ventilationrather than air conditioning. Are theseconditions also suitable for mechanicaldampers embedded within the facadeto allow fan-free ventilation?The other feature of this design is thetreatment of mixed open plan and cel-lular spaces. Many simulation teamsand some simulation tools pretend thatthere is no air movement betweenperimeter and core spaces or acrossopen plan spaces. This isolation of theperimeter discounts air transport whichallows under heated spaces to borrowheat and spaces that are slightly under-capacity for cooling to borrow coolingfrom adjacent spaces.

196

Figure 11.27: inltration model within ofce building

In evaluating whether a ow networkrather than a ow schedule is appropri-ate:• there can be considerable differences

between imposed inltration and thepredicted inltration rates.

• in an open plan ofce there are largeinter-zone ows, resulting in heat-ing/cooling being ’borrowed’ fromadjacent spaces.

There are three stages to investigate• the model with scheduled ows and

the assumption that there is no intra-

zone air movement• a model variant with zone-to-zone

linkages and inltration paths (Fig-ure 11.27)

• a model variant with zone-to-zonelinkages, inltration paths and con-trolled dampers on each facade ori-entation (Figure 11.28).

These three variants are included asexample models (if you want. toexplore ow issues). Review the modeldocumentation, especially the sketchesof the ow networks. Compare thiswith the contents of the ow networkle and the interface.

197

Figure 11.28: vent model within ofce building

Scheduled flows in an open plan officeThe version of the model with sched-uled ows will yield predictions wherethe energy implication of inltration isdependant on the temperature differ-ence and independent of wind speed,wind direction and facade position.Predictions will follow the pattern seenin Figure 11.29.Infiltration and inter-zone flowThe model variant with inltration andow between zones transforms the pre-dictions in several ways (as seen inFigure 11.30): wind speed and

direction are now taken into accountand there is a moderation of demandsas heating and cooling is distributedbetween zones.Controlled vents and inter-zone flowUsing the model variant with con-trolled vents and ow between zonesand running an assessment (as in Fig-ure 11.31) indicates that the vents areopen slightly longer than necessary andthis has performance implications. Thedata also indicate that the conferenceroom is over ventilated, perhapsbecause it has two facade orientationsand the cross ventilation is more than isrequired.

198

Figure 11.29: scheduled ow performance

Take your time when exploring owresults. Discovering approaches whichyield clear indications of ow perfor-mance is an investment well worthmaking. The quantity of informationcan be large and there are several

different views of the ow predictiondata as well as reports on the energyimplications of ow.

199

Figure 11.30: predicted inltration performance

There is one substantial omission in thereporting of ow - there is no overviewof what is happening throughout the

network at a single point in time. Sucha feature would speed up the discoveryof patterns within a network. Currentlyusers must manually collect this infor-mation.

200

Figure 11.31: predicted facade vent performance

Flows that oscillate at each time stepare sometimes an artefact of the simu-lation process. If the magnitude of theoscillation is likely to decrease, butthere is not time (or disk space) to runassessments at a shorter time step,

some users choose to integrate theresults when running the simulation.This removes the oscillation but pre-serves the general trend of ow.

201

11.12 Hybrid ventilationIn 2000 the Chartered Institute ofBuilding Services Engineers publishedMixed mode ventilation CIBSE AM13(ISBN 1 903287 01 4). This publica-tion dened several types of mixedmode ventilation e.g. contingencymixed mode, complementary mixedmode and zoned mixed mode systems.At the time, there were few options fornumerically assessing how mixedmode ventilation worked. The publica-tion was also geared towards regions ofthe world where there was a traditionof natural ventilation as well as an eco-nomic incentive to create buildingswhich were future proof.One of the critical limitations to thesimulation of designs which transitionbetween natural ventilation, mechani-cal ventilation and full HVAC is thedenition of air ow controls.• Approximating the response of

occupants to discomfort or changesin conditions is potentially complex.

• The response frequency of dampersand window actuation devices sug-gests that control logic needs to betested at a relatively high frequency.

• Some people open windows whilethe environmental control systemsare active in other buildings there isbetter coordination. Ideally, systemsshould be controlled differently ifwindows are open.

• Some ventilation regimes may needto sense indoor air quality.

In theory, almost any control logic thatcan be dened via a network of parallelor sequential decision points (see Fig-ure 11.4) can be implemented. The

need for additional bookkeeping nodesto dene such logic paths limits howwell such controls can be scaled.Extending ow networks to accommo-date such logic was more than a linearfunction of the number of openings andfans to be controlled.Simulating the transition between themodes dened in CIBSE AM13 placesconsiderable demands on the facilitiesof simulation tools. Until 2008 it wasdifcult to switch off fans if windowsopened, especially if the logic openingthe windows was based on both insideand outside conditions.Recent versions of ESP-r include amulti-sensor ow controller. Thisallows, for example, a window to openif the ambient temperature is within acertain range AND the inside tempera-ture is within a temperature range as inFigure 11.32.

Ambientbelow 25C

Ambientabove 10C

Zone above 21C

AND

AND

Figure 11.32: control via multiple states

Let’s say there was a variant of the twocellular ofces side-by-side that

202

included two additional zones repre-senting HVAC mixing boxes (one forthe left zone and one for the right zone)as in Figure 11.33. Both mixing boxesare controlled to 16°C and there is aow network that can deliver 5 airchanges to the ofce if required. Thisapproximates a CV HVAC system incooling mode.The left zone includes an upper andlower window opening which is con-trolled based on the logic shown inFigure 11.32. The fan associated withthe mixing box uses an inverse descrip-tion of the window control logic so thatthe fan turns on if conditions are notsuitable for window opening. Theright zone uses the mixing box duringofce hours. The return for the mixingboxes is via the corridor.If the left zone is able to open its win-dows there is a potential savings in fanpower as well as cooling. Heat andhumidity picked up by the return airstream is represented in this model.Unfortunantly, ESp-r does not reportthe electrical energy used by the fanow component so some post-process-ing is required.The listing of the model controldescription below (Listing 11.34)shows the zone control used with themixing box zones as well as the hybridvent ow control.Looking at the performance of the leftzone for one day in Figure 11.35 thetime between 8h00 and 15h00 is ok forwindow opening and there is300-400W of cooling equivalent asso-ciated with the air ow. The delta Tbetween inside and outside is less than5°C so there is not much cooling from

air movement. At 15h00 the outsidetemperature goes over 25°C and thewindows close and the mixing box isused for a few hours until the outsidetemperature drops and the windowsopen again until the un-occupiedperiod starts and both the fans and win-dows are reset to closed.Looking at the performance of the rightzone in Figure 11.36, the CV represen-tation controls the zone in the range of24-25°C. The dotted blue line is theamount of cooling in the mixing box.the dotted brown line is the coolingdelivered to the zone.The difference in the cooling demandfor the two mixing boxes is shown inFigure 11.37. The reduction in coolingfor the left zone clearly indicates that ahybrid ventilation scheme has thepotential to save running costs undersome conditions.

203

Figure 11.33: ofces for hybrid vent and conventional HVAC

Listing 11.34: control descriptions

Zones control strictly controls plant and plant-B temperature to 16degC

The sensor for function 1 senses the temperature of the current zone.The actuator for function 1 is air point of the current zoneThere have been 1 day types defined.Day type 1 is valid Mon-01-Jan to Mon-31-Dec, 2001 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux free floating2 6.00 db temp > flux basic control

basic control: max heating capacity 99999.0W min heating capacity 0.0W max coolingcapacity 99999.0W min cooling cap 0.0W. Heat set-point 16.00C cool set-point 16.10C.

3 18.00 db temp > flux free floating

Zone to control loop linkages:zone ( 1) manager_a << control 0zone ( 2) manager_b << control 0zone ( 3) coridor << control 0zone ( 4) plant << control 1zone ( 5) plant-B << control 1

Flow control Windows open and fan shuts down for manager_a when ambient temp is between10 and 21 degC and room temp is more than 21degC .

The sensor for function 1 senses node (1) manager_aThe actuator for function 1 is flow connection: 1 man_alow - manager_a via low_winThere have been 1 day types defined.Day type 1 is valid Mon-01-Jan to Mon-31-Dec, 2001 with 3 periods.

204

Per|Start|Sensing |Actuating | Control law | Data1 0.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000.2 8.00 dry bulb > flow multi sensor on/off

multi-sensor: normally closed with 3 sensors: For sensor 1 ambient T set-point 25.00inverse action AND sensor 2 ambient T set-point 10.00 direct action AND sensor 3 sensenode manager_a set-point 21.00 direct action.

3 17.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000.

The sensor for function 2 senses node (1) manager_aThe actuator for function 2 is flow connection: 2 man_ahi - manager_a via high_winThere have been 1 day types defined.Day type 1 is valid Mon-01-Jan to Mon-31-Dec, 2001 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000.2 8.00 dry bulb > flow multi sensor on/off

multi-sensor: normally closed with 3 sensors: For sensor 1 ambient T set-point 25.00inverse action AND sensor 2 ambient T set-point 10.00 direct action AND sensor 3 sensenode manager_a set-point 21.00 direct action.

3 17.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000.

The sensor for function 3 senses node (1) manager_aThe actuator for function 3 is flow connection: 9 plant - manager_a via fanThere have been 1 day types defined.Day type 1 is valid Mon-01-Jan to Mon-31-Dec, 2001 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000.2 8.00 dry bulb > flow multi sensor on/off

multi-sensor: normally open with 3 sensors: For sensor 1 ambient T set-point 25.00inverse action AND sensor 2 ambient T set-point 10.00 direct action AND sensor 3 sensenode manager_a set-point 21.00 direct action.

3 17.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000.. . .

Figure 11.35: hybrid vent performance

205

Figure 11.36: CV performance

Figure 11.37: CV performance

11.13 Limitations of Network Air-flow ModelsAlthough network ow models are use-ful, they are limited for some applica-tions:• Large volumes represented by a sin-

gle node, implying well-mixed

conditions.• Temperature distributions within air

volumes cannot be determined (e.g.stratication).

• Momentum effects neglected.• Insufcient resolution for local sur-

face convection determination.

206

Chapter 12

DETAILED FLOW VIA CFD

12 Detailed flow via CFD

Given the limitations of mass ow net-works mentioned in the previous chap-ter, research began about a decade agoto extend ESP-r to support higher lev-els of resolution by incorporating aCFD solver. Although CFD is a matureeld of research, its implementation inbuilding models poses a number ofclassic problems. First, ow velocitiesin buildings are low (in comparison totraditional applications of CFD) andlikely to be within the transition rangebetween ow that is considered turbu-lent and that which is considered lami-nar. The second issue is that boundaryconditions such as surface tempera-tures and air temperatures and drivingforces change over time.In buildings the movement of airchanges surface temperatures and sur-face temperature changes alter the oweld. That our virtual physics modelsdo not represent this well has been aconsiderable irritation to the simulationcommunity.Conversely, the building solver typi-cally makes rough assumptions aboutthe ow eld within the zone and theheat transfer at surfaces. Even in mod-els which include a mass ow networkwe can only make crude guesses at thevelocity that is implied by a given masstransfer.

Clearly, both whole building solversand CFD solvers would have much togain by enabling the two solvers toexchange information as the simulationprogresses.What has been implemented in ESP-ris a radical approach to a difcult prob-lem. It assumes that boundary condi-tions will change so it updates itsboundary conditions at each time-step.It assumes that initial directives to thesolution process may not be appropri-ate when conditions change and it re-evaluates the ow eld to determine ifdifferent so-called wall functionsshould be used. It then creates newdirectives for the solver to follow tobest represent conditions at that time-step and then passes information backto the building solver to use in evaluat-ing heat transfer at the surfaces in thezone. Its default assumption is that theCFD domain is transient rather thanstatic.The solution also takes into accountconnections between the CFD domainand a mass ow network. This allowschanges in pressure or mass ow inother zones of the model to becomenew driving forces for the CFD solver.And because mass ow networks alsoinclude boundary nodes the CFDdomain also has information onchanges in weather patterns. Andtime-varying heat sources within rooms

208

from the zone operations schedules arenoticed by the CFD solver and can beassociated with blocks of cells.

Powerful stuff. And also utterlywrapped up in jargon which soundslike English but means somethingdifferent. CFD is a place where drag-ons live. ESP-r’s interface to CFDhas a steep learning curve.

The Cookbook is not a tutorial on thetheory of CFD or the so-called confla-tion mechanisms used by the solvers.There are several PhD thesis written onthe topic which are available for down-load on the ESRU web site publica-tions page at<<http://www.esru.strath.ac.uk>>. Andthere are any number of books on thesubject. And the source code associ-ated with CFD is heavily commentedand can provide a number of usefulclues.If you already have a solid backgroundin CFD and are comfortable with whatyou found in the literature search men-tioned above, then continue readingthis chapter. If not, CFD will absorbboth computing and mental resourcesat an painful rate. You have beenwarned.The chapter includes an overview ofthe entities and parameters which canbe used to dene a CFD domain, meth-ods for designing a griding schemewithin the domain, and what to lookfor in the performance predictions.There are also some information boxesand dragon boxes where particular care

should be exercised.This chapter will be completed at alater date.

209

Chapter 13

PLANT

13 Plant

In ESP-r environmental control sys-tems can be represented as either so-called idealized zone/ow controls oras a network of system componentswhich is often called a plant system.The choice of which approach to takeis partly based on how much you wantto know about the detailed perfor-mance of the environmental controlsystem and partly on how muchdescriptive information you canacquire about the composition of theenvironmental control.The Cookbook does not cover the the-ory of component networks or the solu-tion techniques used. It provides anoutline strategy for using systems net-work facilities. Readers might treatthis Chapter as an initial draft as thereare many dragons lurking with this por-tion of ESP-r and there remain manygaps in the strategies.Networks of components offer the fol-lowing facilities:• the psychometric state within com-

ponents and at points in the networkis explicitly computed and is avail-able for inspection

• interactions between componentsand/or controls are computed at sub-minutely intervals can be inspectedin this time domain

• those who have an interest in ne-tuning the response of particularcomponents or control deviceswithin the network have manyoptions for creating models whichare close approximations

• those interested in high resolution ofboth system components and massows can link both the system com-ponent solver and the mass owsolver

ESP-r provides feedback on the com-position of such networks and a wealthof information about what is happeningwithin and between components duringsimulations (via trace facilities) anddifferent views of the state variableswithin the res module.Those who master the use of systemcomponents are able to address a rangeof questions that are not possible withother approaches and have access to arich store of performance indicators.Tactical users of simulation do not rushto create networks of components untilthey hav e learned all they can fromideal controls. And they do thisbecause creating networks of compo-nents:• tends to take longer (more descrip-

tive information and more linkagesbetween components)

• such networks need tuning like realsystems

211

• such networks fail in similar ways toreal systems

• some system interactions are in thefrequency of seconds or fractions ofa second and so the volume of infor-mation increases greatly.

• much performance information is ina form that it difcult for many usersto interpret

• the facility requires you to assemblea network that is both syntacticallycorrect and physically correct

In comparison with most of the idealzone controls the use of networks ofsystem components involves a steeperlearning curve. Many tasks and muchof the quality assurance in models withsystem components is the responsibil-ity of the users. A methodicalapproach is essential.• Rule one: start with zone and/or ow

controls learn as much as possibleabout the pattern of demands and thelikely control logic that is appropri-ate for the design

• Rule two: planning and sketches areessential.

• Rule three: walk before you run -test out portions of the network andcontrol options on a simple modelbefore scaling the network.

• Rule four: document what you do.• Rule ve: leave plenty of time for

testing.For readers who are approaching theuse of system networks in ESP-r withprior experience with component basedanalysis be aware that all componentsare entities within a single network. InESP-r there is no conceptual difference

between components representing aduct, a valve, or a cooling tower. Thereis no concept of central plant and zone-side components.

13.1 Using a network to representmechanical ventilationMechanical ventilation is one aspect ofbuilding design which simulation canplay a role. We will create severalmodels of a mechanical ventilationdesign to explore such systems respondto changing demands and boundaryconditions.The rst approach is to represent allaspects of a mechanical ventilationdesign within the component network(i.e. it uses a component as a simpliedrepresentation of a thermal zone).Although this will not provide a fullaccounting of the interactions betweensupply and demand sides it is anapproach suited to early design stagequestions where little might be knownof the zones.Figure 13.1 shows a standard mechani-cal ventilation system which has a sup-ply and an exhaust fan and a heater coiljust up-stream from the supply fan.Tw o zones are supplied and theextracts from each zone are combinedin a mixing box just before the exhaustfan.

212

Figure 13.1 Basic mechanical ventilation system.

Planning is essential, even for a simplemodel. Sketch out your network rstand decide on names for the compo-nents. Most of your work within theproject manager will involve names ofcomponents and numbers representingcomponent attributes and your sketchis essential for keeping track of yourwork, supporting QA tasks and com-municating with clients.After sketching the network gather thecomponent information. The list on thenext page contains component informa-tion for the 12 components and youshould refer to this as you create yournetwork.Components have a sequence - the ini-tial group goes from the returns fromthe zones to the exhaust and then comethe idealized zones and then theinlet_duct to supply_duct. Adopting asequence which proceeds from thereturn to the supply can make subse-quent tasks easier.

After the name of the component is anumber in ( ) which is the componentindex within the plant network. Includethis number on your sketch in additionto the component name. Why? Becausethere are a few places in the interfacewhere you have to type in this indexrather than selecting from a list of com-ponent names.Most components include an attributefor the total mass of the component.For these exercises this need not beexact. There is also a mass weightedav erage specic heat which tends to beeither 500.00 or 1000.00. Each com-ponent also has a UA modulus. Theseparameters support calculations of howthe casing of the component interactswith its surroundings.Ducts have additional parameters,including the length of the duct, cross-sectional area and hydraulic diameter.If you pre-calculate these it will speedup your descriptive tasks as well asreducing mistakes (see Rule two).

213

Figure 13.2 Components (with attributes shown).

Figure 13.3 Connections between components.214

The pattern for creating components issimilar (see Figure 13.5). When youhave nished dening the componentsyou should see something like Figure13.4. Save your network and take amoment to review the componentslisted in the interface menu with yoursketch to ensure they are consistent.

Figure 13.4 Finished network.The next task is to link the componentstogether. Linking plant componentstogether is different from linking ownetwork components together. Clearyour mind - the pattern is to begin yourfocus at a component that receives owand gure out which component issending the ow. Referring back to

Figure 13.1 - the heater is supplied bythe supply_fan so when you set up alink the rst component in the link isthe heater and the second component inthe link is the supply_fan.Look again at the list in Figure 13.3and draw this (a coloured line workswell) on your sketch of the network.When this makes sense, start theprocess of adding connections and not-ing them on your sketch. The massdiversion for supply_duct ->zone_aand supply duct ->zone_b are 0.5because each takes half of the output ofthe component supply_duct. Except forthe receiving component inlet_duct,which takes its supply from ambientair, each of the other connection is withanother component. When the connec-tions are complete save the network.

215

Component: duct_ret_a ( 1)db reference 6Modified parameters for duct_ret_aComponent total mass (kg) : 3.7000Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 5.6000Hydraulic diameter of duct (m) : 0.12500Length of duct section (m) : 2.0000Cross sectional face area (mˆ2) : 0.12270E-01

Component: duct_ret_b ( 2) db reference 6Modified parameters for duct_ret_bComponent total mass (kg) : 1.8500Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 2.8000Hydraulic diameter of duct (m) : 0.12500Length of duct section (m) : 1.0000Cross sectional face area (mˆ2) : 0.12270E-01

Component: mixing_box ( 3) db reference 1Modified parameters for mixing_boxComponent total mass (kg) : 1.0000Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 3.5000

Component: duct_mix_fan ( 4) db reference 6Modified parameters for duct_mix_fanComponent total mass (kg) : 9.2500Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 14.000Hydraulic diameter of duct (m) : 0.12500Length of duct section (m) : 5.0000Cross sectional face area (mˆ2) : 0.12270E-01

Component: exh_fan ( 5) db reference 3Control data: 0.060Modified parameters for exh_fanComponent total mass (kg) : 10.000Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 7.0000Rated total absorbed power (W) : 50.000Rated volume flow rate (mˆ3/s) : 0.10000Overall efficiency (-) : 0.70000

Component: exh_duct ( 6) db reference 6Modified parameters for exh_ductComponent total mass (kg) : 5.5000Mass weighted average specific heat (J/kgK): 500UA modulus (W/K) : 8.4000Hydraulic diameter of duct (m) : 0.12500Length of duct section (m) : 3.0000Cross sectional face area (mˆ2) : 0.12270E-01

Component: zone_a ( 7) db reference 25Control data: -500.000Modified parameters for zone_aComponent total mass (kg) : 10920.Mass weighted average specific heat (J/kgK): 1000.0Wall U value (W/mˆ2K) : 0.40000Total surface area of walls (mˆ2) : 78.000Zone space volume (mˆ3) : 45.000Inside heat transfer coefficient (W/mˆ2K) : 5.0000Outside heat transfer coefficient (W/mˆ2K) : 18.000Outside air infiltration (ACH) : 0.0000

216

Component: zone_b ( 8) db reference 25Control data:-1000.000Modified parameters for zone_bComponent total mass (kg) : 7560.0Mass weighted average specific heat (J/kgK): 1000.0Wall U value (W/mˆ2K) : 0.40000Total surface area of walls (mˆ2) : 54.000Zone space volume (mˆ3) : 27.000Inside heat transfer coefficient (W/mˆ2K) : 5.0000Outside heat transfer coefficient (W/mˆ2K) : 18.000Outside air infiltration (ACH) : 0.0000

Component: inlet_duct ( 9) db reference 6Modified parameters for inlet_ductComponent total mass (kg) : 9.2500Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 14.000Hydraulic diameter of duct (m) : 0.12500Length of duct section (m) : 5.0000Cross sectional face area (mˆ2) : 0.12270E-01

Component: supply_fan (10) db reference 3Control data: 0.060Modified parameters for supply_fanComponent total mass (kg) : 10.000Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 7.0000Rated total absorbed power (W) : 50.000Rated volume flow rate (mˆ3/s) : 0.10000Overall efficiency (-) : 0.70000

Component: heater (11) db reference 5Control data: 3000.000Modified parameters for heaterComponent total mass (kg) : 15.00Mass weighted average specific heat (J/kgK): 1000.0UA modulus (W/K) : 3.5000

Component: supply_duct (12) db reference 6Modified parameters for supply_ductComponent total mass (kg) : 1.8500Mass weighted average specific heat (J/kgK): 500.00UA modulus (W/K) : 2.8000Hydraulic diameter of duct (m) : 0.12500Length of duct section (m) : 1.0000Cross sectional face area (mˆ2) : 0.12270E-01

Figure 13.5 Typical component menu.

217

13.2 Defining containmentsComponents exist in a context (or con-tainment), such as surrounded by axed or ambient temperatures. For pur-poses of this exercise we want toattribute each component with a xedtemperature of 22°C. Figure 13.6shows what you should expect to see.

Figure 13.6 Containments for each component.

13.3 Finishing off the model andtestingAt this point your interface should looklike Figure 13.4. Notice that there is aplace for you to include notes (Rule 4)before you forget what this network isabout!Next we need to test the model to see ifit is complete and syntactically correct.In the simulator interface look for theSimulation parameters optionand provide the name of the results le,the period of the simulation and whatsort of time-step to use. This allows

you to re-run this assessment withouthaving to look around for scraps ofpaper. The parameters shown in Figure13.7 are a good starting point. Oncethese are set commission an interactivesimulation.The simulator will notice that themodel includes only a network of com-ponents and will solve only a systemonly simulation. It will request conr-mation for using zero start-up days(accept this), the default climate andthe name of the results le to be cre-ated (write this name down, you willneed it in a few minutes). The simula-tion should take a few seconds. Exitfrom the simulator and invoke theresults analysis module.

Note for some versions of ESP-rthe initial results le name in theresults analysis module is incor-rect and needs to be edited.

218

Figure 13.7 Simulation parameters.The results analysis facilities (see Fig-ure 13.8) for network componentsallows you to toggle between tabular,psychometric chart, summary statistics,histograms and graphic plots. Itemsselected will be re-displayed as youswitch views.Figure 13.9 shows the temperatures atreturn ducts a & b and Figure 13.10statistics of temperature and enthalpyat return_duct_b.Spend a few moments browsing thereports and graphs in search of patternsthat indicate how the ventilation sys-tem is working.

Figure 13.8 Results analysis menu.The diversion ratio of 0.5 from the sup-ply duct to zone_a and zone_b resultsin the return from zone_b being coolerthan from zone_a. Edit the diversionratios and see if the differences in tem-perature might be reduced.To sav e time, note the information forthe two connections before starting theedit. And remember to save the compo-nent network le to a slightly differentname when you make such changes sothat you recover the original le. Aftersaving the changes and commissioninganother simulation check and see thechange in performance (Figure 13.11).

219

Figure 13.9 Graph of return duct temperature.

Figure 13.10 Statistics at return duct b.

220

Figure 13.11 Temperatures in return ducts after adjustment.

13.3 Moving from ideal demands tothermal zone demandsIn the initial model demands that themechanical ventilation had to respondto were via component representationsof zones. You can also associate a net-work of environmental system compo-nents with thermal zones. In this casewe need to add two zones to the modelwhich will have the same volume andsurface area and overall thermophysi-cal properties as the component repre-sentations.The component zone_a has a volumeof 45mˆ3 and a zone which is 4m widex 4m deep x 2.81m high will be equiv-alent in volume and surface area. Thecomponent zone_b has a volume of27mˆ3 and a zone which is 4m wide x

2.4m deep x 2.81m high will be equiv-alent. If all surfaces in the rooms areattributed with the construction exter-nal_wall and face the outside then theoverall UA will be similar to that of thecomponent representation. These zonesare rectangular and have no windowsor doors, so the process of creating thegeometry and applying attribution isstraightforward.One option is to begin a new modeland to build up both the zone and com-ponent network to match the require-ments of the exercise. A second optionwould be to upgrade the existing modelto include the zones and to adapt theexisting network of components. Bothoptions have benets and drawbacksand it is well worth exploring both.

221

Figure 13.12 Component control types.

For this exercise lets modify the exist-ing model and the rst task is to makea backup copy of the model. If theoriginal model folder is namedmech_vent then give the followingcommand:cp -r mech_ventmech_vent_2z

Then go into the conguration folderof mech_vent_2z and restart the projectmanager with the conguration le we

want to modify. As soon as the modelloads change the root name tomech_vent_2z and alter the modeldescription phrase (as a reminder thatthis is a different model).The model has no zones, so go to thezone composition and create zone_aand then zone_b based on the informa-tion given above. At the end of thisprocess you would see something likeFigure 13.13 for zone_a and somethinglike Figure 13.14 for zone_b.

222

Figure 13.13 Zone a details.

Schedules and other attributesThe two zones need to be fully attrib-uted in terms of composition and oper-ational details. Keep these descriptionssimple - 200W during ofce hours and0.2 air changes of inltration will suf-ce.Modifying existing network of compo-nents takes several steps: rst make abackup copy of the existing network,second change the connection to sup-ply_duct -> zone_a (a connection

between components) to supply_duct-> duct_ret_a (a connection between acomponent and thermal zone_a).In this case the receiving componentbecomes duct_ret_a, the connectiontype is ’from a building zone’ and thenzone_a is selected from the list ofavailable zones. The next question isabout the supply for the zone and thisremains component supply_duct with adiversion ratio of 0.5.

223

Figure 13.14 Zone b details.

The same needs to be done with theconnection supply_duct -> zone_b tobecome supply_duct -> duct_ret_b (aconnection between a component andthermal zone_b). After these changeshave been made the interface will looklike Figure 13.15.The next step is to remove the nowredundant connections g and h in theabove gure and to nally go into thelist of components and remove theideal components zone_a and zone_b.The result will be a network of 10components, 11 connections and 10

containments.

224

Figure 13.15 Connections after editing.

13.4 Links to zones and controlsAt the bottom of the network denitionmenu there is an option link plant tozone. Before we can use this facilitywe need to dene two zone controlsand that requires saving the network ofcomponents and changing to the zonecontrols menu to initialize the controlsand then return to the network compo-nent interface to complete the process.Perhaps a future version of ESP-r willinclude a wizard to sort this out...The rst zone control senses the tem-perature in zone_a and actuates at theair node of zone_a and has one daytype and one period in that day and thecontrol type to ux connection betweenzone and plant but skip lling in thedetails.The second zone control should sensethe air temperature in zone_b and actu-ate at the air node of zone_b and haveone day type and one period with the

ux connection control law (see Figure13.16). While you are in the controlfacility there is an option to set(another type of) linkage between thecontrol law loops you just created andthe relevant thermal zone. When youhave done this save the zone controls.Now return to the network of compo-nents and select the item link plant tozone. The control le will have beenscanned and there should be twoentries, the rst for connected zonezone_a and the second for connectedzone_b, both with a convection typeconnection. The remaining elds denethe nature of the supply and whetherthere is an extract.The link for zone_a uses the compo-nent supply_duct as the supply and theduct_ret_a component is the extract.The link for zone_b uses the compo-nent supply_duct as its supply and theduct_ret_b as the extract.The interface will look like Figure13.17 when this is completed. This is a

225

good time to save the network of com-ponents. You will be asked whether thezone controls should be updated toreect the recent changes in the net-work of components (say yes).Almost nished. The zone controlsneed to be adjusted. The linkage func-tion guessed at the capacity of theheater component and will have set theheating and cooling capacity of thezone control to a value which is incor-rect (the actual value of the heater3000W and 0W cooling).Up to this point we have used zonecontrols to establish the link betweenthe thermal zone and network compo-nent domains and some of the parame-ters in the zone controls (e.g. thecapacity) are based on informationused during the denition of the net-work of components.We now hav e to dene the logic whichwill drive the heater component and forthis we must dene a so-called plantcontrol. There will be one control loop,it will sense node one within theduct_ret_a component and it will actu-ate node one within the heater compo-nent. The controller type is senses drybulb actuates ux (from within the listshown in Figure 13.12). There is oneday type and three periods during theday. From 0h00 to 7h00 the controlwill use a period switch off control,from 7h00 there will be an on-off con-trol with a heating capacity of 3000Wand a cooling capacity of 0W and from18h00 a switch off control.The selection of control laws (see Fig-ure 13.18) is somewhat terse, but thehelp message claries the relationshipbetween the control law and the control

type. These relationships are requiredbecause some components work onux and some on ow and the actua-tion needs to reect this.A word about the data for the on-offcontrol period. There are seven param-eters:• mode of operation (1.00)• off set-point (23C)• on set-point (19C)• output at high (3000W)• output at low (0W)• sensor lag (zero) actuator lag (zero)When the plant control is complete andsaved it is a good idea to generate afresh QA report for the model. Thiswill provide additional feedback forchecking that your model is consistent.After you have reviewed the QA reportadapt the simulation parameter sets.Use a 15 minute time-step for the zonesolution with the plant simulation at 10time-steps per building time-step andensure that there are names for thezone and plant results les lled in.Commission an interactive simulation.If all went well the simulation will takea few minutes to run (the plant is solv-ing every minute). When you go tolook at the performance prediction lookfor performance graphs such as in Fig-ure 13.19. The upper olive-green linesare the heater temperature and ux out-put (labelled as other). The lines beloware the temperatures at various pointsin the ducts. It is also worth looking atthe performance characteristics reportsfor the zones.

226

Figure 13.16 Initial zone control settings.

Figure 13.17 Completed linkages between zones and components.

One of the reasons one might need touse a network of components is toinquire into the internal state of thecomponents so this is a good time toreview what is on offer and, impor-tantly, what information about thecomponents are required to recoverperformance data.One way of discovering the perfor-mance sensitivity of networks of com-ponents to changes in control

parameters is to run a series of simula-tions typically changing one aspect of acontrol or a component parameter at atime. This process works even better ifa friendly control engineer takes part inthe exploration. Certainly an on-offcontrol will result in different perfor-mance characteristics to a PID con-troller, but remember to walk beforeyou run when it comes to PID con-trollers!.

227

Figure 13.18 Component control laws.

Figure 13.19 Performance predictions within model with thermal zones.

Judging the additional resourcesneeded in comparison with ideal zonecontrols is best done once you havedened a couple of component net-works and developed some prociency

at the tasks involved. The goal is toemploy the most appropriate approachto a given simulation project and onlyusing complex facilities where a lesscomplex approach does not support therequirements of the project.

228

Chapter 14

WORKING PROCEDURES

14 Working procedures

Simulation teams who are attemptingto deal with real designs in real timesometimes deliver less than theyintended or exceed planned resources.There are many reasons for this:• missing out a brief, but critical step

in a sequence of tasks• failure to review a model for incon-

sistencies as it evolves• failure to record critical assumptions• failure to locate notes about critical

assumptions• misunderstanding the nature of the

assessments to be carried out• failure to constrain model complex-

ity• altering model les for a quick

change without documenting thechange, checking its syntax or run-ning calibration tests

• assuming that everyone else knowsthat ext_glas is intended for use onthe only the south facade of thebuilding

These are self-inicted errors andomissions. Simulation teams whothrive hav e ev olved working practiceswhich limit errors and omissions. Ifproperly designed, working practicescan also compensate for the limitationsof simulation tools as well as leveragethe specic skills of the team.

ESP-r is designed for practitionerswith strong opinions. It assumesthat those who use it are aware ofthe rules and requirements of theentities used to create models aswell as having a methodologicalapproach to the planning, creationand use of models. Thus there aremany places where users requireguidance and much advantage tobe gained in acquiring some of theattributes of opinionated users.Working procedures whichencode such guidance and supportup-skilling are thus critical to thedeployment of simulation suitessuch as ESP-r.

The following discussion is an expan-sion of ideas that the author and otherscontributed to Building energy andenvironmental modelling: CIBSEApplications Manual AM11: 1998 TheChartered Institution of Building Ser-vices Engineers, London, April 1998.The denition of QA & QC used in thisdocument extends the traditional riskmanagement and consistency checkingfound in AM11 to include proceduresand organizational patterns that helpidentify opportunities for deliveringadditional value to the design process.They are based on a decade of observa-tion of successful and un-successfulsimulation groups. They form a startingpoint for creating group-specic and

230

tool-specic working procedures.Many of these extensions require mini-mal resources and some are intended toreduce resource requirements.

14.1 How can the vendor help?Vendor marketing tends to emphasizeproductivity gains and ease of use andtheir brochures are full of astoundinglycomplex models. Vendors mount train-ing courses which are optimized forkeyboard skills, production tasks andrapid generation of models. They mayoffer a dictionary lled with details ofthe entities which can be used to createbuildings and systems as well as arange of example models.Less attention is paid to the design ofmodels. Vendors tend to view this as anesoteric skills or as not applicable totheir software. Support may be avail-able if you know who the ask and whatto ask for.Interpretation of performance predic-tions is another esoteric skill set whichinvolves domain knowledge, good pat-tern matching skills (when scanningperformance data) and an in-depthknowledge of options for accessingperformance data. It is critical in thedeployment of simulation but is onlylightly covered by most vendors.The design of a simulation tool and itsinterface impact working practices:• Some tools use an if what you see

looks correct it must be correctapproach. Unfortunately, optical illu-sions abound in simulation so simu-lation teams must employ robustprocedures to enforce model quality.

• Some tools offer only one view ofthe contents of the model (the inter-face). Designing working proceduresto adapt to the absence of modelcontents reports is a considerablechallenge.

• Some tools constrain in-model docu-mentation thus links with externaldocumentation becomes an issue forworking procedures to deal with.

• Some tools (including ESP-r) havelimited un-do facilities. Techniques(and habits) to compensate for thisare essential.

• Simulation model les are surpris-ingly fragile. Techniques for recov-ery are an essential part of workingprocedures

The deployment of simulation mustalso take into account that simulationtools tend to be designed for individualuse rather than team use. The needs ofdistributed work groups are largelyunsupported. The implications of thisare far-reaching. Manipulations ofmodels which are substantially robustfor an individual can be the cause ofsystematic failure if models are beingaccessed by multiple users.Simulation data models are among themost complex dreamt up by humans.One might expect robustness and enter-prise class database management toolsbut this is the exception rather than therule. It falls to users to manage diversesets of supporting data.Each simulation tool presents a specicset of challenges. ESP-r provides mul-tiple views of simulation entities and anumber of opportunities for document-ing models but there are exceptions -

231

some limitations on names force usersto be terse and networks for air owand system components lack a graphi-cal display of relationships. ESP-rusers must also put up with minimalundo facilities.Although specic examples of workingpractices are given from the context ofESP-r, users of other software will ndmuch that is familiar. Adaptations to tthe conventions and facilities ofanother tool are left to the reader.

14.2 Responsibilities within teamsAlthough there are successful indepen-dent simulationists, simulation is mostpowerfully deployed in a team environ-ment.Why would this be the case? Firstly,simulation demands a range of man-agerial, technical and communicationskills.Second, projects can fail if errors inmethods or descriptive details are notidentied. Self-administered QA is aninvitation to risk that is difcult toovercome.Third, simulation tools grown in com-plexity and it is increasingly difcultfor an individual to be procient withall aspects of a tool or to manage thevolume of detail in complex models.Individuals can work jointly in ad-hocteams using some of the techniquesemployed by teams who are geographi-cally distributed.For most projects, the challenge of avirtual team is not the speed of theinternet, but the inability of simulationsoftware to cope with asynchronousmanipulation of models, as well as our

ability to maintain an audit trail ofactions taken.In an ad-hoc or formal simulation teamthere are a number of participants:• The team manager, who works

from the perspective of projectgoals, client requests, resource lim-its, delivery dates and staff moti-vation

• The quality manager, who helpswith calibrating the model, ensuresthe model is t for purpose, thatpredictions are as expected andwho (ideally) is looking for oppor-tunities to add value to the deliver-ables

• Simulation staff, who implementthe work plan, coerce the tool tots the needs of the project, com-mission assessments and carry outproduction related data extractionand interpretation of predictions

• Domain experts who advise on themodelling approach and identifyopportunities as well as glitches inthe procedures

• Mentors are also ad-hoc partici-pants focused on creating newworking practices and augmentingstaff skills.

Setting up a simulation team is not atrivial task as can be seen in section4.2.1 of CIBSE AM11. The section onhuman resource requirements is essen-tial reading.

14.3 Classic mistakesSimulation teams tend to underestimatethe time required to create and evolveworking procedures. Similar optimismpervades the task of maintaining and

232

extending staff skills.Bluntly stated - errors and omissions inmanagement are no less important thanerrors and omissions in technicalexecution.First there is the classic mistake of con-fusing keyboard prociency with therecognition and delivery of usefulinsights into the performance of adesign. Staff who are quick and havegood domain skills are rare so teamswith complementary skills are needed.A variant of this mistake is a belief thatuser friendly software allows juniorstaff to function with limited supervi-sion and or limited training. Juniorstaff lack the self-restraint to avoidcomplexity and become driven by thetool. This ensures that only a fractionof the implied power of the software isrealized.The next classic mistake is to rely onraw computing power rather than wellformed working practices and welldesigned models. Yes, there are caseswhere computer power limits produc-tivity, and the majority of simulationtasks are constrained by other factors.Another classic mistake is to equate theability to generate reports and graphswith an understanding of the patternswithin reports and graphs sufcient toadd value to the project. Valuable pat-terns within a data set can remain hid-den just as errors can pass unnoticed.Just because the tool interface includesa WOW feature, you still need a goodreason to select it. Auto-generation orauto-sizing should not be invoked on acasual basis until the team reviewssuch facilities.

A perfect storm for a simulation teamis a manager who gives an inappropri-ate directive to a novice who eitherdoes not have the background to recog-nize the directive is suspect or the con-dence to request clarication. Thenovice thus works very hard at digginga hole for the team to fall into and lackof attention ensures the pain is distrib-uted.

233

14.4 Planning simulation projectsThe author once had a consultingproject to evaluate whether mechanicaldampers could be used in the facade ofan ofce building to provide naturalventilation during transition seasons.The model included eight zones, inter-nal mass, shading devices, two variantsof air ow network and three controlschemes.How much resource should be allo-cated for such a task? How long shoulda client expect to wait for feedback? Inthe even, a synopsis of the ndings wasavailable ve hours after the plans andsections were rst opened.This model was converted into anexemplar and can be browsed fromwithin the project manager in the realprojects category of exemplars.This was possible because the rsthour and a half was devoted to plan-ning the model:• establishing what needed to be

included in the model• dening the extent of the model and

its resolution• establishing critical co-ordinates in

plan and section• planning the zoning of the model• review available construction data-

bases and identify additional ele-ments needed

• planning the sequence of tasks thatwould limit error and allow for enti-ties to be re-used

• planning the calibration tests to becarried out

• sketching out the model, deciding anaming strategy

• sketching out the air ow networkand gathering relevant data

• reviewing an exemplar model whichused the same control logic

With this information the task of creat-ing the initial cellular ofce and facadeelements was straightforward and attri-bution proceeded without interruptions.It was then possible to re-use these ele-ments in many other parts of themodel. There was no need to use a cal-culator or pause during the inputprocess because all of the criticaldimensions and attributes were avail-able for checking.About one and a half hours was spentcreating the model and a half hour wasspent in calibration. The remainingtime was living with the model andtesting out different damper controlsand drafting the synopsis.Spending one third of project resourcesfor planning and data gathering is, formany groups, a typical approach tolimiting the risk of delays and errorslater in the process.The following table includes number ofissues which may confront simulationteams in the planning stage.

234

Core issue Related issue ActionsDoes the client/designteam have prior experi-ence with simulationbased assessments?

Prior experience easesthe educational taskotherwise client expec-tations could be anissue.

Ensure time and resources forclear communication with theclient. Brief the client on thenature of the information theywill be asked to provide.

Does the client/designteam know the types ofperformance data andreports which can begenerated?

Management of report-ing expectations.Identication of howinterim results can becommunicated.

Review client preferences andclarify potential misunderstand-ings in deliverables.

Has the client used lan-guage or providedsketches that indicatebeliefs about howdesign will work? Sim-ulation can test suchbeliefs.

Test beliefs is as soon asthey are noticed.Create focused modelswhich can deliver infor-mation with minimaldelay.

Conrm if typical data for thetype of building if available.Create a test case to conrm thatstaff hav e captured the essentialcharacteristics of the design.

Has the client indicatedwhat criteria would sig-nal success?

What value for each cri-teria?What additional perfor-mance data might becaptured to help cali-brate the model?

Investigate whether the clientcriteria provide useful indicatorsfor future what-if questions.

Has the client indicatedwhat criteria would sig-nal failure?

What magnitude/fre-quency of change?What are likely modesof failure?What needs to be mea-sured to identify risk?

Conrm criteria are in keepingwith current practice or areclient-specic.Evaluate likely assessments thatwill test how robust the designis.Identify operational regimes orboundary conditions that wouldhelp identify risks.

Is the design teamsearching forimprovement on a rangeof issues or a singleissue?

Multiple issues mightrequire several modelsor model variants.

Conrm if staff can cope withmultiple models and/or modelvariants.Clarify how are different modelsor variants to be identied.

235

Core issue Related issue Actions

Are what-if questions inthe form what happensif we use a better qual-ity low-e glass or whathappens if we use prod-uct X?

Is the role of the simula-tion team in the designprocess to provideinformation for othersto make decisions or isit pro-active?

Identify methods might to iden-tify a better quality low-e glass.Raise the issue of wither a sup-plied specication is appropriateand in the clients interest.

Do what-if questionspose parametric ques-tions (e.g. which sky-light area between 12and 36% is the pointwhere cooling demandescalates)?

Resources for paramet-ric studies must be care-fully considered.Early conrmation isessential.

Conrm tool supports the cre-ation of model variants.Discuss whether it will be nec-essary to generate scripts toautomate parametric tasks.Conrm the automation worksand extracted data is correct.Consider if methods are re-usable.

Is this project similar toprevious projects?Can we adapt a pastmodel for this newproject?

What did we learn inthe previous project?What were the difcultissues in past projects ofthis type?

Conrm if staff hav e the skillsto adapt existing models.Conrm the existing model’sdocumentation.Review procedures and staffresources against the currentresource allocation.

Does the current state ofthe model reect theideas and conceptsdeveloped during theplanning stages?

Is the complexity of themodel consistent withthe resources allocated?Have the resources usedmatched the initialplan?

Consider if staff tasks need tobe adjusted.Consider if additional staffrequired.Plan for contingencies if staffbecome ill.

A potential project willbe discussed with aclient in a meetingtomorrow.

Who should take part inthe meeting?What is the near-termwork load?What key phrases areimportant to listen for?How much do we needthis project?

Review details of similarprojects.Review criteria for deciding onwhether to bid.Ensure that presentations andsample reports are available ifthe client needs to be briefed.

14.5 Team managerIt is critical that someone considers thebroad sweep of issues within theproject as well as the clients goals. Few

can manage the mental leaps needed toshift from the detailed focus of simula-tion use to a broad perspective. Ensurethat simulation staff hav e access tosomeone who is paying attention tothese other perspectives.

236

The team manager may be appointedon project basis or hold the position fora number of projects. Individuals mayrotate positions - in one project theymay act as the team manager, inanother they may carry out simulationtasks and for another they focus onquality issues.Flexibility has several benets:• It allows ad-hoc teams to be formed

with the best available talent.• It ensures that staff who have a

broader range of skills and haveopportunities to exercise thoseskills.

• It ensures distributed knowledge ofthe resource requirements for spe-cic simulation tasks.

• It distributes strategies for solvingdesign problems.

Remember, others in the designprocess may know very little about thework of simulation teams and whatinformation they can deliver. If thesimulation team has sufcient con-dence to allow others into the process,there are signicant opportunities forboth parties to discover concepts andideas that will be of mutual benet.And one of the benets of interactiveworking is that it gets around the rigidstructure of formal reports and theinevitable ltering of topics. Fifteenminutes of browsing performance pre-dictions (the ESP-r results analysis toolis specically designed for interactiveuse) may uncover patterns that wouldnot have been included in a report orwhich might have taken hours to for-mat for a formal report.

Staff rotation and interactive workingwith others in the design process alsoprevents the isolation and dead-endhorror stories that many simulationstaff experience in some companies.Another type of exibility is in theselection of the most appropriate toolfor the task. While it may be possibleto coerce your preferred tool to carryout a range of tasks, the lack of choicemay impose a cost.Simulation teams should review thecapabilities and cost-of-use of eachsimulation tool and develop selectioncriteria. The costs associated withacquiring and supporting multiple toolsshould take into account whether staffare able to cope with multiple tools orif additional staff are required.Project planning should considerwhether there will be a need for a men-tor or one or more domain experts.Early warning of a possible request canreduce the risk of such people notbeing available. They may provide use-ful feedback to the project. Consider -if an expert is needed to help with acrises, would if have been less costly tohave retained them at the start of theproject and perhaps have avoided thecrisis?

14.6 The quality managerJust as the author of a book needs aneditor to help complete the story, thosewho work on models nd it difcult torecognize whether the model continuesto be for purpose, whether the latestperformance predictions are providinga consistent story or include a new pat-tern which needs attention.

237

Good pattern matching skills and eyefor detail are core competencies. A tra-ditional approach is for quality man-agers review reports generated by oth-ers and request clarication from staff.And what if the quality manager didnot have to wait for others? A qualitymanager who uses simulation to reviewmodels and generate reports about themodels breaks a classic dependency.For many simulation tools the skillsnecessary for browsing a model andinvoking a pre-dened simulation canbe acquired in a few hours. Additionaltime is needed to become comfortablewith reviewing performance predic-tions and generating graphs andreports.Productive quality managers will haveev olved strategies for reviewing modelsas well as reviewing simulation predic-tions. They will have strategies toensure that they can track the activitiesof others or track the evolution of mod-els so as to identify points of interac-tion.Just as in nancial markets there is amoral hazard in expecting the qualitymanager to catch and solve all glitches.The quality process only works if oth-ers in the design team take steps toreduce risk as models are initiallydened and evolved.Other chapters in the Cookbook werewritten from the perspective of reduc-ing errors as creating models are easyfor others to understand. Quality man-agers appreciate models that tell a clearstory.One task of the quality manager is tobe a champion for the exploration of

value added issues. This requires track-ing the progress of the project andensuring, where possible, that there istime available for speculative explo-rations.Efciency gains in planning and modelgeneration should be directed at freeingup time to live with the model andexplore its performance and thus betterunderstand how it works.Typically the quality manager will havea list of classic questions and issues toexplore within the model.• If there is an early peak Monday

demand is it possible to use an opti-mal start regime?

• Is there excess heat stored in thefabric of the building overnight?Check if a night ventilation purgeor extending the running hours ofthe environmental control systemwill correct this.

• Are conference rooms subject torapid overheating if the room hasfull occupancy? Test is massivepartitions dampen temperatureswings and improve comfort?

• Does the environmental controlsshort-cycle. Check if reducedcapacity will correct this.

• Is the building over-capacity interms of heating and cooling?Check how many additional hoursover the set point occur during aseason with a 5% reduction andcompare this with the reduced capi-tal and running costs.

The table that follows illustrate someof the issues that confront quality man-agers.

238

Core issue Related issue ActionsIs the current projectsimilar to a pastproject?

Is there valuable infor-mation in the projectnotes and documenta-tion?Do staff remember use-ful/critical issues fromthat project?

Discuss ndings with the teammanager as well as the simula-tion staff.Review the past models with theteam and identify critical issuesto be tracked in the currentproject.

Are there design issuesin this project which arenew to the simulationteam?

What might be validapproaches?Can a simple modelsupport explorationsprior to full scale imple-mentation?Should the mentor becalled in?

Review criteria used to identifybest approach.Find out who needs to worktogether to test the approach.Conrm points in the work owwhere interactions with thequality manager are needed.

What naming schemewill clarify the model toothers in the designteam?Is the client visually ori-ented or number ori-ented?

Does the client talkabout the project usingphrases that could beembedded in the model?Are the essential differ-ences in model variantscommunicated by thenaming scheme?

Conrm if the simulation toolcopes with the naming scheme?Consider whether manufac-turer’s names for products areappropriate.Conrm which performancedata presentation form matchesclient preferences.

What documentationhas the client provided?

Does this documenta-tion identify issues to beresolved prior to workstarting?

Conrm what client documenta-tion should be incorporated inthe model.Advise on who should embedthis documentation.

Does the client require arecord of the tasksundertaken and themethod(s) used?

Are staff keeping a logof actions, assumptionsmade and informationsources used?

Show the model to a third partyand see if they understood theessential attributes of the model.

Does the model con-tinue to reect the ini-tial plan?Are there resourcesavailable for valueadded explorations?

Does the actual com-plexity of the modelmatch the initial plan?

Investigate if delays in taskscould make it difcult to keep tothe plan.Ensure updates to the modelhave been broadcast.Outline value added issues thatneed to be discussed.

239

Core issue Related issue Actions

The model predictionsindicate 15% less heat-ing capacity - is this anerror or is this an oppor-tunity?

What changed in themodel?Who made the changeto the model?Who can corroboratethe difference?

Identify other performance datawhich could be inuenced bythis change.Investigate further changeschange to the model to furtherimprove performance.

During checking it wasfound that occupancy inseveral rooms was lessthan specied.

When did this happen?What performance datacould be at risk?What design decisionsmight be at risk?

Check wither the planned occu-pancy density or the modeldetails are correct.Review how predictions changewhen the occupancy is updated.Broadcast the changes.

The project is slightlyahead of schedule whatdo we do now?

Where are opportunitiesfor making the designwork better?What is likely to be thenext issue that the clientwill ask us to consider?

Revisit the assessments lookingfor performance improvements.Investigate modicationsneeded to explore new topics.Employ a focused model tocheck if an alternative approachworks better.

14.7 Simulation staffTraditional deployment of staffinvolves junior staff primarily workingto create models, run assessments andextract performance data under thedirection and guidance of senior staff.There is a place for novices in a well-formed simulation team and there arevaluable tasks they can perform if theyhave access to a mentor and there isfrequent and close supervision.Senior staff often provide oversight andmentoring. There are also times whenit is cost-effective to inv olve seniorstaff in the creation and evolution ofmodels. It is certainly the case thatsenior staff will notice patterns in per-formance predictions which will leadto value-added deliverables. And one

of the best ways to pass on such skillsis to ensure that others in the team areable to observe this magic happening.The critical issue for successfuldeployment is to complement thekeyboard skills of staff with domainknowledge, pattern matching skills andrisk recognition skills.Inexperienced staff are unlikely toappreciate the dependencies within thesimulation tool (between differententity types and between differentassessment domains). They may mis-interpret the jargon within the interfaceas well as the instructions given bysenior staff.Experienced staff must continuallyremember that:• their knowledge about thermophysi-

cal relationships that guide theirdecisions abut modelling and their

240

use of simulation tools many not beknown by others

• their successful navigation of simu-lation tool facilities and interfacesrelies on assumptions and relation-ships that others might not yet know

• their imagination of a time-line oftasks required to reach a particularsimulation goal will probablyrequire quite a bit of effort to trans-late into clear instructions whichothers can act on

• their instruction may be taken liter-ally

Pattern matching skills are mentionedas one of the up-skilling goals. Patternmatching skills can be acquired andthey are useful for a range of tasksfrom detailed model checking to modelcalibration and testing of design ideas.Its part of everyone’s job. It is implicitin many simulation tasks and workingprocedures can clarity what to look forthe tool interface, model contentsreports (see Section 15.9) as well as inperformance predictions.• There is a surface labeled re-door

which is made of the same construc-tion as the laundry room door - isthis possible?

• The operational documentation men-tions a computer server but theschedule indicates considerable offhours - which one is correct?

• Shading patterns were calculated forall ofces on the west facade exceptfor oor three. Did we miss some-thing?

• The heating demand peak duringstartup is four times the value duringthe rest of the occupied period. Is

this expected? Are there alternativeswe should explore?

• The simulation time for the last setof assessments took only half thetime of the prior assessments - didsomething change?

Risk recognition takes many forms andprovides many opportunities to com-promise or enhance deliverables. Thereare dozens of points during a simula-tion project where a reality check isneeded and dozens of possible triggersthat staff can be trained to notice.• The time taken to accomplish a task

is out of expected bounds.• The fourth step of the standard pro-

cedure involved a system crash. Thiswas attempted a second time andalso failed.

• The predicted comfort (or other per-formance metric agreed for theproject) in the meeting room haschanged.

• The performance of the cooling (orother environmental control) is notwhat we expected

• The southwest corner ofces on thefourth and fth oors are performingvery differently

• One of the pattern matching listexamples (above) was noticed.

There is a considerable overlap in pat-tern matching and risk recognition.Pattern matching often involves thediscovery of relationships - if we seekey word W in an error message thenwe forgot step X; if the shape of theheating demand profile looks like thisthen Z; if the largest heat loss path inthe surface energy balance is north

241

facing windows then investigate Y.Experienced simulationists will recog-nize these patterns. They might assumethat others will also notice such pat-terns and conclude (inappropriately)that silence from junior staff is a signthat progress is as expected.To avoid the perfect storm mentionedearlier, ensure that simulation staff areable to buy-into the goals of the projectand encouraged to creatively evaluatedirectives and provide feedback as pat-tern matching and risk detection trig-gers are noted.The following table includes typicalissues which confront simulation staff.

242

Core issue Related issue ActionsWhat preparation isneeded for this project?

Are we clear about theclient’s ideas that themodel should conrm?Have we done similarwork in the past?Do we have test modelsfor this building type?

Meet with team manager toreview client requirements.Sketch likely approaches to themodel and review with the teamReview past projects and iden-tify if one can be adapted.Review past models for use intesting ideas and techniques

What analysis facilitiesare required to supportthe project?

What running cost/con-trol issues?What comfort/air qual-ity issues?Are thermal bridges anissue?

For each domain identify whatneeds to be measured.Dene the level of detailrequired.Identify likely interactionsbetween domains.

What model calibrationapproaches are appro-priate

Which best-practiceperformance indices?Can a previous projectact as a benchmark?What operational andclimate conditionswould be a good test?

Review standard literature andpast reports.Consult working procedures forsuggested tests.Identify climate pattern(s) andoperational characteristics to usein tests.Embed appropriate simulationdirectives in the model.

How much time will ittake to create themodel?

Is there a record ofresources from similarprojects?Is this a crank-the-han-dle or exploratorymodel?What staff would workwell in this project?What staff productivitycan be assumed?

Review past projects with teammanager.Plan a series of proof-of-con-cept models as a benchmark.Review with mentor.Review required tasks withstaff.Ask staff for time estimates forpreparation and model creationtasks and review with the teammanager.

243

Core issue Related issue Actions

What model variantsmight be needed?

What other questionsmight the client pose?Is the current model atthe edge of the toolfacilities or staff skills?Are changes directed bynew information pro-vided or are they gen-eral parametric varia-tions?

Discuss what other topics mightbe addressed with variants ofthe current model.Estimate resources needed toincrease or decrease the resolu-tion of the model.Review current model complex-ity in each domain and discuss.Use a test model to conrm au-tomation facilities or scripts.Report ndings to team.

What zoning patternshould be used in themodel?

What is the distributionof occupancy patterns?What portions of thebuilding are sensitive tothe facade?What variants of controllogic might be used indifferent sections of thebuilding?Is stratication anissue?Is cross-ventilation orair ow between roomslikely?

Using separate overlays sketchout regions for occupancy (den-sity, schedules), control (logic,schedules), perimeter sensitivity,air ow connections, systemtypes and control-ability.Unify the sketch overlays forinitial ideas.Work out an alternative sketchof zones taking into accountlikely future issues.Sketch scenarios for air ownetworks and revise zoning toaccommodate.

14.8 The mentorDifferent groups have different deni-tions of mentor:• A person who has mastered the

simulation software and helps staffto become comfortable with fea-tures which tend to be viewed aseither magic or where dragons live.

• A person who has undertaken sim-ulation projects of the scale, com-plexity and mix of domains whichare being considered by the simula-tion group (to provide guidance).

• A person who knows the physics ofa design issue and who works witha team to help dene strategies andevaluation criteria (e.g. a domainexpert).

• A person retained to carry outextended training within the simu-lation group, typically to assist theteam to enter a new market or workwith different types of clients.

Mentors may be part of the team orconsultants who are retained by theteam via a support agreement (X hoursover the next 3 months). Skill sets maybe focused (e.g. they know how to

244

design and deploy air ow networksfor large spaces) or broad (e.g. theyhave managed and/or delivered similarprojects).Sometimes simulation teams engage amentor to explore new topics orexplore an alternative way of workingwithin an active project (and want tolimit their risks). In such cases men-tors usually are given the authority totake over tasks being carried out bystaff if that is what is required to guar-antee deliverables.In other cases a mentor may be on-callfor brief consultations because theirexperience allows them to quicklyanswer questions or demonstrate atechnique. This could be done in per-son or via a video conference.One rapid approach to evaluating simu-lation methods (and tools) is to identifya recent project and explore one or twoissues in the project via the use of sim-ulation. Participants would then com-pare what simulation delivers with theprior ndings in terms of resourcesrequired, skills needed as well as acomparison of predictions.Recent projects are especially good ifstaff remember the approach they tookand have access to the underlyingproject data. The mentor can bothguide the simulation team and helpthem to understand the predictionsfrom simulation.The following table includes issuesfrom the point of view of the simula-tion team and from the mentor’s pointof view.

245

Core issue Related issue ActionsTeam: The project start-ing next week involvesX. We hav e limitedexperience - how shallwe proceed?

Is this a topic that thementor deals with?Who needs to beinvolved in the discus-sion?Do we upgrade or useour standard approach?

Specify the issues, points ofconfusion, time frame andgoals.Identify staff to work with thementor and clarify their goals.Dene upgrade or discard pol-icy.

Team: Fred is not satis-ed with how he workswith facility X.

Is this in the interest ofthe group to improvethis skill?Does the mentor handlethis issue?Is this issue dealt withvia a standard trainingcourse?

Check if this caused delays orerrors.Check if new skills will free uptime for other activities or helpother team members.Get time/resource estimate frommentor and check for time scaleand cost of the vendor’s course.

Team: time estimateswere out by 30% in thelast project. Is there adifferent approach thatwould work better?

What does the mentorneed to understandabout the group in orderto evaluate that project?What methods could beuse to test alternativeapproaches?

Create a synopsis of the projectfor review.Review synopsis with designteam and get initial feedback.Re-enact the project to identifyfaultsIdentify relevant staff.Agree a timetable for review, re-enactment and work sessions.

14.9 The domain expertWhen the primary concern is to solve atechnical issue or evaluate performancesimulation teams often retain the ser-vices of a domain expert. The domainexpert may know little about thespecics of the simulation tool but willlikely have strong opinions about theinformation used to dene the entitiesassociated with their specialty as wellas opinions of what they expect to seein performance prediction graphs orreports.The domain expert differs from thementor in that the goal is to solve or

understand a project based issue ratherthan adapt the teams working practicesor improve staff skills. Teams mayhope that the domain expert will supplya disinterested second opinion for acontentious issue within a project orhelp verify that current predictions arein line with expectations.The domain expert may also have anopinion that their approach and theirown software are the only possibleways to deal with a specic issue. Ifthere are several valid approaches theninteractions with the expert canbecome complicated. They may or maynot provide information in support oftheir approach or let others vet their

246

software.The other classic point of confusioncomes from the imbalance in informa-tion and communication skills. Theissue which lead to the expert beingcalled is so normal and obvious to thedomain expert that they may stumble intheir explanations to others who do notshare this knowledge.If the suggested approach is valid andthe simulation tool does not supportthat then there are several options:• check to see if the simulation tool

can be adapted• check if the simulation tool can

approximate the approach suggestedby the expert

• introduce another tool into theproject

• subcontract the work to the expert• if the project is dependant on this

issue being resolved and it cannot beresolved within the time or resourcelimits of the project consider with-drawing

The following table includes severalscenarios related to experts:

247

Core issue Related issue ActionsThe expert and the teamuse different terminol-ogy.

Are both we talkingabout the same issue?Is the terminology dif-ferent because there is adifference in the under-lying approach used bythe expert and by thesimulation tool?

Show the expert a list of com-mon denitions of the jargonused within the group andwithin the simulation tool.Arrange for a meeting to discussunderlying methods and termi-nology.

The expert asks to knowhow the simulation tooltreats a specic issue.

Is the information avail-able?Is it in a form which canbe understood?Is there an examplemodel which demon-strates this issue?

Scan the source code for rele-vant blocks of code or pass thequestion to the software vendor.Scan the documentation for rel-evant sections and/or ask thesoftware vendor if there is addi-tional documentation.Set up a session to explore rele-vant models to conrm if a) theexpert understands, b) the expertagrees with the facility withinthe software.

14.10 InfrastructureMuch of the productivity of simulationexperts comes from a combination ofquick access to information as well asclear clues as to its tness for purpose.Take away ether speed or clarity andproductivity suffers.Simulation relies on access to a rangeof descriptive data about entities in thebuilt environment. These are typicallyheld in databases that the simulationtools access but which are composed ofmanufacturers product data, testreports, site surveys, extracts fromjournals and reference books.Typically, only a portion of this infra-structure comes packaged with thesoftware. Much of the value-added for

simulation groups is in extending thisinitial store of data. There is an up-front investment to understand what isinitially available followed by populat-ing the databases with data relevant tofuture projects and then periodicupdates and extensions.In groups where a suite of simulationtools is used the tasks associated withinfrastructure management must takeinto consideration the degree of overlapwithin each tool’s infrastructure as wellas tool specic differences (which canbe subtle). Consider whether there is abusiness case for minimizing differ-ences between tool infrastructures.What we choose to include in our datastores is critical. Criteria for the qualityand pedigree of data under considera-tion for inclusion must be dened. And

248

how we name these new entries and thedocumentation we embed is also criti-cal.The introduction of simulation into abusiness process or a research groupthus requires initial decisions on howsupporting data is acquired, evaluated,modied to t group naming and docu-mentation standards. Procedures forhow data is committed into the infra-structure and then managed on a longterm basis must be agreed.Thus, one of the initial points-of-dis-covery for a new simulation tool is thenature and extent of its in-built data-store. Commercial software tends to bewell populated with entities. And thesemust still be subject to evaluation,adaptation and management.Establishing quality criteria is one ofthe primary tasks of the Quality Man-ager. Every thermophysical attribute orcomponent detail is, to some degree,subject to uncertainty. Some datasources are incomplete, for examplesurface solar absorption may beapproximate. At a minimum, assump-tions and omissions should be docu-mented (even if this is external to themodel). The Quality Manager is alsothe primary point of contact for stafftasked with data entry.Determining whether an entity in thedata store is t for a use in a particularproject may require input from seniorstaff and management. In extremecases further physical tests many berequired.Simulation is also relies on a computa-tional infrastructure. And most groupsassume that this is robust until it provesotherwise. The otherwise is sometimes

random (e.g. a disk failure) and some-times is predictable (someone did notkeep a safe copy of their work). Bothhave antidotes.Decide how many person-hours or per-son-minutes are acceptable as a loss ateach stage of the design process andadapt the computational infrastructureand working practices (habits) toreect this. And the next step is tosecretly back up a model or a computerand then stage a failure and notice howthe group and its infrastructure recov-ers.One can be creative about the deploy-ment of computational resources.Model creation tasks tend to be boundby the users speed of interaction ratherthan the power of the computer. A highquality monitor may be more importantin model creation than computingpower. A fast disk and extra memory islikely to be the critical during assess-ments and for data recovery tasks.

14.11 Support staffContributions from technical and cleri-cal staff are an integral part of the in-frastructure of simulation groups andshould be included in the scope ofworking procedures. There are a num-ber of tasks associated with acquiringand committing data (e.g. materials andcomponents) which support staff canmake valuable contributions.Groups should consider which is likelyto result in a robust infrastructure: ad-hoc data entry by simulation staff (whomay be distracted or may have notdone this task for several months) orstaff trained to follow well-documented

249

work ow with specic QA proce-dures?Other simulation tasks also followestablished procedures and require aspecic set of skills. An examplewould be the production of an ani-mated sequence of solar shading pat-terns on facades and specic internalspaces via a visual simulation tool suchas Radiance. If done on an ad-hoc basisby simulation staff there is a risk thatsteps may be skipped or incorrectparameters entered. The resulting ani-mation will not be to the expected stan-dard and valuable time will have beenlost. A well trained technician whodoes such work regularly may be a bet-ter choice for such tasks.Another acquired skill is the review ofmodel contents reports in conjunctionwith the Quality Manager. For eachsimulation tool these reports tend tofollow a xed format and include keywords which are recognizable. It isthus a reasonable task to ask supportstaff to search to the inclusion orabsence of specic words and phrases.For example, if a room schedule is doc-umented with the phrase one teacherand 24 students with one laptop com-puter then there is a limited range ofsensible and latent loads to be found inthe data lines that follow. The initailtask is to note the inconsistency. Thefollow-up task might be to suggest datawhich better matches the description oran alternative description whichmatches the numbers.Delegation of such tasks can improvethe work-ow of the group. Delegatinga task rst requires someone to payclose attention to and document

successful actions and assumptions.The word pedantic is an appropriatedescription.This is followed by an iterative processof testing and clarication of the proce-dure until it is t for deployment. Sup-port staff will need to be trained in theprocedure and given sufcient time tone-tune their skills. A good indicatorof successful deployment is when tech-nical staff start suggestingimprovements to the procedure.Delegation also implies that the groupwork-ow is re-designed to merge sup-port staff contributions into the designprocess. Both the Project Manager andQuality Manager will be involved inthis step in order to carry out realitychecks and broadcast their availability.

14.12 Staff productivityGiven the same simulation tool, thesame computer type and the samebrief, two different simulation staff canuse radically different times to arrive ata completed model. What a novice canproduce in a frustrating two days, sea-soned staff can produce in ˜two hourswith a computer which is half as fast.Such differences in productivity areexpected and should be factored intothe stafng of a project. A tight time-schedule may be best supported byusing more experienced staff whereasthose with less experience will be morecomfortable with a project with lesschallenging deadlines.When two staff with roughly the samecapabilities take radically differenttimes for the same work then thisshould trigger a closer look. Chances

250

are the biggest difference will be thestrategies employed. Strategies can belearned.If possible, the quality manager shoulddevise task sequences to conrm theskills level, strategies and inventiveresources of staff.Simulation staff who are working at thelimit of their skills are less efcient andmore likely to generate errors than staffwho are well within their competencelevel. Therefore, a well formed work-ing procedure ensures that staff areworking at a pace that is sustainable.Simulation staff should be clear abouttheir current productivity and informmanagement if they are at risk.Staff who are adept at creating modelsare not necessarily good at noticinginconsistencies in their models. Accessto another pair of eyes is essential.This may involve the Quality Manageror a review by a technician who hasbeen trained to identify inconsistencies.It is a challenge to match resourcesactually used with assumptions madein initial planning. One major contri-bution of simulation staff to the plan-ning process is to provide realistic esti-mates of time and computationalresources. Keeping notes about thetime actually taken for specic tasksshould be included in working proce-dures. Frequent updates to estimates asreal data becomes available can help inthe management of staff resources.What about time estimates for new (tothe group) tasks? One could guess andrisk under or over bidding. Or the sim-ulation team can devote some of itsresources to anticipating new topicsand tasks by compiling background

documents, creating exploratory mod-els and undertaking mock projects.Simulation staff should be pro-activeand request time (say 2-3 hours aweek) for speculative explorations andkeep others informed of progress.Remember, it is just as valuable toreport a tool facility that is not readyfor use as it is to discover an additionalmeasurement which can be included inreports.

14.13 Tool selectionThe limitations of a single simulationtool have been outlined above. A simu-lation based group has greater exibil-ity if there is the option to select from asuite of tools to nd the best mix offacilities for the current assessmenttask.Selection criteria is project specic aswell as specic to the stage in thedesign process. Begin by carefully con-sidering the nature of the project aswell as the project goals. Answer thequestions posted in Table 1.1 andsketch out (roughly) your ideas for amodel. For each simulation tool judgeit against the following criteria:• Site resolution (the form and scale of

the site). Does the tool allow you dodescribe the impact of adjacentbuildings and topography? Areweather data and local wind pres-sures available? your sketch?

• Spacial resolution (the form andscale of the building and spacesinside). Does the tool support thecomplexity found in your sketch?

251

• Thermophysical resolution (the com-position of the building and itsresponse to changes in boundary andinternal conditions). E.g. if thebuilding has massive constructionsor uses phase change materials doesthe solution technique support this?

• Environmental systems resolution(the composition of the systems andcontrols). Does the system(s) repre-sentation match the needs of theproject? Is it possible to approximatethe buildings control logic?

• Occupancy, lighting and small powerresolution (the temporal distributionof internal gains). Is is possible torepresent the interactions betweenoccupants and the building e.g. man-ual controls?

• Computational support for theassessment domains required in theproject e.g. if details of airmovement is of interest is CFDavailable, if comfort is of interest isthere a in-built model of comfort?

• Do the computations produce thekinds of performance data (e.g. typeof data, location of data, frequencyof data) to allow the design team tojudge project performance?

• Do you have the necessary support-ing information (databases of mate-rials, constructions, optical proper-ties, system components etc.) neededto represent the project in this simu-lation environment?

• During the life of the project whatadditional performance questionsmight arise? Does the tool supportassessments for these issues and arestaff skills appropriate?

• If other simulation environments orreporting tools are being used in theproject are there established commu-nication routes for information topass between the tool suites?

• Are there sufcient resources in theproject to allow this simulation suiteto be used? Are staff skills appropri-ate for this mix of project require-ments and simulation tool require-ments?

14.14 SummaryA well formed working procedure willensure that staff are working at a pacethat does not exhaust their mentalreserves. This suggests that all mem-bers of the team should be clear abouttheir own level of competence and howmuch reserve capacity they hav e. Andthey should not keep this a secret andthere need to be communication chan-nels for such issues.It is a challenge to match resourcesused for generating and testing modelswith assumptions used in initial plan-ning. With experience, simulation staff,mentors and quality managers can giveclose estimates of the amount of timethey expect to take.Well formed working procedures willensure that before a bid is given to theclient there is an evaluation as to thetness of the suite of software toolsavailable vis-a-vis the likely demandsof the project. There will also be anevaluation of the current skills level incase preparatory work is required.

252

Chapter 15

MODEL QUALITY

15 Model Quality

Simulation teams who are attemptingto deal with real designs in real timeare confronted by the need to ensurethat their models are syntactically cor-rect as well as semantically appropriatefor the project.Simulation teams who thrive inv estconsiderable passion in ensuring thequality of their models. They do so tolimit risk (a traditional reason for QAand QC). The Cookbook also advocatesworking practices that provide earlyevidence of opportunities to deliveradditional value to clients.Model quality involves both the facili-ties of the simulation tool and the skillsof the simulation team. Among themost important issues are:• designing models that the simulation

team can understand• designing models that clients recog-

nize• identifying faults in models that syn-

tax checks fail to recognize• working practices that ensure inbuilt

tool checks are used regularly• working practices that keep the qual-

ity manager in-the-loop• working practices that ensure cali-

bration checks• understanding model contents

reports

Semantic checking is related to thedesign of the model - how it includesand excludes thermophysical aspects ofthe design. Because it is an art as muchas a science it is more difcult to estab-lish rule sets for model design. Herethe issues are:• models (or tools) that are not quite fit

for purpose• models which continue to be used

after entropy has set in• models which are stuck in an unus-

able state

15.1 How can the vendor help?The quality of models begins with thefacilities offered by the software ven-dor e.g. QA reports, documentation,training and in-built software checks.Vendors decisions about in-built facili-ties have a substantial impact on theresources that simulation teams investin model checking.Some vendors believe what you see iswhat you get. Unfortunately, what yousee on screen is only one of many pos-sible views of the contents of a model.Here are some examples of optical illu-sions:• A wireframe view can look correct

but hav e reversed surfaces or miss-ing surfaces

254

• A clever interface may decide tomerge adjacent surfaces together - sowhat is reported is not the same asthe user dened.

• Interfaces may decide to subdividesurfaces or components so that themodel includes entities that the userdid not ask for.

• The user may dene a compactdescription which the tool expandsinto hundreds of entities which aredifcult to understand and evenmore difcult to adapt.

Some software (including ESP-r) pro-vides both information on the screenand model contents reports. Multipleviews of a model allows those withgraphic interpretation skills and thosewith report interpretation skills to worktogether to spot inconsistencies.A good model contents report is a)human readable and b) reect anychange to any entity within the model.Simulation tools are imperfect and thussome entities may not be reported,some reports may be opaque or includea insufcient detail. Ideally, toolsshould allow the user to dene the levelof detail for various reported entities aswell as which topics to include.As mentioned earlier, independentactions by multiple users cause clasheswhich are difcult to resolve. If amodel is working and some action byanother person causes a fault, con-dence can be badly affected.Of course tools may be imperfect intheir implementation of this concept:• Some interfaces (like ESP-r) con-

strain the length of entity names.Terse names are a frustration and

occasional source of error.• Some interfaces assign names auto-

matically and do not allow them tobe changed - unique but arbitrarynames can be opaque to the user.

• Some interfaces do not allow usersto name entities within their models- this is unforgivable in terms of theresources required for model check-ing.

Knowing that simulation tools limit ourability to create self-documenting mod-els it is for the community of users toev olve working practices which com-pensate for such limitations.

15.2 Responsibilities within simula-tion teamsDecisions made by team members asthey plan and build models can inu-ence the resources needed by others tounderstand both the intent and thecomposition of models. Some modelstell a good story and thus we canquickly use our newly acquired under-standing. Other decisions result inmodels with impose a considerableburden on the design team. Makingclients work hard is NOT a protablebusiness strategy.When the client arrives and the modelis opened up on the computer screen isthere recognition, perhaps after a quicktour, and then a move to substantiveissues. Or are there puzzled expres-sions and the meeting gets hijacked byexplanations of how the image on thescreen represents their design.This is not an argument for a literaltranslation of CAD data into a thermalmodel. Much that is included in CAD

255

drawings is simply noise in the thermaldomain. A client who saw a simulationmodel with fty thousand surfaceswould be justied in asking for themethodology behind this approach toabstraction just as if they were told abox represented the Guggenheim inBilbao.Consider what simulation looks likefrom the clients perspective andchoose, if possible, design the model tolimit their confusion. It may save time.Second Cookbook quote of the day:

Self-administered QA brings greatjoy to someone else’s lawyer.

Simulation teams of one are viable inthe long term only if they outsourcemodel checking. In a team it should bestandard practice to outsource the taskto another team member after initialchecks are made by simulation staff.Changes in stafng can require thatmodels be passed to others in the teamfor completion. Models risk becomeorphans if the author of the modelworks in isolation or uses a differentstyle. A model that is opaque to some-one in the team is likely to be evenworse for a client.The task of taking another personsmodel and understanding it wellenough to make modications to it is aclassic test of working procedures.Projects go quiet for weeks at a time. Ifa substantial resource is given over togetting back to speed on a dormantproject this could lessen the resourcesavailable for other tasks. It does nothelp that the design of simulation soft-ware rarely takes into account thatmany teams are working on several

projects simultaneously.Model quality issues are different foreach participant in the simulation team.

Team managerThe team manager has in interest inensuring that models are t-for-purposeand that staff are working within theirlimits (and the limits of the tool). Amodel which tells a good story is onewhich the manager can more easilybrowse. And managers who regularlyreview models can anticipate possibili-ties as well as notice deadlines slip-ping.

Quality managerJust as the author of a book needs aneditor to help complete the story, nei-ther the team manager nor simulationstaff are in a good position to carry outthis task.The quality manager also has an inter-est in regular reviews of the work inprogress as well as ensuring that themodel continues to be t for purpose.Quality managers quickly recognizemodels which tell a good story fromthose that do not. Good working prac-tices ensure that simulation staff getthis feedback regularly.Even with good working practiceserrors become embedded within mod-els. Some typographic errors that getpast tool checks will evidence them-selves in the predictions of perfor-mance if we are paying attention. A10KW casual gain in a room which issupposed to have 2KW may not showup as a temperature difference if theenvironmental control has an oversizedcapacity. The review would have to

256

notice the reaction of the environmen-tal control for this zone differed fromother similar spaces. If the only reportgenerated was a total for the buildingthen this change might not be noticed.Some errors can be subtle - selectingthe wrong type of glazing for one win-dow out of a dozen windows mightalter performance of the room onlyslightly. The logic of a control whichfails for an infrequent combination ofsensed conditions may be difcult tospot.Failure to check for site orientationprior to undertaking shading analysiscan waste valuable time just as failureto notice that re doors may beinstalled with fail-safe closing mecha-nisms (that allow mixing betweenzones) can alter assumptions aboutventilation in buildings.The simulation team should considerthe frequency and types of error canexist without altering the patterns ofperformance to the point where a dif-ferent design decision is made. Checksby simulation staff are likely to spotsome types of errors but others onlybecome apparent by their impact onpredictions.There are benets in the quality man-ager being pro-active in the project andusing simulation tool facilities toreview models, generate model con-tents reports and review performancepredictions. Such investigations neednot be a burden in time or computingresources. The skills necessary forusing the tool to carry out these taskscan be acquired in a few days.Another pro-active task is to workclosely with others in the team to

ensure that model quality is a continu-ous part of the model planning and cre-ation process. The quality managermight also devise task sequences toconrm the skills level, strategies andinventive resources of simulation staff.The denition of the quality processused in the Cookbook places emphasison identifying opportunities as thework progresses and here a pro-activequality manager can take a primaryrole. The quality manager can also be achampion for reserving projectresources for the exploration of valueadded issues.

Simulation staffThe traditional deployment of staffinvolves junior staff primarily workingto create models, run assessments andextract performance data. The criticalissue for model quality is self restraint.Accepting default names for entitiessaves a few seconds but requires thatothers expend effort each time theybrowse through the model or look atperformance reports.Simulation staff are continuously mak-ing decisions and assumptions. Forexample - a quick decision to go withthe standard concrete oor thickness inthe database rather than conrming theactual thickness in the model might bevalid approach at the time. It becomesproblematic if it persists and the deci-sion is forgotten.Unconstrained keyboard skills ofnovices can wreck havoc. Novicesneed active support from others whohave more evolved opinions about thethermophysical nature of buildings andsystems. If those with opinions take

257

the time to pass on ideas then noviceswill be better placed co-operate whenthey start their work.Topics that experienced users may for-get that novices do not know are:• Information required from the client

at different phases of the work• Benets and drawbacks of different

tools, time and computationalresources for different tools.

• Ideas about how design issues mightbe represented

• Ideas about zoning strategies andlevel of detail

• Ideas about past models to reviewSimulation staff should spend 2-3hours a week exploring new workingpractices or generating scripts to auto-mate processes. This investment mayresult in better procedures and bettermodels.

Domain experts and mentorsThe domain expert will likely havestrong opinions about they see in per-formance prediction graphs or reports.Subtle patterns may be easy for them torecognize.The trick is to get the domain expert toalso look at the model and the perfor-mance predictions with a view of fur-ther tweaks that could be made toimprove performance or to conrm thatthe prediction is in line with expecta-tions.Mentors can play a pivotal role inenabling staff productivity and ne tun-ing working practices that ensure clar-ity in models. Prior experience withsimilar projects may allow the mentor

to be among the rst to identify wheremodels are providing unexpectedresults.Mentors engaged to explore new topicsor explore an alternative way of work-ing will likely be part of the teamupdating procedures and helping toadapt simulation tool facilities.

Musical chairsIn another section of the Cookbook itwas suggested that occasional rotationof tasks within a simulation team canbe useful. Rotation of quality assurancetasks has several benets:• A fresh pair of eyes can notice in

seconds what has been evading oth-ers for hours.

• Conversations needed to conrmwhat is this are instructive for bothparticipants.

• An appreciation how differentdesigns of models impacts modelchecking tasks can result in bettermodels.

15.3 Model planningThere are many steps between a simu-lation model that looks like a CADmodel and a simulation model that issimplied beyond recognition. Thethermophysical nature of a space whichis reasonably represented by one hun-dred surfaces is not ten times better if athousand surfaces are used. Andbecause increasing complexity requiresmore than a linear increase in resourcesmuch thought is required to arrive at anappropriate model resolution.This said, a small increment in modelcomplexity may provide sufcient

258

visual clues so as to reduce the effortneeded to understand a model. Modelsthat clients recognize help them to buyinto the process and it often simpliesreporting requirements. This might beas simple as including visual placeholders for columns and desks orincluding a crude block representationof adjacent buildings.Other aspects of model design are cov-ered in sections 1.4, 2.3, 3.3 and 4.1. Ineach of these sections the emphasis ison the planning stage and working outideas in sketches rather than on thekeyboard.

Entity namesA tool might be just clever enough toname the 27th surface in the zonewhich is vertical Wall-27. The authorof the model knows the surface is thepartition_to_corridor and probablyknows several other attributes of thesurface. The interface presents the ini-tial guess for editing, ve seconds oftyping would make this clear. Accept-ing the default forces everyone else towork hard to understand what Wall-27is each time it is selected from a list orincluded in a report. It also slows downtheir use of selection lists and reducesthe time delay and error if the wrongitem is selected (or deleted).The Cookbook quote of the day is:

Names are the rst step to under-standing and essential to owningideas.

Names like hmeintrt_1 might bederived from horizontal mass elementintermediate floor type instance onebut almost no one else will appreciatethis baggage. If a client talks about

room 1.12b then use that name in themodel.The second Cookbook quote of the dayis:

attribute names rst and followconsistent patterns

Recording assumptionsAs we create and evolve simulationmodels we make dozens of seeminglytrivial decisions and assumptionswhich soon pass from our memory. Ifthese are not recorded there can beadverse impacts. One of the drivingforces for software development is toensure that the internal data model ofthe simulation tool has space availableto record decisions and assumptions.The existence of a dialogue forexplaining the intent of an occupancyprole does not ensure that it is used.The quality manager has an interest inself-documenting models and workingpractices should set standards for howdecisions and assumptions arerecorded.

PlaceholdersEntities in simulation models requirelots of attribution and the informationrequired may not be available whenrequired. The use of place holders fordata not yet conrmed (e.g. creation ofan approximate construction in thedatabase) is a valid way of continuingto get work done. Working proceduresare needed to ensure that such prag-matic actions are followed up and themodel is updated as better informationbecomes available.

259

Who does such updates, the frequencyof reviews, and decisions about whoneeds to know that changes have beenmade are all items to include in a well-ordered working procedure.

15.4 ComplexityThe evolution of software now allowssimulation teams to create modelswhich are closer approximations to thebuilt environment and these modelsoften involve a lev el of complexitywhich would not have been contem-plated a few years ago. Our attempts tocreate better models is tempered by ourability to manage such models.One of the unexpected problems withsoftware which is designed to be bothuser friendly and over-functional is thelevel of self-restraint needed to createmodels which match the needs of theproject. Facilities intended as produc-tivity aids can easily seduce the userinto an overly complex models.Those who are unprepared for com-plexity multiply their workload as wellas the risk that errors and omissionswill go undetected. Preparationincludes the evolution of working prac-tices in projects of increasing complex-ity. Another investment is to allow staffto gain condence in projects ofincreasing complexity. Clarity in thedesign of models reduces the attentionrequired for many tasks and is essentialwithin complex models.Ensuring that the model is correct is,for many practitioners, the critical limiton the complexity of their models.Reviewing a literal representation of ahospital complex with hundreds ofrooms to certify the correctness of

thousands of entities is, at the least, aniterative task. Each iteration focuses ona different aspect of the model and/orits performance.Spot checks are a useful step in ensur-ing the quality of models. Quality man-agers will develop techniques for scan-ning model contents reports as well astechniques for reviewing the modelform and composition with the toolinterface.A classic point of failure is to allocatetime for reviewing model contents butnot for commissioning assessmentsdesigned to identify semantic errors.Techniques that hi-light semantic errorstend to focus on short period assess-ments where patterns in the operationalregime and boundary conditions shouldresult in expected patterns of response.Finding expected patterns is usuallycause for celebration. The risk is incutting short our multi-criteria assess-ments because we are in a good moodrather than concluding the assessmentswhen we have reached a holistic under-standing of the design.In addition to evolving skills and work-ing practices to cope with complexity,successful simulation teams also areable to recognize when complexity canbe avoided. During model planningconsider whether a design must be rep-resented as one simulation model orwhether it can be sub-divided. Sub-division can take two forms - multiplemodels which combine to the whole ofthe building and models which containa selected portions of the building.There are cases where a fully explicitrepresentation is required - for examplein a naturally ventilated building where

260

air ow patterns are widely distributed.In many buildings there is considerablerepetition and little to be gained bydescribing all rooms. The techniquerequires that the constrained modelembody both the typical and excep-tional elements of the design. Selectingwhat can be omitted from a model is acritical step in the planning process justas determining scaling factors is in thecalibration phase. And the benets canbe considerable and many simulationgroups use such scaling techniques intheir projects to conserve the resourcesneeded to create, run and extract datafrom their models.Another technique to re-allocateresources for semantic checking is toemploy scaling techniques to theassessments carried out. Limited dura-tion assessments (e.g. typical fortnightsin each season along with extremeweeks) which are carefully scaled canresult in predictions that are very closeto predictions of brute-force annualsimulations. This technique is espe-cially important for simulation toolssuch as ESP-r which are disk intensiveduring the simulation and data extrac-tion phases.

15.5 Multi-criteria assessmentsAs mentioned elsewhere in the Cook-book, time gained by good workingpractices can provide a reserve of timeto explore model performance. Themore complex the model the moremulti-criteria assessments are essentialfor discovering unintended conse-quences of design decisions as well aserrors and omissions within the model.

So where might one begin the processof gaining condence in a model? Wellfounded opinions as to what should behappening within the building (oraccess to such opinions) is a rst step.This may take the form of informationfrom similar projects, tabular data inhandbooks, access to a mentor orexpert or to measurements in this orsimilar buildings.The next step is familiarity with toolsand techniques for extracting perfor-mance data in forms which clarifywhat is happening within the virtualphysics. In workshops for ESP-r, thetime allocated for exploring model per-formance tends to be at least as long asfor the model creation tasks. Bothinteractive inv estigative skills and theautomation of data extraction are partof the process. The following listincludes some useful indicators:• the range of dry bulb temperatures in

each zone and the time of the maxi-mum and minimum AND frequencybins to conrm the number ofextreme occurrences

• the difference between dry bulb andmean radiant temperature and ifextreme do further checks for sur-face temperatures

• the range of heating and coolingdemands and time of peak occur-rence AND a frequency distributionof demand

• the number of hours heating andcooling is required AND the numberof hours when zones are oating inthe dead-band

• casual gains in each zone either asstatistics and as a plot to conrm if

261

lighting is switching as expected• graphs of zone temperatures and

zone environmental controls to see ifan optimal start or stop might beuseful, if there is heat stored in thebuilding overnight or if a modularsystem might be appropriate

• statistics and graphs of solar enteringthe zones to conrm that windowsthat look like they are facing northactually do face north

• when a zone catches your attentioncheck its energy balance for the typeof heat transfer associated with biggains and losses

The time of occurrence is mentionedabove because a peak temperature dur-ing ofce hours may be very differentthan a peak temperature when no one isin the building. Frequency bins arementioned because a peak demands fora dozen hours in a season may not be agood indicator of system capacity andextreme temperatures that are rare maybe amenable to demand-side manage-ment.Experts will also re-run transition sea-son assessments without environmentalcontrols or with reduced capacity forenvironmental controls. Why? Becausebuildings can often be comfortablewith little or no mechanical interven-tion. The traditional focus on systemcapacity tends to ignore performanceduring the hundreds of hours of mildconditions that happen in most regions.A few moments to create a model vari-ant to conrm this can result in signi-cant value to the client.Another trick of the experts is to gatherstatistics for the occupied period as

well as at all hours. Why? Becauseattention to after-hours performanceprovides clues for improving thedesign of the building and its operatingregime.Some simulation tools such as ESP-rcan be driven by scripts to automate therecovery of the data mentioned above.There are two common approaches:• recording the keystrokes used during

an interactive session into a scriptsto automate subsequent checks

• dening an Integrated PerformanceView (IPV) for the model and usingthis to invoke specic assessmentsand recover the multi-criteria data.

The use of scripts is covered in an Ap-pendix of the Cookbook as well as inthe Automation section in a subsequentpage of this chapter. Setting up an IPVis a topic not yet included in the Cook-book.

Working at the edgeMost experts plan their work and theirmodels to avoid the computational andcomplexity limits of their tools. A fail-ure to anticipate the likely course of theproject is a classic way to run short onoptions.ESP-r is compiled with specic limitsof model complexity and it is worthchecking what the current limits areduring the planning stages. It may benecessary to re-compile ESP-r if youwant different limits (there are alterna-tive header les available for differentmodel resolutions that have beentested). The Install Appendix providesinformation about this. Some simula-tion tools are written to allow models

262

to grow in complexity without havingto re-compile, and there are still limitsthat knowledgeable users avoid.Models which have been extendedtowards the limits of the simulationtool reach a point where productivitycan suffer and where dependencieswithin a working model can be brokenand errors introduced. There are manypossible vectors for this, some involveactions by the user and some can begaps in the logic of the software.Caution and paranoia are useful atti-tudes. Backup the working model as arst step. Generate a full model con-tents report and extract a range of per-formance data for use in comparisonswith the revised model. Talk to othersabout their experiences of managingcomplex models and for advise onwhere simplications can be madebefore altering the model. Plan thesequence of tasks, make frequent back-ups, carry out calibration runs on therevised model and check these againstthe initial performance predictions.In addition to the overhead of workingwith large models there is a cost incomputing time, generation of largeperformance data sets as well as thetime needed to recover performancedata. Each simulation tool and dataextraction technique tends to have apoint where the burden becomesnoticeable. Users dependant on Excelfor data presentations typically test thelimits of column and rows in tables.XML documents tend to become slowto parse and graphs can becomeunreadable.The ESP-r is disk intensive. Dataextraction gets progressively slower as

result les approach one Gigabyte andcan be unstable after that point. A largeproject with a dozen design variantsand ve minute time steps can take amorning if not a weekend to process.Thus, the design of the model and thedesign of the assessments and datarecovery tasks are topics to be consid-ered in the planning stages of theproject.Some projects may require a computeserver or several workstations to pro-vide timely information to the designteam. The option of larger disks andmore memory can help reduce the timefor data recovery tasks. To see whichapproach is most appropriate carry outtests on an existing model of similarcomplexity.Entropy is a word that begins todescribe parametric studies. So much isinvested in setting up a base casemodel that can be adjusted to reectthe various design variants. If after test-ing and running the scripts the wholeedice can be destroyed by demands toalter the base case and re-run theassessments.ESP-r has the exibility to be used forparametric work but the distributed lestructure can make it difcult to makeglobal changes to dozens of modelsand the potentially hundreds of lesthat support such models.

AutomationUsing a simulation tool interface toapply multiple changes to a model canbe frustrating. Some users hack theirmodel les and some use scripts to per-form parametric changes to models.While such actions can save time they

263

are also a potential source of subtleerrors if dependencies are not resolved.Some practitioners make fewer errorsthan others when creating model vari-ants. A critical review of the order ofthe tasks and the checks that were doneto limit errors resulted in a createmodel variant facility within ESP-r.As seen in Figure X, the user whowants to create a model variant selectstopics from a list and the code deter-mines the related dependencies andmanages the model les so that subse-quent changes do not corrupt the initialmodel.ESP-r includes functions to search andreplace instances of a specic construc-tion within the model or to alterattributes of surfaces associated with anamed list (also called an anchor list).There are also functions to rotate ortransform the model which requiresthat a number of dependencies be man-aged. Other global changes to modelsmay require editing of model les by asequence of manual tasks or the use ofscripts.Experts tend to test their scripts on aduplicate of the model or a portion ofthe model prior to use. In all cases theworking procedure should insure thatthe altered model is scanned by the toolto see if errors are detected. It is also agood idea to generate a new modelcontents report and compare that withthe initial model.Some parametric changes require morethan a substitution of key words andnames in model les. For example,removing a surface requires that manyrelationships within the model be re-established. It also results in

calculations for shading patterns andview factors becoming obsolete.Simulation tools are designed trackthese dependencies and attempt toresolve them. A user generated scriptmight have difculty duplicating all ofthe tasks. Consider whether the scriptmight be re-written to invoke the toolinterface to carry out these tasks.In many cases the logic within the toolcan be generalized so that the sameaction that is carried out interactivelycan be driven from an alternative inter-action or command line directive to thetool. Because scripts can be fragile anddifcult to maintain it is worth check-ing with the software vendor to see if itis possible to revise the tool to supportsuch modications. For open sourcetools such as ESP-r there are manyoptions for evolving the code toaccomplish standard tasks.

15.6 Semantic checksIdeally we design models to be nomore and no less complex that isrequired to answer the current designquestion. If we are clever our modelwill also be designed to answer thenext question the client will ask. Amodel which is overly simple may failto represent the thermophysical natureof the design. A model which is overlycomplex absorbs resources which maynot be sustainable.Thus we need to design tests to deter-mine whether the model represents theessential characteristics of the designand is likely to deliver information atacceptable condence levels. One formof question follows the pattern: build-ings of this type tend to XX when YY

264

happens- If heating stops at 10h00 on a sunny

cold winter day we expect to see thelittle immediate change but perhapsa gradual drop in temperature until15h00 when solar radiation levelsdrop.

- If cooling stops at 15h00 on a hotday we expect an immediate rise of3°C and then a slow rise until about20h00.

- During a Monday morning startupafter a cold weekend we expect tosee full demand for 2.5 hours fol-lowed by a drop to about 40% ofcapacity when the set-point has beenreached.

- If we double occupancy in the con-ference room we expect the coolingsystem to cope for one hour and thenthe heat absorbed in the walls shouldcause comfort to degrade.

- If we constrain heating capacity by15% we expect a half hour longer towarm up and to nd eight hoursbelow the heating set-point duringthe month.

These questions are based on expecta-tions of a specic circumstance. Theexpectations might be in the form of apattern description, a statistic or a fre-quency of occurrence. Whether we areable to write down an expectation inadvance or are able to construct anopinion as we look at the performancepredictions or are unable to make asemantic judgement is largely a func-tion of background and experience.This points to one of the reasons thatsimulation is difcult for students.They are only beginning to form their

ideas about how buildings and systemswork and their pattern matching skillsare also in development. Conversely,well designed virtual experiments canbe an excellent learning tool for stu-dents. They hav e access to the thermo-physical state of everything at eachmoment of time and by changing a fewnumbers they can undertake anotherexperiment and look at the differences.Guidance for students is essential (anda critical weakness in the provision ofsimulation). It is also endishly dif-cult to design a good virtual experi-ment. The good news is that patternmatching skills can be acquired.The typical form of question involves ascenario dened in terms of a fewhours or days (one exception involves amonth). A graph or report covering ashort period is quick to produce and itsdensity of data is more manageable andthus it is possible to overlay other per-formance data to see what else is hap-pening at the same time or just beforeour point of interest.Missing from the above list are ques-tions ending with "we expect 29.5kWhr/metre square/year heating".Why. Firstly, it implies an annual simu-lation. We want to delay computation-ally intensive checks until we havegained condence in other aspects ofthe model. Secondly, what is beingmeasured is derived from the perfor-mance of dozens if not hundreds ofentities and their interactions. Areported value matching our expecta-tions does not necessarily bestow con-dence in the underlying entities. Anunexpected value provides few clues asto the underlying cause but does

265

present us with a massive pile of datato sift through. Again, lets rst focuson performance indicators with fewerdependencies.The task for the simulationists is todesign a virtual experiment which willallow us to see if predictions matchexpectations. Some of the questionsrequire a step change to be introducedinto the model and some questionsimply a base case assessment and asecond assessment run with someaspect of the model changed. Of coursewe will keep a copy of the unalteredmodel so that we can continue withstandard assessments after the semanticchecks have been run! Of course wewill remember to include in our modelslabels that will remind us of whichsemantic check we are working on andto clearly identify which graph orreport fragments are associated withthat test!Some semantic checks can be carriedout by reviewing the client’s questionsand considering the underlying physicsinvolved. If, for example, the design issensitive to the distribution of solarradiation within rooms then a reviewwould usefully look at the pattern ofsurface temperatures during the dayvis-a-vis the distribution of radiation.A design goal to make best use of solarenergy for heating while controllingsummer overheating will likely requirecareful attention to geometric resolu-tion and the constructions which areused. To nd out if additional geomet-ric resolution (e.g. subdividing wallsand oors) yields better predictionsthen the same room can be representedby three zones at different resolutions.

What is learned from this exercise canbe applied to the full scale model.If control of blinds was also includedthen switching patterns would also bechecked. But in this case it may be nec-essary to compare against the sameroom without the blind control. Indeed,to clarify the impact of ideal zone con-trols or system component control avariant model without the control orwith a simple control is often the mostefcient approach and working proce-dures should ensure that such modelvariants can be quickly created or aremaintained as the work progresses.The result of a semantic test might bethat the model is predicting a pattern ofperformance for that scenario that is agood match with out expectations. Bril-liant. Do other parts of the buildingexhibit this same pattern? Is this some-thing to tell the client about? With eachscenario is increasing condence in themodel, adding to our understanding ofhow the design performs and if thatperformance is in line with the initialideas of the design team. Because theissue is focused it is possible to convertour newly acquired understanding intoa story which is easy to deciminate toothers.The result of a semantic test might alsobe confusion. What was see is not whatwe expected and the task evolves intodetermining if our expectations wereill-founded, the model does not, in fact,support this kind of assessment, themodel includes errors, or if our virtualexperiment has yielded some newinformation and a new pattern for thedesign team to understand. Methodsfor dealing with this are covered in

266

Chapter X. Clearly the resourcerequired will be some function of thecomplexity of the model.If a simulation team is confronted witha new kind of building or system andanticipates the need for rigorous syn-tactic and semantic checks then there isa business case to be made for workingprocedures that highlight expected orunexpected performance as early aspossible and with the least resourcesconsumed as possible. Focused initailmodels and focused semantic checksare one way to conserve projectresources.With a general tool such as ESP-r thereare usually several possible designs ofthe model. In the planning stage aseries of constrained models of differ-ent approaches can be created to iden-tify the most promising approach.Some simulation teams will have arange of test models available or willhave procedures for setting up testmodels. The working practices chapterrecommends that simulation groupsinvest in exploratory approaches and inthe creation of models for testingfuture design process issues.An example enabling a suite of modelsto test sensitivity is the sequence ofmodels in the technical features groupof exemplar models distributed withESP-r. These represent the same pair ofcellular ofces and a corridor at differ-ent levels of resolution and with differ-ent simulation facilities enabled.A semantic check may also be trig-gered by an unexpected performanceprediction.• Why is this room several degrees

warmer than expected?

• What is the largest heat gain to thespace? When is it happening?

• What else is happening at the sametime or just before this?

Professor Joe Clarke introduced theidea of causal chaining of energy bal-ances in the early 1990’s. It involvesidentifying the dependencies impliedby a thermal event and working backdown the dependency tree to isolate theform of energy transfer, which if cor-rected, will alter the initially noticedthermal event.Models which have evolved manytimes in response to changes in designfocus may include details which are nolonger relevant or at an in appropriatelevel of detail. A critical review may bein order to determine if a fresh startwill be more productive than furtherrevisions. Another classic point toevaluate a fresh start is when the clientposes a new what-if question.The resources required to carry on witha not-quite-t-for-purpose modelshould be judged against the cost ofdesigning and implementing a modelfor the new design question or para-metric study.An example is the quality of light inrooms. Generating daylight factors toroughly assess whether the back of aroom will be perceived as dark is avery different question than is thereglare at the head of the conference ta-ble. Daylight factors are much less sen-sitive to the geometry of the facadethan the requirements of a glare assess-ment. One is essentially independent oftime and the other is both position andtime dependant.

267

Hardware and human gremlinsThink of simulation models asprisoners of war which have aduty to escape (or at least ruinyour weekend).

There are countless ways for models tobe rendered unusable because of cor-ruption, inconsistencies or lost les.Phrases like - I was going to backupthis evening compete with I was onlytrying to make the model work betterand there was a power spike becomepart of the folk history of every simula-tion group. The intensity and durationof the disruption which follows isdetermined by the robustness of ourworking practices.Making backups is not rocket science.It is amazing how a delayed holidaybrought on by a disk crash can changework habits to the point where the lossof a half hours work is considered afailure within the group.For every type of computer and operat-ing system that ESP-r runs on there areutility applications available to createarchives of model folders. InUnix/Linux/OS X systems commandslike tar cf brox-burgh_18_apr_contol_a.tarbroxburgh will put all the les andsub-folders of broxburgh into an ar-chive le. On Windows it is usually amatter of a right click on the modelfolder to create a zip le. Each simula-tion group will have its own namingscheme for such les as well as rules asto where these les are stored.The frequency of backup dependspartly on the imagined hassle of repeat-ing a particular set of actions as well asthe state of the model. The following

are classic trigger points for makingbackups:• when a zone becomes fully attrib-

uted• prior to making a model variant• prior to a search and replace opera-

tion• prior to a transform or rotation• prior to a change in control strategy• to record the current state of the

model prior to a review• when someone with electrical test

gear is seen in the buildingAnd backups can be focused on one ortwo les which are related to an issuebeing tested. A quick test of reducingthe cooling capacity in one zone of thebuilding would start with making abackup of the current control, altering afew values in the control denition,running a test and then recovering theinitial state of the control. Differentgroups adopt different styles of lenaming conventions and the logs of theactions taken and reverted.One issue which is much debated iswhether model archives should includeresults les. Some groups includethese, some compress such les priorto archiving and some groups includein the archive scripts and directivesneeded to re-generate results les.ESP-r models can include pre-denedsimulation parameter sets and manygroups build their working proceduresaround such facilities.

15.7 Team ChecklistsThe following table includes some ofthe issues to notice when working with

268

simulation models. Roughly, the orderbegins at the start of the work. Clearlythere are scores of topics which couldbe added to this table.The form of the table is to pose a gen-eral issue in the left column and pro-vide a list of associated topics or ques-tions in the middle column and relatedactions in the right column. The Cook-book uses terse phrases and onlyincludes a sub-set of related actionswithin these tables. Consider this as astarting point and create verbose ver-sions of the tables in this chapter andextend the topics as new situationsarise and as working procedures forspeculative future work is contem-plated.

269

Question Related issues ActionsWhat is interestingabout the site?

What do we know aboutthe site?Does the client realizethe importance of thesite?Is the north arrow onthe site plan?How might site issuesconstrain the design?How might site layoutbe used to improve thedesign?

Check the site plan and area maps.Find out which way is north.Review photographs or visit the site.Check site solar and wind obstruc-tions.Check principal wind direction andwhether vernacular architecture takesthis into account.Collect local opinions of the site.Discuss with design team options foradjusting the building on the site.If orientations may vary ensure nam-ing regime avoids confusion (e.g.avoid north_entrance).

What weather data isappropriate for the site?

What climate data isavailable near the site?What patterns ofweather will impact thebuilding design?How hav e other build-ings adapted to the localweather?What are the designteams ideas about theinuence of weather?

Review climate data to establish sea-sons, typical periods and extremeperiods.Review climate data for useful build-ing failure test sequences.Review climate data for duration ofextremes as well as the frequency ofmoderate weather patterns.Discuss with design team the resultsfrom initial review of weather.

Is the design evolvingor static?

What drawings orsketches can we access?Are there plans, sec-tions and elevationsavailable to review?Are the drawings likelyto change?What is the design teamdebating now and whatare likely future topics?

Review drawings or CAD les andgather comments from simulationstaff and quality manager.Check that the drawing scale is rea-sonable and if details might inuencethe design of the model.Discuss the level of detail requiredwithin the team.Arrange a meeting with the designteam and present sketches of plannedmodel and likely approaches.

270

Question Related issues Actions

What is the compositionof the building?Are the goals of theproject consistent withthese constructions?

Are construction detailsknown?What what-if questionsrelate to constructions?Are these typical forthis building type?Do we have sources formissing data?What criteria for rejec-tion of constructions?

Review standard databases for match-ing constructions and/or SIMILARconstructions.Create place holder constructions anddocument. Review sections and dis-cuss with design team.Discuss support for selecting appro-priate constructions.

How is the buildingused?Is the building for aknown tenant or is itspeculative?How are rooms likely tobe occupied at differenttimes and seasons?

Does the client have anwell-formed opinionabout the building use?Is building occupancyan issue for future-proong?Is there seasonal diver-sity as well as dailydiversity?

Check the assumptions made by theclient.Quantify likely scenarios.Consider diversity, holidays and peakuse occurrences.Check past models for similar pat-terns.

What is the clients bigidea?What kind of modelwould conrm thisidea?What are others in thedesign team interestedin?

What performanceissues are related to thebig idea(s)?What analysis domainsand metrics of perfor-mance will conrmthis?Can beliefs held by thedesign team be con-rmed?

Listen to the language used andreview sketches to identify beliefsbehind the big idea(s).Identify issues and determine if theycan be assessed.Review available tools to check formatches in numerical capabilities andreporting facilities.Brief the design team on the approachto be taken and the likely informationto be derived from the assessments.

In-built Tool checklistsThe internal checks which simulationtool interfaces support typicallyinclude issues such as is this polygonflat and does the construction attributepoint to a correct entity in the databaseand does the boiler have a non-nega-tive capacity.

Tool checks are not likely to ag a sur-face named door which is composed of150mm of concrete or which is hori-zontal. It is unlikely that doors are hor-izontal or have a concrete constructionattribute. Unlikely can happen andusers are in the best position to noticethis.In addition to checks in the interface,further scanning of the model may bedone by the simulation engine. If the

271

simulation engine scan passes then itbecomes possible to move from syntaxchecks to semantic checks based onpredicted performance (see sections15.6 and 15.8).Criteria for frequency of syntax checksshould be included in the working pro-cedures. Typically these would happenduring the evolution of the model aswell as after simulations have been run.There are techniques for reducing thetime taken for checks. Incrementalchecks are well supported by lookingat the differences against an earlierreport and software for hi-lighting thedifferences between two les orbetween two folders is readily avail-able. The use of pattern search tools(i.e. grep) can identify key words inmodel contents reports.The table that follows illustrate someof the issues. Use this as a startingpoint for generating your ownresponses to issues as they arise and forplanning future tasks.

272

Core question Related issue ActionsWhat changed sinceversion 1.3?

Who is working on themodel?What tasks are theyinvolved in?Does this match thework plan?

Consult the work log or the log ofactions generated by the tool.Generate a model contents report andsee how this differs from the previousreport.Check with the quality manager andsimulation staff about current status.

The client wants to testa different roof type

Which parts of themodel are affected?Is information availableon the new roof?What performanceissues might change?What tasks are requiredand which staff shouldbe involved?Is this a model variantor an edit of the existingmodel?

Update the constructions database ifrequired.Generate a model contents report, ar-chive the current model and perfor-mance predictions.Create model variant if required.Apply changes, generate model con-tents report, check against previousreport, re-run calibration assessmentsand review.Archive the revised model and briefthe client.

The interface says’problem edges’ in con-ference zone.

Is there a missing sur-face?Are there edges whichdo not follow the rulesused in the tool?Is there one or morereversed surface?

Look at the wire-frame for missingsurface labels.Use the check vertex topology optionfor a report.Turn on surface normal arrows toreview orientation of surfaces.Check for vertices linked to only onesurface.

The ceiling void iswarm and retaining suf-cient heat to cause amorning cooling issue.

Under what operatingregimes and weatherconditions is this hap-pening?What are the primarygains within the ceilingvoid?Is it possible to removeheat from the ceilingvoid?

Carry out checks under differentweather patterns.Review the energy balance in the ceil-ing void.Review how boundary conditions arerepresented and the state of adjacentzones.Test different operating regimes todetermine sensitivity.Force a brief purge of heat from theceiling void and check the whether(and how long) it takes the conditionto re-establish.

273

15.8 Simulation outputsIn simulation the time when the fatlady sings is most often after the simu-lation has been run and the team isexploring the performance predictionslooking for the story to tell the rest ofthe design team.Some simulation groups generate thesame report irregardless of the project.Such poor value for money is largelythe fault of the client for not makingtheir needs clear or not having suf-cient experience to know the variety ofdeliverables that a simulation team canprovide.It is only natural that simulation staffhave their preferences for the graphsand tables that are included in reports.However, the goals of many projectsare multi-criteria and working patternsneed to be established to ensure that arange of performance issues are testedand taken into account in reports to theclient.Gremlins enjoy watching us nd pat-terns we expect, declaring success andthen having someone else discover thechaos. The risk of unintended conse-quences can be reduced by multi-crite-ria assessments and by different peoplewith different agendas attempting tounderstand the predictions.This is not a new issue. ESP-r has longincluded the concept of an IntegratedPerformance View (IPV) where a num-ber of performance issues are identiedat the planning stage and recorded inthe model so that recovery of multi-cri-teria assessments can be automated. Atypical range of metrics would be

comfort, system capacity, energy useover time, emissions of carbon dioxide,distribution of light in rooms and thenumber of hours of system use. Asimplemented, the IPV is imperfect andfurther work is required to allow risk tothe better managed and opportunitiesidentied.In other simulation tools this could beimplemented by the inclusion of ’per-formance meters’ for a range of issues.The critical step is taking the time earlyin the design process to identify issueswhich may arise as design options aretested.Running well-designed calibrationassessments should usually only take afew moments each so they will focuson typical weeks rather than whole sea-sons. For performance metrics whichare not yet part of an IPV there are stilloptions to automate assessments anddata recovery. A library of standardscripts for extracting performance dataon a range of topics is a useful comple-ment to interactive explorations.The table that follows is a sample ofissues and questions and actions forstaff attempting to understand perfor-mance predictions. Use this as a start-ing point for your own working prac-tices.

274

Core issue Related issue ActionsIs the model still cali-brated?

Have calibration assess-ments been run?Were there enough mea-surements to understandperformance?

Review the criteria for calibrationassessments.Identify measurements which matchexpectations.Identify unexpected measurements andinvestigate further.

Is performance trackingplanning stage expecta-tions?What issues were men-tioned in recent meet-ings?What value addedissues are under consid-eration?

Does the data recoveryscript include theseissues?Do we have trigger val-ues for failure?What other data viewswill complement stan-dard reports andgraphs?Who can conrm theadditional reports?

Explore performance interactively,including a few tangent issues.Get a second interactive review.Follow up issues by looking at depen-dant or related issues.Run test script to conrm data recoverylogic and reporting format is ok. Do spotchecks.Run the full script. Do spot checks andget someone else to conrm.

What if we altered thevision glass?

What products would belikely candidates?Do we have thermo-physical and opticaldata?What criteria would sig-nal better performance?Is performance sensitiveto the facade orienta-tion?

Establish what is available and theclaimed benets.Review data sources or generate dataIdentify glazing-related improvementsDecide where alternative glazing couldbe applied.Implement design variants.Archive model, establish base case per-formance, test substitution and dataextraction procedures.Implement one change at a time andcompare against the base case.Rank the design variants and identifyperformance changes.Get a second opinion.

275

15.9 The model contents reportThis section is a review of the ESP-rmodel contents report. What shouldyou be looking for? What are keywords to scan for? How much detail isavailable? Where is is informationheld? The reports generated by othertools will differ in detail but they willcover many of the same issues. Thoseof you who are constrained to screencaptures of the tool interface can alsocreate rules for interpreting entitiesshown in the interface.The following listings are portions ofthe model contents report for the doc-tors ofce used in the initial chapters ofthe Cookbook. Prior to each section is adiscussion of the contents of the report.After the report fragment is a discus-sion of key words and phrases to lookfor.The user has the option to selectedwhich topics are included in the reportas well as the level of detail includedfor each topic. The example belowused the verbose level for most topics.As mentioned elsewhere, many qualitymanagers will create a hard-copy ofsuch reports and use them in conjunc-tion with the interface when reviewingmodels. One common pattern is forsimulation staff to generate the reportand then insert additional notes andassumptions or highlight blocks of textthat require further discussion and passthis to the quality manager along withthe location of the model.

The headerThe header of the model report focuseson site and high level project relatedinformation. Some of the text is based

on user supplied phrases and otherparts are generated from model dataand le names.The key words for this section are thedate that the report was printed and thename of the model log le (which maycontain useful additions by the user).The rst two lines of the report also arethe place to identify what is differentabout this model. These phrases areused in many places in the interfaceand in reports.The year mentioned in the summarywill have been initially set to matchthat of the climate le. One reason toalter the year is to shift the day of theweek - for example, in 2001 the rst ofJanuary is a Monday.

276

Synopsis

This is a synopsis of the model for training session on Thursday defined inoffice_for_doctor.cfg generated on Fri Jul 30 11:13:01 2010. Notes associatedwith the model are in office_for_doctor.log

The model is located at latitude 55.90 with a longitude difference of -4.10from the local time meridian. The year used in simulations is 2007 andweekends occur on Saturday and Sunday.The site exposure is typical city centre and the ground reflectance is 0.20.

Simulationist name: not yet definedSimulationist telephone: not yet definedSimulationist address: not yet definedSimulationist city: not yet definedSimulationist postcode: not yet defined

The climate is: ESP test climate and is held in: /usr/esru/esp-r/climate/clm67with hour centred solar data.

What to look for in headerThe summary of the site location andthe climate should be checked to see ifthey match the project. Default valueshere may be indicative of a lack ofattention.In the report below the lines identifyingthe building, the building owner andthe simulation team have not yet beenlled out.If the project requires model variantsthen its is really important to considernaming schemes and titles - users in ahurry can easily select the wrongmodel! If you create a model variantcheck that the tiles and documentationhave been updated to reect this.The log le for the model is a text doc-ument which is initially lled in by theinterface when the model is created.Some groups use this le as a place todocument progress on the model.Imagine reviewing a model after sev-eral months. What kind of notes would

you like to nd in order to come backto speed on this project?

The databasesThe next section of the report focuseson databases associated with themodel. Some of these are standarddatabases - the path (/usr/esru) is oneclue or the report indicates that it is astandard database. Databases can alsobe model specic - a path ../dbs. Anddatabases might be located in a non-standard location with a full path give -/home/fred/databases.Databases in the standard esp-r/data-bases folder are initially supplied withthe software. The exemplar and valida-tion models may reference these data-bases as will many user created mod-els. Thus is it important that these data-bases are secure and are only alteredwith due care and attention. Other data-bases can be added to the standarddatabases folder as required or addedto a non-standard location if that ismore convenient.

277

It is up to the group to manage anddocument the databases. Databasesitems should be reviewed and the con-tents should be of a know quality andkept up to date by the quality manager.The le read and write permissions onUnix and Linux and OSX computerscan be used to ensure that these so-called corporate databases are pro-tected from corruption or casual modi-cations. Groups working within aWindows infrastructure will have toimplement their own proceduresbecause it is difcult to prevent corrup-tion or casual modication by users.Databases associated with the modelmay or may not be derived from thestandard database. Typically they willinclude items specic to the model.Such entities may eventually migrate toa standard database (a task for the qual-ity manager). ESP-r has limitations onthe internal documentation of databaseentities. It falls to the simulation teamto supplement the information held inthe model data les and databases sothat they conform to group policies.Each database differs slightly in imple-mentation. Currently the constructionsdatabase contents are the core of thereport. The constructions make refer-ence to items in the materials databaseand if the construction is transparent tothe associated optical properties. Thelayout of the report is similar to thatused in the interface.The constructions part of the report is acombination of numbers and shortlabels. It follows an older format whichlacks clarity for some users. For exam-ple, name of the construction isrestricted to twelve characters and

there are no categories.Until the data structure is revised it isup the user to compensate for the limi-tations in the tool (other tools will havedifferent limitations to compensatefor).

278

Databases associated with the model:standard pressure distr: pressc.db1materials : ../dbs/office_for_doctor.materialdconstructions : ../dbs/office_for_doctor.constrdb

standard plant comp : plantc.db1standard event profiles: profiles.db2.astandard optical prop : optics.db2. . .sections skipped. . .

Multi-layer constructions used:

Details of opaque construction: extern_wall

Layer|Matr|Thick|Conduc-|Density|Specif|IR |Solr|Diffu| R |Descr|db |(mm) |tivity | |heat |emis|abs |resis|mˆ2K/W

Ext 6 100.0 0.960 2000. 650. 0.90 0.70 25. 0.10 lt brown brick : Light brown b2 291 150.0 0.040 12. 1000. 0.90 0.70 30. 3.75 Min wool quilt : Insulation (M3 0 50.0 0.000 0. 0. 0.99 0.99 1. 0.17 air 0.17 0.17 0.17

Int 2 100.0 0.440 1500. 650. 0.90 0.65 15. 0.23 breeze block : Breeze blockISO 6946 U values (horiz/upward/downward heat flow)= 0.226 0.228 0.224 (partition) 0.222Total area of extern_wall is 78.45

Details of opaque construction: int_doors

Layer|Matr|Thick|Conduc-|Density|Specif|IR |Solr|Diffu| R |Descr|db |(mm) |tivity | |heat |emis|abs |resis|mˆ2K/W1 69 25.0 0.190 700. 2390. 0.90 0.65 12. 0.13 oak : Oak (radial cut)

ISO 6946 U values (horiz/upward/downward heat flow)= 3.316 3.682 2.928 (ptn) 2.554Total area of int_doors is 4.20. . .

Details of transparent construction: dbl_glz with DCF7671_06nb optics.

Layer|Matr|Thick|Conduc-|Density|Specif|IR |Solr|Diffu| R |Descr|db |(mm) |tivity | |heat |emis|abs |resis|mˆ2K/W

Ext 242 6.0 0.760 2710. 837. 0.83 0.05 19200. 0.01 plate glass : Plate glass2 0 12.0 0.000 0. 0. 0.99 0.99 1. 0.17 air 0.17 0.17 0.17

Int 242 6.0 0.760 2710. 837. 0.83 0.05 19200. 0.01 plate glass : Plate glassISO 6946 U values (horiz/upward/downward heat flow)= 2.811 3.069 2.527 (ptn) 2.243

Clear float 76/71, 6mm, no blind: with id of: DCF7671_06nbwith 3 layers [including air gaps] and visible trn: 0.76Direct transmission @ 0, 40, 55, 70, 80 deg0.611 0.583 0.534 0.384 0.170

Layer| absorption @ 0, 40, 55, 70, 80 deg1 0.157 0.172 0.185 0.201 0.2022 0.001 0.002 0.003 0.004 0.0053 0.117 0.124 0.127 0.112 0.077

Total area of dbl_glz is 11.55

What to look for in databasesWhen reading the report remember thelayers go from ’other-side’ to roomside. Make a point of comparing the

reported U values with other datasources to ensure that the constructionis properly dened. In the case of ESP-r, a U value is a derived value and notpart of the calculation process. It isalso up to the user to correctly account

279

for the changes in heat transferbetween the centre of glazing and sec-tions near the frame. There are severalapproaches such as using averaged val-ues and using separate surfaces for thecentre and edge of glass but little con-sensus in the community.Constructions which are transparenthave additional entries in the report foroptical properties. This part of thereport includes jargon and a not partic-ularly human readable format. The dataused by ESP-r is more detailed that thatprovided by some manufacturers. Andit does not include some data generatedby optical analysis tools such as Win-dow 5.2 and WIS. ESP-r is not uniquein simplifying some aspects of diffus-ing glass and advanced light re-direct-ing glazing products.Other potential errors might includereference to the wrong database or con-fusion about the contents of the data-base. Several of the exemplar modelsinclude local copies of a standard data-base and maintain the same name asthe standard database. Updates to thestandard database will not be reectedin these derived databases. Converselyif new entities have been added to alocal database care and attention arerequired when incorporating this intothe standard databases to avoid nameclashes.Updates to standard database alsorequire care and attention. For exam-ple, an ISO standard recommended thatfoundation constructions include atleast 500mm of earth. Tw o standardconstructions in the databases wereidentied for upgrading but it was alsonecessary to scan for references to

these constructions in the exemplar andvalidation models distributed withESP-r. For one of the constructions adozen models required updating andthe update needed to include not onlyrefreshing the zone construction lesbut also remembering to update themodel contents reports. A similar pro-cedure would apply to simulationgroups and their own archives of mod-els.Another relationship to check in theconstructions database is between theconstruction and optical property. Athree layer double glazed windowsconstruction can only be matched to athree layer optical property set. For awindow with a low-e coating theimproved performance is representedas an increased resistance in the air gapin the construction denition.An internal (between the glass) blind isoften represented by glass air metal airglass in the construction with opticalproperty sets that allow some radiationto pass through the metal layer. Thusthe metal layer mass is used in the con-struction denition and the opticalproperty tells the simulator what por-tion of the solar radiation passingthrough the construction is absorbed atthe metal layer. An operable blind isusually implemented by altering onlythe optical properties (the mass doesnot move).The thickness of a layer in a construc-tion is often the same as the physicalentity. And there are instances wherethis in not appropriate and where agiven construction may need to be rep-resented in different ways. For exam-ple, a sandstone wall in a castle is

280

700mm thick and ESP-r will complainabout this as it stresses the underlyingnumerical method and limits ourknowledge of the temperatures withinthe wall. A better representation wouldbe four layers e.g. 150mm 200mm200mm and 150mm (assuming the400mm in the centre are rubble and theouter 150mm is faced stone). A simi-lar approach would apply to insulationproducts. Layers of insulation of100mm are preferred.The idea that constructions are com-posed of layers is thermophysicallydefensible for homogeneous construc-tions but requires adaptation for non-homogeneous constructions. A givenlayer (parallel with the face of the con-struction) may be composed of one ortwo repeating materials perpendicularto the face of the construction e.g. insu-lation and structure. In this case theproperties of the parallel layer isderived from the weighted contribu-tions of the insulation and structure. Ifsuch composite materials are to beincluded in a database then it must beclear what materials were used and thepercentages of each.

Zone controlsThe next section of the model report isextracted from the controls dened forzones and/or ow or system networks.The documentation phrases are pro-vided by the user. Next there is a shortsynopsis of what is being sensed andwhat is actuated. This is followed by anautomatically generated synopsis foreach period in the control schedule.The control section of the report is acompromise. The space available for

translating the parameters of eachperiod’s control law is limited andabbreviations are necessary. Some con-trols include jargon used by controlengineers. There are a few controlswhich have almost no translation of thecontrol parameters. Some controlswhich have parameters which includeauxiliary sensor denitions can be con-fusing because the standard report ofsensor and actuator locations does notknow that it has been superseded.Invest time in understanding to howESP-r represents and reports on con-trols so you can spot errors and omis-sions before you run assessments. Thereports may also provide clues if yound the model is not working asexpected.The control portion of the QA reportbelow indicates that the model is prob-ably at an early stage. There is, forexample, no mention of why 2KWcapacity was specied for heating andcooling during ofce hours and 1KWduring the setback periods.Documentation is important for idealcontrols because the sensor actuatorcontrol law pattern used by ESP-r canapproximate any number of physicaldevices. It may be that a later versionof the model shifts from ideal represen-tations to component based representa-tions of environmental controls and ini-tial statements can assist this transition.

281

The model includes ideal controls as follows:Control description:to work with reception occupant 80W with diversity during the day max to400W. Lighting at 150 W during occupied period. 60W equipment duringoccupied period

Zones control includes 1 functions.1kW heating overnight during setback, 2kW office hours to reach 20C set-pointduring office hours. Weekend setback to 10C.

The sensor for function 1 senses the temperature of the current zone.The actuator for function 1 is air point of the current zoneThe function day types are Weekdays, Saturdays & SundaysWeekday control is valid Mon-01-Jan to Mon-31-Dec, 2007 with 6 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 10.0 24.0 0.0

basic control: max heating capacity 1000.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 10.00C cooling set-point24.00C.

2 7.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 20.0 24.0 0.0basic control: max heating capacity 1000.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 20.00C cooling set-point24.00C.

3 8.00 db temp > flux basic control 2000.0 0.0 1000.0 0.0 21.0 24.0 0.0basic control: max heating capacity 2000.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 21.00C cooling set-point24.00C.

4 9.00 db temp > flux basic control 2000.0 0.0 1000.0 0.0 21.0 24.0 0.0basic control: max heating capacity 2000.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 21.00C cooling set-point24.00C.

5 17.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 20.0 24.0 0.0basic control: max heating capacity 1000.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 20.00C cooling set-point24.00C.

6 21.00 db temp > flux free floatingSaturday control is valid Mon-01-Jan to Mon-31-Dec, 2007 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux free floating2 8.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 10.0 24.0 0.0

basic control: max heating capacity 1000.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 10.00C cooling set-point24.00C.

3 19.00 db temp > flux free floatingSunday control is valid Mon-01-Jan to Mon-31-Dec, 2007 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux free floating2 8.00 db temp > flux basic control 500.0 0.0 1000.0 0.0 10.0 24.0 0.0

basic control: max heating capacity 500.0W min heating capacity 0.0W max coolingcapacity 1000.0W min cooling capacity 0.0W. Heating set-point 10.00C cooling set-point24.00C.

3 19.00 db temp > flux free floating

Zone to contol loop linkages:zone ( 1) reception << control 1zone ( 2) examination << control 1

What to look for in controlsWords and numbers must be backed upwith a clear description and an initialcheck should evaluate whether the

282

description given is a good synopsis forthe controls that have been imple-mented. The software does not forceyou to update the description when youare working with control loops so nda way to make this a habit!ESP-r allows control loops to bedened which are not yet referenced inthe model. Users are also responsiblefor assigning links between controlloops and thermal zones. Thus is itpossible that this association is not cor-rect. It is possible that an incorrect linkwill result the the appearance that thezone is controlled and so it is necessaryto be pedantic in inspections of thecontrol listing to ensure that the correctcontrol is used.Control logic is separated into differentperiods in the day. This allows for con-siderable exibility in environmentalcontrols and it also complicates theprocess of proving that controls areworking as intended. Control logicmay also differ on different day types -one typical error is to update controlsfor one day type and not check further.Dead-bands and heating and coolingset-points can be used to ne tune con-trol logic to match the response ofphysical devices. There are caveats -ESP-r is implementing ideal controlsso the time-lags in physical devices isabsent. We might think we know whatis happening in a room thermostat butmost of the time we are guessing.ESP-r does not support auto-sizing soit is up to the user to dene heating andcooling capacity. Sometimes we havethis information but many users juststick in a big number. Imagine what abig number represents to a numerical

engine - a small room with a hundredthousand Watts of heat dumped into itnot something that we would do inreality so it is probably best not to gothere in a virtual world either.Some controls in real life are unstableif not properly tuned and an un-tunedPI or PID controller in ESP-r willexhibit the same patterns. Reserve timefor virtual tuning and be aware that thesame controller may not perform wellin different seasons without re-tuning.Minimal capacity is a concept embed-ded in a number of ideal controls. Theidea is that some wet central heatingsystems tend to have poorly laggedpipes that are exposed in the room andev en if a valve turns off the radiatorthere is still some heat released fromthe piping.

Zone compositionThe next section of the model reportprovides both summary and detailedreports of zone composition. If theattribution in a zone is incomplete thesummary will reect this.The report for each zone reects theverbosity selected before the reportwas generated. Much of the report isbased on information derived fromscanning the form and composition ofthe zone. If the zone is fully attributedthen U-values and UA values arereported for a quick reality check.Note that the derived values may be abit confusing if the zone shape is com-plex - for example if portions of thefacade are horizontal and facing upthen they will be included in the roofarea. Transparent surface that are notvertical may be reported as skylights.

283

ID Zone Volume| SurfaceName mˆ3 | No. Opaque Transp ˜Floor

1 reception 120.0 12 165.5 4.5 40.0 reception has one staff and up to 4 visitors2 examination 60.0 11 86.0 7.0 25.9 examination for one doctor and one visitorall 180. 23 252. 12. 66.

Zone reception ( 1) is composed of 12 surfaces and 26 vertices.It encloses a volume of 120.mˆ3 of space, with a total surfacearea of 170.mˆ2 & approx floor area of 40.0mˆ2reception has one staff and up to 4 visitorsThere is 94.000m2 of exposed surface area, 54.000m2 of which is vertical.Outside walls are 123.75 % of floor area & avg U of 0.226 & UA of 11.195Flat roof is 100.00 % of floor area & avg U of 0.924 & UA of 36.965Glazing is 11.250 % of floor & 8.3333 % facade with avg U of 2.811 & UA of 12.648

A summary of the surfaces in reception( 1) follows:

Sur| Area |Azim|Elev| surface | geometry | construction |environment| mˆ2 |deg |deg | name |optical|locat| use | name |other side

1 12.0 180. 0. partn_a OPAQUE VERT - mass_part ||< partn_a:examination2 9.90 270. 0. partn_b OPAQUE VERT - mass_part ||< partn_b:examination3 9.75 180. 0. south_wall OPAQUE VERT WALL extern_wall ||< external4 21.0 90. 0. east_wall OPAQUE VERT WALL extern_wall ||< external5 9.75 0. 0. north_wall OPAQUE VERT WALL extern_wall ||< external6 12.0 0. 0. partn_c OPAQUE VERT - mass_part ||< identical environment7 9.00 270. 0. west_wall OPAQUE VERT WALL extern_wall ||< external8 40.0 0. 90. ceiling OPAQUE CEIL ROOF roof_1 ||< external9 40.0 0. -90. floor OPAQUE FLOR - grnd_floor ||< ground profile 110 2.25 180. 0. south_glz DCF7671_ VERT C-WIN dbl_glz ||< external11 2.25 0. 0. north_glz DCF7671_ VERT C-WIN dbl_glz ||< external12 2.10 270. 0. door OPAQUE VERT - int_doors ||< door:examination

An hourly solar radiation distribution is used for this zone.Insolation sources (all applicable):south_glz north_glz

Explicit viewfactors have been derived for this zone.Shading patterns have been calculated for this zone.

The list of surface attributes is proba-bly best viewed in conjunction with awire-frame image of the zone. This isone of the places where a welldesigned naming regime will allowinconsistencies to be identied quickly.After the surfaces attributes have beenlisted there may be additional lineswhich identify optional attributes of thezone. In the example above is a noticethat shading patterns have been pre-calculated for the zone as well as radia-tion viewfactors calculated.

Details of the polygons which make upthe surfaces of the zone are notincluded. Users interested in this levelof detail will either have to look at theinterface (where co-ordinates and edgelists are found) or look at the modeldescriptive les.

What to look for in zone reports

Quality managers will scan this reportfor ’UNKNOWN’ attributes. Onemight expect some ’UNKNOWN’early in the model composition. Someusers tend to address attributes one at atime - for example, they might make a

284

pass through the model assigning con-struction attributes, and then make asecond pass attributing the ground con-nection details for foundation surfaces.Frequent re-freshes of the model con-tents report will clearly show wheresuch progress has been made.Another check that is part of manygroup’s work ows is to look fornames that do not match the entity. Forexample, a wall named south_wallmight actually be facing West. Is thisbecause the zone was rotated after thesurfaces were named? If so a betternaming scheme might be front, back,left, right. Differences in names andwire-frame views might also indicatethat a surface has been inverted. In thiscase one would look at the numericalvalue of the azimuth and elevationreported as well as the wire-frame viewof the zone and turn on the draw sur-face normal option.In the column of surface names lookfor duplicate names - this can causehavoc with some functions in ESP-r.Check also that the surface names arefollowing the general rules for namingagreed by the group.The column of optical tags will eitherinclude the key words OPAQ UE orTRAN or the initial part of the opticalproperty name. If ESP-r becomes con-fused or the user is forgetful then sur-faces which you intended to be trans-parent might show up with anOPAQ UE tag. To correct this go to themenu for the attributes of this surfaceand re-select the construction and also,if necessary set the optical propertytoggle. If the problem persists then itmight be that the entry in the

constructions database does not havethe correct optical property.The column of location tags are basedon the orientation of each polygon andare used by some methods within ESP-r. For example, a polygon which isapproximately vertical uses a specicheat transfer regime so it is useful topre-calculate this attribute of the sur-face. The tag also can be useful tag forquick visual scans of the model.The column of surface uses supportsbuilding code compliance rules whichneed to identify specic types offacade entities. As a form of documen-tation surface use tags are also useful.In the future these tags may help auto-mate the creation of ow networks.Currently surface use attributes areoptional so you will often nd this col-umn lled with ’-’ entries.The column of construction namesshould be read in the context of theoptical property name as well as thesurface name. Some users also checkthe location tag. In a well designed andwell composed model these attributesshould reinforce each other and a keypattern matching skill is to learn toquickly recognize discontinuities inthese attributes.The right-most column describedboundary conditions. For partitions thisreport is more specic than the’ANOTHER’ tag that occurs in thegeometry le or the higher levelmenus. Be aware that there are spacelimitations and longer zone and surfacenames may have been truncated.After the columns of surface attributesthe report (if generated in verbosemode) should tell you about extensions

285

to the zone denitions. In the exampleabove there is a note that explicit view-factors have been calculated. Thereport does not include the actual view-factors and it is not clear from thereport whether or not the view-factorsare up to date. To get more informationone must go to the interface for view-factors.

Zone schedulesThe next section of the report focuseson the schedules of air ow and casualgains dened for the zone. First there isthe user supplied documentation andthen the data for each of the scheduletypes.The format of the report is similar tothat supplied in the interface and thus itis somewhat terse. In the examplebelow there is no control imposed onthe air ow schedule and so no infor-mation on the control logic is included.The current version of ESP-r supports aminimum period of one hour so therecan be up to 24 periods in a day. Peri-ods should be in sequence and includethe whole of each day type.Working procedures that minimizeerrors typically enforce matching docu-mentation and data. Numbers may becorrect without being clear as to whatthey represent.The user documentation includes abrief note about the casual gains. Thereis some diversity included in the casualgains for occupants. Lights are a xedwattage as are small power loads. Thedocumentation says computer all thetime but the data is only on duringofce hours. Which is correct? A qual-ity manager would notice that the

radiant and convective split is 50 50 foroccupants and lights and ask for clari-cation.

286

Air schedule notes:one air change all day. reception - up to 3 people, one computer all the timeControl: no control of air flow

Number of air change periods for daytype weekdays : 1Period Infiltration Ventilation From Sourceid Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp.1 0 - 24 1.00 0.0333 0.00 0.0000 0 0.00

Number of air change periods for daytype saturday : 1Period Infiltration Ventilation From Sourceid Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp.1 0 - 24 1.00 0.0333 0.00 0.0000 0 0.00

Number of air change periods for daytype sunday : 1Period Infiltration Ventilation From Sourceid Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp.1 0 - 24 1.00 0.0333 0.00 0.0000 0 0.00

Notes:reception - up to 3 people, one computer all the timeNumber of weekdays casual gains= 14Day Gain Type Period Sensible Latent Radiant Convec

No. label Hours Magn.(W) Magn. (W) Frac Fracweekd 1 OccuptW 0- 7 0.0 0.0 0.50 0.50weekd 2 OccuptW 7- 8 80.0 40.0 0.50 0.50weekd 3 OccuptW 8- 9 240.0 120.0 0.50 0.50weekd 4 OccuptW 9-12 400.0 200.0 0.50 0.50weekd 5 OccuptW 12-14 240.0 120.0 0.50 0.50weekd 6 OccuptW 14-17 400.0 200.0 0.50 0.50weekd 7 OccuptW 17-21 40.0 20.0 0.50 0.50weekd 8 OccuptW 21-24 0.0 0.0 0.50 0.50weekd 9 LightsW 0- 8 0.0 0.0 0.50 0.50weekd 10 LightsW 8-19 150.0 0.0 0.50 0.50weekd 11 LightsW 19-24 0.0 0.0 0.50 0.50weekd 12 EquiptW 0- 8 0.0 0.0 0.40 0.60weekd 13 EquiptW 8-19 60.0 0.0 0.40 0.60weekd 14 EquiptW 19-24 0.0 0.0 0.40 0.60Number of saturday casual gains= 3Day Gain Type Period Sensible Latent Radiant Convec

No. label Hours Magn.(W) Magn. (W) Frac Fracsatur 1 OccuptW 0-24 0.0 0.0 0.50 0.50satur 2 LightsW 0-24 0.0 0.0 0.50 0.50satur 3 EquiptW 0-24 0.0 0.0 0.40 0.60Number of sunday casual gains= 3Day Gain Type Period Sensible Latent Radiant Convec

No. label Hours Magn.(W) Magn. (W) Frac Fracsunda 1 OccuptW 0-24 0.0 0.0 0.50 0.50sunda 2 LightsW 0-24 0.0 0.0 0.50 0.50sunda 3 EquiptW 0-24 0.0 0.0 0.40 0.60

What to look for in zone schedulesAs with controls the documentation ofzone schedules should match the val-ues and an update to the scheduleshould (by habit) include a revision tothe documentation. A review of the

model contents report should ensurethat the documentation is both clearand consistent.The section on inltration and ventila-tion provides both air changes per hourand mˆ3/second values. The latter isderived from the volume of the zoneand thus should change if the room

287

volume changes. Another thing to lookfor in the ventilation section is that thevolume given for ventilation betweenrooms is in terms of the current zone,not the supply zone. It is the usersresponsibility to derive the correct vol-ume for ventilation.The example above indicates eightperiods for occupants on weekdays andit is implied that the changes in valuesare to introduce some diversity into theschedule. The 400W periods areclearly the peak and the peak laststhree or four hours. There is also aramp-up and ramp-down at the startand end of ofce hours. It is assumedthat this is used to represent brief occu-pancy of cleaning staff but it is notexplicitly stated in the documentation.Another pattern to observe is the radi-ant and convective split. It is likely thatdefault values have been used and itmay be worthwhile to ne tune thesevalues. Note that ESP-r uses xed rep-resentations of sensible and latent val-ues for occupants but in reality they aresensitive to the temperature of theroom and the metabolic rate. Thosedoing analysis in temperate climateswithout air conditioning should adaptvalues accordingly.There is also a summary section in theQA report which provides a range ofderived data which have proved to beof use to practitioners. For examplethere are UA values for different por-tions of the building fabric which pro-vide a quick reality check.

288

Project floor area is 65.900m2, wall area is 78.450m2, window area is 11.550m2.Sloped roof area is 17.088m2, flat roof area is 40.000m2, skylight area is 0.00m2.There is 147.09m2 of outside surface area, 90.000m2 of which is vertical.

Outside walls are 119.04 % of floor area & avg U of 0.226 & UA of 17.743Sloped roof is 25.930 % of floor area & avg U of 0.924 & UA of 15.791Flat roof is 60.698 % of floor area & avg U of 0.924 & UA of 36.965Glazing is 17.527 % of floor & 12.833 % facade with avg U of 2.811 & UA of 32.463

What to look for in the project sum-maryThe reported oor area is based on thelist of surfaces associated with the baseof each zone. Occasionally errors occurin this if surfaces have been added orremoved or the oor is sloped. Checkthe values in each zone report.The summary report makes assump-tions when allocating surfaces to par-ticular categories. It is possible thatcomplex zones may not be accuratelyreported. An example is a facadewhich includes horizontal elements.The reported UA values are based onstandard assumptions and might alsobe mis-allocated if their location ismis-interpreted. The intent is to pro-vide a guide for practitioners who alsowork with software that uses UA basedcalculations or include quick UA eval-uations as part of their model qualitychecks.

15.10 SummaryWell-formed working procedures willensure that models tell a clear story tothe design team and that performancepredictions have been reviewed toensure that predictions are within nor-mal expectations and options for better

than expected performance are deliv-ered to the design team.It is a challenge to ensure resourcesused for generating and testing modelsis within the project budget and thatsufcient time and attention is avail-able for exploring value-added issues.A pro-active quality manager is neededto champion such issues.The quality of models is a result ofdecisions made during the planningstage, the design of the model, actionsby members of the simulation team andthe facilities included within the simu-lation tool.The increasing complexity of models ispartly driven by new questions fromdesign teams and by productivity fea-tures in simulation tools but is con-strained by our ability to conrm thatmodels are both syntactically andsemantically correct.The discussions and tables included inthis chapter are intended to be a start-ing point for simulation teams to gener-ate robust working procedures and pro-vide ideas for skills which may be use-ful to acquire.

289

Chapter 16

INSTALL APPENDIX

14 Install Appendix

ESP-r is available on a number of com-puting platforms and this section pro-vides information on how to acquireESP-r pre-compiled distributions or tocheckout one of the current ESP-r dis-tributions from the Subversion reposi-tory.

ESP-r was initially a suite of tools run-ning on Sun workstations and thenwith the advent of Linux running onlower cost personal computers the codewas adapted to also run on Linux.There are a few lines of code whichrequired adaptation for Solaris andLinux platforms and there are almostno differences in user interactions andin administrative tasks.ESP-r implicitly assumes a range ofoperating system services and protec-tions. For example, that corporate data-bases and example models are held infolders where normal users can readbut not overwrite such les. On othercomputing platforms such protectionsare either enforced in a different wayor absent.Note that ESP-r assumes the computerenvironment is using a USA or UKlocale and that real numbers use aperiod as a decimal point and that a

comma, tab or space is a separatorbetween data. There is also a restrictionthat names of entities use an ASCIIcharacter set rather than extended char-acter set. These dependencies arerelated to the underlying Fortran sourcecode read and write statements. ESP-rhas been observed to have problemswith some, but not all Asian keyboardsand locales.Solaris supports an F90/C/C++ compil-ing environment as well as the GNUcompiler collection. The former is par-ticularly useful for development workas Sun supports IEEE oating pointexceptions (e.g. divide by zero) andarray bounds checking (e.g. asking forthe 12th value of an array of size 10).Linux supports the GNU compiler col-lection. Note that recent Linux distribu-tions tend to have version 4.2 of theGNU compilers and ESP-r currentlyworks better with the older 3.4 versionof the compilers. There is also a gen-eral issue with 64 bit computers - thereare slight differences in predictions anda risk of some graphical tasks causingprogram crashes. ESP-r is currentlymore robust when running on 32 bitcomputers.

With the advent of OSX, Apple

291

computers offer many of the samecompilers and low lev el operating sys-tem services as Linux and so it hasbeen possible to port ESP-r to Applecomputers. There are a few minor dif-ferences in operating system services(le name case sensitivity is incom-plete and users folders are found in/Users rather than /home.In terms of use the interface is thesame as is offered on Linux. Because itdoes not follow the full OSX look andfeel rules, some users nd this confus-ing.OSX supports the GNU compiler col-lection as well as X11 libraries andsource code conventions. For develop-ment work it is necessary to install theso-called fink facilities as well as X11support. A full list of requirements canbe found in the ESRU web pages. Thepre-compiled distribution is made on aPPC rather than Intel Apple computer.It has been reported to run on Intelbased Apple computers.

Because of the differences in compilersand operating system services it tooksome time to realize a version of ESP-rthat runs natively on Windows comput-ers. The initial approach to ESP-r run-ning on Windows computers was to usean emulation environment called Cyg-win. Cygwin provides the compilationenvironment required by ESP-r as wellas translating many operating systemrequests and providing a similar com-mand line interpreter (shell scripting)as one would nd on a Linux machine.

Again there few code differencesrequired for development and use ofESP-r on Cygwin. In terms of userexperience, ESP-r thinks it is runningon a Linux box and the same user inter-actions apply.Cygwin supports the usual GNU com-piler collection and X11 graphicslibraries and the development tasks areessentially the same as on Linux. Filepermissions are less strict than Linuxand thus care should be exercised toavoid overwriting les that ESP-rassumes have strict permissions.

The native Windows version of ESP-ris an almost complete port of the facili-ties available on other computer plat-forms. This version works on Windows2000 and Windows XP computers.There has been little or no testing onWindows Vista or on 64-bit versions ofWindows.The underlying graphic libraries cur-rently restrict some functions (this iswork-in-progress). The major differ-ences are found in the facilities pro-vided by the operating system and inthe layout and conventions of the lesystem.ESP-r currently has a limited ability tocope with spaces in le names and italso has limits on the length of lenames. These limit where ESP-r can beinstalled as well as how deeply nestedmodel folders can be before le namesbecome truncated. For this reason, pre-compiled versions of ESP-r aredesigned to be in C:\Esru\esp-r

292

rather than in C:\ProgramFiles\Esru. ESP-r models workbetter in C:\Esru\Models rather thanC:\Documents and Set-tings\Fred\Current Models\

Development for Native Windows cur-rently requires the MSYS collection oftools in addition to MinGW, a port ofthe GNU compiler collection.

Environment variables and filesWhen ESP-r is initially compiled sev-eral types of information are embeddedin the executables (e.g. where ESP-r isinstalled) and other types of informa-tion (e.g. where to nd example modelsand what databases to initially load) isscanned in from text les. One of thesetext les is called esprc and the stan-dard version is assumed to be in theinstallation sub-folder esp-r. Itscontents are listed in Figure X and themeaning of the tokens is presentedbelow.The le is in tag - data, data format.Typically the rst token is a label andthe second token is either an executableto be invoked or the name of a le to beused. To alter this initial specicationuse a text editor and change the rele-vant token as required. Look in thepreferences menu of the ProjectManager to access the details of thisle.The initially created version of theesprc le is held in the ESP-r installa-tion folder. If a user wants a customversion of this le to use they shouldcopy it to their home folder with thename .esprc.• *ESPRC - this is the le type tag. It

must be the rst line

• *gprn - commands associate withcapturing a rectangular section of thescreen. The 2nd token import is theexecutable which captures a sectionof the screen. In this case the esprcle was created with a Linux com-puter and the executable name wouldbe different for a different computeroperating system.

• *tprn - commands associated withdumping the current text feedbackbuffer to le will write to the leidentied in the second token.

• *gxwd - a variant of *gprn but whichcaptures the whole screen.

• *cad - instructions for a CAD tool toinvoke. The second token is theexecutable and the third token is akey word describing the type of leit creates.

• *image_display - commands relatedto the display of model-associatedimages. The second token is a keyword identifying the format of thele and the third token is the nameof the executable to invoke to dis-play that type of image. There canbe several *image_display lines inthe esprc le.

• *journal - turns on a time-stampfacility which logs user actions andthe key words are ON and OFF.

• *editor - which ASCII text editor toinvoke if an external application isrequired.

• *report_gen - not used• *exemplars - the name of the le to

read which includes a list of modelswhich can be accessed and wherethey are stored. The initial contentsof the exemplars le is for use in

293

ESP-r workshops but the contentscan be edited to include other mod-els.

• *validation_stds - the name of a leto read with information needed tocommission standard tests

• *db_defaults - the name of a defaultle which holds a list of initial data-bases. If you want to use an alterna-tive list of initial databases edit thisle or include a reference to an alter-native list of databases.

• *db_climates - the name of a cli-matelist le which holds a list of cli-mate data sets and their location. Ifyou want to use an alternative listedit the le or provide the name ofan alternative le.

Default file assumptionsThe second le which is commonlyscanned when ESP-r modules start isthe default le. The name of this le isincluded in the esprc le. The le is atag - data format and is typically foundin the installation folder. An exampleof this le is listed in Figure 10.2. Notethat the path /Users/jon/esru_prj_devpoints to an installation made for test-ing purposes and this path was gener-ated as the test version of ESP-r wascompiled based on the directives giv enat the time.As with the previous les the name ofthe le is associated with a specictopic and/or dialogue within the userinterface. These dialogues associatedwith specic types of model lesrequire a default name and the defaultle names are scanned in via thedefault le rather than being hard-coded into the interface. The name of

the le can be altered by editing thele.• *ESP-r Defaults - this must be the

initial line of the le.• *ipth - this is the path to where ESP-

r has been installed based on the spe-cic commands given during theinstallation process

• *cfg - this is a default le name for amodel conguration le (useful fordemonstration purposes)

• *ctl - this is a default le name forcontrol loop denitions

• *mfn - this is a default le name foran air ow network

• *dfd - this is a default le name for aCFD domain description

• *res - this is a default le name for azone predictions (results) le. Thisle should be created during theinstall process so that it is easy todemonstrate ESP-r.

• *mfr - this is a default le name formass ow predictions

• *clm - this is a default le name forclimate data. This climate le shouldbe created during the install process.

• *prs *prm *mlc *opt *evn *pdb -these are default le names of data-bases (in case the user request adefault database. Many users willchange the name of the databaseles to suite the needs of their work.This le can be accessed via thepreferences menu of the ProjectManger.

294

*ESPRC*gprn,rectangular dump,import*tprn,Text dump,/tmp/tx_dump*gxwd,screen dump,import -window root*cad,CAD package,xzip,ZIP*image_display,TIF,xv*image_display,XBMP,xv*image_display,GIF,xv*image_display,XWD,xv*journal,OFF*editor,editor,nedit*report_gen,Reporting tool,xfs*exemplars,Exemplars,/Users/jon/esru_prj_dev/esp-r/training/exemplars*validation_stds,Validation standards,/Users/jon/esru_prj_dev/esp-r/validation/stds_list*db_defaults,Defaults,/Users/jon/esru_prj_dev/esp-r/default*db_climates,climatelist,/Users/jon/esru_prj_dev/esp-r/climate/climatelist*end

Figure 16.1 A typical esprc le.*ESP-r Defaults*ipth /Users/jon/esru_prj_dev/esp-r*cfg /Users/jon/esru_prj_dev/esp-r/training/basic/cfg/bld_basic.cfg*ctl /Users/jon/esru_prj_dev/esp-r/training/basic/ctl/bld_basic.ctl*mfn /Users/jon/esru_prj_dev/esp-r/training/basic/networks/bld_basic_af1.afn*dfd /Users/jon/esru_prj_dev/esp-r/training/cfd/template.dfd*pnf /Users/jon/esru_prj_dev/esp-r/training/plant/vent_simple/cfg/vent.cfg*res /Users/jon/esru_prj_dev/esp-r/databases/test.res*mfr /Users/jon/esru_prj_dev/esp-r/databases/test.mfr*clm /Users/jon/esru_prj_dev/esp-r/climate/clm67*prs /Users/jon/esru_prj_dev/esp-r/databases/pressc.db1*prm /Users/jon/esru_prj_dev/esp-r/databases/material.db3.a*mlc /Users/jon/esru_prj_dev/esp-r/databases/multicon.db2*opt /Users/jon/esru_prj_dev/esp-r/databases/optics.db2*evn /Users/jon/esru_prj_dev/esp-r/databases/profiles.db2*pdb /Users/jon/esru_prj_dev/esp-r/databases/plantc.db1*ecdb /Users/jon/esru_prj_dev/esp-r/databases/elcomp.db1*mcdb /Users/jon/esru_prj_dev/esp-r/databases/mscomp.db1*icdb /Users/jon/esru_prj_dev/esp-r/databases/icons.db1*mldb /Users/jon/esru_prj_dev/esp-r/databases/mould.db1*sbem /Users/jon/esru_prj_dev/esp-r/databases/SBEM.db1*end

Figure 16.2 A typical default le.*CLIMATE_LIST*group ESRU standard climates# WARNING: Keep this file up to date with current directory structure !*item*name Default UK clm Climate*aide Climate data as distributed with ESP-r for testing purposes.*dbfl /usr/esru/esp-r/climate/clm67*winter_s 2 1 12 3 30 10 31 12*spring_s 13 3 14 5 4 9 29 10*summer_s 15 5 3 9*winter_t 6 2 12 2 20 11 26 11*spring_t 17 4 23 4 2 10 8 10*summer_t 3 7 9 7*avail ONLINE*help_startLocation is 52.0N and 0.0E. The solar radiation is Direct Normal.Month Minimum Time Maximum Time Mean

295

Jan -6.4 @20h00 Sun 8 12.7 @14h00 Sun 29 3.8Feb -1.9 @ 5h00 Tue 14 12.2 @13h00 Thu 2 5.2Mar -0.8 @24h00 Fri 31 16.1 @15h00 Tue 21 6.8Apr -1.9 @ 2h00 Sat 1 19.4 @15h00 Mon 17 7.1May 0.0 @ 3h00 Wed 3 22.7 @14h00 Thu 11 10.4Jun 5.0 @ 2h00 Fri 9 21.1 @15h00 Tue 6 13.6Jul 9.4 @ 3h00 Mon 3 27.7 @12h00 Mon 17 18.0Aug 7.7 @ 4h00 Sat 5 24.4 @12h00 Tue 1 15.6Sep 5.0 @ 6h00 Thu 21 22.2 @12h00 Tue 26 13.5Oct 2.2 @ 5h00 Mon 30 19.4 @13h00 Sat 7 10.8Nov -0.8 @ 5h00 Mon 27 14.4 @14h00 Sat 11 5.2Dec -4.2 @ 1h00 Sat 9 12.7 @ 9h00 Sat 23 3.8All -6.4 @20h00 Sun 8 Jan 27.7 @12h00 Mon 17 Jul 9.5Typical winter week begins Monday 6 Feb,Typical spring week begins Monday 17 April,Typical summer week begins Monday 3 July.Typical autumn week begins Monday 2 October.Typical winter week begins Monday 20 November,*help_end*item*name ALBUQUERQUE NM USA iwec 723650*aide ALBUQUERQUE NM USA iwec 723650 was sourced from US DoE web Sep 2005*dbfl /usr/esru/esp-r/climate/USA_NM_Albuquerque_iwec. . .

Figure 16.3 A typical section of a climatelist le.

The list of available climate filesThe last ASCII le which is used byESP-r modules on a regular basis is theso-called climatelist le. This le isreferenced by the esprc le (see abovediscussion) and includes a list of theclimate data sets that were installed onthe computer. When the interface ofone of the ESP-r modules presents alist of available climate data it scansthis le.Each time you want to add climate datato your computer you should edit thisle with a text editor so that the listingwill include the new le. There is adetailed discussion of how to use clmto add new climate les in Chapter 6.A portion of this le is shown in Figure16.3.The climatelist le includes the follow-ing types of information:

• a display name for the climate data(as seen the the interface list)

• a brief documentation about the cli-mate data

• its location on the computer• the start and end dates of each of ve

seasons (winter from 1 Jan, spring,summer, autumn, winter ending 31Dec). These dates typically weresupplied by a person who knows theclimate of the region and the socialcustoms of the region.

• the start and end dates of a typicalweek in each season. There is anfacility in the clm module whichsearches for typical weeks based onheating and cooling degree days andsolar radiation patterns.

• a block of text up to 60 lines whichprovides a summary of the climate.This block is auto-generated withinclm and you can edit it and extend itif required.

296

297

Chapter 17

VERSION APPENDIX

17 Version Appendix

In addition to its multi-platform capa-bilities, ESP-r has three possible stylesof interaction on most computing plat-forms: text-mode interactions, a legacyX11 graphic interface and a newerGTK graphic interface. In most casesthe command menu selections are thesame. Differences are found in the lay-out of some types of dialogue, in thele browser facilities, in sensitivity tomouse clicks and keyboard input short-cuts.First a brief review of the interactionstyles. Text mode operation is the mostgeeky on offer. It is primarily used byexperts who are commissioning aseries of standard assessments. Theinterface is driven either by user sup-plied keystrokes or commands includedin a script. This mode is also useful forworking on a remote compute-server orwhen only a slow internet connection isavailable.The X11 interface has separate regionsfor graphic feedback, text feedback,menu selections and user dialogues forediting entities and selecting les.Menus items are selected via mouseclicks or by keystroke. This interface isavailable for all operating systemsexcept for Native Windows. User inter-actions are uniform across all machinetypes and each of the ESP-r modulesfollows the same layout although some

take up more room on the screen.The GTK+ based interface wasselected as a replacement for the X11interface because it can be deployedacross a range of operating systems,including Windows. It also has a richerapplication programming interface anda larger number of in-built features thatpreviously had to be written fromscratch in X11.

17.1 Text modeTe xt mode operation is available as acommand line option for users workingon Solaris, Linux, Cygwin and OSX.To use text mode on Native WindowsESP-r must be compiled withoutgraphics. As it is difcult to have twoversions of ESP-r on a Windows com-puter this usually necessitates the useof a second (or virtual) Windows com-puter in order to have access to wire-frame views of models and graphs inthe results module.In Figure 17.1, the project manager hasbeen invoked from a command window(the same command syntax applies inLinux, Solaris, OSX and Cygwin). Thelist of user options is shown in a doublecolumn (options which start with acharacter or number are activated bytyping that character). The prompt isseen at the bottom of the gure.

299

Figure 17.1 An example of invoking the project manager in text mode.

Production work often requires a spe-cic sequence of tasks be carried out.To reinforce this practitioners willoften create a script to drive ESP-r. Forexample, during testing a standard setof assessments need to be run and thena standard report should be extractedfor each assessment.Below is a portion of a script calledSIMULATE.wc is used to run a stan-dard assessment (with ideal controlsactive). The script invokes an ESP-rmodule (bps) with a suitable set ofcommand line parameters and thenpasses a sequence of keystrokes to themodule to control it.

#!/bin/csh -fbset CONFIG=$1bps -file $CONFIG -mode text <<XXX

c$CONFIG.wc_res9 115 131syESRU Standard test: $CONFIGyy--XXX

Having run the assessment, a secondscript in the source code valida-tion/benchmark/QA/model/cfg foldernamed ANALYSE_4 is invoked to startup the results analysis module andcause a sequence of reports to be

300

generated.

#!/bin/csh -fbset RESFILE=$1res -file $RESFILE -mode text<<XXX

d # enquire about>$RESFILE.data$RESFILE resultsa # summary statisticsh # sensiblea # heatinghb # coolingb # temperaturesa # zone dbbe # zone resultantbd # zone control pt--d # enquirea # summary statisticsf # zone fluxa # infiltrationfb # ventilationma # real powermb # reactive powerjb # convective casual gains-jc # radiant casual gains-d # solar processesa # entering from outsidedc # solar absorbedi # zone rhj # casual gainsa # all-jb # convective portion-jc # radiant portion-je # total occupant gain-ji # total lighting gain-jm # total small power---c # timestep reports

g # perf metricsj # casuale # total occupant-ji # total lighting-jm # total small power-! # list data--df # energy deliveredg # casual gains distribh # zone energy balancebbi # surface energy balancebb* # all surfaces in reception-* # all surfaces in office-* # all surrace in roof-l # monthlyab # frequencyb # of temperaturesa # zone dby>---XXX

Seasoned users of ESP-r often use thePerl language to compose a sequenceof assessments and data recovery tasks.Indeed, it is possible to use a script tomodify the shape and or compositionof a model. Anything that can be donevia an interactive session in text modelcan be included in a script.

301

17.2 Legacy X11 graphics

Figure 17.2 Specifying a le name.

Figure 17.3 Pop-up help for a dialog.

Figure 17.4 X11 real number dialog.

Figure 17.5 X11 radio button dialog.This style of interaction supports themost complete graphics input function-ality. It is also dated in appearance andhas limited le browsing facilities. Thecurrent plan is to depreciate and even-tually remove X11 graphic dependen-cies as and when the newer GTK

302

library code (see below) are in place.

Figure 17.6 X11 wire-frame control menu.

Figure 17.2 is an example of a text dia-logue (asking for a le name). Thelayout is similar to all X11 dialogues -there is a prompt above and/or to theleft of the editing box. On the right isan ok box, a ? box and a default box.Clicking on the ? produces a pop-updialogue (see Figure 17.3). If there aremore than about 20 lines of text thenup and down arrows will be included tosupport scrolling. Figure 17.4 is a dia-log requesting a real number. Such dia-logues usually have range checkingincluded and you might be asked to re-specify the number. Figure 17.5 is the

X11 equivalent of a radio button (onlyone item can be selected). Figure 17.6shows the X11 control of a wire-frameview and Figure 17.9 is for the GTKinterface. In this case a menu dialoguehas been used to approximate a pro-forma.Selection lists where you are able toselect more than one entity e.g. Figure17.7 shows a list of surfaces in a zonethat have been selected and the selecteditems have a * in the right column.There is an * All items optionwhich will select the whole list. If youwant to remove and item from theselection then select it and the * will beremoved.

Figure 17.7 X11 entity selection(s) list.

303

17.3 GTK+ graphics

Figure 17.8 GTK le browsing dialog.

Figure 17.9: GTK wire frame control dialogue.

This style of interaction is more inkeeping with what the user communityexpects. The port is incomplete, how-ev er, many users nd that they can

work around the limitations. The cur-rent plan is to continue coding until thefull X11 functionality is in place. Thedevelopment community will thenreview how the layout of ESP-r might

304

ev olve to take advantage of the func-tionality in the GTK graphics API.The following Figures are the GTKequivalents to the le specication dia-logue, pop-up help message, real num-ber dialogue and a radio button dia-logue. It generally takes fewer lines ofcode to implement a dialogue in GTKthan it does in raw X11.

Figure 17.10 GTK popup help.

Figure 17.11 GTK real number dialogue.

Figure 17.12 GTK radio button dialogue.ESP-r dialogues normally use English,however GTK does support locale spe-cic text in buttons that are used insome dialogues. Once the X11 code isdepreciated it should be possible toconsider revising the code structure tosupport multiple languages if resourcescould be found.<< more text here >>

The table below provides a summary ofdifferences. This is followed by spe-cic examples where you mightencounter differences.The chapter is work in progress. Moretext to be added here.

305

Chapter 18

CAPABILITIES

18 Capabilities

This Chapter is a review of the capabil-ities of ESP-r for representing the vir-tual physics of buildings and systemsas well as what can be measured andreported. Some of the information issimilar to the publication Contrastingthe Capabilities of Building EnergyPerformance Simulation Programs byCrawley, Hand, Kummert and Griffithof July 2005.In that publication the summary ofESP-r is:

ESP-r is a general purpose, multi-domain (building thermal, inter-zone air ow, intra-zone airmovement, HVAC systems andelectrical power ow) simulationenvironment which has beenunder development for more than25 years. It follows the pattern ofsimulation follows descriptionwhere additional technical domainsolvers are invoked as the buildingand systems description evolves.Users have options to increase thegeometric, environmental controland operational complexity ofmodels to match the requirementsof particular projects. It supportsan explicit energy balance in eachzone and at each surface and usesmessage passing between thesolvers to support inter-domaininteractions. It works with third

party tools such as Radiance tosupport higher resolution assess-ments as well as interacting withsupply and demand matchingtools.ESP-r is distributed as a suite oftools. A project manager controlsthe development of models andrequests computational servicesfrom other modules in the suite aswell as 3rd party tools. Supportmodules include: climate displayand analysis, an integrated (alldomain) simulation engines, envi-ronmental impacts assessment,2D-3D conduction grid deni-tions, shading/insolation calcula-tions, view-factor calculations,short- time-step data denitions,mycotoxin analysis, model con-version (e.g. between CAD andESP-r) and an interface to thevisual simulation suite Radiance.ESP-r is distributed under a GPLlicense through a web site whichalso includes an extensive publi-cations list, example models,cross-referenced source code,tutorials and resources for devel-opers. It runs on almost all com-puting platforms and under mostoperating systems.Although ESP-r has a strongresearch heritage (e.g. it supportssimultaneous building

307

fabric/network mass ow andCFD domains), it is being used asa consulting tool by architects,engineers, and multi-disciplinepractices and as the engine forother simulation environments.

18.1 General modelling featuresThis section provides an overview ofhow ESP-r approaches the solution ofthe buildings and systems described ina user’s model, the frequency of thesolution, the geometric elements whichzones can be composed and exchangesupported with other CAD and simula-tions tools.• ESP-r employs a partitioned solution

approach. Simultaneous loads, net-work air ow, CFD domain, electri-cal power and system componentsolution is via custom domainsolvers. Interactions betweendomains are handled with messagepassing between the solvers at eachtime-step.

• The building solution is based onmatrix partitioning and Gaussianelimination. Partitioning is by ther-mal zone and zone coupling is han-dled by message passing at eachtime-step. This approach conservesmemory in the case of large models,but requires resources for messagepassing.

• Entities in ESP-r are represented ascontrol-volume heat-balance nodes(nite volumes). Such nodes are dis-tributed throughout the fabric and airvolumes of the building and withinsystem components. An explicitenergy balance is maintained at eachzone air volume, at each face of each

surface and at each nite volume ofused in system components.

• System components support temper-ature, two component (moist air andsteam) ow, heat injection/extractionand electrical characteristics at eachcomponent node.

• Electrical power solution supportsmixtures of DC as well as threephase power with real and reactivepower. The electrical network canlink to casual gains in zones and sur-faces which include electrical char-acteristics as well as system compo-nents.

• The mass ow solution works withmixed air and water ow networksof nodes (at zones, system compo-nents and at boundary locations) aswell as a range of ow components.Control logic can be applied to owcomponents to approximate mechan-ical or user interventions. The solveris highly optimized and can solvenetworks of hundreds of nodes withminimal computational overhead. Ittypically runs at the same frequencyas the zone solver with the option toiterate (useful for models with largeopenings).

• Iteration supported in system com-ponent and network ow solutiondomains. Zone solver can beadjusted from fully implicit to fullyexplicit but defaults a Crank-Nicol-son formulation. Conductiondefaults to 1D and models caninclude 2D and 3D conduction (ifadditional data is supplied).

• Domain interactions supported e.g.mass ow solution feeds systemcomponent and zone solution at each

308

time-step.• Zones can be assessed with a mix-

ture of environmental controls,including free oat and user under-sized controls as well as supportingradiant gains and injection of heatinto layers of a construction.

• Simulation frequency is one minuteto one hour for zone and air owdomains. System and electrical com-ponents solved from one second toone hour. Time-step controller withsupport for rewind to start of day forexploring optimal start regimes.

• Zone geometry is based on 3D poly-gons of arbitrary complexity (includ-ing explicit representation of internalmass). Shading devices are blockshapes. There are a number of geo-metric rules: a) zones must be fullybounded, b) surfaces must be at, c)edge ordering denes outward faceof surface, d) unbounded edgesdetected, e) internal mass requiresback-to-back surfaces, f) zones canbe embedded within other zones. Allzone surfaces take part in the zoneenergy balance.

• Glazing is a surface with opticalproperty attributes which supportssolar transmission and absorption ateach layer in addition to the convec-tive, conductive and radiantexchanges of opaque surfaces. Opti-cal properties can be subject to con-trol action. Frames can be repre-sented explicitly or via adapting theproperties of the surface representingglazing.

• Surfaces can have attributes forphase change materials, temperaturedependant conductivity, electrical

characteristics (e.g. integrated PV),moisture adsorption, contaminateemission properties.

• Facility to import DXF les (V12)which conrm to specic standardsof layer naming and use of 3D enti-ties.

• Facility to export DXF les (V12),EnergyPlus (geometry, construc-tions, casual gains), VRML worlds,Radiance visual simulation models.

• Measured data (one minute to onehour frequency) of temperatures, set-points, weather data, casual gainscan be associated with a model.

• Ideal environmental control systemscan be dened (in addition to com-ponent based system descriptions).

18.2 Zone LoadsThis section provides an overview ofESP-r’s support for solving the thermo-physical state of rooms: the heat bal-ance underlying the calculations, howconduction and convection withinrooms is solved, and how thermal com-fort is assessed.• An explicit energy balance is main-

tained at each zone air volume and ateach face of each surface. Thedefault treatment is to use threenite volumes for each layer of eachconstruction. Typically, materialsover about 200mm thick are subdi-vided into multiple layers to increasethe efciency of the solution as wellas providing additional points forrecording temperature.

• The minimum size of a zone is˜1cmˆ3. Rooms with dimensionsgreater than 100m probably should

309

be subdivided. Minimal surfacedimensions are ˜1mm and there is nospecic maximum size. Surfaces caninclude ˜24 edges but complex sur-faces or surfaces with large dimen-sions may not be well represented by1D conduction. Minimum thicknessof a construction layer is ˜0.2mmalthough care should be taken whenthin and thick layers are adjacent.

• A number of boundary conditiontypes are supported in ESP-r: a)exterior, b) other side has similartemperature and radiation, c) otherside has xed temperature and radia-tion, d) other side is a surface in thisor another zone, e) standard or userdened monthly ground temperatureprole or a 3D ground model, f) adi-abatic (no ux crosses), g) other sideis part of a BASESIMP foundationdescription, h) CEN 13791 partition.

• Air gaps are typically treated a resis-tance layers which are sensitive tosurface orientation. Glazing usingalternative gasses or with coatingsmust be approximated by alteringthe air gap resistance. Air gaps canbe explicitly represented as thermalzones and optionally included in anair ow network (such explicit treat-ments do not scale well but do sup-port explicit treatments of radiationand convection across air gaps).

• There are ˜20 internal convectionregimes and 25 external convectioncorrelation’s in addition to userdened heat transfer coefcients.Conditions at inside and outside faceare evaluated at each time-step.Some outside regimes are sensitiveto the angle of incidence of the wind

as well as whether the surface is onthe windward or leeward side. Heattransfer coefcients derived via aCFD solution can be applied at thenext time-step.

• Internal mass can be explicitly repre-sented and these surfaces take part inthe full energy balance as well assolar insolation patterns and longwave radiant exchanges.

• Radiation view factors can be calcu-lated for zones of arbitrary complex-ity and shape, including internalmass.

• Fanger thermal comfort as well asMRT and resultant temperaturereported. If sensor bodies are denedthen radiant asymmetry is alsoreported.

18.3 Building envelope and day-lightingThis sections is an overview of thetreatment of solar radiation outside abuilding as well as its distributionwithin and between zones. Outside sur-face conduction is also discussed.• The default treatment is to assume

no shading and that the distributionof insolation is diffusely distributedwithin a room. If there are externalsources of shading these are repre-sented as opaque non-reectiveblock shapes. Shading calculations(direct and diffuse) are done for eachhour on a typical day of each month.Diffuse shading can be based on iso-tropic or anisotropic sky conditions.

• Insolation distribution (includingradiation falling on internal masssurfaces) can also be predicted at

310

each hour on a typical day of eachmonth.

• Beam solar radiation is tracked torst absorption and then diffuselydistributed. Solar radiation passinginto adjacent zones is treated as adiffuse source. Solar radiation pass-ing out through a facade is assessed.

• Optical data on transmission andabsorption at ve angles is typicallyused and can be imported from Win-dow 5.1 or 5.2. Data from WISrequires additional editing. Bidirec-tional optical properties and controlis supported for those with experi-mental data.

• Seasonal adaptation of shadingdevices requires separate models,each pointing to obstruction descrip-tions for that season.

• Optical properties can be switchedbased on a range of criteria (thenumber of layers is required to beconstant). There is a facility to sub-stitute an alternative construction aswell as alternative optical properties.The requirement for a constant num-ber of layers poses a challenge forthe representation of movable blindsand shutters.

• Day-lighting control can be based onsplit-ux method, user dened day-light factors or time-step use of theRadiance visual simulation suite tocompute lux on a sensor. Multiplecircuits can be treated in each ther-mal zone.

• Some users choose to explicitly rep-resent opaque blinds as sets of sur-faces. In the case of blinds betweenglass this is often approached by

treating the blind as a layer with theconstruction which has optical prop-erties approximating the transmis-sion through the slats and openings.If the optical properties of this layerare switched then the absorptioncharacteristics of the blind layerchange (as does the thermal state ofthe construction).

• Conduction is typically representedin 1D but can be switched to 2D and3D (the input data requirementsincrease considerably).

18.4 Infiltration ventilation andmulti-zone air flowThis section provides an overview ofhow air movement, either from the out-side or between rooms or in conjunc-tion with environmental systems istreated.• The simple approach to air

movement in ESP-r is to createschedules of inltration (airmovement from the outside eithernatural or forced) and ventilation (airmovement between zones). Controlcan be applied to these scheduledows based on a range of criteriae.g. increase inltration to 2ach ifroom goes over 24 degrees C.

• The intermediate approach to airmovement is to create a network ofow nodes and components andsolve the leakage distribution at eachtime-step based on the currentboundary driving forces as well asstack and pressure distributionsinside. Most of the underlying com-ponent representation are derivedfrom the literature. In common withmost other mass ow solution

311

approaches there are some gaps inthe provision of component types.

• Control can be applied to mass owcomponents to approximate occu-pant interactions or mechanical owcontrols. Combinations of controlsin sequence and in parallel are usedto create complex regimes.

• The highest resolution approach is todene a computation uid dynamicsdomain with one zone of the model(optionally in addition to a ow net-work). The CFD domain is in a rect-angular co-ordinate system withoptional blockages. Solution is typi-cally transient 2D or 3D. There are arange of wall functions available aswell as equation types.

• The CFD solution supports one wayand two way conation. The lattertakes its boundary conditions fromthe zone solution and returns heattransfer coefcients. There is anadaptive controller which re-formsthe CFD domain at each time-stepbased on changes in boundary condi-tions and the ow patterns predictedfrom an initial course CFD assess-ment.

• The CFD solution can also use owboundary conditions from an associ-ated mass ow network. This allowswind pressures and ows with otherzones to be assessed at each time-step. Iteration is used to negotiatebetween the mass ow and CFDdomain solvers.

• The CFD solution can include cellswhich are heat and contaminatesources. The former can be associ-ated with zone casual gain schedulesso that there is a temporal aspect to

such gains.• Zone air volumes are assumed to be

well mixed at one temperature. Strat-ication requires either the use of aCFD domain or subdivision of phys-ical spaces into multiple thermalzones with a mass ow network usedto assess air exchange.

• A mass ow network can includeelements associated with naturalventilation and buoyancy driven owas well as components within amechanical system. Thus it is possi-ble to create an air based solar col-lector from a collection of explicitzones and a ow network (as analternative to a component basedapproach).

• For models of high resolution thereis a post-processor which determinesif specic species of mycotoxin willgrow on surfaces of a model.

• Architectural elements such asTrombe-Michelle walls and doubleskin facades are usually composedof multiple zones with a mass ownetwork to support air movementassessments.

• ESP-r includes a database of windpressure coefcients (at 22.5 degreeintervals) which can be associatedwith wind pressure boundary nodesin a ow network. Some users popu-late this database with data fromwind tunnel tests or CFD runs.

18.5 Renewable energy systems andelectrical systemsThis section is an overview of optionsfor representing renewable energy sys-tems either as components within an

312

ESP-r model or via 3rd party tools.Including an electrical power networkin a model allows a number of issuesrelated to renewable energy systems tobe addressed.• Some system components represent

components of renewable energysystems such as generators, fuelcells and batteries. These can betested independent of or switchedinto the power grid. Mixtures of1/2/3 phase AC and DC can bedescribed.

• The electrical solvers works at thesame time-step as the system com-ponents and yields real and reactivepower ows, power losses, currentmagnitudes and phase, voltage mag-nitudes and phase, phase loadings.

• ESP-r data can be exported for usewith supply and demand matchingtools such as MERIT (also availablefrom ESRU).

18.6 Ideal environmental controlsThis section is an overview of ESP-r’sapproach to ideal (from a control engi-neers perspective) zone controls.• For early stage design issues ESP-r

users tend to use ideal zone controlsto represent environmental controlsas loops of sensors and actuatorswith a range of control laws.

• Ideal zone controls can be combinedwith control of mass ow compo-nents to increase the resolution ofmodels. Mass ow components canbe used to represent some aspects ofduct work in mechanical systems(ESP-r has not been designed to beused as a duct design tool).

• Sensors in ESP-r can be located at anumber of positions within thebuilding (the zone air volume, at orwithin a surface, at a ow node oroutside of the building for use withclimate variables). Actuators in ESP-r can be located at the air node, at orwithin a surface, at a ow compo-nent etc.

Zone control loops include a scheduleof control laws are applied as requiredto approximate many environmentalcontrol regimes. The zone controlsinclude:• basic ideal control with maximum

and minimum heating and coolingcapacity, heating set-point, coolingset-point and moisture injection.

• free oating control• xed injection/extraction with heat-

ing injection, cooling extraction,heating set-point and cooling set-point.

• basic proportional control with max-imum and minimum heating injec-tion, maximum and minimum cool-ing extraction, heating set-point,cooling set-point. There is a throt-tling range and optional integralaction time and/or derivative actiontime.

• A multi-stage controller with hys-teresis. There are three stages ofheating and three stages of cooling.There are heating off and cooling offset-points as well as dead bands forheating and cooling and heating andcooling set-points.

• Variable supply controller with orwithout available cooling. It includesa maximum supply temperature,

313

minimum supply temperature, airow rate room heating and coolingset-points.

• Separate ON/OFF controller whichincludes heating and cooling capac-ity, heating on below, heating offabove, cooling on above and coolingoff below set-points.

• Ideal match temperature controllerwhich is given a maximum heatingand cooling capacity and a list ofsensors and their weightings as wellas scaling factors. A typical use is tocontrol a boundary zone to a mea-sured temperature or to match thetemperature in another zone. Thereis also an ON/OFF controller whichcan be used to match measurementsor other zone temperatures.

• Time proportioning control whichincludes heating and cooing capac-ity, heat on and off set-points, cool-ing on and off set-points, minimumon times and off times. Useful forequipment that has a slow cycletime.

• Optimal start logic with heatingcapacity, desired set-point, desiredtime of arrival, minimum time differ-ence with optional start time. Thereis also an optimal stop controller.

• Slave capacity controller points to acommon sensor and forces the zoneactuator to act as the master actuatorbut with a user dened heating andcooling capacity.

• VAV approximation controller whichincludes a reheat capacity, supplytemperature, room set-point, maxi-mum and minimum ow rate

18.7 Component based systemsThis section is an overview of ESP-r’scomponent-based approach to describ-ing environmental systems. There are anumber of component types (some arelisted below) which can be linkedtogether to form a range of environ-mental control systems. Some devicesare represented by several components- for example there is a single noderadiator as well as an eight node radia-tor - so the user has a choice of compo-nent resolution.As with zone controls, system compo-nents can be included in system controlloops. There are a number of controllaws available depending on whetherux or ow is to be controlled.• Air conditioning steam/spray humid-

ier, water/steam ow multiplier,water/steam ow converger anddiverger

• Air conditioning cooling coils withux control, a counterow coolingcoil with water mass ow rate con-trol, a counterow cooling coil fedby WCH system, a two node coolingcoil with specic n and tubedetails.

• Air conditioning heating coils withux control, a counterow heatingcoil with water mass ow rate con-trol, a counterow heating coil fedby WCH system

• Plate heat exchanger, air/airexchanger, heat exchanger segment,duct, duct damper

• Cooling tower• Centrifugal fan

314

• Wet central heating boilers: non-con-densing boiler, with on/off control,with aquastat control, calorier,modulating boiler, TRNSYS type 6WCH boiler storage water heater

• Wet central heating radiators: basic(one node), exponent model radiator,WCH thermostatic radiator valve,mechanical room thermostat.

• WCH pipes: pipe, converging 2-legjunction, converging multi-leg junc-tion, heat transfer tube, heat transfertube with transport delay, insulatedpipe with transport delay, ow con-trol valve

• WCH basic chiller or heat pump,water cooler, compressed gas cylin-der

• WCH generic liquid/liquid heatexchanger and gas/liquid heatexchanger and water/air heat rejector

• Oil lled electric panel radiator• CHP engine components: one node

and three node representations.• Hydrogen appliance (generic genera-

tor supplied by hydrogen source)

18.8 Environmental emissionsThe emissions associated with theenergy use of buildings can be trackedvia user supplied conversion factors forheating and cooling and small powerloads as well as loads which are not at-tributable to a particular zone.There is a rarely used facility thatallows users to dene environmentalimpacts associated with the assemblyand transport and disposal of buildingcomponents.

18.9 Climate dataThis section gives a summary of howESP-r uses climate data and how usersaccess and manipulate this data.ESP-r holds the following climate datain both ASCII and binary le format.Solar data can be in two forms. Thenormal le formats support hourlydata.• Diffuse solar on the horizontal

(W/m**2)• External dry bulb temperature

(Deg.C)• Direct normal solar intensity or

global horizontal (W/m**2)• Prevailing wind speed (m/s)• Wind direction (degrees clockwise

deg from north)• Relative humidity (Percent)• Site description, latitude and longi-

tude difference from the local timemeridian.

There is a conversion utility which isable to read EnergyPlus EPW weatherdata and extract the required dataelds. ESP-r also works with sub-hourly weather data via a so-calledtemporal le.There is an facility that scans a climatedata set to determine best t weeks ineach season based on heating and cool-ing degree days and radiation levels. Italso reports initial scaling factors thatcan be used to convert from shortperiod assessments to seasonal perfor-mance data.

315

18.10 Results reportingThis section is an overview of howbuilding and systems performance datais accessed in ESP-r. The standardapproach differs from many other sim-ulation suites in that one or more cus-tom binary databases are createddepending on the number of domainsolvers used in a particular model.• The zone solver writes out a number

of items at each time step whichrelated to temperatures of the zoneair and surfaces as well as uxesassociated with a zone air energybalance and surface energy balances.

• The plant component solver writesout the temperature, 1st phase and2nd phase ows at each node of eachcomponent.

• The mass ow solver records thepressure and temperature at eachnode, pressure difference acrosseach network connection as well asstack pressure and mass ows alongeach connection.

• The electrical power solver writesout the real and reactive power,power loss, current magnitude andphase, voltage magnitude and phase,phase loading for each node in theelectrical network.

ESP-r includes a results analysis mod-ule which is able to read these binaryresults les and, for any of the storedvariables report on the data in variousformats and undertake statistical analy-sis.• Graphs of time vs variable with

option of multiple vertical axis andsupport for combinations of data.

• Graphs of variable vs variable tolook for trends and correlation’sbetween data types

• Statistics with maximum value andtime of occurrence, minimal valueand time of occurrence, mean andstandard deviation

• Statistics with number of hours overand under a specied value

• Time step listings in multiple col-umns with various separators asrequired by third party applications

• Frequency bins and cumulative fre-quency bins in tables and graphs.

• Zone and surface energy balances aswell as individual reporting of allcontributor variables in the energybalances.

• Energy demand over time includinghours of use.

• Comfort in terms of PMV, PPD,radiant asymmetry, resultant temper-ature, MRT.

• Monthly gains and losses for a num-ber of variables in each zone.

There is an facility which generatesXML les based on a description ofvariables to save during a simulation.The list of items to capture is typicallygenerated by editing a separate speci-cation le.There is a facility which allows usersto include a range of performance met-rics for a model called an IntegratedPerformance View. This description isused by the results analysis module togenerate a report based on informationin one or more simulation les.

316

18.11 ValidationTesting of software has been an ongo-ing activity for the ESP-r developmentcommunity and takes several forms:assuring the quality of the code in ESP-r, testing that the underlying computa-tions are correct and detecting differ-ences with the predictions of othertools. ESP-r has been involved in thefollowing projects:• IEA Annex 1 (1977-1980). Inter-

program comparison of 19 differenttools

• IEA Annex 4 (1979-1982). Inter-program comparison of a commer-cial ofce building with nine toolsover four years.

• IEA Annex 10 (1984-1986). Inter-program comparison of HVAC sys-tems.

• IEA Annex 21 (1988-1993). Inter-program and analytical comparisoncommonly known as BESTEST.

• SERC validation project (1988).Inter-program comparison under-taken by several Universities andresearch groups in the UK withextensive analytical tests.

• UK Energy Technology SupportUnit Applicability study was carriedout over sev en years and focused onpassive solar houses.

• EC PASSYS project (1986-1993)combined outdoor test facilities (in14 locations) with model predic-tions.

• British Research Establishment/Electricity de France empirical vali-dation study of a BRE ofce build-ing and a BRE house.

• BESTEST, RADTEST, HomeEnergy Rating System BESTESTwere carried out at various times andby various teams and focused onradiant heating systems (RADTEST)and air conditioning systems andfurnace models (HERS).

• CEN 13791 standard required anumber of extensions to ESP-r toaccommodate the unusual physicsassumed in the standard.

317