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.

15 November, 2008

COPYRIGHT DECLARATIONThe copyright of this publication belongs to the author under the terms of theUnited Kingdom Copyright Acts as quali!ed 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 speci!cation . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 644.1 Modelling approaches . . . . . . . . . . . . . . . . 654.2 Steps to create a roof space . . . . . . . . . . . . . . 694.3 Shading obstructions . . . . . . . . . . . . . . . . 74

5 Schedules . . . . . . . . . . . . . . . . . . . . . 765.1 Scheduled air "ows . . . . . . . . . . . . . . . . . 805.2 Importing operation schedules . . . . . . . . . . . . . 80

6 Climate data . . . . . . . . . . . . . . . . . . . . 836.1 Importing climate data . . . . . . . . . . . . . . . . 836.2 De!ning seasons and typical periods . . . . . . . . . . . 846.3 Climatelist entries . . . . . . . . . . . . . . . . . 88

7 Zone environmental control . . . . . . . . . . . . . . . . 917.1 Introduction . . . . . . . . . . . . . . . . . . . 917.2.1 Abstract representations . . . . . . . . . . . . . . 917.2.2 Abstract example . . . . . . . . . . . . . . . . 93

7.3 Zone control laws . . . . . . . . . . . . . . . . . 957.4 Exploring building control issues . . . . . . . . . . . . 977.4.1 Basic (ideal) control . . . . . . . . . . . . . . . 977.4.2 Interpreting control predictions . . . . . . . . . . . . 102

7.5 Controls implementing boundary zones . . . . . . . . . . 107

8 Thermophysical resolution . . . . . . . . . . . . . . . . 1129 Preparation for simulation . . . . . . . . . . . . . . . . 11410 Understanding performance predictions . . . . . . . . . . . . 11711 Flow networks . . . . . . . . . . . . . . . . . . . . 120

11.1 Limitations of Scheduled Flow . . . . . . . . . . . . . 12011.2 Fluid Flow Networks . . . . . . . . . . . . . . . . 12011.3 Building blocks . . . . . . . . . . . . . . . . . 12211.3.1 Flow components . . . . . . . . . . . . . . . . 12311.3.2 Flow connections . . . . . . . . . . . . . . . . 124

11.4 Steps in creating a network . . . . . . . . . . . . . . 12611.5 A simple network . . . . . . . . . . . . . . . . . 12811.6 To the keyboard... . . . . . . . . . . . . . . . . . 13111.7 Calibrating "ow models . . . . . . . . . . . . . . . 13511.8 Flow control . . . . . . . . . . . . . . . . . . 13811.9 To the keyboard... . . . . . . . . . . . . . . . . . 14011.10 Window representations . . . . . . . . . . . . . . 14411.10.1 Component selection . . . . . . . . . . . . . . 146

11.11 Schedules vs networks . . . . . . . . . . . . . . . 14811.12 Hybrid ventilation . . . . . . . . . . . . . . . . 15411.13 Limitations of Network "ow models . . . . . . . . . . 158

12 Detailed "ow via CFD . . . . . . . . . . . . . . . . . 16013 Plant . . . . . . . . . . . . . . . . . . . . . . . 163

13.1 Using a component network to represent mechanical ventilation. . . . . . . . . . . . . . . . . . . . . . . . 164

13.2 De!ning containments . . . . . . . . . . . . . . . 17013.3 Finishing off the model and testing . . . . . . . . . . . 17013.4 Moving from ideal demands to thermal zone demands . . . . . 17313.5 Links to zones and controls . . . . . . . . . . . . . . 177

14 Working procedures . . . . . . . . . . . . . . . . . . 18214.1 How can the vendor help? . . . . . . . . . . . . . . 18314.2 Responsibilities within simulation teams . . . . . . . . . . 18314.3 Classic mistakes . . . . . . . . . . . . . . . . . 18414.4 Planning simulation projects . . . . . . . . . . . . . 18614.5 Team manager . . . . . . . . . . . . . . . . . . 18914.6 The quality manager . . . . . . . . . . . . . . . . 19114.7 Simulation staff . . . . . . . . . . . . . . . . . 19514.8 The mentor . . . . . . . . . . . . . . . . . . . 19814.9 The domain expert . . . . . . . . . . . . . . . . 20014.10 Staff productivity . . . . . . . . . . . . . . . . 20214.11 Summary . . . . . . . . . . . . . . . . . . . 203

15 Model Quality . . . . . . . . . . . . . . . . . . . . 20415.1 How can the vendor help? . . . . . . . . . . . . . . 20415.2 Responsibilities within simulation teams . . . . . . . . . . 206

15.3 Model planning . . . . . . . . . . . . . . . . . 20915.4 Complexity . . . . . . . . . . . . . . . . . . . 21015.5 Multi-criteria assessments . . . . . . . . . . . . . . 21115.6 Semantic checks . . . . . . . . . . . . . . . . . 21515.7 Team Checklists . . . . . . . . . . . . . . . . . 21715.8 Simulation outputs . . . . . . . . . . . . . . . . 22315.9 The model contents report . . . . . . . . . . . . . . 22615.10 Summary . . . . . . . . . . . . . . . . . . . 233

16 Install Appendix . . . . . . . . . . . . . . . . . . . 23517 Version Appendix . . . . . . . . . . . . . . . . . . . 242

17.1 Text mode . . . . . . . . . . . . . . . . . . . 24217.2 Legacy X11 graphics . . . . . . . . . . . . . . . . 24517.3 GTK+ graphics . . . . . . . . . . . . . . . . . . 247

18 ESP-r capabilities . . . . . . . . . . . . . . . . . . . 25018.1 General modelling features . . . . . . . . . . . . . . 25118.2 Zone Loads . . . . . . . . . . . . . . . . . . . 25218.3 Building envelope and day-lighting . . . . . . . . . . . 25318.4 In!ltration ventilation and multi-zone air "ow . . . . . . . . 25418.5 Renewable energy systems and electrical systems . . . . . . . 25518.6 Ideal environmental controls . . . . . . . . . . . . . 25618.7 Component based systems . . . . . . . . . . . . . . 25718.8 Environmental emissions . . . . . . . . . . . . . . 25818.9 Climate data . . . . . . . . . . . . . . . . . . 25818.10 Results reporting . . . . . . . . . . . . . . . . . 25918.11 Validation . . . . . . . . . . . . . . . . . . . 260

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 de!nitions 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 edi!ce 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 IntroductionThe design process proceeds on thebasis of the beliefs the design teamholds about how the current design sat-is!es 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 isconsiderable 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 ef!cient, 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.Many practitioners rely on mentoringand workshops to keep them up to date

1

as 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 speci!c 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 speci!c 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 bestpractice models. Vendors do not alwaysmake clear which is which.

2

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 speci!c 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 andenvironmental systems. A future revi-sion is planned for those who are less

opinionated. 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-textinterface which tends to be used forscripted production work or to enable

3

ESP-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 speci!c 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 withoutdelaying 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 questions

What do we want toknow about the design?

What thermophysical issues should be addressed bythe model?

How do I know if thedesign works?

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

How might the designfail?

What boundary conditions and operating regimeswould be a reasonable test?

How do I match theinformation I have withthe requirements of thetool?

What is the essence of the design in terms of form,composition, operation and control?What essential interactions need to be represented?What facilities can be employed and what skills areneeded to use them?

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

Are the performancepredictions credible?

What assessments need to be undertaken to gaincon!dence in the model?What is expected of a best practice design?

How can I deliver themost value for myclient?

What else would clarify how the design works?How might the design and the model evolve duringthe design process?What would I do now to make it easier to work withthis model 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 bene!ts. 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 clientsspeci!cation and design questions formthe context. From this we decide what

type of model(s) the speci!cationimplies as well as the assessment(s)that need to be done to answer theclients 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 thespeci!cation 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 of!ce. Theclient speci!cation 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 tocon!rm or refute such beliefs.Figure 1.1 shows a plan and section(looking from the east) of the generalpractitioners of!ce. The reception has a"at 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 of!ce.

Figure 1.2 Wire-frame view of generalpractitioner of!ce.

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 of!ce.

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 of!ce.

This project represents a portion of ageneral practitioner’s of!ce. 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 to!ve 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 speci!c 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 in!ltration. There is adiscussion about air "ows in a latersection. For now lets use an initialengineering assumption that there willbe 0.5 ac/hr in!ltration 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 speci!cation. 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 speci!cation) 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 de!ne 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 isdiversi!ed 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 suf!ce. 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 de!nition 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 of!ce.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 outpace a novice, good work-ing 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 speci!cs 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-ci!c 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 we!rst 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 re"ect 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 of!ce 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 structural"oors with little or no air movementare often represented as layers of airin constructions. Where airmovement is likely or there are sig-ni!cant 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 speci!c directives partn_corin office is connected with partn_off incorridor which are separate from thegeometric de!nition.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 of!ce 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 in"u-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 heat"ow 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 arespeci!cally 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 of!ce.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 de!ne their model using cardi-nal orientations and later rotate andtransform the model to re"ect 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 con!rmcritical 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 speci!cation 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 de!ning 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 eachde!ned 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 de!nition 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 de!ning schedules of greater com-plexity. For example, there is a shorttime-step data facility which allowscasual gains to be speci!ed at eachtime-step.

15

Figure 1.9 Pro!les for reception.

16

Figure 1.10 Pro!les 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 beenspeci!c 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 de!ne 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 whichde!ne a generally recognised 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 de!ne 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 and be-haviour 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-de!ned system lists.Opinionated practitioners are able tobe speci!c and evaluate alternativedesigns and explore many moreaspects of system performance.Unfortunately detailed descriptionsare tedious to set-up, dif!cult 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 mass"ow 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 speci!city and detail in envi-ronmental control systems. Deliveringinformation quicker and with lesseffort than our competitors is a goodbusiness plan.Actually, many simulation tools makeit dif!cult not to be speci!c in the earlystages of a simulation project. Vendorssell Wizards that offer scores of pre-de!ned 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 suf!cient 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 idealisedcontrol 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 detailedmodi!cations of an initial template-based design?

• Does the interface support suf!cientvariants 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 characterise 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 speci!c 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 speci!ed what thebuilding is to be made of. We are goingto have to select placeholders from anexisting database until such time asthere is a clearer de!nition. 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 modelWith planning complete we can takethe client’s speci!cation and oursketches and notes and begin a newproject. If you are using another simu-lation tool adapt your keystrokes and!nd 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_of!ce.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 of!les 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 de!ne the form and com-position of the general practitionersof!ce. 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 EPW!les and Korean MET of!ce !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 con!rm 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 analyse 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 optimised to copewith brief rather than extended coldperiods.

Figure 2.9: Synoptic analysis.Another example is Figure 2.12 wherethe psychrometrics 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-ci!c 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 con!gure 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-ci!c 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 oruses an approximation. This can beassociated with the surfaces in themodel and later, when the actual infor-mation is available it can be updated

32

and 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 de!ning 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 tominimise 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 de!ne 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 speci!c 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 clientsde!nition.The next dialogue asks whether wewant to start with an rectangularplan, polygon plan, general3D, bitmap. For purposes of thisexercise select polygon plan and!nd 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 de!ne. To the East of thispoint the wall faces the outside. Weneed to de!ne 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-ordinates!rst 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 beende!ned 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 de!ne co-ordinates in acardinal orientation and then rotate tore"ect 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 andoff names and vertices and the site

origin. 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 simpli!ed 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 de!ne 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 to!nd 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 speci!c 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 air"ow 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 manyof their attributes are UNKNOWN.Surface attribution is what we will turn

our attention to in the next section.

43

Completing attributionTactically, we would prefer that others!nd 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 tode!ned 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 identi!er 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 ofsurfaces and then copying surfacesfrom the reception. For purposes of thisexercise it is an ef!cient approach and

it 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 of!cehours). You will be offered a choice ofinitial form and this time choose rect-angular 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 is

47

shown 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 tothe reception zone as well as externalwalls and clear-story glazing.One quick way to make this transformby !rst deleting both Wall-2 and

Wall-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 de!ned 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 con!rm 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 de!nethe edges anticlockwise from thelower left corner. If you see theinside face of the surface in thewireframe then de!ne 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 de!n-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 con!rmation(Figure 2.39).

Figure 2.39: Topology checking con!r-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 zone!les 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 inputsESP-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 gridding options. A bit-map with only a few pixels per metrewill be dif!cult 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 of!ce 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 model!ll 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 de!nition 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-de!ned 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 gridding option and acceptthe suggested !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.

• de!ne 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 de!ne zones whichextend into the negative X or Y dimen-sion you would adjust the position ofthe origin to re"ect 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 de!ned the ’real’grid can be overlaid by selecting thegridding 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. The"oor 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 de!ne points it isworth noting that you are able to inter-rupt the input process and move arounda bitmap.

56

Use the start option to beginde!ning 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 satis!ed. Whilesaving the zone data, an additional !leis created to hold the ’topology’ of themodel and you can safely accept the!le name offered for con!rmation.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 de!nition.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 wouldrecognise 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 topogra-phy was created and initial simulationscommissioned within 12 hours of thecompletion of the simulation planning

phase. It would have been faster, butone drawing was off-scale and severalzones had to be adjusted to bring theminto 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 exer-cise that explores clicking on a planimage from a CAD tool - make up your

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.The next chapter approaches the topicof model geometry from a differentperspective.

62

Chapter 4

3D MODELLING

4 3D modelling

Figure 4.1 Section and view of house

64

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 ranking

thermophysical 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-pli!cation 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 strati!cation).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 fullthickness and the partial thicknessinsulation and extend the roof zone to

65

allow 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 de!ning 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. Geometrydigitised 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 faade.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 are

covered 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.

66

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 dif!cult 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.

67

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 retro!t 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.

68

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 de!nevariant 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 minimisekeystrokes 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.

69

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

Figure 4.10: Initial dummy surface in roof_space.

70

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.

71

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 polygonde!ned 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

72

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.

73

• west surface should include vertices8 1 17.

There are patterns in the above de!ni-tions. What are they?• Each surface is de!ned 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 con!dent 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.

4.3 Shading obstructionsThe roof is formed and attributed butthe walls will not be shaded untilobstruction blocks are added to themodel. This section is incomplete.Other attribution such as casual gainand air "ow schedules are coveredelsewhere.

74

Chapter 5

SCHEDULES

5 SchedulesThe 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 de!nition. It is, however,in our interest to de!ne the essentialcharacteristics of what goes on in abuilding and learn from the perfor-mance patterns that emerge suf!cientclues 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 tode!ne 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 ofin!ltration (air from the outside viaintentional sources such as fans orunintentional sources such as cracks inthe facade) and ventilation (air from

another thermal zone) and there are alimited number of controls you canimpose on in!ltration 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 tore"ect the properties of speci!c light!ttings 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.For the current building a brief descrip-tion was given in the ’How the building

76

is used’ section, speci!cally Figure1.10 and 1.11. Re-read that section.Also look at Figure 53 for receptiondata. Before we de!ne 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 of!ce 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 of!ce hours and the ramp-down after of!ce hours approximatestransient occupancy. The peakdemands are long enough to indicatewhether heat will tend to build up inthe rooms. Such patterns will also exer-cise the environmental system and per-haps provide an early clue as to the

relationship 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 de!ne 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 de!ne the schedules(Figure 5.1).

77

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 de!ned the magnitudeof the sensible and latent gains andaccepted the default radiant and con-vective split you should see somethinglike Figure 5.3.

78

Figure 5.3 Weekday casual gains.

Figure 5.4 Weekday in!ltration schedules.

Using the information on your notesyou could also de!ne the casual gainsfor the examination room.

79

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 this!gure. 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 in!ltration 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 in!ltration 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 patternfolder (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 the!le 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 de!ned, 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.

80

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 notde!ned environmental systems then theassessment will be based on a free "oatassumption.

81

Chapter 6

CLIMATE DAT A

6 Climate dataUnless we !nd ways to focus and con-strain our models and the assessmentswe carry out, simulation tasks riskdemanding more computing and staffresources then we have available. Inthis section the focus one one way todeliver information faster (and withoutexhausting ourselves) by resisting ourimpulse to run long assessments earlyin the design process.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 of!cebuilding.For many building types there is astrong correlation between predictionsover one or two weeks in each seasonand seasonal demands. If we can estab-lish that this is the case for a building,scaling of performance predictionsfrom short periods to whole season val-ues becomes an option.The ESP-r climate data sets can be sup-plemented with information about sea-sons (early-year winter, spring, sum-mer, autumn, late-year winter in theNorthern Hemisphere, early-year sum-mer, autumn, winter, spring later-yearsummer in the Southern Hemisphere)as well as typical assessment periods.

Seasons are partly based on local con-ventions and partly on science. We pos-sible the demarcation between seasonsis based on input from the simulationcommunity. There are severalapproaches to deriving a typical assess-ment period from the climate data !leand then placing it where it is easy toaccess.

6.1 Importing climate dataTo better understand how this worksour !rst task is to install a new climate!le 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://www.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 the!les will be CHE_Geneva_IWEC.epw.

83

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.

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

To check that the conversion worked,invoke the clm module with the new!le 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.1). There are several changeswe might need to make in the !le.Line 6 include a # character before theWMD number and this should bereplaced by a blank character. Line 6 isalso 702 characters long and ESP-r canonly read text lines that are less than248 characters. After reading theASHRAE notice, edit the notice textshorten it. The last change is that someEPW !les have a blank line at the endof the !le (line 8769). Remove this lineand save the !le. Further instructionsfor working with EPW !les will befound in the ESP-r source distributionin the climate folder.

6.2 Defining seasons and typicalperiodsOur next task is to de!ne the days asso-ciated with each season. There are anynumber of approaches one might takeand we will use a combination of look-ing at the patterns of temperatures overthe year and the solar radiation. In theclimate module choose graphical anal-ysis from the menu options. Then pickdry bulb temperature and draw graph toget a display similar to that in Figure6.2.

84

Figure 6.1 Editing of EPW !le.

Figure 6.2 Annual dry bulb temperatures.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 days

and then weekly. Take the default baseheating and cooling temperatures Thiswill produce a table as Figure 6.3.

85

Figure 6.3 Heating and cooling degree days.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 de!nition 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

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.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.4.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/cli-mate/CHE_Geneva_IWEC. Menuoption d is a toggle which tells ESP-rwhether the !le is ONLINE orOFFLINE. Set this to ONLINE. If it is

86

OFFLINE then others will not see this!le.

Figure 6.4 Menu for creating a cli-matelist entry.

The section of the menu under seasonsallows us to edit the beginning andending date of each season. Afterde!ning 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 de!ne seasons that do not start atthe same day of the week.

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 aftercon!rming 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 weekeight 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 con!rming eachof the seasonal suggestions and select-ing the graph ambient T and sea-sons option the interface should looklike Figure 6.5.

87

Figure 6.5 Seasons of the year.

6.3 Climatelist entriesThe !nal tasks are to record this infor-mation via the list/generate/editdocumentation option initialiseoption 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 yournewly created climate !le to the stan-dard folder. The next time ESP-r isused the new climate !le should be

available 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/usr/esru/esp-r/climate (or wherever the!le climatelist is located on yourmachine).

88

*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 Time MeanJan -6.8 @ 4h00 Fri 26 11.1 @16h00 Sun 14 1.1Feb -5.8 @ 7h00 Tue 27 11.7 @16h00 Wed 7 2.4Mar -2.7 @ 7h00 Tue 27 16.8 @16h00 Sat 10 5.9Apr 1.4 @ 7h00 Wed 11 22.4 @16h00 Wed 4 10.1May 1.6 @ 4h00 Tue 8 25.5 @16h00 Tue 15 13.4Jun 7.7 @ 1h00 Tue 19 29.0 @16h00 Mon 25 16.7Jul 10.5 @ 4h00 Thu 5 32.1 @16h00 Mon 9 20.3Aug 7.1 @ 4h00 Thu 30 31.4 @13h00 Wed 22 19.9Sep 8.3 @ 7h00 Fri 7 27.6 @16h00 Sat 22 15.7Oct 0.1 @ 7h00 Wed 31 21.1 @13h00 Mon 1 10.6Nov -4.1 @ 7h00 Sun 25 14.7 @16h00 Fri 2 4.7Dec -4.0 @22h00 Mon 31 9.8 @13h00 Mon 17 2.8Annual -6.8 @ 4h00 26 Jan 32.1 @16h00 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

89

Chapter 7

ZONE CONTROLS

7 Zone controls7.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 ide-alised 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

91

setup and can be more dif!cult to cali-brate.The !rst step in understanding howESP-r deals with idealised 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 idealised 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 de!ne 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 ef!ciency 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 speci!ed 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.

92

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 de!ne 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 of!ce 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 de!nenetworks of components for the twodesigns or we could represent theirgeneral characteristics via sensor - law

- actuator de!nitions.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 abstract"oor 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

93

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 speci!c layer of the"oor 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-de!ning the location of theactuator.Once the required characteristics of the"oor 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 aresimpli!ed. 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 dif!cult, 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 speci!c 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.

94

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 suf!cient 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 dehumidi!cation 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 modi!ed 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

speci!cation. 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 identi!ed.

• 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.

95

• 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 de!ned 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 speci!ed 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 de!ned 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 air"ow network. Another use of thiscontrol is to abstractly represent a"oor 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, heatingsetpoint, 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

96

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 air"ow 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-terise 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 con!rmation 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 con!guration !le is cellu-lar_bc/cfg/cellular_bc.cfg andin the list of exemplar models it is inthe technical features menu asthe !rst item.

97

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 of!ce 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 thisspeci!cation 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):

98

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 setpoint 15.00C cooling setpoint26.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 setpoint 19.00C cooling setpoint24.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 setpoint 15.00C cooling setpoint26.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 setpoint 15.00C cooling setpoint26.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 setpoint 19.00C cooling setpoint24.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 heaing capacity 0.0W. Heating setpoint 10.00C cooling setpoint30.00C.

Zone to contol 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 notenough 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 noticeis 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 a

99

change from controlled to free "oatingconditions.The last item in the report is the link-ages between the de!ned control loopsand the zones of the model. In this caseone control loop is de!ned 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 de!ne, 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 speci!c 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.5There are menu items for describingthe included controls, linking speci!ccontrols to speci!c zones in the modeland managing the controls (add/deleteetc.), checking controls and saving thecontrol de!nition to !le. As with otherfacilities in ESP-r, documentation is anintegral part of the model. Working

practices should enforce documenta-tion to set the context of the manyarrays of numbers that make up controlloop de!nitions.

Figure 7.5 Top level zone control menu.

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

Each control loop has one de!ned loca-tion for its sensor (although some con-trol laws will supplement this de!ni-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

100

questions the three indices are gener-ated.

Figure 7.6 Sensor choices.

There are two choices senses cur-rent zone db temp and sensestemp in a specific zone whichneed clari!cation. Some controls aregeneric and could be referenced bymany zones in which case the formeerchoice is used. If you have a controlthat senses conditions at a speci!c sur-face then the latter is needed. There aresome control laws that also require thata speci!c zone be identi!ed for thesensor and actuator location.Some models will be able to usegeneric control loops and other modelswill require separate control loops withspeci!c location information for sen-sors and actuators.And you can also de!ne control loopswhich are not linked to any zone in themodel, but which are available as

alternatives to link to at a future pointin time.The references temporal fileitem allows you to associate a sensorwith time-step based data e.g. from anexperiment.There are fewer choices for the actua-tor of an ideal zone control loop.Unlike other domains which mightcontrol two phase "ow or a damperposition, a zone control either adds orremoves "ux from a node within thesimulation solution matrix as shown inFigure 7.7.

Figure 7.7 Actuator choices.

Periods (Figure 7.8 and 7.9) arede!ned 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.

101

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 of!ce hours and a set-back tem-perature is maintained overnight with afree "oat from late Saturday till earlyMonday. Most of these expectationsare con!rmed in the performance dataincluded in Figure 7.10.Note that the set-point in the twoof!ces 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 suf!ciently 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?

102

Figure 7.10 Winter performance predictions.

Figure 7.11 Winter performance predictions.

103

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 of!ces are sensitiveto solar gains.If we want to evaluate the capacityrequired in these rooms we can use theSummary Statistics ->heat/cool/humidify report

which 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 peakwhich decreases over sev eral hours.

104

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 (brie"y 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 a

frost protection on days that start

above 5C.• altering the area of glazing to limit

the solar radiation entering the room• adding an outside shading device to

moderate 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 day!nds 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.

105

Figure 7.14 Spring performance predictions.

Figure 7.15 Spring switch from heating to cooling.

106

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 of!cebuilding 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 de!ned zones is to de!ne 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 de!ne anothercontrol which takes the mean tempera-ture of the manager_a and man-ager_b rooms and conditions theupper low-resolution occupied space tofollow the predicted temperature of the

de!ned 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.

107

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 setpoints 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 setpoint 15.00C cool setpoint 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 setpoint 19.00C cool setpoint 24.00C.

108

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 setpoint 15.00C cool setpoint 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 setpoint 15.00C cool setpoint 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 setpoint 19.00C cool setpoint 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 setpoint 10.00C cool setpoint 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 setpoint 16.00C cool setpoint 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 setpoint 20.00C cool setpoint 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 setpoint 16.00C cool setpoint 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 setpoint 15.00C cool setpoint 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 setpoint 19.00C cool setpoint 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 setpoint 10.00C cool setpoint 30.00C.

109

Zone to contol 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 supportscaling of focused model predictions.And by delaying the requirement forspeci!c details it may allow for a

broader exploration of design ideasduring the early design stages.

110

Chapter 8

THERMOPHYSICAL RESOLUTION

8 Thermophysical resolutionIn 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 decidingwhen additional thermophysical

resolution is required, techniques todetermine the resources needed andthen back to methods for taking advan-tage of 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 up!lling up hard disks for little or no ben-e!t to the simulation team. Tool-drivenpractitioners push buttons because theyexist. Readers of the Cookbook mightbe more inclined to be selective in theirbutton pressing.This chapter will be completed at alater date.

112

Chapter 9

PREPARATION FOR SIMULATION

9 Preparation for simulationIn 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 why such infor-mation is embedded in the model:• decisions made in the planning stage

can be recorded• clarify working practices• support for automation and produc-

tion 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. Thenbusiness became complicated and frus-trating. The predictions did not matchwhat was in the initial client report.What had changed? Where did the faultlie? Had the model become corrupted?Had the numerical engine changed in away that would cause different predic-tions? Eventually, after days of tests

the causal factor was found to be thenumber of pre-simulation days thatwere used. That particular value hadnot been recorded in the project notes.And thus it became clear that thedescription of the model would bemuch more robust if it included adescription of the speci!c assumptionsand directives used by the simulationengine.One of the side-effects of recordingsuch information is that it simpli!esthe task of carrying out production runsand reduces the chances of errors.It also supports implementing the plan.If, at the planning stage, the teamdecide that speci!c weeks will be agood test of building performance thereis a way to record these preferences sothat when the model is ready to test isisvery easy to implement the test.Further text to be added here.

Integrated performance viewsIn addition to directives about thenature of the simulation to be run ESP-r also supports directives about the per-formance issues which the simulationteam is interested. The jargon that theESP-r community uses to describedirectives describing what we want tomeasure and where we want to mea-sure it is Integrated Performance Views(IPV). Essentially, this is a formal

114

language which supports multi-criteriaassessments. Multi-criteria assessmentsprovide a rich set of information thatcan help simulation teams identifyunintended consequences of designdecisions as well as identify opportuni-ties for improvements in a design.How does this differ from the metersimplemented in other tools? The whatand where is a similar idea. The differ-ence is in how the raw values are usedafter they hav e been extracted. Eachitem included in the IPV has a statisti-cal report and tabular data and a sum-mary produced. Multiple report typesare generated because different usersrecognise patterns in different forms.And the IPV has similar risks to anyprior-speci!cation scheme. If it doesnot include a range of topics it will failas technique for enforcing multi-crite-ria assessments.This chapter will be completed at alater date.

115

Chapter 10

UNDERSTANDING PERFORMANCE PREDICTIONS

10 Understanding performance predictionsAs ESP-r workshops have evolved overthe years a pattern has emerged. Partic-ipants spend almost as much time inthe task of understanding the perfor-mance of models they created as theydid in creating the model. This samepattern is also found in simulationteams 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 and"ow 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 !lestores (depending on the number ofanalysis domains processed by the sim-ulation engine). Some would call theserandom access !le stores databases.The ESP-r suite include a module reswhich is able to recover the values ofthe thermophysical state from these

databases and present them in graphi-cal and statistical and tabular form.Other simulation tools tend to write outpre-selected performance data and relyon third party applications to parse andprocess and display such information.There are advantages and disadvan-tages in the approaches taken by differ-ent simulation suites.The essential difference is of philoso-phy. In one case you direct the simula-tion engine what type of data and thelocation of the data to record beforeyou run the simulation and in the othercase the user directives are essentiallydelayed until the point of data extrac-tion.

Risk: if the simulation engine onlyrecords what you ask it to recordunintended consequences or oppor-tunities may not be identi!edRisk: performance data needed forclari!cation may not be availableand require altering the save direc-tives and re-running the simulation

3 Bene!t: for standard reports and forcases where you already know whatyou want to measure then user direc-tives and third party tools can bemore ef!cient.

The res moduleRes is a tool for interactive explorationof a rich data store. It allows users to

117

create ad-hoc collections of informa-tion and view them in different formatsor perform statistical operations on thedata or !lter it in various forms. Suchfacilities are used by practitioners toreact to ad-hoc questions and toexplore dependencies within themodel.Because the display of graphs andtables and tabular data is optimised forinteractive work it tends not to be at adisplay resolution which is suitable forpresentation reports and the typicalapproach taken is to export the relevantdata in a format that can be processedby a third party application.This chapter will review the types ofinformation that is held in the datastore as well as the various views of thedata that can be generated. And, ofcourse, the core purpose of the chapteris in methodologies of explorationwhich have been proven successful inidentifying unintended consequencesand opportunities.This chapter will be completed at alater date.

118

Chapter 11

FLOW

11 FlowThis Chapter focuses on air"ow model-ling techniques in ESP-r:• overview of network air "ow model-

ling;• the art of planning "ow networks;• de!ning 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 in!ltration and ventila-tion. For example a user could stipulate0.5 air changes of in!ltration 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 in!ltration 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 coupling

between 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 considerable"exibility in describing a range ofdesigns and the potential to increasethe resolution of models to supportassessments which are dependant 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-driven"ows within zones and/or environmen-tal control systems that are associatedwith the network. The "ows at nodesare a function of nodal pressures and

120

the connected components’ characteris-tics. The mass balance at each node issolved using a customised Newton-Raphson approach. The solution iter-ates until it converges and the pressureat each node and the mass "ow througheach connection are saved.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 in"uence 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 Behaviour within WholeBuilding Performance Simulation (ASamuel, 2006), Energy Simulation inBuilding Design (J A Clarke 2001),The Adaptive Coupling of Heat and Air

flow 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 ef!cient 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 tode!ne "ow networks explicitly. Anexplicit description allows knowledge-able users to control the resolution ofthe network as well as the choice of"ow components and their details.This approach assumes that the userhas opinions about "ow paths as wellas access to relevant information about

121

the "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 tode!ne 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 (rarelyused);

• 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 de!ned to track the tem-perature of a speci!c "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, a"ow 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 simpli!ed.

Pressure coefficientsThe jargon we use to express changesin pressure due to changes in winddirection is a pressure coef!cient Cp.In ESP-r, Cp values for standard anglesof incidence (16 values to represent360°) for a speci!c location are held asa set.ESP-r has a database of Cp coef!cientsets for different types and orientationsof surfaces derived from the literature.

122

Lets be clear about this, one of thegreatest points of uncertainty in "owsimulation is in the derivation of pres-sure coef!cient 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 coef!cientsbut 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 pro!le and accounts fordifferences between wind measurementheight and surrounding terrain (urban,rural, city centre) and building heightand surrounding terrain.Wind pro!les can be calculated usingthree different models: power-law,LBL, logarithmic.Caution is advised in the use of Rf val-ues as the pro!les 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 in!ltration heating studies to repre-sent worst case conditions.

11.3.1 Flow componentsFlow components (e.g. fans, pumps,ducts, cracks, valves, ori!ces etc.)describe the "ow characteristicsbetween "ow nodes. Flow is usually a

non-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, ori!ces anddoors. Generic !xed volume or mass"ow 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 mass"ow (35) are abstract representationsof a fan (can be controlled toapproximate variable speeds).

• Common ori!ce (40) can be used foropenings with a user de!ned dis-charge coef!cient

• Speci!c air "ow opening (110) has a!xed discharge coef!cient and onlyrequires an area.

• Speci!c air "ow crack (120) is use-ful for openings up to 12mm wide.

123

• 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’of!ce’ via component ’door’.A connection also de!nes 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.

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 looking

124

down (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 procedureswhich 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 ori!ce to repre-sent the window when it is opened as

well 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.

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.

125

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-de!nedand 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

networks of dozens of nodes and com-ponents 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!

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 expect

126

there to be differences in air tempera-ture within a building.For example, if you believe that aperimeter section of an of!ce 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 nodes

Linking the nodes and components is acritical step which bene!ts 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.

127

Window

Node

Crack_under_doof

Crack_at_wingow

examination reception

Figure 11.6: simple network for doctor’s of!ce

11.5 A simple networkTo illustrate the process lets create asimple network for the doctors of!cethat 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 mor-tar would not change the thermophysi-cal state of the wall, but the air movingthrough the crack might be noticed. In

ESP-r the description of the zone andthe "ow network can differ as long aswe remember the intent of the differ-ence.Air can also "ow around the frames ofthe windows. It is dif!cult 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.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 lets

128

assume 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 several"ow components which might be use-ful. And before we look at the compo-nent details it is worth consideringwhether the windows in this doctorsof!ce 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 win-dow operates will determine the typesof "ow components we should use aswell as the connections we establishwithin the "ow network.

ESP-r offers a pre-de!ned windowcomponent which only requires theopening area, it also includes a com-mon ori!ce 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 iscentred 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 con!rm whether forcedventilation in the doctors of!ce 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 con!rm the general char-acteristics and response of the buildingwe can consider whether a speci!c fancurve should be applied to the model.

What kind of room?What else might require our attention?Looking back at the dimensions of the

129

doctors of!ce 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.25m

south - 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 - ori!ce 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 azone node and end at a boundary nodeso that the "ow is outwards. For otherconnections the order is not

130

numerically important.It does help to have a consistent policywith openings to the outside because a"ow along a connection is reported as apositive number if it is in the samedirection as the connection de!nitionand 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 de!ne 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 !rstde!ne 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 con!rm 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 de!ne the nodes !rst and then de!nethe 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.

131

Figure 11.8: auto-generated nodes

Figure 11.9: adding boundary nodes

Figure 11.10: the completed components

132

Boundary nodesThe next step is to de!ne 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 con!rm the heightcheck the notes (aren’t you glad youmade a note of this). You will also beasked about which pressure coef!cientset 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 de!ne. The orderyou create the components is notimportant. When you de!ne theextract fan as a constant volume "owrate component note the various waysyou can de!ne 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 thebrowse 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 de!ning 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 de!ne allof the links with boundary nodes !rstand then they de!ne links betweeninternal nodes.Another pattern is in the de!nition ofheight differences. The boundary nodeswere de!ned 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.

133

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-de!ne connections. For this exercisethere are three sets of parallel

connections involving the windows andthe cracks. The interface will ask forcon!rmation when you de!ne the

134

parallel connection. The interface willask you if you want to auto-generatethe connections. For this exercise sayno.

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 con!rm 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 of!ce.

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 expectsigni!cant "ows, especially on dayswith some wind where up to one airchange per minute might occur. Wewant to include in our assessment daysthat have a variety of wind speeds and

directions.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 becarried out on the model to ensure thatit it both syntactically correct and thatthe model dependencies are correct.

135

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 of"ow 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 in!ltration cooling in the examina-tion room is minimal. The in!ltrationcooling (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 weneed 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 of"ow 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.

136

Figure 6.14: temperatures during spring assessment

Figure 6.15: temperatures and air cooling during spring assessment

137

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 de!ne "ow con-trol loops. A control loop senses a spe-ci!c type of data at a speci!c location,the sensed value is evaluated by a con-trol law and the control actuation isapplied to the component associatedwith a speci!c "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 conditionsto 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 re"ect 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 of!ce, 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 de!ned by itslocation and the values which it cansense. These include temperature, tem-perature difference, pressure, pressuredifference, "ow rates, humidity, etc. atnodes within the network. It is also

138

possible to sense temperatures in zonesor climate data.Most "ow components are able to becontrolled. Control is expressed as amodi!cation 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 speci!cinstances 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 thede!nition 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 - butswitches to an alternative rate/area as afunction of the sensed condition - low

rate 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 of!ce, the initial"ow 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 con-trol could approximate this?

139

• ON/OFF with ON expressed as afraction 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-de!ne 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 re"ected 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 for

each of the windows allowing them toopen 25% of their de!ned area if thetemperature rises over 22°C. We willde!ne 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 de!ne "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 de!ne the win-dow opening regime (closed at nightand weekends and open 25% if over22°C) during 8h00-18h00 weekdays(Figure 11.18).

Figure 11.18: control loop interface

140

prior to adding periods

Figure 11.19: control loop interfaceafter adding periods

Select the ’wkd’ day type and de!nethe 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 flowconnection and then the relevantconnection that uses the long_win "owcomponent.Next edit the period data for the ’wkd’.The !rst period is an unoccupiedperiod so use a high temperature forthe set point. After editing the interfaceshould look like Figure 11.20.When !lling in the data for Saturdaysand Sundays there is no need to re-de!ne the sensor and actuator ("owcontrol loops use the same sensor andactuator location for all day types andperiods). Once all the day types have

been de!ned 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 simple thermostat thatdoes not know what day it is. The con-trol should re"ect this by having oneday type and one period. This controlwill sense the temperature at the Exam-ination node and the connection relatedto the extract fan will be where thecontrol acts.Update the control !le and generate anew QA report and look at the detailsand your notes to see if the data is cor-rect.Re-run the simulation. If you turn onmonitoring during the simulation youmight see something like the Figure11.21. Now the temperatures in bothrooms are much closer and they areboth warmer than ambient. If we usethe results analysis tool and look at the"ow entering the Reception the "owrate is based on the crack componentbecause the temperature did not goabove the control set point.

141

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 con!rm thecontrol is working. When monitoringthe simulation (Figure 11.22) we cansee that Examination seems to peak at24°C (which happens to be the setpoint for the extract fan) and there issome rapid changes in the receptionnear the 22°C temperature point.Because Examination is constrained by"ow under the door it has almost no airmovement until the extract fan turns

on.The energy implications of the windowopening is clearly seen if we plot zoneflux -> infiltration in theresults analysis module. The windowsopen brie"y 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.

142

Figure 11.22: warm period with controlled windows

143

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 the"ow paths and components. The fol-lowing discussion uses a model withthree 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 in

their 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 in"uence 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 in!ltra-tion are rare the crack component is abetter representation of the "ow paththan de!ning a very small ori!ce.

144

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 de!ned). This crack compo-nent (door_crack) is 0.8m x 10mmand is used many times

• The adjacent space node should bede!ned as using the current tempera-ture of the "ow node in the !rstzone.

• Manager has one window opening(window1.67) which is 1.67m2 isde!ned once and used once

• Manager_t_b (with upper and lowerwindows) needs 2 windows

(win_up_.884 and win_low_.884)which are separately de!ned.

• Manager_bi (with a bi-directional"ow opening). The component(win_bi) is Xm wide, Ym tall, has adischarge coef!cient 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 de!ne difference bi-directionalcomponents for use in different con-texts.

• Boundary nodes are de!ned at thespeci!c height of the opening orcrack they are associated with. Thisallows a zero difference in heightbetween the boundary node and thecomponent.

145

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. De!ne the bound-ary nodes to re"ect 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 beapplied.

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 de!nition works best?• an air "ow opening does one-way"ow 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 win-dows;

• bi-directional "ow can be approxi-mated with a pair of air "ow open-ings. Stack effects are accounted forif heights are correctly de!ned;

146

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 no"ow. 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.

147

Figure 11.26: portion of an of!ce 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 anof!ce building (which includes a recep-tion, conference room, general open-plan of!ce and cellular of!ce). Exceptfor the cellular of!ce, 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 ventilation

rather 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.

148

Figure 11.27: in!ltration model within of!ce building

In evaluating whether a "ow networkrather than a "ow schedule is appropri-ate:• there can be considerable differences

between imposed in!ltration and thepredicted in!ltration rates.

• in an open plan of!ce 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-zonelinkages and in!ltration paths (Fig-ure 11.27)

• a model variant with zone-to-zonelinkages, in!ltration paths and con-trolled dampers on each facade ori-entation (Figure 11.28).

These three variants are included asexample models. If you are interesteduse these models to explore "owissues. Review the model documenta-tion, especially the sketches of the "ownetworks. Compare this with the con-tents of the "ow network !le and theinterface.

149

Figure 11.28: vent model within of!ce building

Scheduled flows in an open plan officeThe version of the model with sched-uled "ows will yield predictions wherethe energy implication of in!ltration 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 in!ltration and"ow between zones transforms the pre-dictions in several ways (as seen inFigure 11.30): wind speed and direc-tion are now taken into account and

there is a moderation of demands asheating 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.

150

Figure 11.29: scheduled "ow performance

Take your time when exploring "owresults. Discovering approaches to theuse of the results analysis modulewhich yield clear indications of "owperformance is an investment well

worth making. The quantity of infor-mation can be large and there are sev-eral different views of the "ow predic-tion data as well as reports on theenergy implications of "ow.

151

Figure 11.30: predicted in!ltration performance

There is one substantial omission in thereporting of "ow. It is not at all easy toget an overview of what is happeningthroughout the network at a singlepoint in time. Such a feature would

speed up the discovery of patternswithin a network. Currently users mustmanually collect this information.

152

Figure 11.31: predicted facade vent performance

A word about saw-tooth predictions.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 run

assessments 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.

153

11.12 Hybrid ventilationIn 2000 the Chartered Institute ofBuilding Services Engineers publishedMixed mode ventilation CIBSE AM13(ISBN 1 903287 01 4). This publica-tion de!ned 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 thede!nition 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 de!ned via a network of parallelor sequential decision points (see Fig-ure 11.4) can be implemented. The

need for additional bookkeeppingnodes to de!ne such logic paths limitshow well 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 de!ned in CBISE AM13 placesconsiderable demands on the facilitiesof simulation tools. Until 2008 it wasdif!cult 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 of!ces side-by-side that

154

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 a"ow network that can deliver 5 airchanges to the of!ce 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 des-crition of the window control logic sothat the fan turns on if conditions arenot suitable for window opening. Theright zone uses the mixing box duringof!ce 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 electical energy used by the fan"ow 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.

155

Figure 11.33: of!ces 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 setpoint 16.00C cool setpoint 16.10C.

3 18.00 db temp > flux free floating

Zone to contol 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.Per|Start|Sensing |Actuating | Control law | Data

156

1 0.00 dry bulb > flow on/off setpoint 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 setpoint 25.00inverse action AND sensor 2 ambient T setpoint 10.00 direct action AND sensor 3 sensenode manager_a setpoint 21.00 direct action.

3 17.00 dry bulb > flow on/off setpoint 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 setpoint 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 setpoint 25.00inverse action AND sensor 2 ambient T setpoint 10.00 direct action AND sensor 3 sensenode manager_a setpoint 21.00 direct action.

3 17.00 dry bulb > flow on/off setpoint 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 setpoint 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 setpoint 25.00inverse action AND sensor 2 ambient T setpoint 10.00 direct action AND sensor 3 sensenode manager_a setpoint 21.00 direct action.

3 17.00 dry bulb > flow on/off setpoint 100.00 direct action ON fraction 0.000.. . .

Figure 11.35: hybrid vent performance

157

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 con-ditions.

• Temperature distributions within airvolumes cannot be determined (e.g.strati!cation).

• Momentum effects neglected.• Insuf!cient resolution for local sur-

face convection determination.

158

Chapter 12

DETAILED FLOW VIA CFD

12 Detailed flow via CFDGiven 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 mature!eld 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 "ow!eld. 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 to

gain by enabling the two solvers toexchange information as the simulationprogresses.What has been implemented in ESP-ris a radical approach to a dif!cult 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 roomsfrom the zone operations schedules arenoticed by the CFD solver and can be

160

associated 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 de!ne a CFD domain, meth-ods for designing a gridding schemewithin the domain, and what to lookfor in the performance predictions.There are also some information boxesand dragon boxes where particular careshould be exercised.

This chapter will be completed at alater date.

161

Chapter 13

PLANT

13 PlantIn ESP-r environmental control sys-tems can be represented as either so-called idealised 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 particular

components or control deviceswithin the network have manyoptions for creating models whichare close approximations

• those interested in high resolution ofboth system components and mass"ows 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

163

• 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 dif!cult 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 simpli!edrepresentation 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.

164

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 idealised 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 addition

to 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 speci!c 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).

165

Figure 13.2 Components (with attributes shown).

Figure 13.3 Connections between components.

166

The pattern for creating components issimilar (see Figure 13.5). When youhave !nished de!ning 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 toFigure 13.1 - the heater is supplied bythe supply_fan so when you set up a

link 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.

167

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

Component: zone_b ( 8) db reference 25

168

Control 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.

169

13.2 Defining containmentsComponents exist in a context (or con-tainment), such as surrounded by a!xed 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.

7.3 Finishing off the model and test-ingAt 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 allowsyou to re-run this assessment withouthaving to look around for scraps of

paper. 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 con!r-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.

170

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).

171

Figure 13.9 Graph of return duct temperature.

Figure 13.10 Statistics at return duct b.

172

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 x2.4m deep x 2.81m high will be equiv-alent. If all surfaces in the rooms are

attributed 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 bene!ts and drawbacksand it is well worth exploring both.

173

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 con!guration folderof mech_vent_2z and restart the projectmanager with the con!guration !le wewant to modify. As soon as the modelloads change the root name to

mech_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.

174

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 of!ce hours and0.2 air changes of in!ltration 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 connectionbetween 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.

175

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 10containments.

176

Figure 13.15 Connections after editing.

13.4 Links to zones and controlsAt the bottom of the network de!nitionmenu there is an option link plant tozone. Before we can use this facilitywe need to de!ne two zone controlsand that requires saving the network ofcomponents and changing to the zonecontrols menu to initialise 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 de!nethe 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 agood time to save the network of com-ponents. You will be asked whether thezone controls should be updated tore"ect the recent changes in the

177

network 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 de!nition of the net-work of components.We now hav e to de!ne the logic whichwill drive the heater component and forthis we must de!ne 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 clari!es the relationshipbetween the control law and the controltype. These relationships are requiredbecause some components work on"ux and some on "ow and the actua-tion needs to re"ect this.

A word about the data for the on-offcontrol period. There are seven param-eters:• mode of operation (1.00)• off setpoint (23C)• on setpoint (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.

178

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 parame-ters is to run a series of simulationstypically changing one aspect of a con-trol or a component parameter at a

time. 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!.

179

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 havede!ned a couple of component net-works and developed some pro!ciencyat the tasks involved. The goal is to

employ the most appropriate approachto a given simulation project and onlyusing complex facilities where a lesscomplex approach does not support therequirements of the project.

180

Chapter 14

WORKING PROCEDURES

14 Working proceduresSimulation teams who are attemptingto deal with real designs in real timecan deliver less than they intended orwork harder than they intended for anumber of reasons:• 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

or failure to !nd notes about criticalassumptions

• misunderstanding the nature of theassessments to be carried out

• hacking model !les for a quickchange without documenting thechange, checking that the changewas syntactically correct or runningcalibration tests

• assuming that everyone else knowsthat ext_glas is intended for use onthe only the south facade of thebuilding

Such self-in"icted errors and omissionsare only the tip of the iceberg. Softwarevendors, even if they wanted to, havelittle or no in"uence on the organisa-tion and procedures of simulation workgroups let alone the form and contentof interactions between team members.The following discussion is an expan-sion of ideas that the author and otherscontributed to Building energy and

environmental modelling: CIBSEApplications Manual AM11: 1998 TheChartered Institution of Building Ser-vices Engineers, London, April 1998.And, as is mentioned in the ModelQuality chapter, the recommendationsin AM11 continue to be valid andshould be on the bookshelves of everysimulation group. From the perspectiveof the Cookbook AM11 tends to beunderstated in its recommendations.The Cookbook’s de!nition of QA &QC extends the traditional risk man-agement and consistency checkingfound in AM11 to include proceduresand organisational patterns that helpidentify opportunities for deliveringadditional value to the design process.Many of the extensions to standardpractice require minimal resources.They are not rocket science althoughthey require attention and "exibilityfrom members of the simulation teamas well as others in the design process.Simulation teams who thrive inv estconsiderable passion in working prac-tices which compensate for the limita-tions in their tools. This chapter is, inpart based on a decade of observationof successful and un-successful simula-tion groups. Space constraints havelimited the number of examples ofworking procedures and the depth ofdiscussion of their details. Considerthis chapter as a starting point for

182

creating your own working procedures.The complement of this chapter is theModel Quality chapter which expandssome of the issues raised in the follow-ing text.

14.1 How can the vendor help?In one sense, the topics covered in thischapter are independent of softwarevendors because there are many possi-ble ways to deploy simulation tools andas many preferences of use as their aresimulation teams. Although speci!cexamples are given from the context ofESP-r, users of other software willprobably !nd much that is familiaralthough some adaptations may berequired on the working procedures to!t the conventions and facilities ofanother tool.Vendors do have in"uence - their mar-keting to managers is spun to empha-sise productivity gains and ease of useand their brochures are full of astound-ingly complex models. Once thelicense is purchased vendors have moreincentive to train users on keyboardskills than to support managers whowish to evolve better working prac-tices. There is also little incentive tohelp managers understand what consti-tutes a model which is well-suited tothe needs of a particular design project.Vendors mount training courses whichare optimised for keyboard skills, pro-duction tasks and rapid generation ofmodels. Less attention is paid to themore esoteric skills (e.g. modelabstraction, interpretation of results).Materials which address these issuesmay be available if you know who theask and what to ask for.

Vendors in"uence is greatest in thecore design of the tool. There are twogeneral classes of shortcomings whichimpact simulation teams. The !rst thethe tendency to equate model qualitywith if what you see looks correct itmust be correct. Optical illusionsabound in simulation so simulationteams must employ robust proceduresto enforce model quality.The second shortcoming is that it is farto easy for independent actions by mul-tiple users to cause clashes which aredif!cult to resolve. Although simula-tion data models are among the mostcomplex dreamt up by humans they arenot implemented via database manage-ment tools that support simultaneoususer interactions. This limits thedeployment of simulation in distributedwork groups.

14.2 Responsibilities within simula-tion teamsAlthough there are successful indepen-dent simulationists, simulation tends tobe most powerfully deployed in a teamenvironment.Why would this be the case? Firstly,simulation demands a range of skillsets e.g. managerial, technical andcommunication skills.Second, projects can fall short of theirgoals if errors in methods or descrip-tive details are not identi!ed. Someindividuals can perform the mentalshifts required, but self-administeredQA is an invitation to risk that is dif!-cult to overcome.Third, as simulation tools becomemore complex and their facilitiesexpand into new analysis domains, it is

183

increasingly dif!cult for an individualto be pro!cient with all aspects of atool or to manage the volume of detailincluded in complex models. Realdesigns often imply a level of complex-ity which can only be managed withina team environment.There are, of course, options for indi-viduals to work jointly in ad-hoc teamsusing the facilities and techniques ofsimulation teams who are geographi-cally distributed.For most projects, the limitations insharing models and maintaining a vir-tual team is not the speed of the inter-net, but the inability of simulation soft-ware to cope with asynchronousmanipulation of models and, to a lesserdegree limitations in the underlyingdata model which make it dif!cult toembed documentation and assumptionsrequired by well formed working prac-tices or maintain a log of actions taken.In an ad-hoc or formal simulation teamthere are a number of participants:

The team manager, who worksfrom the perspective of projectgoals, client requests, resource lim-its, delivery dates and staff moti-vationThe 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-ablesSimulation staff, who implementthe work plan, coerce the tool to!ts the needs of the project, com-mission assessments and carry out

production related data extractionand interpretation of predictionsDomain experts who, on an ad-hocbasis, help to de!ne the modellingapproach, con!rm predictions andidentify opportunities and glitchesMentors are also ad-hoc partici-pants in the process during theplanning process and tend to befocused on creating new workingpractices and augmenting staffskills.

Setting up a simulation team is not atrivial task as can be seen in section4.2.1 of CIBSE AM11. Time has notdiminished the critical truths in the sec-tion on human resource requirements.

14.3 Classic mistakesObservations over a number of yearsindicate that simulation teams tend tounderestimate the time investmentrequired to create and evolve workingprocedures. Similar optimism pervadesthe task of maintaining and extendingstaff skills.Conference papers tend not to hi-lightthe risks associated with team man-agers who hold themselves aloof fromknowledge of the tools used and arethus unable to adapt their directives totake advantage of the strengths of theirstaff and tools. Bluntly stated - errorsand omissions in management are noless important than errors and omis-sions in technical execution.There are any number of working pat-terns that result in a misallocation ormisuse of the skills of staff. Each ofthese sub-optimal working patterns hasone or more alternatives which make

184

better use of tools and/or staff skills.First there is the classic confusion thatkeyboard pro!ciency implies domainskills. Opinionated users with appro-priate background skills to guide theiruse of the tool have a distinct advan-tage what ever their speed of interac-tion.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.Managers often believe that userfriendly software allows junior staff tofunction with limited supervisionand/or limited training. What tends tohappen is that junior staff lack the self-restraint to avoid complexity andbecome driven by the tool.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-nise the directive is suspect or the con-!dence to request clari!cation. Thenovice thus works very hard at digginga hole for the team to fall into and lackof attention ensures the pain is distrib-uted.Another classic tempting-of-fate is anassumption that ability to generatereports and graphs equates to a anunderstanding of the patterns withinreports and graphs suf!cient to addvalue to the project. Valuable patternswithin a data set can remain hidden justas indicators of error can pass unno-ticed.

Such paths to failure can be avoided.For example, those with the maturityand intuition needed to quickly andaccurately recognise patterns in perfor-mance predictions are often found in anearby of!ce. That such valuableassets are out-of-the-loop is a self-in"icted limitation. Bring them into theconversation.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. Is the in-built facilitybased on rules and concepts that theteam agrees with? Are the resultingentities understandable and do theyconform to the requirements of theproject?

185

14.4 Planning simulation projectsThe author once had a consultingproject to evaluate whether mechanicaldampers could be used in the facade ofan of!ce 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. A synopsis of the !ndingswas available !ve hours after the plansand sections were !rst opened.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• de!ning 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 of!ce and facadeelements was straightforward and

attribution proceeded without interrup-tions. It was then possible to use theseelements 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 experts, a typical approach. Ifless than a quarter of the project is usedfor preparation then the risk of delaysand errors later in the processincreases.The following table includes a numberof issues which may confront simula-tion teams in the planning stage.

186

Core issue Related issue ActionsDoes theclient/design teamhave prior experi-ence with simulationbased assessments?

Prior experienceeases the educa-tional task otherwiseclient expectationscould be an issue.

Ensure time and resourcesfor clear communicationwith the client. Brief theclient on the nature of theinformation they will beasked to provide and con-sider their response.

Does theclient/design teamknow the types ofperformance datawhich can be gener-ated and the avail-able reporting for-mats?

Management ofreporting expecta-tions.Identi!cation of howinterim results canbe communicated.

Review client preferencesas well as clarify potentialmisunderstandings in deliv-erables.

Has the client usedlanguage or providedsketches that indi-cate beliefs abouthow design willwork? Simulationcan test such beliefs.

The best time to testbeliefs is as soon asthey are noticed.The creation ofquick focused mod-els which can deliverinformation withminimal delay iscritical.

Con!rm that staff hav e theskills to deploy the types offocused models needed inthis project.Con!rm if typical data forthe type of building if avail-able.Create a test case to con!rmthat staff can extrapolatefrom sketches and capturethe essential characteristicsof a design.

Has the client indi-cated what criteriawould signal suc-cess?

What magnitude/fre-quency of change inthat criteria?What additional per-formance data mightbe captured to helpthe simulation teamcalibrate the model?

Con!rm if criteria in keep-ing with current practice oris it a client-speci!c de!ni-tion.Investigate whether the cri-teria provide useful indica-tors for what-if questionsthat the client has not yetraised.

187

Core issue Related issue Actions

Has the client indi-cated what criteriawould signal failure?

What magnitude/fre-quency of change?What are likelymodes of failure?What needs to bemeasured to identifyrisk?

Con!rm criteria are inkeeping with current prac-tice or are client-speci!c.Evaluate likely assessmentsthat will test how robust thedesign is.Identify operational regimesor boundary conditions thatwould help identify risks.

Is the design teamsearching forimprovement on arange of issues or asingle issue?

Multiple issuesmight require severalmodels or modelvariants.

Con!rm if staff can copewith multiple models and/ormodel variants likely in thisproject.Clarify how are differentmodels or variants to beidenti!ed.

Are what-if ques-tions in the formwhat happens if weuse a better qualitylow-e glass or whathappens if we useproduct X?

The role of the simu-lation team in thedesign process mayneed to be "exible.Is it to provide infor-mation for other tomake decisions or isit pro-active?

Identify methods might toidentify a better qualitylow-e glass.Raise the issue of wither asupplied speci!cation isappropriate and in theclients interest.

Do what-if questionspose parametricquestions (e.g. whichskylight areabetween 12 and 36%is the point wherecooling demandescalates)?

The distributed !lesystem used in ESP-r models has thepotential to simplifyparametric studies orcomplicate themdepending on thenature of the param-eter to be changed.Early con!rmation isessential.

Con!rm tool supports thecreation of model variantsrequired for this project.Discuss whether it will benecessary to generatescripts to automate para-metric tasks.Con!rm the script is correctand that correct data hasbeen extracted.Consider if scripts andmethods re-usable.

188

Core issue Related issue Actions

Is this project similarto previous projects?Can we adapt a pastmodel for use in thisnew project?

What did we learn inthe previous projectwhich could beapplied?What were the dif!-cult issues in pastprojects of this type?

Con!rm if staff hav e theskills to re-use and adaptexisting models.Con!rm if the existingmodel well documented.Con!rm log of the proce-dures and staff resourcesused to see if the currentresource allocation isappropriate.

Does the currentstate of the modelre"ect the ideas andconcepts developedduring the planningstages?

Is the complexity ofthe model consistentwith the resourcesallocated to theproject?Have the resourcesused matched theinitial plan?

Consider if staff tasks needto be adjusted.Consider if additional staffrequired.Plan for contingencies ifstaff become ill.

A potential projectwill be discussedwith a client in ameeting tomorrow.

Who should takepart in the meeting?What is the near-term work load?What key phrasesare important to lis-ten for?How much do weneed this project?

Review details of similarprojects and the staffinvolved.Discussion criteria fordeciding whether to bid onthe job.Ensure that presentationsand sample reports areavailable if the client needsto be briefed on team capa-bilities.

14.5 Team managerIt is critical that someone considers thebroad sweep of issues within theproject as well as the clients goals. Fewcan manage the mental leaps needed toshift from the detailed focus of simula-tion use to a broad perspective. It isusually considered good practice toensure that simulation staff hav e access

to someone who is paying attention tothese other perspectives.It is possible to adopt pro-active or pas-sive approaches to team managementas long as the frequency of communi-cation and the rigourous testing of theplan and the deliverables is maintained.The team manager may be appointedon project basis or hold the position for

189

a number of projects. In some teamsindividuals service several positions -in one project they may act as the teammanager, in another they may carry outsimulation tasks and for another theyfocus on quality issues.Flexibility has several bene!ts:

It allows ad-hoc teams to be formedwith the best available talent.It ensures that staff who have abroader range of skills and haveopportunities to exercise andimprove those skills.It can distribute skills to recognisewhat simulation tasks are straightforward and which are likely to betedious.

It is particularly helpful if a simulationteam has access to those with experi-ence in the operational characteristicsof buildings as well as in strategies forsolving design problems. Such knowl-edge, if deployed interactively, canspeed up the process of testing designissues.Remember, others in the designprocess may know very little about thework of simulation teams and whatinformation they can deliver. If thesimulation team has suf!cient con!-dence to allow others into the process,there are signi!cant opportunities forboth parties to discover concepts andideas that will be of mutual bene!t.And one of the bene!ts of interactiveworking is that it gets around the rigidstructure of formal reports and the lim-ited topics that can be included inreports. Fifteen minutes of browsingperformance predictions (the ESP-rresults analysis tool is speci!cally

designed for interactive use) mayuncover patterns that would not havebeen included in a report might havetaken hours to format for a formalreport.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. The Cookbook is writtenin the context of ESP-r. Simulationteams may have a preference for onesimulation tool and if you are readingthe Cookbook then ESP-r may be yourpreference. It may be possible tocoerce your preferred tool to carry outa range of tasks but the lack of choicemay impose a cost. There are virtualphysical descriptions that other simula-tion environments provide which mightbe more appropriate for a speci!cdesign.The Cookbook recommends that simu-lation teams review the capabilities andcost-of-use of simulation tools anddevelop selection criteria. The costsassociated with acquiring and support-ing multiple tools should take intoaccount whether staff are able to copewith multiple tools or if additional staffare 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 a

190

crises, 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, nei-ther the team manager nor simulationstaff are in a good position to recognisewhether the model continues to be !tfor purpose, whether the latest perfor-mance predictions are providing a con-sistent story or include a new patternwhich needs attention.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 clari!cation from staff.And what if the quality manager didnot have to wait for others to generatereports and did not have to look overtheir shoulders to see the current stateof the model and/or assessments?What must phrases such come over tomy screen and see what I found in theMonday morning start-up test periodoriginate with simulation staff?An ability to use simulation tool facili-ties to review models, generate reportsabout the models breaks a classicdependency. An additional pair of eyeswith pattern matching skills and differ-ent goals increases the probability ofdiscovering opportunities as well asfaults. A decision to invest in suchskills for quality managers transformstheir mode of working from passive toactive.Such pro-active inv estigations need notbe a burden in time or computing

resources - if the group has methods inplace to target simulations on speci!cshort period assessments. Indeed, thecriteria one might use for initial cali-bration runs would often do dual-dutyas periods for the quality manager touse. In the case of ESP-r, it is possibleto pre-de!ne simulations and embedthis information within the model.For many simulation tools the skillsnecessary for browsing a model andinvoking a pre-de!ned simulation canbe acquired in a few hours. Of course,more time is needed to become com-fortable with browsing performancepredictions 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 initiallyde!ned 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 reserving projectresources for the exploration of valueadded issues. This requires tracking the

191

progress of the project and ensuring,where possible, that there is time avail-able for exploring issues that the clienthas not yet raised.Such resources may be in the form oftime for simulation staff to undertakespeculative explorations or it mayrelate to a current or past project.As the Cookbook has mentioned inother sections, ef!ciency gains shouldbe directed at freeing up time to livewith the model and explore its perfor-mance and thus better understand howit works.Typically the quality manager will havea list of classic questions and issues toexplore within the model.

If there is an early peak Mondaydemand 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.

192

Core issue Related issue ActionsIs the current projectsimilar to a pastproject?

Is there valuableinformation in theproject notes anddocumentation?Do staff rememberuseful/critical issuesfrom that project?

Discuss !ndings with theteam manager as well as thesimulation staff.Review the past modelswith the team and identifycritical issues to be trackedin the current project.

Are there designissues in this projectwhich are new to thesimulation team?

What might be validapproaches for eachissue?Can a simple modelallow the team toexplore this issueprior to implement-ing it in full scale?Should the mentorbe called in?

Review criteria used toidentify which approach isbest.Find out who needs to worktogether to test out theapproach.Con!rm points in the work"ow where interactionswith the quality managerare needed.

What namingscheme will clarifythe model to othersin the design team?Is the client visuallyoriented or numberoriented?

Does the client talkabout the projectusing phrases thatcould be embeddedin the model?Are the essential dif-ferences in modelvariants communi-cated by the namingscheme?

Con!rm if the simulationtool cope with the namingscheme?Consider whether manufac-turer’s names for productsappropriate for use in theproject.Con!rm which performancedata can be presented invisual form to match clientpreferences.

What documentationhas the client pro-vided?

Has a review of thisdocumentation iden-ti!ed questions thatneed to be resolvedprior to work start-ing?

Con!rm if some or all ofthe client documentation beheld with the model.Advise on who shouldembed this documentation.

193

Core issue Related issue Actions

Does the clientrequire a record ofthe tasks undertaken,the method(s) usedand the model?

Are staff keeping alog of what they did,what assumptionsthey made and whatinformation sourcesthey used?

Show the model to a thirdparty and see if they under-stood the essential attributesof the model.

Does the model con-tinue to re"ect theinitial plan or doesthe plan need tochange?Are there resourcesavailable for valueadded opportunitiesto be explored?

Is the actual com-plexity of the modelin the same order ofmagnitude as the ini-tial plan?

Investigate if delays in taskscould make it dif!cult tokeep to the plan.Ensure updates to the modelbeen broadcast to all inter-ested parties.Outline value added issuesthat need to be discussed.

The model predic-tions indicate 15%less heating capacity- is this an error or isthis an opportunity?

What changed in themodel?Who made thechange to themodel?Who can corroboratethe difference?

Identify other performancedata which could be in"u-enced by this change.If an opportunity, inv esti-gate further changes changeto the model to furtherimprove performance.

During checking itwas found that occu-pancy in sev eralrooms was less thanspeci!ed.

When did this hap-pen?What performancedata could be at risk?What design deci-sions might be atrisk?

Check wither the plannedoccupancy density or themodel details are correct.Review with simulationstaff how predictionschange when the occupancyis updated.Broadcast the changes andwhether change is in linewith project goals.

194

Core issue Related issue Actions

The project isslightly ahead ofschedule what do wedo now?

Where are opportu-nities for making thedesign work better?What is likely to bethe next issue thatthe client will ask usto consider?

Revisit the assessmentslooking for likely perfor-mance improvements.Investigate modi!cationsneeded to explore likelytopics.Employ a focused model tocheck if an alternativeapproach could provide bet-ter performance data.

14.7 Simulation staffTraditional deployment of staffinvolves junior staff primarily workingto create models, run assessments andextract performance data. The criticalissues for successful deployment is thelevel of experience junior staff hav e inaddition to their tool-related skills andtheir status in the group.Staff who lack experience in a particu-lar design or engineering domain are ata disadvantage in comparison withmore opinionated staff. Although toolvendors do not advertise it, those withstrong opinions are much more likelyto make good use of simulation tools -opinions help in the selection and useof tool facilities. Managers who wishto overcome this limitation might con-sider pairing the novice with moreexperience staff for several projects.Those with opinions will certainly havemuch more to contribute to the plan-ning stages of a simulation-basedproject in terms of:• Information required from the client

at different phases of the work

• Feedback on likely simulation toolsfor the project e.g. bene!ts anddrawbacks of different tools, timeand computational resources impliedfor different tools.

• Ideas about how design issues mightbe represented within the simulationenvironment(s)

• Ideas about zoning strategies andlevel of detail implied for variousdesign questions

• Ideas about past models which maybe useful to review

There is a place for novices in a well-formed simulation team if they hav eaccess to more experienced staff aswell as the mentor and there is frequentand close supervision.Where simulation staff are included indiscussions, are able to buy-into thegoals of the project and have suf!cientstatus to creatively evaluate directivesand suggest alternatives, there is littlechance for a perfect storm to develop.Take one or more of these away andrisk increases.The following table includes typicalissues which confront simulation staff.

195

Core issue Related issue ActionsWhat preparation isneeded for thisproject?

Are we clear aboutthe client’s ideas thatthe model shouldcon!rm?Have we done simi-lar work in the past?Do we have testmodels for thisbuilding type?

Meet with team manager toreview client requirements.Sketch likely approaches tothe model and review withthe teamReview past projects andidentify if there is an optionfor adapting prior models.Review library of test mod-els for candidates for use intesting ideas and techniquesfor the current project

What analysis facili-ties are required tosupport the project?

What runningcost/control issues?What comfort/airquality issues?Are thermal bridgesan issue?

For each domain identifywhat needs to be measured.De!ne the level of detailrequired.Identify likely interactionsbetween domains.

What model calibra-tion approaches areappropriate

Is there a range ofbest-practice perfor-mance indices?Can a previousproject be used as abenchmark?What operationaland climate condi-tions would be agood test of theresponse of thebuilding?

Review standard literatureand past reports.Consult working proceduresfor which types of tests arerecommended for thisbuilding type.Identify climate pattern(s)and operational characteris-tics to use in tests.Embed appropriate simula-tion directives in the modelso that calibration runs canbe undertaken as the modelev olves.

196

Core issue Related issue Actions

How much time willit take to create themodel?

Is there a record ofresources from simi-lar projects?Is this a crank-the-handle orexploratory model?What staff wouldwork well in thisproject?What staff produc-tivity can beassumed?

Review past projects of thistype and review with teammanager.If an exploratory modelplan a series of proof-of-concept models as a bench-mark. Review with mentor.Review tasks required vis-a-vis available staff andstaff who have worked onsimilar projects.Ask each staff member toprovide an estimate of timefor preparation and modelcreation and review with theteam manager.

What model variantsmight be needed?

What other questionsmight the clientpose?Is the current modelat the edge of thetool facilities or staffskills?Are changes directedby new informationprovided or are theygeneral parametricvariations?

Discuss with mentor anddomain experts what othertopics might be addressedwith variants of the currentmodel.Review working practicesfor resource estimatesneeded to increase ordecrease the resolution ofthe model.Review current model com-plexity in each domain anddiscuss this with mentorand project manager.Locate a test model and useit to test automation facili-ties or scripts. Report !nd-ings to team.

197

Core issue Related issue Actions

What zoning patternshould be used in themodel?

What is the distribu-tion of occupancypatterns?What portions of thebuilding are sensitiveto the facade?What variants ofcontrol logic mightbe used in differentsections of the build-ing?Is strati!cation anissue?Is cross-ventilationor air "ow betweenrooms likely?

Using separate overlayssketch out regions for occu-pancy (density, schedules),control (logic, schedules),perimeter sensitivity, air"ow connections, systemtypes and control-ability.Unify the sketch overlaysfor initial ideas.Work out an alternativesketch of zones taking intoaccount likely future issues.Sketch scenarios for air"ow networks and revisezoning to accommodate.

14.8 The mentorDifferent groups have different de!ni-tions of mentor:

A person who has mastered thesimulation 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 de!ne strategies andevaluation criteria (e.g. a domainexpert).A person retained to carry outextended training within the simu-lation group, typically to assist the

team to enter a new market or workwith different types of clients.

Mentors may be part of the team ormay be outside consultants who areretained by the team via a supportagreement (X hours over the next 3months). Skill sets may be focused(e.g. they know how to design anddeploy air "ow networks for large spa-ces) or broad (e.g. they hav e managedand/or delivered similar projects).Sometimes simulation teams engage amentor because they want to explorenew topics or explore an alternativeway of working within an activeproject (and want to limit their risks).In such cases mentors usually are giventhe authority to take over tasks beingcarried out by staff if that is what isrequired to guarantee deliverables.In other cases a mentor may be on-callfor brief consultations because their

198

experience 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.

199

Core issue Related issue ActionsTeam: The projectstarting next weekinvolves X. We hav elimited experience -how shall we pro-ceed?

Is this a topic thatthe mentor dealswith?Who needs to beinvolved in the dis-cussion?Do we upgrade oruse our standardapproach?

Specify the issues, points ofconfusion, time frame andgoals.Identify staff to work withthe mentor and clarify theirgoals.De!ne upgrade or discardpolicy.

Team: Fred is notsatis!ed with how heworks with facilityX.

Is this in the interestof the group toimprove this skill?Does the mentorhandle this issue?Is this part of alarger issue to bedealt with by a men-tor or via a standardtraining course fromthe vendor?

Check if this caused delaysor errors.Check if new skills will freeup time for other activitiesor help other team mem-bers.Get time/resource estimatefrom mentor and check fortime scale and cost of thevendor’s course.

Team: time estimateswere out by 30% inthe last project. Isthere a differentapproach that wouldwork better?

What does the men-tor need to under-stand about thegroup in order toevaluate that project?What methods couldbe use to test alterna-tive approaches?

Create a synopsis of theproject for review.Review synopsis withdesign team and get initialfeedback.Re-enact the project toidentify faultsIdentify staff who shouldtake part.Agree a timetable forreview, re-enactment andwork sessions.

14.9 The domain expertDomain experts can play different roleswithin a simulation team. For example,their domain may be the theory ofcomputational "uid dynamics or expe-rience with wind tunnel testing andhow to integrate experimental data into

the virtual physics.The domain expert differs from thementor in that the goal is to solve orunderstand a project based issue ratherthan adapt the teams working practicesor improve staff skills. The domainexpert may know little about the

200

speci!cs of the simulation tool but willlikely have strong opinions about theysee in performance prediction graphsor reports.The domain expert can supply a disin-terested second opinion for a con-tentious issue within a project or helpverify that current predictions are inline with expectations.Remember that the issue for the expertis likely to be both normal and obvi-ous to them. They may not realise thatothers do not share this knowledge.This can cause confusion to both par-ties. Take steps to reduce this confu-sion if at all possible.The domain expert may have opinionsthat includes the fact that theirapproach is the only possible way todeal with a speci!c issue. This may ormay not be true. If there actually areseveral valid approaches then theexpert’s contribution may be to provideinformation their approach and then theteam must evaluate this against theother options.If there is only one valid approach andthe simulation tool does not supportthat then there are several options:

check to see if the simulation toolcan be adaptedcheck to see if there is another toolwhich uses this approachevaluate whether there is a way tocoerce the tool to approximate theapproach suggested by the expertif it is early enough in the projectcheck if this part of the analysis canbe subcontracted

if the project is dependant on thisissue being resolved and it cannotbe resolved within the time orresource limits of the project con-sider withdrawing

The following table includes severalscenarios related to experts:

201

Core issue Related issue ActionsThe expert and theteam use differentterminology.

Are both partiestalking about thesame issue?Is the terminologydifferent becausethere is a differencein the underlyingapproach used by theexpert and by thesimulation tool?

Show the expert a list ofcommon de!nitions of thejargon used within thegroup and within the simu-lation tool.Arrange for a meeting todiscuss underlying methodsand terminology.

The expert asks toknow how the simu-lation tool treats aspeci!c issue.

Is the informationavailable?Is it in a form whichcan be understood?Is there an examplemodel which demon-strates this issue?

Scan the source code forrelevant blocks of code orpass the question to thesoftware vendor.Scan the documentation forrelevant sections and/or askthe software vendor if thereis additional documenta-tion.Set up a session to explorerelevant models to con!rmif a) the expert understands,b) the expert agrees withthe facility within the soft-ware.

14.10 Staff productivityGiven the same simulation tool, thesame computer type and the same brieftwo different simulation staff can useradically different times to arrive at acompleted 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.That difference in productivity isexpected and should be factored intothe staf!ng of a project. A tight time-schedule may be best supported byusing more experienced staff whereas

those 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 the man-ager and mentor should investigate.Chances are the biggest difference willbe the strategies employed. Strategiescan be learned.If possible, the quality manager shoulddevise task sequences to con!rm theskills level, strategies and inventiveresources of staff.

202

Simulation staff who are working at thelimit of their skills are less ef!cient andmore likely to generate errors than staffwho are well within their competencelevel. Therefore, a well formed work-ing procedure will ensure that staff areworking at a pace that is sustainable.Simulation staff should be clear abouttheir current productivity and informmanagement if they are at risk.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 speci!c 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. It can compile backgrounddocuments, create exploratory modelsand undertake mock projects in prepa-ration.Simulation staff should be pro-activeand request time (say 2-3 hours aweek) for speculative explorations andkeep the mentor and the team leaderinformed of progress. It is just as valu-able to report a tool facility that is notready for use in consulting projects asit is to discover a virtual measurementwhich can be included in futurereports.

14.11 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 the!tness 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.

203

Chapter 15

MODEL QUALITY

15 Model QualitySimulation 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 ensure modelquality because of the early warning ofopportunities to deliver additionalvalue 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-

nise• identifying aspects of models that

tool checks may not recognise ascorrect

• identifying aspects of models thatthe team may not recognise as cor-rect

• working practices that bypass inbuilttool checks

• working practices that bypass thequality manager

• frequency of model and calibrationchecks

• understanding model contentsreports

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 dif!cult 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 their marketingdepartments spin that 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.Interfaces can present users with

204

optical illusions. Here are some exam-ples:• A wireframe view can look correct

but hav e reversed surfaces or miss-ing surfaces

• A clever interface may decide tomerge surfaces together that areadjacent and share the same compo-sition - so what is reported is not thesame as the user de!ned.

• Interfaces may decide to subdividesurfaces or components so that themodel includes entities that the userdid not ask to be created.

• The user may de!ne a compactdescription which the tool expandsinto hundreds of lines of descriptionand provides only limited facilitiesfor exploring the expanded entitylist.

Some software (including ESP-r) pro-vides both information on the screenand model contents reports. Thisallows those with graphic interpretationskills and those with report interpreta-tion skills to work together.A good model contents report wouldnot only be human readable but re"ectany change to any entity within themodel. Simulation tools are imperfectand thus some entities may not bereported or may not include a suf!cientlevel of detail.Ideally, tools should allow the user tode!ne the level of detail for variousreported entities as well as which top-ics to include. Similarly, interfacesshould allow the user to expand or col-lapse interfaces so as to focus on spe-ci!c issues.

If vendors mount training courseswhich pay little attention to topicsrelated to model quality and your teamconsiders this important then talk toyour vendor and look for alternativetraining providers. Better yet checkbefore attending the course or buyingthe product.Another shortcoming that is attribut-able to the design of the simulation toolis the ease by which independentactions by multiple users cause clasheswhich are dif!cult to resolve. If amodel is working and some action byanother person causes a fault, con!-dence can be badly affected. This con-strains the deployment of simulation indistributed work groups.Of course poor working practices canreduce the ef!cacy of tool facilities.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.A 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 hasto mentally reconstruct an understand-ing from the shape and location of thesurface and what it is composed ofeach time it is selected from a list or

205

included in a report. The Cookbookquote of the day is:

Names are the !rst step to under-standing and essential to owningideas.

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 andoccasional 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 in"u-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 pro!tablebusiness 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 CADdrawings is simply noise in the thermaldomain. A client who saw a simulationmodel with !fty thousand surfaceswould be justi!ed 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 staf!ng 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.

206

The task of taking another personsmodel and understanding it wellenough to make modi!cations 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 severalprojects 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 recognisemodels which tell a good story fromthose that do not. Good working prac-tices ensure that simulation staff get

this 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 tonotice 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 dif!cult tospot.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 bene!ts 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 for

207

using 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 toensure that model quality is a continu-ous part of the model planning and cre-ation process. The quality managermight also devise task sequences tocon!rm the skills level, strategies andinventive resources of simulation staff.The de!nition 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 con!rming 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. Novices

need active support from others whohave more evolved opinions about thethermophysical nature of buildings andsystems. If those with opinions takethe 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 theclient at different phases of theworkBene!ts and drawbacks of differenttools, time and computationalresources for different tools.Ideas about how design issuesmight be representedIdeas about zoning strategies andlevel of detailIdeas about past models to review

Simulation 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 torecognise.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 con!rm thatthe prediction is in line with expecta-tions.

208

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 mentorto 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 bene!ts:• A fresh pair of eyes can notice in

seconds what has been evading oth-ers for hours.

• Conversations needed to con!rmwhat 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 issimpli!ed 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 requires

more than a linear increase in resourcesmuch thought is required to arrive at anappropriate model resolution.This said, a small increment in modelcomplexity may provide suf!cientvisual clues so as to reduce the effortneeded to understand a model. Modelsthat clients recognise help them to buyinto the process and it often simpli!esreporting 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 namesNames like hmeint"rt_1 might bederived from horizontal mass elementintermediate floor type instance onebut almost no one else will appreciatethis baggage. But if a client seems atease when talking about room 1.12bthen that might be the best name forthat zone in the model.Names are especially important wherethere are lists to select from. For exam-ple, if the interface presents a list of100 surfaces and it takes ten seconds tolocate the "oor surfaces because of anobscure naming convention and twoseconds with a clear naming regimethen the pay back is immediate. Select-ing the wrong surface can result incostly errors. The Cookbook recom-mends that the !rst attribution to alterfrom the default is the entity name and

209

that names follow consistent patternswithin a model. Surface names onlyneed to be unique within a zone butnodes and components within a net-work need to be unique.

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 occupancypro!le 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 con!rmed (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.Who does such updates, the frequencyof reviews, and decisions about whoneeds to know that changes have been

made 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 con!dence 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 ofthousands of entities is, at the least, aniterative task. Each iteration focuses ona different aspect of the model and/or

210

its 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 recognise 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 whereair "ow patterns are widely distributed.In many buildings there is considerablerepetition and little to be gained by

describing 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 bene!ts 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 con!dence in a model? Wellfounded opinions as to what should behappening within the building (or

211

access 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 con!rm 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 con!rm iflighting is switching as expected

• graphs of zone temperatures andzone environmental controls to see ifan optimal start or stop might be

useful, if there is heat stored in thebuilding overnight or if a modularsystem might be appropriate

• statistics and graphs of solar enteringthe zones to con!rm 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 of!ce 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 con!rm this can result in signi!-cant value to the client.Another trick of the experts is to gatherstatistics for the occupied period aswell as at all hours. Why? Becauseattention to after-hours performanceprovides clues for improving thedesign of the building and its operatingregime.

212

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

• de!ning an Integrated PerformanceView (IPV) for the model and usingthis to invoke speci!c 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 speci!c 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 modelsto grow in complexity without havingto re-compile, and there are still limitsthat knowledgeable users avoid.Models which have been extendedtowards the limits of the simulation

tool 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 a!rst 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 simpli!cations 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 asresult !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.

213

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 re"ectthe various design variants. If after test-ing and running the scripts the wholeedi!ce 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 dif!cult 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 theyare 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 of

the 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 speci!c 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 calcula-tions for shading patterns and view fac-tors becoming obsolete.Simulation tools are designed trackthese dependencies and attempt toresolve them. A user generated script

214

might have dif!culty 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 generalised 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 anddif!cult to maintain it is worth check-ing with the software vendor to see if itis possible to revise the tool to supportsuch modi!cations. 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.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.Some semantic checks can be carriedout by reviewing the client’s questionsand considering the underlying physicsinvolved. If, for example, the design is

sensitive 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 mostef!cient approach and working proce-dures should ensure that such modelvariants can be quickly created or aremaintained as the work progresses.With a general tool such as ESP-r thereusually several possible designs of themodel. In the planning stage a series ofconstrained models of differentapproaches can be created to identifythe most promising approach. Somesimulation teams will have a range oftest models available or will have pro-cedures for setting up test models. Theworking practices chapter recommendsthat simulation staff hav e time allo-cated to exploring alternative

215

approaches and creating models fortesting likely issues that will arise inthe design process.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 of!ces 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 the

space? When is it happening?• What else is happening at the same

time 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.If the initial model was well designedthere is a tendency, when the clientposes a new what-if question, toassume that the model can be adapted.Sometimes this is the case. And some-times the new question implies a differ-ent domain of assessment or a differentlevel of resolution.This is a critical semantic check. Theresources required for a not-quite-!t-for-purpose model can be similar orgreater than the cost of designing and

implementing a model for the newquestion. And this is also a semanticcheck that should be undertaken forbroad parametric studies. A criticalreview may suggest that a higher reso-lution is required for some portions ofthe design matrix.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.

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 a

216

failure 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 followingare 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 de!nition,

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-de!nedsimulation parameter sets and manygroups build their working proceduresaround such facilities.

15.7 Team ChecklistsThe following table includes some ofthe issues to notice when working withsimulation 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.

217

Question Related issues ActionsWhat is interestingabout the site?

What do we knowabout the site?Does the clientrealise the impor-tance of the site?Is the north arrow onthe site plan?How might siteissues constrain thedesign?How might site lay-out be used toimprove the design?

Check the site plan and maps ofthe area.Find out which way is north.Review site photographs or visitthe site.Check site solar and windobstructions.Check principal wind directionand whether vernacular architec-ture takes this into account.Collect local opinions of the siteand ensure that these are takeninto account in model planning.Discuss with design teamoptions for adjusting the build-ing on the site.If orientations may vary ensurenaming regime avoids confusion(e.g. avoid north_entrance).

What weather data isappropriate for thesite?

What climate data isavailable near thesite?What patterns ofweather will impactthe building design?How hav e otherbuildings adapted tothe local weather?What are the designteams ideas aboutthe in"uence ofweather?

Review climate data to establishseasons, typical periods andextreme periods.Review climate data for usefulbuilding failure test sequences.Review climate data for durationof extremes as well as the fre-quency of moderate weather pat-terns.Discuss with design team theresults from initial review ofweather.

218

Question Related issues Actions

Is the design evolv-ing or static?

What drawings orsketches can weaccess?Are there plans, sec-tions and elevationsavailable to review?Are the drawingslikely to change?What is the designteam debating nowand what are likelyfuture topics?

Review drawings or CAD !lesand gather comments from sim-ulation staff and quality man-ager.Check that the drawing scale isreasonable and if details mightin"uence the design of themodel.Begin planning tasks and discussthe level of detail requiredwithin the team.Arrange a meeting with thedesign team and presentsketches of planned model andlikely approaches.

What is the compo-sition of the build-ing?Are the goals of theproject consistentwith these construc-tions?

Are constructiondetails known?What what-if ques-tions relate to con-structions?Are these typical forthis building type?Do we have data orsources for missingdata?What criteria forselection or rejectionof constructions?

Review standard databases formatching constructions and/orSIMILAR constructions.Create place holder construc-tions and document. Reviewsections and discuss with designteam.Discuss support for selectingappropriate constructions.

219

Question Related issues Actions

How is the buildingused?Is the building for aknown tenant or is itspeculative?How are roomslikely to be occupiedat different times andseasons?

Does the client havean well-formed opin-ion about the build-ing use?Is building occu-pancy an issue forfuture-proo!ng?Is there seasonaldiversity as well asdaily diversity?

Check the assumptions made bythe client.Quantify likely scenarios.Consider diversity, holidays andpeak use occurrences.Check past models for similarpatterns.

What is the clientsbig idea?What kind of modelwould con!rm thisidea?What are others inthe design teaminterested in?

What performanceissues are related tothe big idea(s)?What analysisdomains and metricsof performance willcon!rm this?Can beliefs held bythe design team becon!rmed?

Listen to the language used andreview sketches to identifybeliefs behind the big idea(s).Identify issues and determine ifthey can be assessed.Review available tools to checkfor matches in numerical capa-bilities and reporting facilities.Brief the design team on theapproach to be taken and thelikely information to be derivedfrom the assessments.

Tool check checklistsTool checking will typically includeissues such as is this polygon flat anddoes the construction attribute point toa correct entity in the database anddoes the boiler have a non-negativecapacity.Tool checks are not likely to notice is asurface named door which is composedof 150mm of concrete or which is hori-zontal. It is unlikely that this combina-tion is true but it can happen and usersare in the best position to notice this.Fire-access-door would be a bettername in this situation.

Scanning of the model done by thesimulation engine can include topicsthat are not checked as the model iscreated or standard reports are gener-ated. With most simulation tools is itpossible to pass the model to the simu-lation engine without actually runninga full simulation.If that scan passes that then running thestandard calibration assessments usu-ally only takes a few moments. If thereis a standard script for extracting pre-dictions covering several performancecriteria then that step also takes littletime.

220

Indeed it is often a trivial task to auto-mate many syntax and semantic checksfreeing up time for review of the out-put. The generation of automationscripts is a valuable skill within in ateam and a consideration for selectingsimulation tools.The criteria for determining the fre-quency of checks should be included inthe working procedures. Typicallythese would happen at several pointsduring the evolution of the model aswell as after simulations have been run.Usually it takes only a few seconds tocommission a check but much longerto review the reports and predictions soa balance must be found.There are techniques for reducing thetime taken. Incremental checks are wellsupported by looking at the differencesagainst an earlier report and softwarefor hi-lighting the differences betweentwo !les or between two folders isreadily available. The use of patternmatching tools can identify key wordsin model contents reports.Ideally the assessment would bedesigned to test a number of attributesof the design that signal whether itsperformance is as expected or excep-tional.The table that follows illustrate someof the issues during the use of toolchecking facilities. Use this as a start-ing point for generating your ownresponses to issues as they arise and forplanning future tasks.

221

Core question Related issue ActionsWhat changed sinceversion 1.3?

Who is working onthe model?What tasks are theyinvolved in?Does this match thework plan?

Consult the work log or the logof actions generated by the tool.Generate a model contentsreport and see how this differsfrom the previous report.Check with the quality managerand simulation staff about cur-rent status.

The client wants totest a different rooftype

Which parts of themodel are affected?Is information avail-able on the newroof?What performanceissues might change?What tasks arerequired and whichstaff should beinvolved?Is this a model vari-ant or an edit of theexisting model?

Update the constructions data-base if required.Generate a model contentsreport, archive the current modeland performance predictions.Create model variant if required.Apply changes, generate modelcontents report, check againstprevious report, re-run calibra-tion assessments and review.Re-run standard assessmentsreview.Archive the revised model andbrief the client.

The interface says’problem edges’ inconference zone.

Is there a missingsurface?Are there edgeswhich do not followthe rules used in thetool?Is there one or morereversed surface?

Look at the wire-frame for miss-ing surface labels.Use the check vertex topologyoption for a report.Turn on surface normal arrowsto review orientation of surfaces.Check for vertices linked to onlyone surface.

222

Core question Related issue Actions

The ceiling void iswarm and retainingsuf!cient heat tocause a morningcooling issue.

Under what operat-ing regimes andweather conditions isthis happening?What are the pri-mary gains withinthe ceiling void?Is it possible toremove heat fromthe ceiling void?

Carry out checks under differentweather patterns.Review the energy balance inthe ceiling void.Review how boundary condi-tions are represented and thestate of adjacent zones.Test different operating regimesto determine sensitivity.Force a brief purge of heat fromthe ceiling void and check thewhether (and how long) it takesthe condition to re-establish.

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 identi!edat the planning stage and recorded inthe model so that recovery of multi-cri-teria assessments can be automated. Atypical range of metrics would be com-fort, system capacity, energy use overtime, emissions of carbon dioxide, dis-tribution 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 opportunitiesidenti!ed.

223

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 would con!rm issues which mayarise as design options are tested.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.

224

Core issue Related issue ActionsIs the model still cal-ibrated?

Have calibrationassessments beenrun?Were there enoughmeasurements tounderstand perfor-mance?

Review the criteria for calibrationassessments.Identify measurements whichmatch expectations.Identify unexpected measurementsand investigate further.

Is performancetracking planningstage expectations?What issues werementioned in recentmeetings?What value addedissues are under con-sideration?

Does the data recov-ery script includethese issues?Do we have triggervalues for failure?What other dataviews will comple-ment standardreports and graphs?Who can con!rm theadditional reports?

Explore performance interactively,including a few tangent issues.Get a second interactive review.Follow up issues by looking atdependant or related issues.Run test script to con!rm datarecovery logic and reporting for-mat is ok. Do spot checks.Run the full script. Do spot checksand get someone else to con!rm.

What if we alteredthe vision glass?

What productswould be likely can-didates?Do we have thermo-physical and opticaldata?What criteria wouldsignal better perfor-mance?Is performance sen-sitive to the facadeorientation?

Establish what is available and theclaimed bene!ts.Review data sources or generateoptical dataIdentify glazing-relatedimprovementsPlan what to measure and wherealternative glazing could beapplied.Implement design variants.Archive model, establish base caseperformance, test substitution anddata extraction procedures.Implement one change at a timeand compare against the base case.Rank the design variants and iden-tify performance changes.Get a second opinion.

225

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 of!ce 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 summary of the site location andthe climate should be checked to see ifthey match the project. Finding defaultvalues may be indicative of a lack ofattention (quality managers will noticethis).Lines identifying the building and thebuilding owner and the simulation teamhave not yet been !lled out.The !rst two lines of the report also arethe place to identify what is differentabout this model. This can be impor-tant if there are several model variants -users in a hurry can easily select thewrong model for a task!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.

226

This is a synopsis of the model Case-study of the ESP-r cookbook: 2 zones;reception + examination defined in doctor_office.cfg generated on Fri Aug 114:21:25 2008. Notes associated with the model are in doctor_office.log

The model is located at latitude 52.40 with a longitude difference of -1.73from the local time meridian. The year used in simulations is 1995 andweekends occur on Saturday and Sunday.The site exposure is typical city centre and the ground reflectance is 0.20.

Project name: not yet definedBuilding address: not yet definedBuilding city: not yet definedBuilding Postcode: not yet defined

The climate used is: and is held in:/usr/esru/esp-r/climate/uk_birmingham and uses hour centred solar data.

The databasesThe next section of the report focuseson databases associated with themodel. Some of these are standarddatabases (the path (/usr/esru) is theclue) and some are model speci!c (apath ../dbs).Databases in the standard esp-r/data-bases folder are initially supplied withthe software. They might have beenexpanded or details modi!ed for thegroup. Other databases can be added tothis folder. It is up to the group to man-age and document the databases. Data-bases items should be reviewed and thecontents should be of a know qualityand kept up to date by the quality man-ager.Databases associated with the modelmay or may not be derived from thestandard database. Typically they willinclude items speci!c to the model.Such entities may eventually migrate toa standard database. It is up to the sim-ulation team to supplement the infor-mation held in the model data !les withadditional notes on the new entities.Each database differs slightly in imple-mentation. Currently the constructions

database 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 labelswhich lacks clarity for some users. Itfollows an older style of !le with anemphasis on space for data and limiteddocumentation. The name of the con-struction is restricted to twelve charac-ter. This constraint reduces the clarityof the report.Until the data structure is revised it isup the user to compensate for the limi-tations in the tool. No doubt other sim-ulation environments have limitations.The use of additional documentationhelps but it relies on persistence by theuser community. What is required areclear channels of communicationbetween the user community and andsoftware vendors and mechanisms forconverting user demands into changesin software.

227

Databases associated with the model:pressure distributions : /usr/esru/esp-r/databases/pressc.db1materials : /usr/esru/esp-r/databases/constr.db2constructions : ../dbs/doctor_office.constrdbplant components : /usr/esru/esp-r/databases/plantc.db1event profiles : /usr/esru/esp-r/databases/profiles.db1optical properties : /usr/esru/esp-r/databases/optics.db2. . .sections skipped. . .

Multi-layer constructions used:

Details of opaque construction: extern_wall

Layer|Prim|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 brick2 211 75.0 0.040 250. 840. 0.90 0.30 4. 1.88 Glasswool3 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 blockISO 6946 U values (horiz/up/down heat flow)= 0.393 0.397 0.387 (partition) 0.379Total area of extern_wall is 92.70. . .Details of transparent construction: dbl_glz with DCF7671_06nb optics.

Layer|Prim|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 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 glassISO 6946 U values (horiz/up/down heat flow)= 2.811 3.069 2.527 (partition) 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 9.30

When reading the report remember thelayers go from ’other-side’ to roomside. Make a point of comparing thereported U values with other datasources to ensure that the constructionis properly de!ned. In the case of ESP-r, a U value is a derived value ratherthan an integral part of the calculationprocess. It is also up to the user to cor-rectly account for the changes in heattransfer between the centre of glazingand sections near the frame. There areseveral approaches such as using aver-aged values and using separate surfacesfor the centre and edge of glass but

little consensus 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 somewhat moredetailed that that provided by somemanufacturers. And it does not includesome data generated by optical analysistools such as Window 5.2 and WIS.ESP-r is not unique in simplifyingsome aspects of diffusing glass andadvanced light re-directing glazingproducts.

228

Zone controlsThe next section of the model report isextracted from the controls de!ned 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 fortranslating the parameters of eachperiod’s control law is limited. Somecontrols include more than a dozenparameters and some abbreviations arenecessary. Some controls include jar-gon used by control engineers. Thereare a few controls which have almostno translation of the control parame-ters. Some controls which have param-eters which include auxiliary sensorde!nitions can be confusing becausethe standard report of sensor and actua-tor locations does not know that it hasbeen superseded.Most users take some time to get usedto how ESP-r represents controls. Fur-ther practices is required to learn howto spot errors and omissions in the con-trol report. Often a close inspection isonly done if the model is not workingas expected.This model is probably at an earlystage. The intent of the controls is notclear. There is no mention of why2KW capacity was speci!ed for heat-ing and cooling. In many groups thiswould be a substantial breach of proto-col. An alternative approach would beto provide extensive documentationabout what was de!ned in the planning

stage and then gradually improve itsimplementation.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.

229

The model includes ideal controls as follows:Control description:A basic control is used during occupied periods on weekdays with a set-backin the evenings. Saturday and Sunday is allowed to free-float.

Zones control includes 1 functions.An idea control with a dead-band of 4 degrees is used.

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, 1995 with 3 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux basic control 2000.0 0.0 2000.0 0.0 10.0 30.0 0.0

basic control: max heating capacity 2000.0W min heating capacity 0.0W max coolingcapacity 2000.0W min cooling capacity 0.0W. Heating setpoint 10.00C cooling setpoint30.00C.

2 7.00 db temp > flux basic control 2000.0 0.0 2000.0 0.0 20.0 24.0 0.0basic control: max heating capacity 2000.0W min heating capacity 0.0W max coolingcapacity 2000.0W min cooling capacity 0.0W. Heating setpoint 20.00C cooling setpoint24.00C.

3 19.00 db temp > flux basic control 2000.0 0.0 2000.0 0.0 10.0 30.0 0.0basic control: max heating capacity 2000.0W min heating capacity 0.0W max coolingcapacity 2000.0W min cooling capacity 0.0W. Heating setpoint 10.00C cooling setpoint30.00C.Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1995 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux free floating

Sunday control is valid Sun-01-Jan to Sun-31-Dec, 1995 with 1 periods.Per|Start|Sensing |Actuating | Control law | Data1 0.00 db temp > flux free floating

Zone to control loop linkages:zone ( 1) reception << control 1zone ( 2) examination << control 1

Zone compositionThe next section of the model reportprovides a a summary and then adetailed view of zone composition. Thesummary provides a quick overview ofthe size and complexity of each zone.If the attribution in a zone is incom-plete the summary will re"ect this.The report for each zone re"ects 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.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 identi!ed quickly.The example included below is for ver-sion one of the geometry !le. The ver-sion 1.1 includes additional attributes.

230

ID Zone Volume| SurfaceName mˆ3 | No. Opaque Transp ˜Floor

1 reception 120.0 12 165.5 4.5 40.0 reception L shaped room, 2 windows, 2 inter2 examination 60.0 10 88.3 4.8 28.0 examination: square room with a sloop roof,all 180. 22 254. 9. 68.

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 L shaped room, 2 windows, 2 internal walls with examinThere 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.393 & UA of 19.439Flat roof is 100.00 % of floor area & avg U of 1.799 & UA of 71.970Glazing 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 |type |loca| name |other side

1 12.0 180. 0. r_int.wall_1 OPAQUE VERT partition ||< r_int.wall_1:examination2 9.90 270. 0. r_int.wall_2 OPAQUE VERT partition ||< r_int.wall_2:examination3 9.75 180. 0. r_wall_south OPAQUE VERT extern_wall ||< external4 21.0 90. 0. r_wall_east OPAQUE VERT extern_wall ||< external5 9.75 0. 0. rWall1-north OPAQUE VERT extern_wall ||< external6 12.0 0. 0. rWall2-north OPAQUE VERT extern_wall ||< identical environment7 9.00 270. 0. r-wall-south OPAQUE VERT extern_wall ||< external8 40.0 0. 90. r-ceiling OPAQUE CEIL roof_1 ||< external9 40.0 0. -90. r-floor OPAQUE FLOR grnd_floor ||< ground profile 110 2.25 180. 0. r_window_sou DCF767 VERT dbl_glz ||< external11 2.25 0. 0. r_window_nrt DCF767 VERT dbl_glz ||< external12 2.10 270. 0. indoor_door OPAQUE VERT int_doors ||< ex_int_door:examination

An hourly solar radiation distribution is used for this zone.Shading patterns have been calculated for this zone.

After the surfaces have been listedthere may be additional lines whichidentify optional attributes of the zone.In the example below is a notice thatshading patterns have been pre-calcu-lated for the zone.What is missing from this report arethe details of the polygons which makeup the surfaces of the zone. Users inter-ested in this level of detail will eitherhave to look at the interface (where co-ordinates and edge lists are found) orlook at the model descriptive !les.There are additional data !elds in com-parison with the interface so care andattention to the report can help identifyissues in the model.Quality managers will scan this reportfor ’UNKNOWN’ as well as for names

that do not match the entity. For exam-ple a wall named south_wall mightactually be facing West. Is this becausethe zone was rotated after the surfaceswere named? And there is also thecommon error that a surface polygonhas been inverted and what looks cor-rect may be facing the wrong way.

Zone schedulesThe next section of the report focuseson the schedules of air "ow and casualgains de!ned 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 example

231

below 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. The inter-face will attempt to sort the data pro-vided by the user to !t this rule.Working procedures that minimiseerrors typically enforce matching docu-mentation and data. Numbers may becorrect without being clear as to whatthey represent.There is a brief note about the valuesfor the air "ow schedule but there isnothing about the casual gains. Theredoes seem to be some diversityincluded in the casual gains for occu-pants. Lights are a !xed wattage as aresmall power loads. Again this is proba-bly early in the design process. A qual-ity manager would notice that the radi-ant and convective split is 50 50 foroccupants and lights and equipmentand ask for clari!cation.

232

Air schedule notes:One half air change for all days and all hours (initial engineering guess).Control: no control of air flow

Number of Weekday Sat Sun air change periods = 1 1 1Period Infiltration Ventilation From Sourceid Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp.

Wkd 1 0 - 24 0.50 0.0167 0.00 0.0000 0 0.00Sat 1 0 - 24 0.50 0.0167 0.00 0.0000 0 0.00Sun 1 0 - 24 0.50 0.0167 0.00 0.0000 0 0.00

Notes:no operations notes (yet)Number of Weekday Sat Sun casual gains= 13 0 0Day Gain Type Period Sensible Latent Radiant Convec

No. labl Hours Magn.(W) Magn. (W) Frac FracWkd 1 OccuptW 0 - 7 0.0 0.0 0.50 0.50Wkd 2 OccuptW 7 - 8 80.0 40.0 0.50 0.50Wkd 3 OccuptW 8 - 9 240.0 120.0 0.50 0.50Wkd 4 OccuptW 9 - 12 400.0 200.0 0.50 0.50Wkd 5 OccuptW 12 - 14 240.0 120.0 0.50 0.50Wkd 6 OccuptW 14 - 17 400.0 200.0 0.50 0.50Wkd 7 OccuptW 17 - 24 0.0 0.0 0.50 0.50Wkd 8 LightsW 0 - 8 0.0 0.0 0.50 0.50Wkd 9 LightsW 8 - 19 150.0 0.0 0.50 0.50Wkd 10 LightsW 19 - 24 0.0 0.0 0.50 0.50Wkd 11 EquiptW 0 - 8 0.0 0.0 0.50 0.50Wkd 12 EquiptW 8 - 17 100.0 0.0 0.50 0.50Wkd 13 EquiptW 17 - 24 0.0 0.0 0.50 0.50

Users who may have hacked their !lesmay have introduced gaps or overlapsin the periods and this report is oneway to identify such occurrences.

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 betterthan 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 thatsuf!cient 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 con!rm 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.

233

Chapter 16

INSTALL APPENDIX

14 Install AppendixESP-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 acomma, tab or space is a separator

between 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 com-puters offer many of the same

235

compilers 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 realise 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

236

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 speci!cationuse a text editor and change the rele-vant token as required. Look in thepreferences menu of the ProjectManager to access the details of this!le.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 esprc!le 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 !leidenti!ed 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 the!le 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

237

ESP-r workshops but the contentscan be edited to include other mod-els.

• *validation_stds - the name of a !leto read with information needed tocomission standard tests

• *db_defaults - the name of a default!le which holds a list of initial data-bases. If you want to use an alterna-tive list of initial databases edit this!le 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 speci!ctopic and/or dialogue within the userinterface. These dialogues associatedwith speci!c types of model !lesrequire a default name and the default!le 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 the!le.• *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-ci!c commands given during theinstallation process

• *cfg - this is a default !le name for amodel con!guration !le (useful fordemonstration purposes)

• *ctl - this is a default !le name forcontrol loop de!nitions

• *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. This!le 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 database!les to suite the needs of their work.This !le can be accessed via thepreferences menu of the ProjectManger.

238

*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 MeanJan -6.4 @20h00 Sun 8 12.7 @14h00 Sun 29 3.8Feb -1.9 @ 5h00 Tue 14 12.2 @13h00 Thu 2 5.2

239

Mar -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 this!le 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.

240

Chapter 17

VERSION APPENDIX

17 Version AppendixIn 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 the!le 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 sometake 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 dif!cult 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.

242

Figure 17.1 An example of invoking the project manager in text mode.

Production work often requires a spe-ci!c 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 gen-erated.

#!/bin/csh -fbset RESFILE=$1res -file $RESFILE -mode text<<XXX

243

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 reportsg # 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.

244

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 GTKlibrary code (see below) are in place.

245

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 theX11 equivalent of a radio button (only

one 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.

246

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 canwork around the limitations. The cur-rent plan is to continue coding until thefull X11 functionality is in place. The

development community will thenreview how the layout of ESP-r mightev olve to take advantage of the func-tionality in the GTK graphics API.The following Figures are the GTKequivalents to the !le speci!cation dia-logue, pop-up help message, real

247

number dialogue and a radio buttondialogue. It generally takes fewer linesof code to implement a dialogue inGTK than 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-ci!c text in buttons that are used insome dialogues. Once the X11 code is

depreciated 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-ci!c examples where you mightencounter differences.The chapter is work in progress. Moretext to be added here.

248

Chapter 18

CAPABILITIES

18 CapabilitiesThis 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 thirdparty tools such as Radiance to

support 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 de!ni-tions, shading/insolation calcula-tions, view-factor calculations,short- time-step data de!nitions,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 fabric/net-work mass "ow and CFD

250

domains), it is being used as aconsulting tool by architects, engi-neers, and multidiscipline prac-tices and as the engine for othersimulation 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 eachsurface and at each !nite volume of

used in system components.• System components support temper-

ature, two component (mosit 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 optimised 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 eachtime-step.

251

• 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 de!nes 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, electricalcharacteristics (e.g. integrated PV),

moisture adsorption, contaminateemission properties.

• Facility to import DXF !les (V12)which con!rm to speci!c 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 de!ned (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 three!nite volumes for each layer of eachconstruction. Typically, materialsover about 200mm thick are subdi-vided into multiple layers to increasethe ef!ciency 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 shouldbe subdivided. Minimal surface

252

dimensions are ˜1mm and there is nospeci!c 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 userde!ned monthly ground temperaturepro!le 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 userde!ned heat transfer coef!cients.Conditions at inside and outside faceare evaluated at each time-step.Some outside regimes are sensitiveto the angle of incidence of the windas well as whether the surface is on

the windward or leeward side. Heattransfer coef!cients 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 de!nedthen 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-re"ectiveblock 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 anistropic sky conditions.

• Insolation distribution (includingradiation falling on internal masssurfaces) can also be predicted ateach hour on a typical day of each

253

month.• Beam solar radiation is tracked to!rst 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 de!ned 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 bytreating the blind as a layer with the

construction 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 in!ltration (airmovement from the outside eithernatural or forced) and ventilation (airmovement between zones). Controlcan be applied to these scheduled"ows based on a range of criteriae.g. increase in!ltration to 2ach ifroom goes over 24 degrees C.

• The intermediate approach to airmovement is to create a network of"ow 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 solutionapproaches there are some gaps in

254

the provision of component types.• Control can be applied to mass "ow

components 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 tode!ne 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 con"ation. The lattertakes its boundary conditions fromthe zone solution and returns heattransfer coef!cients. 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 tosuch gains.

• Zone air volumes are assumed to bewell mixed at one temperature. Strat-i!cation 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 speci!c species of micotoxin 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 coef!cients (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 anESP-r model or via 3rd party tools.Including an electrical power network

255

in 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 the

building (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 setpoint, coolingsetpoint 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,minimum supply temperature, air"ow rate room heating and cooling

256

set-points.• Separate ON/OFF controller which

includes 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 setpoint, 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 de!ned 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 whether"ux or "ow is to be controlled.• Air conditioning steam/spray humid-

i!er, water/steam "ow multiplier,water/steam "ow converger anddiverger

• Air conditioning cooling coils with"ux control, a counter"ow coolingcoil with water mass "ow rate con-trol, a counter"ow cooling coil fedby WCH system, a two node coolingcoil with speci!c !n and tubedetails.

• Air conditioning heating coils with"ux control, a counter"ow heatingcoil with water mass "ow rate con-trol, a counter"ow heating coil fedby WCH system

• Plate heat exchanger, air/airexchanger, heat exchanger segment,duct, duct damper

• Cooling tower• Centrifugal fan

257

• Wet central heating boilers: non-con-densing boiler, with on/off control,with aquastat control, calori!er,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 de!ne 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 data!elds. 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.

258

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 speci!ed 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.

259

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 of!ce 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 of!ce 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.

260