THE ESP-r COOKBOOK Strategies for Deploying Virtual Representations of the Build Environment

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

Energy Systems Research Unit Department of Mechanical Engineering University of Strathclyde, Glasgow, UK.

2 December, 2010

COPYRIGHT DECLARATION
The copyright of this publication belongs to the author under the terms of the United Kingdom Copyright Acts as qualied by the University of Strathclyde Regulation 3.49. Due acknowledgement must always be made of the use of any material contained in, or derived from, this publication.

This document is designed to be printed in one of the following formats: Two pages per sheet of A4 or B4 paper At 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 . . . . . . . . . . . . . Acknowledgements . . . . . . . . . 1 Introduction . . . . . . . . . . . 1.1 Tactical approaches . . . . . . . 1.2 The client specication . . . . . 1.3 Design questions . . . . . . . 1.4 Model planning . . . . . . . . 1.5 Model coordinates . . . . . . . 1.6 How the building is used . . . . . 1.7 Environmental controls . . . . . 1.8 Model composition . . . . . . . 2 Building a model . . . . . . . . . 2.1 Review of climate patterns and databases 2.2 Locating constructions for our model . 2.3 Zone composition tactics . . . . . 2.4 Model topology . . . . . . . . 3 Geometry alternative inputs . . . . . . 3.1 To the keyboard . . . . . . . . 3.2 Clicking on a bitmap . . . . . . 3.3 Examples of approaches to take . . . 4 3D Modelling . . . . . . . . . . 4.1 Modelling approaches . . . . . . 4.2 Steps to create a roof space . . . . 5 Schedules . . . . . . . . . . . 5.1 Scheduled air ows . . . . . . . 5.2 Importing operation schedules . . . 6 Climate data . . . . . . . . . . 6.1 Importing climate data . . . . . . 6.2 Dening seasons and typical periods . 6.3 Climatelist entries . . . . . . . 7 Zone environmental control . . . . . . 7.1 Introduction . . . . . . . . . 7.2.1 Abstract representations . . . . 7.2.2 Abstract example . . . . . . 7.3 Zone control laws . . . . . . . 7.4 Exploring building control issues . . 7.4.1 Basic (ideal) control . . . . . 7.4.2 Interpreting control predictions . . 7.5 Controls implementing boundary zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v vi 1 4 6 8 9 10 14 18 21 23 27 32 34 51 54 55 59 60 65 66 70 77 81 81 84 86 87 91 95 95 95 97 99 101 101 106 111

8 Thermophysical resolution . . . . . . 8.1 Shading and insolation . . . . . . 8.2 Shading predictions . . . . . . . 8.3 Radiation view factors . . . . . . 9 Preparation for simulation . . . . . . 9.1 Integrated performance views . . . 9.2 Results libraries and reports . . . . 9.3 XML output directives . . . . . . 9.4 XML user interactions . . . . . . 10 Understanding performance predictions . . 10.1 The res module . . . . . . . . 10.1.1 Enquire about . . . . . . . 10.1.2 Environmental systems reporting . 10.1.3 Casual gains . . . . . . . 10.1.4 Zone energy balances . . . . . 10.1.5 Surface energy balances . . . . 10.1.6 Hours above and below . . . . 10.1.7 Energy delivered . . . . . . 10.1.8 Condensation reports . . . . . 10.2 Timestep reporting . . . . . . 10.3 Graphic reporting . . . . . . . 10.3.1 Variables against time . . . . 10.3.2 Fruency bins . . . . . . . 10.3.3 3D surface plots . . . . . . 10.3.4 Variable vs variable graphs . . . 10.4 Methods for exploration of data sets . 11 Flow networks . . . . . . . . . . 11.1 Limitations of Scheduled Flow . . . 11.2 Fluid Flow Networks . . . . . . 11.3 Building blocks . . . . . . . 11.3.1 Flow components . . . . . . 11.3.2 Flow connections . . . . . . 11.4 Steps in creating a network . . . . 11.5 A simple network . . . . . . . 11.6 To the keyboard... . . . . . . . 11.7 Calibrating ow models . . . . . 11.8 Flow control . . . . . . . . 11.9 To the keyboard... . . . . . . . 11.10 Window representations . . . . 11.10.1 Component selection . . . . 11.11 Schedules vs networks . . . . . 11.12 Hybrid ventilation . . . . . . 11.13 Limitations of Network ow models

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

116 116 119 121 129 131 136 140 144 149 149 151 153 153 154 155 156 157 159 160 161 161 162 163 164 165 168 168 168 170 171 172 174 176 179 183 186 188 191 194 196 202 206

12 Detailed ow via CFD . . . . . . . . . . . . 13 Plant . . . . . . . . . . . . . . . . . . 13.1 Using a network to represent mechanical ventilation . 13.2 Dening containments . . . . . . . . . . 13.3 Finishing off the model and testing . . . . . . 13.4 Moving from ideal demands to thermal zone demands 13.5 Links to zones and controls . . . . . . . . . 14 Working procedures . . . . . . . . . . . . . 14.1 How can the vendor help? . . . . . . . . . 14.2 Responsibilities within simulation teams . . . . . 14.3 Classic mistakes . . . . . . . . . . . . 14.4 Planning simulation projects . . . . . . . . 14.5 Team manager . . . . . . . . . . . . . 14.6 The quality manager . . . . . . . . . . . 14.7 Simulation staff . . . . . . . . . . . . 14.8 The mentor . . . . . . . . . . . . . . 14.9 The domain expert . . . . . . . . . . . 14.10 Infrastructure . . . . . . . . . . . . . 14.11 Support staff . . . . . . . . . . . . . 14.12 Staff productivity . . . . . . . . . . . 14.13 Tool selection . . . . . . . . . . . . . 14.14 Summary . . . . . . . . . . . . . . 15 Model Quality . . . . . . . . . . . . . . . 15.1 How can the vendor help? . . . . . . . . . 15.2 Responsibilities within simulation teams . . . . . 15.3 Model planning . . . . . . . . . . . . 15.4 Complexity . . . . . . . . . . . . . . 15.5 Multi-criteria assessments . . . . . . . . . 15.6 Semantic checks . . . . . . . . . . . . 15.7 Team Checklists . . . . . . . . . . . . 15.8 Simulation outputs . . . . . . . . . . . 15.9 The model contents report . . . . . . . . . 15.10 Summary . . . . . . . . . . . . . . 16 Install Appendix . . . . . . . . . . . . . . 17 Version Appendix . . . . . . . . . . . . . . 17.1 Text mode . . . . . . . . . . . . . . 17.2 Legacy X11 graphics . . . . . . . . . . . 17.3 GTK+ graphics . . . . . . . . . . . . . 18 ESP-r capabilities . . . . . . . . . . . . . . 18.1 General modelling features . . . . . . . . . 18.2 Zone Loads . . . . . . . . . . . . . . 18.3 Building envelope and day-lighting . . . . . . 18.4 Inltration ventilation and multi-zone air ow . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

208 211 212 218 218 221 225 230 231 232 232 234 236 237 240 244 246 248 249 250 251 252 254 254 255 258 260 261 264 268 274 279 289 291 299 299 302 304 307 308 309 310 311

18.5 Renewable energy systems and electrical systems 18.6 Ideal environmental controls . . . . . . 18.7 Component based systems . . . . . . . 18.8 Environmental emissions . . . . . . . 18.9 Climate data . . . . . . . . . . . 18.10 Results reporting . . . . . . . . . . 18.11 Validation . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

312 313 314 315 315 316 317

ABSTRACT
This Cookbook uses the general purpose simulation suite ESP-r as a platform to explore strategies for deploying virtual representations of the built environment to answer questions posed in the real world of design and research groups. The Cookbook talks about translating client questions into virtual representations that are no more and no less complex than is required for the task. It talks about rediscovering the power of pencils and paper and it dares to mention the word methodology. And discovering valuable patterns in the clutter and then learning the art of responding to what if questions. And since the author is professionally paranoid you might pick up some new denitions of the word QA. Almost all of the strategies presented can be applied to the task of creating elegant virtual representations in other simulation suites. Readers might alert their colleagues to take a peak.

ACKNOWLEDGMENTS
This book could have been completed only within the exceptional group environment of the Energy Systems Research Unit of the University of Strathclyde in Glasgow Scotland. Where else could an architect compose tens of thousands of lines of source code and then use the resulting virtual edice to explore and support the design process and then turn the process on its head to return to the written page to explore strategies of its use. The author would also like to acknowledge the time which Samsung Construction allowed the author during a period of secondment in Seoul.

vi

Chapter 1

INTRODUCTION

1 Introduction The design process proceeds on the basis of the beliefs the design team holds about how the current design satises the needs of the client. Sketches indicating interactions of heat and light and the movement of air are statements of belief. Simulation can be used to test the beliefs of the design team. For example, some Architects and Engineers operate on the assumption that buildings constantly require mechanical intervention. Is this assumption true? Rather than assume that buildings do not work, lets test how often buildings work well enough to satisfy occupant requirements without intervention. Many design methods focus on extreme conditions and ignore what happens at other times. What is the cost of this? Instead of ignoring transition seasons, lets explore the nature of the buildings response to these transient climate patterns and, by understanding the pattern of demands, devise environmental control regimes which work well in part-load and intermittent scenarios. Some design methods assume that changes dictated by value engineering have little or no impact on systems and control response or running costs or comfort. Folk-lore suggests there is 1 considerable risk in this assumption. Although we can test whether a particular design variant alters performance criteria that are important to the client, the process of undertaking such assessments has a cost. We need criteria to guide us in determining when a design variant warrants attention, how we might approach such assessments, how best to employ numerical tools, how to interpret the performance data and then translate what we learn into the real world. Learning how to use simulation tools for design decision support and for research has tended to follow three paths - the mentor path, the workshop path and the there-be-dragons path. The mentor path works exceedingly well and is an efcient, if not particularly inexpensive way of gaining the skills and tactics needed to apply simulation to real-time projects. Workshops are another successful approach to simulation training. Two or three days of initial sessions, supplemented by advanced topic workshops and the occasional email allows many practitioners to productively use simulation. Both of these approaches rely on personal contact with an expert and iterations of demonstration, followed hands-on experience and dialogue for skills acquisition.

Many practitioners rely on mentoring and workshops to keep them up to date as tools evolve and for exploring new facilities. Documentation tends to lag the evolution of simulation tools and many lesser-used tasks may not be well documented or documented in ways accessible only to geeks. What you are reading now (and the companion Cookbook Exercises is addressed primarily at those who are taking the path of confronting the dragons. It has also been used to support workshops in conjunction with the exercise volume. The Cookbook strives to be generic in its discussion. As the title suggests, where specic examples are needed they are based on the ESP-r suite. Some blocks of text apply only to ESPr and occasionally you may notice the following icon...

geek command (on one line):

svn checkout https://espr.net/espr/espr/branches/development_branch

and compiled your own version. Most of the instructions needed to get a working distribution can be found on the download page. Additional instructions are included with the source and there are discussion lists that might provide additional clues. And the ESP-r download pages do not really tell you much about what to do once you have ESP-r on your computer. This statement is probably applicable to most other vendors. Of course there are web based tutorials and exercises as well as manuals that approach telephone directory proportions. Most vendors went through a phase where they believed that web based tutorials would supplant mentoring and workshops. From the authors perspective, web pages work less well than the mentor/workshop paths. The Cookbook is an attempt to bridge this gap. It evolves, as does ESP-r itself, from observations of practitioners who are attempting to support real-time design assessments of real-world issues. Simulation tools almost always arrive with a range of example models of two broad types - abstract models which are composed so as to illustrate semantics and syntax and those models derived from consulting projects which focus on specic building performance design issues. The rst type is often used by novices to get used to the simulation tool, the second type for those who are looking for examples of best 2

If you are reading this from the point of view of another application skip down a few paragraphs. The Cookbook also includes sections of interest to technical support staff and uber-geeks. These are marked with the following icon...

If you have downloaded one of the precompiled ESP-r distributions for Linux (most distributions), Mac OSX, Windows (native GUI), Cygwin (emulation under Windows) from the ESRU web site <http://www.esru.strath.ac.uk> or acquired the source from the source code control repository via the uber-

practice models. Vendors do not always make clear which is which. Example models contain a wealth of information for those who know what they are looking for, for those who are persistent or for those who are using them as reference materials within the context of a workshop or in mentor based training. For these users example models can act as: a mechanism for exploring the tool (e.g. where do I nd out information about environmental controls, the composition of walls) to explore the sequence of tasks required to run an assessment and recover specic performance metrics to explore incremental changes in the description of the model and the performance implications of such changes Creating a model from scratch under close supervision and with commentary on the approach taken does reduce the frequency of encounters-withdragons. In ESRU workshops almost all participants rst model works correctly the rst time it is simulated. What you are currently reading expands on existing workshop materials and years of mentoring, recast for the resolution of the printed page. The goal is not simply to act as a dictionary or reference but as a guide to how to approach realistic design decision support in real time, delivering real information and still have time for a cup of coffee at the end of the day. This document is based on the premiss that readers will already have an intuition about the physics of buildings and 3

environmental systems. A future revision is planned for those who are less opinionated. And for readers who are users of other tools there will be much of value even if the details of implementing the methods differs. Who knows, someday there may be an EnergyPlus Cookbook and an EE4 Cookbook.

A word about ESP-r versions

ESP-r is under active development. On any given day there may be a half dozen commits of code or documentation or updates to exemplar models to the repository. This Cookbook evolves at a slower pace. This 2008 version has been revised to match the evolved interface of ESP-r but that match is likely to be imperfect. Interface entities and paths such as Model Management
-> browse/edit/simulate -> composition -> geometry & attribution may have a different

syntax. If you dont nd a match, please look around for something similar. You may also notice is that some interface related gures in the Cookbook look different from what you see on the monitor. There are currently three different interfaces for ESP-r. There is the traditional X11 interface which has its roots in the world of UNIX and Linux. There is an almost complete port of ESP-r to a graphic library called GTK. GTK is implemented on a dozen operating systems and this allows ESPr to be run as a native Windows executable. It also has a more familiar look and feel and once the port is complete it will be the primary interfaces to ESP-r. The third interface is a pure-text

interface which tends to be used for scripted production work or to enable ESP-r to act as a background engine for other software. Look in the Version Appendix to see typical dialogues from the different interfaces. With the exception of le browsing facilities, the command sequence needed to undertake most tasks is almost identical across each of the interfaces. Where facilities differ you may see one of the following icons followed by specic instructions...

delaying the design process. The rst table is a powerful dragon slayer. Clients ask us questions - but what are the questions we ask ourselves as we plan and then compose our virtual worlds?

1.1 Tactical approaches Depending on your personal preferences, getting acquainted with a simulation tool either begins with exploring existing models (in ESP-r these are called exemplars) or in the context of creating a model from scratch. If you are taking the from scratch route grab a note-pad and some sketch paper. The following sections explore how you can use ESP-r to arrive at a working simulation model and a growing set of simulation skills. If you are using a different simulation suite keep reading. Tactics can almost always be applied universally. Lets begin by deciding what kind of model we are going to make and then plan the work so that it ts our resources. This is a tactical approach to simulation which concentrates on the art of making concise models to answer our clients questions without 4

Table 1.1 Initial tactics:

Design Question What do we want to know about the design? How do I know if the design works? How might the design fail? How do I match the information I have with the requirements of the tool? Simulation questions What thermophysical issues should be addressed by the model? What performance can I measure to inform my judgements? What level of model detail is required for this? What boundary conditions and operating regimes would be a reasonable test? 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 are needed to use them? Can I sketch out my model and explain it to others? What assessments need to be undertaken to gain condence in the model? What is expected of a best practice design? What else would clarify how the design works? How might the design and the model evolve during the design process? What would I do now to make it easier to work with this model again after a four month delay?

Is our approach ok? Are the performance predictions credible? How can I deliver the most value for my client?

Without tactics we will miss out on the value-added aspects of simulation which cost us little to implement but deliver substantial benets. A tactical approach keeps you in charge of the simulation tool. Simulation models have a context within which they are created and evolve. In the next section the clients specication and design questions form the context. From this we decide what type of model(s) the specication implies as well as the assessment(s) that need to be done to answer the 5

clients questions or further our research goals. The plural is intentional - real projects are iterative and models either evolve or spawn the next generations of model.

1.2 The client specication The following section provides the specication of our rst project. It is designed to allow an exploration of the best-practice choices made while planning simulation projects.

80% 0.75 2.0 2.1

1.5

3.0

Section looking west 3.0 x 0.75

No matter what simulation tool you are using, there is always more than one approach to a given task. Workshops typically use sequences that are known to work. Mentors will encourage you to explore alternative approaches. Enlightened managers allocate time for such explorations. This initial simulation project is part of a general practitioners ofce. The client specication is intentionally terse so as to demonstrate typical decisions made by simulation teams in practice. Clients have beliefs about how buildings work and simulation is one approach which can be used to conrm or refute such beliefs. Figure 1.1 shows a plan and section (looking from the east) of the general practitioners ofce. The reception has a at roof and the examination room has a sloped roof with a skylight to the north. Figure 1.2 is a wireframe perspective view (looking from the south-west). Note the strip windows on the north of the reception and the two strip windows on the south facade.

3.0 7.0 1.5 4.0 3.0 x 0.75 4.0 1.0 1.5 3.0x0.75

4.0

Figure 1.1 Plan and section of general practitioner ofce.

Figure 1.2 Wire-frame view of general practitioner ofce. Figure 1.3 is a colour rendering (looking from the south-west) which was created by exporting the ESP-r model 6

to Radiance. This project represents a portion of a general practitioners ofce. Focusing initially on a portion of a building is a powerful strategy and one which is applicable to almost all simulation tools. The client indicates that this medical practice has a brisk turn-over of clients and that, on average, there are two people in the examination room during the hours of 9h00 to 16h00 on weekdays (200W sensible, 100W latent). The reception area serves other portions of the building which are not included in this model and there might be up to ve people. Lighting in the reception is 150W during the hours of 8h00 to 19h00 and there are no small power loads in either room for purposes of this model. The heating set point is 20C and the cooling set point is 23C between 9h00 and 17h00 on weekdays with frost protection (15C) on weekends. The client has no specic opinion as to how this is to be achieved. ESP-r, unlike some simulation suites, includes both ideal zone controls and component based descriptions of environmental systems. In this exercise we will start with a minimalist ideal description and assume that both heating and cooling are assumed to be delivered convectively. ESP-r demands an initial guess at the heating and cooling capacity, but otherwise we will maintain our focus on demand side issues. 7

Figure 1.3 South-west view of general practitioner ofce. Figure 1.4 is a view from the northwest through the examination room. The white surfaces represent walls which are partitions to a portion of the building which has not been included within the model.

Figure 1.4 North-west view of general practitioner ofce.

Questions to ask about auto-size functions: a) what boundary condition(s) and operational regime(s) are associated with peak conditions? b) what method(s) are used to assess intra-component dependencies as components are sized? c) what criteria are used to determine which sub-optimal set of component sizes works best? d) what criteria might you use to conrm the suggested sizes?

form, composition and use as described in the client specication. The model need not be particularly detailed and our goal is to maintain the volume of the spaces as well as the orientation, area, distribution of mass and general shape of the room surfaces. Review Table 1.1. If the client asked different questions the nature of the assessments might well be different. So, what sort of assessments will address the question of typical heating and cooling demands, capacity and comfort? If we werent thinking tactically we might run an annual simulation and then get bogged down in scanning the predictions for useful information.

Components might seem unambiguous. Be sceptical until you can conrm that they match your expectations. Back to our initial model. Even the best of buildings have inltration. There is a discussion about air ows in a later section. For now lets use an initial engineering assumption that there will be 0.5 ac/hr inltration at all hours. 1.3 Design questions The client wants to know what the typical demands for heating, heating capacity, thermal comfort in the winter and summer, whether it is likely to overheat and if the daylight distribution is ok. To answer these questions we require a model which represents the general 8

A tactical approach limits the quantity of information we have to deal so both the model and its performance is easier to understand and the QA burden is reduced. Lets look rst on seasonal patterns to highlight performance issues. Computers may process a year in seconds but QA staff costs are greater. The key initial objective is to support our own understanding of performance by looking at patterns in a limited set of data and so be able to spot glitches in our model as well as opportunities for improvements to the design (or the clients specication) as soon as possible. Value added: The client did not ask for it, but it takes little extra effort to check

for typical spring and autumn performance might provide useful feedback to the design team. Another tactic is to dene performance metrics (e.g. what can we measure in our virtual world) early in the process. Some metrics e.g an energy balance within a zone, might contribute to our own understanding of the design and other metrics e.g. thermal comfort might be useful to report to others in the design team. ESP-r workshops typically devote as much time to exploring building performance issues as is spent on model creation. Simulation suites which do not include an interactive exploration facility will include a descriptive language to specify what performance metrics are to be captured during each assessment - so learn that language! The metric for heating and cooling demands is kWhr (integrated) over the week and for capacity the metric is diversied kW (the peak capacity required for this portion of the building). Just to be sure that the pattern of demand is reasonable we will want to graph this. In addition to a table of demands and capacity we might include the graph in our report if it proves of interest. Resultant temperature is a common comfort metric. A frequency bin of resultant temperatures during the occupied periods would inform the client about the distribution of comfort. For our own use, we also want to check the number of hours over 24C and graph the temperatures, we might include these in our report if they prove interesting. 9

To answer the question about daylighting we can look at daylight factors across a grid in each of the rooms. To build a model that will answer questions of thermal and lighting performance we need to decide how much geometric resolution if required. In the case of daylight factors the level of detail needed for the thermal assessment should sufce. If glare was to be assessed the model would need to include additional visual geometric details. Later on we will consider tactics that anticipate probable future design performance questions. QA tip: Write down these decisions, we will want to review them as the project progresses to make sure we are working to-the-plan. 1.4 Model planning Get out your grid paper and note pads and keep the laptop lid closed for now. Pre-processing information and sketching the composition of our model will limit errors and make it easier for others to understand what we intend to create, and, after we have made it, to help check that it is correct. This rule applies whether we are going to import CAD data or use the in-built CAD functions of our simulation tool. It also saves time and removes another source of error if we convert the important horizontal and vertical dimensions (such as those shown in Figure 1.1) to model co-ordinates and include them in our planning sketches. This avoids jumping between a keyboard and a calculator during model denition as well as helping in QA tasks

User friendly software does not reduce the need for planning or robust QA. If anything, it is even more important to guard against needless complexity. Lets call this avoiding the dark side. An exercise related to model planning is included in the Cookbook Exercises within Exercise 1. 1.5 Model Co-ordinates Novice practitioners often proceed under the assumption that geometric input consumes the bulk of their project time. Seasoned simulationists know that geometry takes about a third of their project time and they evolve strategies to help them limit the time spent on creating and checking geometric entities (so they will have the time and attention to leverage valueadded opportunities that might arise). An experienced user can generate models with scores of thermal zones that t together correctly the rst time. Such skills can be acquired over time. We are going to walk before we run, and our initial goal is to create a correct three zone model for the doctors ofce. In workshops nine out of ten participants create models which simulate correctly the rst time. If asked, most are able to re-create this model with minimal support and in 25-35% less time. So even though an experienced user will out-pace a novice, good working practices ensure that even 10

novices can produce useful models. The approach we take to create the form of the model is as dependant on the questions we wish to address with the model as it is on the specics of the building blocks and input facilities that are offered by the simulation suite. questions about general comfort and energy demands at peak and moderate climate conditions require only a moderate geometric resolution e.g. correct volume of the space, approximate location of doors and windows questions related to comfort at a specic location require higher geometric resolution, especially if surface temperatures are likely to be vary across a surface question related to visual comfort will require higher geometric resolution for facades and may require that furniture within rooms and outside obstructions be accounted for questions related to the distribution of air temperature within a physical space may require that it be represented by more than one thermal zone or that it include a CFD domain questions related to passive solar performance may require a higher level of geometric and construction detail to assess the impact of mass and the distribution of solar radiation Each of these issues require that we rst consider the physics underpinning the assessment. Second we must search the available model building blocks for relevant entities. Lastly we must consider what resolution to apply those entities within our model.

For example, a passive solar design will be sensitive to heat stored in the fabric of the room as well as details of glazing in the facade and in partitions to adjacent rooms. The surface temperatures in a sun patch might be substantially elevated. To nd out where the sun falls in the room at different times of the year we might create a rough model and then check what we can see in a wire-frame view at different times of the year. Our goal would be to nd out if we need to subdivide surfaces to better reect the temperature differences in insolated and un-insolated portions. We can then make a variant of the zone with higher geometric resolution and compare the predicted surface temperatures. As a general rule the design of models should ensure that the volume of the air is close to the correct value just as we want to ensure that the surface area is correct and that mass within the rooms is appropriately distributed. In the doctors ofce the windows are not large and the questions are general and so the exact location of the windows is not critical (but it costs us nothing to place them accurately). The dimensions shown in Figure 1.1 should be straightforward to represent. Looking closer, there is no thickness indicated so the criteria used to arrive at the dimensions is unclear. If you were tasked with determining dimensions from information supplied by a client a set of rules would be useful. Where the volume of the space is large with respect to the thickness of the facade and where the complexity of the facade is low it is common to 11

measure from the inside face of exterior walls. Measuring partitions at each face is common where the co-ordinates are taken from CAD drawings and at the centre line during the sketch stage. Ceiling voids or raised structural oors with little or no air movement are often represented as layers of air in constructions. Where air movement is likely or there are signicant heat gains within the void they may be better represented as a separate thermal zone. As ceiling (below) to oor (above) distances increase it makes sense to take the height co-ordinates literally and geometrically separate levels within buildings. There are ESP-r exemplar models which have the zones on each side of a partition in the same plane and other exemplars have zones separated in space. In most simulation tools it is a matter of personal preference because the heat ow between zones is established by specic directives partn_cor in ofce is connected with partn_off in corridor which are separate from the geometric denition. Most simulation tools represent geometry as polygons and separately represent their composition. Wire-frame displays often present models as having walls of little or no thickness. For modern (thin) construction the wireframe display may provide an image that allows us to forget that real walls have thickness.

Consider the modern ofce construction in Figure 1.5 there will be little or no change in predictions whether the centre line or the actual location in space is used. Given that there are doors in the partition there is a strong case for adopting the centre line to avoid visual confusion.

Figure 1.6 Plan of a historic building. Translating the historical plan into a model required a number of decisions to represent in one dimensional heat ow paths a building which is a substantially three dimensional heat ow problem. The result, shown in Figure 1.7, substantially retains the volume and positions of the spaces rather than the exterior form of the building. Thin partitions are taken to the centre line. Some plan detail has been omitted and minor spaces amalgamated into adjacent rooms. Having sketched on an overlay what we wanted to transcribe, the actual creation of the initial extruded form of the rooms was accomplished in a matter of minutes via a click-on-bitmap facility. 12

Figure 1.5 Plan of a modern building. At the other extreme, historical buildings can have exterior walls and partitions which vary in thickness and are substantially different from the thickness of doors. In Figure 1.6 the inside and outside faces are multi-faceted the shape of the window surround inuences the distribution of light within the room. Some partitions are thin enough to be treated as centre lines and others suggest a separation of the thermal zones.

Figure 1.7 Model of a historic building. The geometry at the window heads and sills was then adapted and the doors inserted. When attributing the surfaces, the associated construction was selected to account for the local cross section. A further discussion about options for interpreting complex three dimensional designs into appropriate models can be found in Chapter 4. The Cookbook is concerned with the art of composing models which are specically adapted to the needs of the design process. Not all projects are as demanding as the historic building. There is also an art to creating models which are t for the sort of general questions posed in the doctors ofce. While planning a model we might ask ourselves: would patterns of temperature and heating change if the volume of the space was off by the width or a wall? 13

would more sunlight enter the room if a window was lowered by 5cm? is it necessary to include the frame of the window? is it necessary to include the furniture within the rooms? Essentially our concern is to ensure that the uncertainty in the model is constrained to the point where it would be unlikely to change a design decision. Each of the above bullet points could, in fact, be tested by creating model variants and then looking at the performance differences. There are many simulation groups who have undertaken such parametric studies to arrive at their rule set. For this initial exercise the rule is keep it simple. The X axis in ESP-r is towards the East and the Y axis is towards the North. Most users nd it convenient to keep their model in positive co-ordinates and to dene their model using cardinal orientations and later rotate and transform the model to reect conditions at the site. Figure 1.8 shows critical co-ordinates (X,Y) derived from Figure 1.1. To simplify our task let us assume that the origin of the model is at the lower left corner of the examination room. The critical vertical points to record on your notepad are 0.0 (ground), 2.0 (window sill), 3.0 (ceiling), 4.5 (top of sloped roof).

Taking the time to gather and conrm critical co-ordinates in the plan and sections before going to the keyboard is a key technique in getting-it-rightthe-rst-time.

Figure 1.8 Critical dimensions taken from the plan. 1.6 How the building is used Our next stage in the planning process is to deal with how the building is used (schedules of occupants, lighting, small power). The client specication must be transformed into schedules. Experienced user will either sketch the day schedules or record the time and values for each casual gain data for each day type just like they did for the co-ordinates. Just as dening an appropriate level of geometric detail is important, schedules can be crafted to test a number of performance characteristics within a 14

single assessment. Why bother? Because a few minutes effort can give early clues of how buildings may fail and how the building fabric and its systems respond. Another reason to bother is that "all staff are here all the time and copy machines have a constant queue of telephone directory length reports" is not usually how buildings are used. It might be a secondary question to ask when testing risk to have such an extreme as an alternative, but not as the primary operational regime. The examination and reception spaces have a simple schedule of occupancy which includes some diversity. For example, there is a lunch hour and there is a ramp-up and ramp-down of gains at the start and end of the day to represent cleaning staff in the morning and stragglers at the close of work. In both cases there are periods during the morning and afternoon with full loads so that capacity issues and the potential for overheating are addressed. ESP-r represents internal (casual) gains as a schedule which applies to each dened day type. By default there are weekdays, Saturdays and Sundays. For this exercise lets stick with a default set of day types. You can lump all casual gains together for denition and reporting purposes or use up to three separate types of casual gains. Typically the rst type is for occupants, the second is for lights and the third is for small power (equipment). Each of the days has one or more periods associated with each type of casual gains. Periods must not overlap and

should cover the entire day (0h00 to 24h00. Each period has a sensible load (W), a latent load (W) as well as the fraction of the sensible load which is radiant and convective. In the reception occupant sensible gains are 80W from 7h-8h, 240W from 8h-9h and 12h-14h and 400W from 9h-12h and 14h-17h. For purposes of this exercise occupant latent loads in the reception are assumed to be half the sensible loads. Consider though what might be happening in such spaces. What is the latent gain from several cups of tea or a boiling kettle? For purposes of this exercise we will treat all casual gains as having a 50% convective component. In a real project you would use values appropriate to the type of occupant, light or small power device. The notes eld allows space for recording assumptions and the intent of the data. Such notes help others decode the numbers within the schedules and are an essential part of QA. If the note mentions how many people or light xtures this could be used to subsequently scale the data.

During model planning sketch the pattern of the various casual gains for each of the day types indicating the different periods and the magnitude of the gains. This information can then be used when inputting data as well as during model checking. Sketches save time. Try it for the data described above and compare this with Figure 1.9 for the reception and Figure 1.10 for the examination room. This overview of how the building is used will be your reference material for much of the discussion of working practices in Chapter 5. If you want to explore a variety of schedules for different building types, browse through the exemplar models and focus on how schedules are treated. Although not discussed in the Cookbook there are additional options for dening schedules of greater complexity. For example, there is a short time-step data facility which allows casual gains to be specied at each time-step.

15

Figure 1.9 Proles for reception.

16

Figure 1.10 Proles for examination.

17

1.7 Environmental controls The Cookbook advocates a fast-tack strategy 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 satisfactorily without mechanical intervention. Such early indicators are valuable to other members of the design team. Deriving them may also result in wellfounded opinions about demand side improvements and likely environmental control regimes. Section 1.1 it did not include a specication for an environmental control system other than the set points to be maintained. Even if the brief had been specic it might not be well founded and would need to be evaluated. Each simulation suite implements environmental controls via one or more arbitrary conventions: Ideal control laws which dene what is sensed e.g. dry bulb air temperature, control logic that responds to the sensed condition and some form of actuation e.g. the injection of ux at some point in the model. Usually there are a limited number of parameters that can be set by the user and such controls tend to be applied to individual thermal zones. 18

Ideal system descriptions which dene a generally recognized pattern (e.g. VAV terminals with a perimeter trench heater), via high-level parameters which are then associated with a number of thermal zones in the model. Depending on the simulation tool there will be a different nite list to select from. Libraries of detailed system components e.g. fan coils and valves, which can be assembled by the user into a variety of environmental systems as required and linked with control components and logic. Templates which dene an environmental control system from detailed components. The template expand a limited number of descriptive terms into scores, if not hundreds of components of a known topology, typically including control components and control logic. Templates often use a high level language to support the creation of component networks. Software vendors have had mixed luck with each of these approaches. From the user perspective each has pros and cons. Ideal zone controls can mimic any number of real systems but present users with a mix of abstract terms e.g. radiant/convective splits and behavior e.g. proportional/integral action rather than physical devices. Frustratingly, ideal zone controls often ignore the parasitic losses and electrical demands that many practitioners are interested in. Ideal systems, often only roughly approximate what the practitioner has in mind. Vendors have reacted

by adding more variants and/or providing additional input parameters. The chat lists for tools are full of practitioners confronted by the black art of tweaking an existing system to mimic a different design variant. Occasionally the mimicry takes on elements of a farce. Libraries of components are, in many ways a reaction to the constraints of pre-dened system lists. Opinionated practitioners are able to be specic and evaluate alternative designs and explore many more aspects of system performance. Unfortunately detailed descriptions are tedious to set-up, difcult to calibrate and can approximate a black hole if they need debugging. Few interfaces or QA reports are able to communicate fully the attributes and relationships within a network of components. Somewhat to the surprise of software vendors, there are practitioners that lack the background, opinions or tenacity necessary to create systems from scratch. Which brings us to component networks created from templates. They offer the detailed performance characteristics of components with most of the tedium removed. Whereas the older ideal systems approach might have expanded a score of user inputs into a score of equations to be solved, the template approach can generate a network of scores, if not hundreds of components, and generate thousands of lines of description. Clearly the author of a template would have an advantage in understanding the resulting network 19

composition and using it to support the design process. For others who have any level of curiosity about a newly created system the QA implications are substantial. Does the interface support understanding of what was created? If the practitioner needed to adapt or revise the parameters within components within such a network what methodology might they use to ensure this was done correctly? If you think your tool only offers detailed components, look closer to see if there are abstract components available. In the early stage of design they may be more than adequate. ESP-r supports the following options for environmental controls within a model: Ideal zone controls (to be covered in this section) Ideal systems expressed as ideal zone controls with additional parameters to support post-processing of additional performance data e.g. ue losses, fan power. There is no interface to this facility and it is not supported on all computing platforms (a shameful state of affairs) Detailed system components, optionally in conjunction with mass ow network components and electrical power networks (to be covered in a later section) At this point, many practitioners would, no doubt, feel compelled to jump into the details of their usual environmental control system. Rounding up the usual suspects is the antithesis of a strategic use of simulation. First, establish patterns of demand.

Second, explore options quickly by delaying specicity and detail in environmental control systems. Delivering information quicker and with less effort than our competitors is a good business plan. Actually, many simulation tools make it difcult not to be specic in the early stages of a simulation project. Vendors sell Wizards that offer scores of predened system templates which expand into networks of wondrous detail. Wow, so much from so little work (and it didnt crash so it must be a good design)! Vendors have less to sell with an abstract purchased air option or ideal zone controllers. So what approach to take? Here is a list of questions which might help identify whether a network of system components is suitable at the current stage of the design process: Do we have sufcient information to generate a network? What performance indicators of the network and/or components are we interested in? Can we explore broad-brush whatif questions? Can we tweak component details during the detailed design phase? Are the physics within an idealized control or abstract component sufcient to explore a design issue? E.g. mimicking a radiant cooling system with purchased air might be torturing the physics. What form of tool-generated documentation is available to support QA tasks? 20

How does one validate a templatebased system design? Is a systematic exploration of templates and components possible? Does the interface support detailed modications of an initial templatebased design? Does the interface support sufcient variants of an ideal control to allow a design team to pose relevant what-if questions? What support is available to move from an abstract representation to one with a higher resolution? Since the focus is on learning about patterns of demand, an abstract description of the system is all that is required. ESP-rs ideal zone controls supports abstract descriptions of how heat or cooling is generated. For purposes of this exercise an ideal zone control will characterize the response of a convective heating and cooling system to the clients set points. We do not know the capacity, so we will make an initial guess (say 4KW heating and 4KW cooling) and see how well that matches the demands. Once these patterns are known our experience might suggest a sub-set of approaches. We can then explore different types of control logic and begin to be specic about the equipment that would be appropriate. If the environmental controls have a schedule this should be recorded in much the same way as occupancy schedules. Indeed, there are often dependencies between occupancy patterns and environmental controls that

should be resolved at the planning stage. If there are options for the type of system or the control actions which can be applied, ESP-r can accept alternate controllers which can be tested in subsequent assessments with little additional effort. 1.8 Model composition The client has not specied what the building is to be made of. We are going to have to select placeholders from an existing database until such time as there is a clearer denition. Given the building type most professional practices will have available a number of likely constructions. The following general types of constructions will be required for the building 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 as a roof a ceiling for the reception One of our initial tasks will be to review the current contents of the construction and materials databases to locate existing entities which may be used as well as decide which ones can be adapted via copy and edit and which need to be added. An example of the steps needed to do this are included in the Cookbook 21

Exercises within Exercise 5. This completes the planning phase and our next task is to create a model which matches the requirements set out in the planning stage.

Chapter 2

BUILDING A MODEL

2 Building a model With planning complete we can take the clients specication and our sketches and notes and begin a new project. If you are using another simulation tool adapt your keystrokes and nd equivalent facilities to create your model. There are several exercises in the Cookbook Exercises volume which focus on this Chapter. Look at Exercise 2 as you start to create your model and complete Exercises 3-6 to ensure the databases are prepared with the entities you will need to build your model. Interface interactions and typing are shown in typewriter text. First select a folder for your model. Consider appropriate access privileges, how models will be archived and how models might be shared. A discussion of such issues can be found in the Install Appendix. Give one of the following sets of command depending on the operating system your are using:

The following sequence will take you to your home folder and start up the ESP-r Project Manager:
cd esp-r

Use Windows Explorer to select C:\Esru\Models or another folder that is not deeply nested and which has a minimum of spaces in the path. In the C:\Esru\Models folder there is an esp-r.cmd le which will start-up the ESP-r project manager. Figures 2.1 thru 2.4 illustrate (via the X11 interface) the steps we are going to take. Those using a GTK based interface will be asked the same questions, in the same order. Our tasks is to create a new model so select menu option Model Management -> 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 of the project manager which will ask you for a root name to use when creating the model and its folders (Figure 2.1). For this exercise lets use doctor_ofce. This root name will also appear in many of the model les so choose something which is short and clear. You have the choice of placing your model les within a single folder or a standard set of folders. The single folder choice might be appropriate for a simple model. Since ESP-r separates model information into a number of les the standard approach is to use multiple folders to hold different types of information. For example, information about controls is held in a ctl folder and zone related information is held in a zones folder. For this exercise choose standard. You will be asked for a descriptive title for the model which is included in reports and above the wire-frame view. There is a text log le associated with the model where you can keep track of who does what and when. You might also include in it a summary of the assumptions that you are making (in case someone asks). QA tasks are so much easier if you take a few moments documenting your model. Notice in Figure 2.3 that the Longitude difference? dialogue shows a pop-up help message. All dialogues and menus have contextual help. When in doubt use the ? button.

Figure 2.4: Model management menu.

26

2.1 Review of climate patterns and databases At this point we have registered a new simulation project (the terms project and model are often used interchangeably in ESP-r). There are a number of tasks that we want to complete before we begin to dene the form and composition of the general practitioners ofce. This section and Exercise 3 in the Cookbook Exercises are concerned with the following tasks: Find a climate le and typical climate periods for our assessments. Review construction and materials databases. Select or create places holders for constructions and materials. The Cookbook advocates the use of short climate sequences for model calibration and focused explorations. For example, a Monday morning start-up after a cold weekend can tell us much about the characteristics of a building. Do peak summer demands coincide with the hottest day or is it a function of several hot days in sequence? There is no point in using an annual assessment to address such issues and, more importantly, great advantage to frontloading simulation tasks so that models are calibrated as soon as possible. The following discussion includes climate data search techniques for identifying an appropriate week in winter with a cold weekend and a summer week with a sequence of warm days. To work with climate databases, select the menu option Model Management -> Database Maintenance and in 27

the options shown in Figure 2.5 select the annual climate option. Once a database is selected then there are a (mostly) common set of tasks which are available (see Figure 2.6). Some databases include functions to convert between binary and ASCII versions. Databases which require frequent random access typically have a binary form. ASCII versions are useful for transport between computers. For climate databases there are also options to convert EnergyPlus EPW les and Korean MET ofce les to ESP-r format le. Assuming ESP-r was installed correctly, you will now be presented with a list of known climate les (see Figure 2.7). Adding additional sets is a separate topic. For purposes of this exercise we want to select an existing climate data le. Choose the Birmingham IWEC climate, look at the summary in the text feedback area and conrm the selection. The ESP-r climate module (clm) will start, and your rst task is to conrm the climate le name in the initial dialogue. The ESP-r climate module (clm) provides facilities to explore climate data sets via graphs, statistics and pattern analysis facilities (see Figure 2.8). Our initial task is to use these facilities to better understand the climate patterns in Birmingham and identify useful assessment periods.

Figure 2.5 List of ESP-r databases.

Figure 2.6: Typical options for databases. 28

of the is an option find typical

weeks.

Figure 2.7: Available climate sets. There are a number of options under synoptic analysis (Figure 2.9) which are useful for nding climate patterns with which to test our building. To generate a statistical report as in Figure 2.10, rst select the climate data you wish to analyze e.g. dry bulb temperature and then the type of analysis e.g. maximum & minimum and then the reporting frequency e.g. day/week/month. Near the bottom 29

This facility works as follows: the average & total heating and cooling degree days (HDD & CDD) and solar radiation are determined for each season, for each week, average HDD & CDD and solar data is found and compared with the seasonal values and the week with the least deviation (using user supplied weighting factors) is reported. For this climate and with the default heating and cooling base temperatures the best-t weeks start on 27 Feb, 10 April, 19 June, 5 Oct and 4 Dec. Write these dates down and then go review these periods by graphing and/or gathering statistics about them. The climate module provides several ways of looking at the data so see which view tells you the most! The provision of different views of the climate data can assist in locating patterns within the climate data and answering different questions that clients might pose. Time spent exploring this module can provide critical clues as to patterns within a climate that may be used in the design process.

Figure 2.8: Clm module opening menu. An example is the graph of temperatures over the year (Figure 2.11) with the current seasons indicated across the top of the graph. There are a number of times when it is below freezing, but the graph indicates that these tend to be brief. This might support the use of brief performance assessments for winter heating demands and capacity. It also indicates scope for testing whether a design might be optimized to cope with brief rather than extended cold periods.

Figure 2.9: Synoptic analysis. Another example is Figure 2.12 where the psychometrics of the outside air have been plotted over the whole year for the same location. Most companies who regularly deploy simulation will have evolved procedures for selecting climate data for specic design assessments. The acquisition of climate data is covered in a later chapter.

30

Figure 2.10: Weekly statistics.

Figure 2.11: Annual plot of temperatures.

31

Figure 2.12: Annual psychrometrics. It is possible to congure ESP-r to load an initial set of databases that are appropriate for a given region and building type (see Install Appendix). Typically material and construction databases are managed at a corporate level but ESP-r also allows model specic databases and possible working practices are also discussed. So, return to Model Management ->
database maintenance -> constructions select the current (e.g.

2.2 Locating constructions for our model Our next task is to do a quick review of available constructions so that we will be able to attribute our model as we create it. You will want to look at Exercise 4 which focuses on a review of materials which may be needed and the steps required to take an existing material and create a variant which is appropriate for the current project. Exercise 5 will give you practice at the review of constructions as well as in adapting existing constructions and creating new constructions. The exercise uses the standard ESP-r constructions database. If you are working with a different set of databases the process is the same but you will have to adapt the details to t. 32

standard) database and note the list of constructions (see Figure 2.13) and details (see Figure 2.14) of those you might associate with this new model. One tactic, if you don t nd what you are looking for, is to make a project copy of one of the standard databases and then add in place-holder constructions. A place-holder is a named construction which either does not have a full set of thermophysical properties or

uses an approximation. This can be associated with the surfaces in the model and later, when the actual information is available it can be updated and all of the surface which use it will take on the revised properties.

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

Figure 2.13 List of available constructions in database.

33

2.3 Zone composition tactics Before we begin dening our zones lets review tactics. For purposes of this exercise we are going to use the inbuilt CAD facilities. We are going to use these facilities tactically so as to minimize the number of keystrokes and avoid errors. Later on you can adapt the techniques for even greater efciency. Here are the tactics: plan for maximum re-use of existing information use information on your planning sketches and notes take opportunities to embed documentation in the model give entities meaningful names and use attribution early-on in the processing learn the tool well enough to use inbuilt facilities to copy, edit and transform The order we dene a model can allow us to build new zones from portions of adjacent zones. In this exercise if we begin with the reception we can make use of this information when creating the examination room. If we take the information from our planning sketches rather than improvising or using a calculator, we will make fewer errors, we will be less likely to loose track of where we are when the phone rings and we will be less likely to nd we need two more surfaces than the interface allows. ESP-r has numerous places where you can document your assumptions. Of course you would never want to use such facilities because you never loose 34

scraps of paper and you always remember the assumptions you made about that model four months ago and your clients solicitor will never ask you to prove you followed procedures or used the correct values for that computer lab. A surface in a simulation model is not just a polygon, it has a name, it is made of something, it has specic boundary conditions and it must conform to the (virtual) laws of physics. QA gets a lot easier if something that looks like a door in a wireframe image, is named door and is composed of a door type of construction. The tactic is for these attributes to reinforce each other so it is easy to notice if we get something wrong and to be able to easily focus on the correct portion of our model.

Dening the reception

Returning to the Model Management menu nd the *preferences menu option and set ESP-r to use the most recent geometry le format as in Figures 2.4 and 2.15. The option labelled
upgrade files -> scan and update all zones sets the prefer-

ence. Next we want to traverse the menu structure to focus on the geometry of a new zone as shown in Figures 2.16 2.18. Select Model Management ->
browse/edit/simulate -> composition -> geometry & attributions. Since there are no existing

zones you will be asked whether you want to input dimensions or load
existing (ESP-r), load existing (CAD) or cancel. Choose to input dimensions, name the zone

e.g. reception is a good choice.

ceiling (3.0m). How many walls? Figure 2.17 indicates an additional point at X=4.0 and Y=7.0 where there is a break in the wall. To the West of this break the wall is a partition which faces another portion of the building which we are not going to bother to dene. To the East of this point the wall faces the outside. We need to dene two walls along the north side of the reception and so the total number of walls that we are going to extrude from the oor plan is 7.

The arrows shown in Figure 2.17 indicate the ordering of the walls. Remember this rule: when extruding a oor plan proceed anticlockwise. Write down the critical co-ordinates rst and dont answer the phone. In this case we will start with 0.0,4.0 and 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 been dened you have the option to accept them. If you are in any way worried about having made a mistake, say no and you will have a chance to check and edit the data. The Rotation angle? dialogue allows you to dene co-ordinates in a cardinal orientation and then rotate to reect site conditions. You can also perform transforms and rotations later. To skip the rotation, leave the rotation angle at zero in Figure 2.18.

Figure 2.15: Browse/Edit prior to adding zones. Next you will be asked to describe this zone - so lets paraphrase of the clients denition. The next dialogue asks whether we want to start with an rectangular
plan, polygon plan, general 3D, bitmap. For purposes of this exercise select polygon plan and

nd your sketch which corresponds to Figures 1.1 and 1.8. This type of input requires the height (in real space) of the oor (0.0m) and 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

off names and vertices and the site origin. Spend a few moments exploring this. The GTK+ interface includes a pro-forma for adjusting viewing parameters (see Version Appendix) The text feedback shown in Figure 2.19 includes a synopsis of the geometry of the zone and a list of the attributes and derived values for each of the surfaces. This report is designed to complement the wireframe image and you will notice that the word UNKNOWN shows up many times so there is still some work to be done! You will notice that the surfaces have been given names like Wall-1 and Base-9. These are unambiguous without being particularly helpful. Figure 2.21: Initial list of surface edges. Once you accept the points the project manager display will update to what is shown in Figures 2.19 and 2.20 with a listing of the vertex associations in Figure 2.21 are several things to notice about the graphic feedback and the command options. Items in the menu which start with a character can be selected and those that start with a blank in the rst column are reporting derived values (which will be updated as you modify the model). Under the graphic feedback area (of the X11 interface) are a number of buttons for altering the viewpoint, altering the size of the graphic feedback area and controlling the image. The latter allows you to turn on and 39

Doors and windows

In ESP-r, windows and doors should be included as surfaces in a model if they are thermally important. A tactical approach also includes windows and doors if they make it easier for others to understand the model. The door probably falls into the latter category we save time because we will not have to explain why we have omitted it. Essentially a surface is a window or door if you decide it is and give it a name that reminds you of this decision. This is somewhat different than other simulation tools so it is worth reviewing the rules: any surface in a model can be glazing or a door with the exception that a transparent surface cannot be used for a back-to-back connection representing mass within a zone

 their shapes are constrained only by normal polygon rules if glazing has no frame there is no requirement that it be a child of another surface doors and glazing can be bounded by more than one surface (e.g. glazing could have a frame on the left and top and right but adjoin a spandrel panel on the bottom edge) the base of a door (or glazing) can be at oor level or it can have a raised sill door and window composition can be any valid construction (e.g. doors can be transparent or opaque and windows can be opaque even though that would tend to confuse others) if you want to represent the adjacent-to-frame portion of glazing differently from the centre glass then you can either adjust the thermophysical and optical properties or create two separate glazing surfaces In ESP-r, solar radiation will pass through any surface which has an optical attribute set. This is the case for surfaces facing the outside as well as surfaces which are acting as partitions with another zone. A construction can use glass as a material and will consider the glass as opaque if it is matched to an OPAQUE optical property. Thermophysically a door is treated like any other surface in ESP-r. Surfaces with an optical property will transmit and absorb solar radiation but are otherwise treated as any other surface. Other simulation tools may treat doors and windows as simplied entities e.g. 40

a solar heat gain fraction might be used rather than explicitly treating the radiation and convention from glazed surfaces. You have several choices in the treatment of window frames. You can explicitly represent frames as one or more surfaces in the zone. A frame may wrap around the glazing or you can take an abstract approach and lump all of the framing facing one direction in a room into a single surface. You also have several choices for glazing. If the accurate positioning is important then create zones with explicit representations. If you only require that the area and orientation of the glazing is important then you could choose an abstract approach and lump all of the glazing of one type and orientation into a single surface. One issue which you may wish to consider is the relative size of surfaces in a zone and the interactions between surfaces: if a large pane of glass is used in a room with small surfaces (e.g. explicit blinds) then you may wish to subdivide the glass if you are calculating view-factors then small dimensions may confuse these calculations - a frame 20mm wide around a large glazing or door surface may not get enough grid points for an accurate calculation. if you are interested in local comfort then you should consider increasing the geometric resolution in the portion of the zone where comfort is being assessed.

 if the impact of solar distribution is important (e.g. a passive solar design) then you may want to subdivide the oor and the major thermal mass to account for the patches of sunlight as well as using explicit representations of glazing. In ESP-r, air passes between rooms ONLY if you dene an air ow schedule or create an air ow network. It is optional to include a door, grill or window surface at the air movement entity location. Such visual clues may help to clarify a model.

If your ESP-r model is going to be exported to an application which has a different set of rules for windows and doors then also take those rules into account (if possible). For example, Energy Plus requires glazing to be a child surface of an opaque parent surface so ensure that glazing in ESP-r models are also represented this 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-3 and Wall-5 and a door into Wall-2. The interface provides a way to make a rectangular hole in an existing surface and place a new surface into that hole. The original (parent) surface wraps around all sides of the child surface. In Figure 2.22 there are a number of options for creating new surface. You will use these options frequently so it is worth the time to explore them to 41

identify which of the variants might be used in different situations. The interface also provides an option to insert a door into a surface. It does this by wrapping the existing surface around the sides and top of the door. In both cases you will be asked to provide an offset and a width and height of the rectangle to be inserted. The offset is from the lower left corner of the existing surface (looking from the outside). These inbuilt facilities support the insertion of rectangular child surface. There is no specic requirement in ESP-r that doors and windows must be rectangular. If the design includes an arched opening or a round window you can do this (but the surface will have to be made of a number of straight segments). According to Figure 1.1, the window in Wall-3 starts 2.0m above the oor and is centered in the wall. So the offset X is 0.5m and the offset Z is 2.0m and the window size is 3.0m x 0.75m (see Figure 2.24). The same offsets and size apply to the window to be inserted into Wall-5. The door is 1.5m from the edge of Wall-2 and is 1.0m wide (see Figure 2.26). No height is given in the specication so lets assume 2.1m. Beginning with the window in Wall-3, select surface list and edges ->
add/insert/copy/extrude_from and then choose inserted into a surface -> within surface.

Notice there are also options to insert a surface as percentage of parent

surface.

used for documentation.

Figure 2.23: Use for window. Repeat this process for the window in Wall-5. Remember that you can rotate Figure 2.22: Options for creating surfaces. the wire-frame viewpoint to get a better Provide the dimensions from the paraview of your work. graph above and the proposed location For the door, use the inserted into of the window will be shown on the a surface->at base option. Wall-2 wireframe. If it is not ok you can reis 4m wide and if the door is to be enter the data, otherwise a new surface 1.0m wide (this is a medical facility) will be added and the existing Wall-3 then the offset for the door will be which started out with 4 edges 1.5m in Figure 2.26. When you have becomes a 10 edge surface which done this the display should look like wraps around the new surface. You will Figure 2.27. be asked to name the new surface What might you look for in the inter(south_glz or something similar) and face at this point? The wire-frame pick a construction for it (there is an image complements the text in the entry dbl_glz in the constructions datareport below. The wire-frame and the base). report are designed to be used together. A recent addition to ESP-r is the conFor example, a surface in the wirecept that surfaces have a usage frame might look ok but the report attribute (Figure 2.23). Code compliindicates it is facing the opposite direcance tasks are assisted if we identify tion. The data included in the text feedthe WINDOW as a code compliant back area report is similar to that facade. Work is underway to use these included in a model QA report (disusage attributes when exporting ESP-r cussed later). models. A future version of ESP-r will also make use of an opening type attribute (Figure 2.25) to help form air ow network (currently they are only 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 their attributes are UNKNOWN. Surface attribution is what we will turn our attention to in the next section. 43

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

Completing attribution
Tactically, we would prefer that others nd it easy to understand our models. If we can also reduce errors and speed QA tasks we have a winning combination. One successful pattern of model attribution is to begin with the names of the surfaces so that subsequent selection tasks and reports take less mental effort. Of course if you want to do it the hard way...

will be updated as in Figure 2.29.

To name something is to own it. Tactically we want to take possession of our models. Giving entities names is a key step especially if it helps the design team. The pattern used in this room is one of many possible patterns and 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 a unique identier e.g. oor_a, oor_b or oor_1, oor_2 (but the latter might be misinterpreted) walls that face the outside might indicate which way they face via north_wall, east_wall but if a model might be rotated such names can be confusing so front_wall is better partitions can be named based on the zones on each side e.g. kitchen_partn, coridor_partn, some prefer partn_a, partn_b. The pattern above uses the name to give a clue about the location and composition of the surface. Note: ESP-r is looking for unique combinations of characters, so other languages are ok as long as the ASCII character set is used.

Figure 2.28: Surface(s) attribution. As shown in Figure 2.28, the surface attributes menu includes an *attribute many option (this uses a list selection dialogue described in the Version Appendix). You have a choice of attribution types name, composition, boundary condition,

Select name and you will be asked to dened the name of each of the selected surfaces (note the surface is highlighted in the wire-frame drawing). After attributing the names the display 44

Figure 2.29: Surface naming. 45

Typically adding construction attributions, for those surfaces that you have an opinion about, would be the next task. Use the list of useful constructions you wrote down when you were reviewing the databases). Where several surfaces have the same construction use the *attribute many option. Otherwise select the surface you wish to attribute as in Figure 2.30 where all of the attributes of the surface are reported on and are available for editing. After you have selected the constructions the interface will look like the second part of the Figure. Skip boundary conditions for the moment - there is an automatic process to assign this attribute later in the process. The point of careful attribution is that the combination of the graphic image and surface attribution ensures that the model is correct. If something called door is composed of concrete and you see it as a horizontal in the image someone is likely to notice!

Figure 2.30: All the attributes of a surface and list.

46

Figure 2.31: Initial box shape of examination room. surfaces and then copying surfaces from the reception. For purposes of this exercise it is an efcient approach and it will give you a chance to work with a range of transformation facilities. Referring back to Figures 1.2 and 1.8 the initial box has an origin of 0.0, 0.0, 0.0 and a width of 4m (East along the X axis) and depth of 4m (North along the Y axis) and is 3m high. So return to Model Management ->
browse/edit/simulate -> composition -> geometry & attributions. Select the option to add a zone via input dimensions.

Adding the examination room

The examination room is rectangular in plan, but has a sloped roof and it shares partitions with the reception. There are a number of approaches to creating this zone: start with a simple shape and evolve it use the co-ordinates and link them together to form the surfaces of the zone For purposes of this exercise we are going to start with a simple shape (a box) and transform it into the nal shape. For additional practice look at Exercise 9 in the Cookbook Exercises volume. The transformation is going to involve changing two coordinates to elevate the roof, deleting a couple of 47

You will be asked for a name (say examination) and a description (say something like examination room with doctor and one patient during ofce hours). You will be offered a choice of initial form and this time choose

rectangular plan.

You will be asked for the origin (0.0 0.0 0.0) and dimensions (4.0 4.0 3.0) and orientation (0.0). The result is shown in Figure 2.31. To make the roof sloped we need to alter the Z value of vertex 7 and 8 to 4.5m. If you cannot see the vertices in the X11 version select image control and toggle the vertices option. In the GTK version use the pull down view tab and toggle the vertices option. Select the vertex coordinates menu option and pick vertex 7 and 8 and change the Z value to 4.5m. As you do this the wireframe image will be updated (see Figure 2.32).

the reception zone as well as external walls and clear-story glazing. One quick way to make this transform by rst deleting both Wall-2 and Wall-3. The place to do this is the surface list & edges -> add/ delete/ copy/ extrude_from

option. After you delete these surfaces the wireframe image will look like Figure 2.33.

Figure 2.32: After editing vertices. ESP-r has a rule: every surface has one boundary condition. So what is the boundary condition for Wall-2 and Wall-3? How does this compare to the initial sketch in Figure 1.2? The examination room has partitions adjacent to 48

Figure 2.33: After deleting surfaces. Our next task is to add surfaces to the zone by copying the relevant surfaces from the reception zone. Figure 2.34 shows the available options. We will be using several of these as we progress, rst select copy surface from another zone. A list of known zones is presented (select reception) and then select surfaces part_a part_b and door. You are then presented with a set of transform options for these copied surfaces. These options allow you to reuse existing surfaces in many ways without having to get out a calculator.

Figure 2.34: Copy options. There is a rule in ESP-r: the order the edges of a surface are dened in tells ESP-r which is the outer face of the surface. For example, part_a in reception had an azimuth of 180. We need to reverse this and we select the invert option. You will be asked to conrm this choice for the other two surfaces that you copied. You will also be asked if it is ok to update the edges of some of the existing surfaces to take account of the new vertices that have been included (say yes). After copying the surfaces your model should look like Figure 2.36. Our next task is to ll in the upper external portion of examination. We already have most of the information we need. One of the surface addition options is from existing vertices. We must supply the vertices for the triangular shaped surface on the East side of examination. 49

Figure 2.36: Examination room after partitions and door have been copied. Another ESP-r rule is: If you see the outside face of a surface in the wireframe dene the edges anticlockwise from the lower left corner. If you see the inside face of the surface in the wireframe then dene the edges clockwise. From this rule vertices 6 9 7 are of interest. Do the same for the wall on the upper North face. In the wireframe we see the inside face so the vertices are 9 10 8 7. This will become the frame around the clear-story window so name this surface something like north_frame. Our nal task is to insert the clear-story glazing. Select the inserted into a surface -> as percentage option and give 80%. This will centre the glazing in the surface and is a quick approach when the exact position of the glazing is not an issue. Attribute the glazing with dbl_glz.

Follow the steps you used in the rst zone to complete the attribution of the composition of the surfaces that still have UNKNOWN attributes and to give names. Notice that there are fewer surfaces requiring attribution. Copied surfaces will be partially attributed. You should see something like 2.37 after you have completed the attribution.

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

Figure 2.37: Examination room before 50

2.4 Model topology Having completed the form of the zones there remains the task of dening the boundary conditions which apply to each surface in the model. There is an automated process for this and our next task is to use this facility. For additional practice complete Exercise 10 in parallel with reading this section. Go to Zones composition
-> surface connections & boundary (see Figure 2.38). The

The topology facility scans the polygons of a model looking for surfaces in various zones which are close matches in terms of shape and position and makes inferences from this to complete the boundary condition attribute of each surface. You control the tolerance and the extent of the search parameters and if the tool is unsure of what to do it will pause and ask for conrmation (Figure 2.39).

option you will want to select (after reading a bit further) is check via vertex contiguity but rst click on the ? help option and read about the facilities.

Figure 2.38: Topology options within the project manager.

Figure 2.39: Topology checking conrmation options. One by-product of checking model topology is that it checks every surface in your model in sequence so it makes a great way to review your model. If you periodically invoked the topology facility (say after adding two zones) you will have a chance to review the model at the same time it is searching for matches to the new surfaces you have added. Up to this point the strategy has been to follow working procedures which help 51

us to create correct models. How do we know they are correct? One of the steps in checking the quality of our models is to generate a QA report and then review this against our initial sketches. Exercise 12 of the Cookbook Exercises volume is all about QA and this point in the model creation process is an appropriate time to complete that exercise. In order to run a simulation, each zone in a model must include full thermophysical data for each layer in each surface. To practice creating these zone les read and complete Exercise 14 of the Cookbook Exercises volume. If your initial zone geometry is properly attributed the task of creating these zone les will only take a moment for each zone.

52

Chapter 3

GEOMETRY ALTERNATIVE INPUTS

3 Geometry alternative inputs ESP-r offers several options for geometric input: creating rectangular bodies, extruding oor plans, working with polygons, clicking on points on a grid, clicking on points on a bitmap image (e.g. site plan, building plan or elevation) or importing CAD drawings. It is up to you to select the approach or mix of approaches which are appropriate for your skills and for the model you wish to create. In planing your simulation tasks consider the regularity of the plan, the quality of the bitmap image and the level of clutter in the CAD le. A plan with a 1.3m x 1.7m repeating pattern will not easily t within ESP-rs griding options. A bitmap with only a few pixels per metre will be difcult to accurately select points on and a CAD model that includes thousands of extra surfaces for furniture might be a good candidate for converting into a bitmap. Also consider whether you might use the facilities discussed in this section to acquire critical points on curved elevations and in non-rectilinear plans. This section focuses on clicking on points on a grid with the goal of creating the same model as the rst exercise. Later there will be examples shown of using images from historical records and maps as the source of points in a model. 54

If you are using the Native windows graphic interface or the GTK version of ESP-r on any platform this alternative graphic input facility is not yet available. The planning stage for re-creating the doctor ofce is essentially the same: review the available information establish the level of detail required sketch the model (use your previous sketch) identify critical dimensions and/or points on the sketch decide on the sequence of zone and surface creation Begin with a review the model from the rst exercise and nd your notes from the previous exercise. The overall dimensions of the model are 8m (eastwest) and 7m (north-south). Corners fall on a 1m grid. The exemption is the windows and doors but these will be added later. For this exercise use a 0.5m grid for generating the zones. As with the rst exercises, the identication of critical dimensions, perhaps by marking on an overlay of your initial sketch, is also a key step for this alternative mode of input. You will be

shifting your attention between the sketch and the screen so you will want to nd ways to record your progress. In this exercise you will extrude both zones in sequence and then use the normal geometric manipulation facilities to make the examination roof sloped and add the windows and doors into each zone. Typically one would want to create a sequence of zones (or even a whole model) in one session. A skilled user might expect an average rate of one surface every few seconds and might input a couple of dozen zones in one session. This exercise is intended to help you acquire the skills needed to use the click-on-grid facility. It will likely take you several iterations to acquire the necessary habits. Before using your keyboard and mouse have a read of the next pages and look at the gures. There are multiple steps involved. Those who plan their work and then implement the plan without interruption have the best chance of success. 3.1 To the keyboard... Begin this new project by exiting any open versions of esp-r. Return to where you keep your models and then invoke esp-r. To create a new model following the same process as you initially used: select Model Management -> create new with gp_grid as the root name. accept the folders for this new model ll in the high level description of the project 55

ll in the site data After the site details have been entered select browse/edit/simulate ->
composition-> geometry & attribution.

Select dimensional input and provide the name and a description for the rst zone (reception).

Lets start clicking...

To use the click on grid approach to geometry denition choose the bitmap option. This opens up an initial (blank) command window as shown in Figure 3.1 which allows you to select one of several pre-dened grids or to supply your own bitmap (scanned from a document or created from a CAD tool).

Figure 3.1: Opening menu of click-on-bitmap Before selecting the grid le, adjust the size of the graphic feedback area to be closer to square. You might also use

the window manager to resize the Project Manager so that you have plenty of room to work. This will prevent you having to pan-around the grid as you work. For this exercise select the large for griding option and accept the suggested le name in the dialogue box. This option gives 23 horizontal and 17 vertical so considering each tick is 0.5m will give plenty of space. The initial grid requires further information in order for you to use it as a basis for creating new zones: identify the origin (X=0.0, Y=0.0) typically slightly in from the lower left corner - say at the left + mark. dene the scale of the grid by drawing a line of a know length. If each of the + are 1.0m apart draw a line from the left + to the fourth + and give the distance as 4.0.

initial origin. Now that the scale is dened the real grid can be overlaid by selecting the griding option (choose 0.5m) and then turn on the snap-to option. The mode >> menu option (Figure 3.3) lists a number of choices for entering data points. The rst two options are useful for topographic/site data. The oor plan extrusion option is equivalent to the oor plan extrusion used in the initial exercise to create the reception zone. However, this time rather than typing in coordinates, you will be clicking on points on the grid you created.

Figure 3.2: Origin and scale and grid If you plan to dene zones which extend into the negative X or Y dimension you would adjust the position of the origin to reect this. Note that you can pan to the right and/or upwards as necessary but you cannot pan any farther left or down after you set-up the 56

Figure 3.3: Which input mode Once you have selected the oor plan extrusion input mode (see Figure 38) set the oor elevation to 0.0 and the ceiling elevation to 3.0 (to match Figure 1.2) Just before starting to dene points it is worth noting that you are able to interrupt the input process and move around a bitmap.

Use the start option to begin dening points in the same order you used in the previous chapter. Start at the grid nearest x0.0, y4.0 and then x4.0, y4.0 etc. until you reach x0.0, y7.0 (see Figure 3.4) after which you will type the character e to end the input. With the snap-to option you only need to click near the point and it will snap to the nearest grid. If the snap-to option is off the Project Manager will accept the actual point where you click. If you make a mistake or the point snaps to an incorrect grid point then immediately type the character d to delete the last entry (multiple deletes are possible. After you have signalled the end of points for the initial zone (by typing the character e) you can save the zone data (if you did it correctly) or try again if you are not satised. While saving the zone data, an additional le is created to hold the topology of the model and you can safely accept the le name offered for conrmation. A new option create another zone will be displayed in the menu once the initial zone is saved. This can be used as many times as required to extrude zones (using the current oor and ceiling height attributes). In the current exercise the examination room needs to be added. It has the same initial oor and ceiling height as the reception zone so those attributes need not be altered. When you are ready, select the create another zone option and supply a name and description for the examination room. 57

Note that three of the corners of the examination room are at the same grid points as used by the reception and unless you specify otherwise, those coordinates will be used. Note also that the edges of the reception are still visible so that it is easy to create new zones adjacent to (including above or below) prior zones. Since you are extruding a oor plan you will proceed anti-clockwise from the origin typing the character e when you have done all four corners. When you started clicking on each subsequent zone, a message is included in the text feedback to remind you of the keyboard control options. When you signal that you have nished selecting points for the examination room (by typing the character e) you will be presented with options to save or repeat the zone denition. As the examination room is the last zone, exit from the click-on facility and you will be presented with a wireframe view of the zones you have created (Figure 3.6). These zones still require surface attribution as well as the addition of doors and windows and raising the roof in the examination room. Such tasks can be accomplished by using the geometry & attribution facilities introduced in the previous chapter. And this would also be a good time to revisit Exercise 12 in the Cookbook Exercises volume, generate a QA report and compare it with the original model.

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 bitmap A variant of the click-on-grid approach is to supply your own bitmap (plan/section/elevation/site-plan) and click on points found in that image to create one or more thermal zones. In Figure 3.7 an UK Ordnance Survey map has been converted into an X11 bitmap le and used with the click-onbitmap facility to create ground topography surfaces to associate with a model. Note that the solid lines (representing the contours selected) is an approximation of the contours on the map because ground representations supports several hundred surfaces rather than several thousand surfaces. The option used to within the bitmap facility were points with different Z.

Figure 3.7: Using a contour map bitmap le. Several tactical warnings should be given: try a small portion of a map until you are comfortable with converting such contours into surfaces. there is an automated triangulation facility but many users report that complex arrays of points can be 59

problematic. using a click on bitmap approach is no excuse for skimping on the planning of your model! It is far to easy (bitter experience) to get carried away with the clicking and include more complexity than necessary get lost while doing the clicking collect points in such a way that the time taken to post-process the surfaces is greater than that associated with the clicking. So ALWAYS... mark-up your image with indications of the critical points you want to capture and the bounds of the zones you will be creating, if you have bitmaps for more than one level make sure you can keep the points in-register and that the scale can be set-up to be equivalent, sketch your model in three dimensions so that you can plan how partitions between zones work, If you have ceilings and/or oors that are not level there are several possible approaches, some of which will save you time and some will not. Experiment with constrained models to see what approach to the click-on-bitmap works best for you. Keep a note of what works so that you can follow this tactic when confronted with a similar project in the future. 3.3 Examples of approaches to take Once you have the requisite skills it should be possible to create substantial models with some speed. In the 60

examples below there were two issues creating models which the client would recognize and also models which captured the spacial characteristics of the building. An example of using a scanned image to import information that is only available in hard-copy form (no CAD data). The theatre shown in was initially constructed in the mid seventeen hundreds and the last set of drawings available were from the mid nineteen seventies. It is also notable in that almost nothing is rectilinear. The mode in Figure 3.9 was initially composed by clicking on a set of points from Figure 3.8 which were placed in dummy zones. Surfaces and points from those dummy zones were then used to build up the model zones. There was a detailed plan of the zoning worked out prior to the use of the clickon-bitmap facility. Even with this, considerable care was required and postprocessing and reconciliation of the partition surfaces was required. This is an example of what can be accomplished by an experienced user and is just the sort of project which would be cruel and unusual punishment for a novice.

Figure 3.8: Bitmap image from historic building.

Figure 3.9: Bitmap image from historic building. topography was created and initial simulations commissioned within 12 hours of the completion of the simulation planning phase. It would have been faster, but one drawing was off-scale and several zones had to be adjusted to bring them into alignment. 61

The model in Figure 3.10 and 3.11 was largely composed by a clicking on a mix of Ordnance survey maps, old planning documents and drawings. The model, including zone geometry, shading obstructions and ground

Figure 3.10: Layout of a museum and park.

Figure 3.11: Rendering of a museum and park. exercise that explores clicking on a plan image from a CAD tool - make up your own exercise! These facilities are useful for many models and the fact that they have not been ported to the GTK interface is a limitation which needs to be addressed. 62

If you want additional practice (highly recommended) try to complete Exercise 11 in the Cookbook Exercises volume. It describes a four zone model to create. See how much time it takes you to create that model. There is no

The next chapter approaches the topic of model geometry from a different perspective.

63

Chapter 4

3D MODELLING

4 3D modelling

Figure 4.1 Section and view of house 65

The geometric forms discussed thus far use polygons as the building blocks of our virtual built environment. While modern (thin) constructions, such as those used in Figure 1.5 are often approximated by conventional polygons, historical buildings (see Figure 1.6) and the thick walls and insolation seen in Figure 4.1 highlight the limitations of this convention. Focusing on Figure 4.1, there are several aspects of the section which need to be considered during the planning and creation of models: the thickness of insulation is substantial and at the edge is somewhat less thick the wall section comprises a number of material types there is an overhang which will act to shade the facade of the building the overhang is thermally isolated from the air within the roof space the overhang forms a boundary for the upper section of the wall. there appears to be an air space below the tiles which is separate from the air within the roof space. the portion of the roof with the tapering insulation is in direct contact with the layer of wood below the tiles it is not clear from the section whether the roof space is well ventilated. the area at the top of the insulation layer is somewhat different from the surface area at the ceiling. 66

The list of bullet points could be much longer. We need strategies for ranking thermophysical issues and deciding what needs to be included in our model(s). 4.1 Modelling approaches The geometric and compositional resolution of a simulation model depends on the questions being asked and the resources available. Some thermophysical relationships may require simplication and other might not be possible to represent within our model. All virtual environments are abstractions. Simulation tools support one or more levels of abstraction for each of the domains they solve. Options allow experts freedom at the cost of a steep learning curve for novices. A tactical approach to simulation uses the planning phase to constrain options. The following is one possible ranking of what to preserve while abstracting 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 air A low resolution model might treat the overhang as a solar obstruction and ignore the different thickness of the insulation. It might assume the air is well mixed within the roof space (i.e. there is no temperature stratication). It would also not explicitly represent the overhang as a boundary condition for the upper portion of the wall. A medium resolution model might subdivide the surfaces to represent full

thickness and the partial thickness insulation and extend the roof zone to allow it to form a boundary at the upper wall section. A high resolution model might represent the overhang portion of the roof as a separate zone or zones because there will be times when the air temperature in the overhang is different from that of the main section. A high resolution model would have an upper and lower section so that the temperature near the peak of the roof can be different from the air adjacent to the insulation layer. By default, ESP-r assumes one-dimensional conduction. The thickness of the insulation in Figure 4.1 poses a challenge in comparison to a suspended ceiling. Do we choose to ignore the ceiling thickness when dening geometry? Use of physical co-ordinates would help to preserve the volume of the roof space and the surface areas and takes more time to describe. Many example models distributed with ESP-r appear to ignore the thickness of partitions while other example models indicate a separation between rooms. Such differences are typically related to the method of data input. Geometry digitized from CAD drawings will have rooms separated in space. Zone geometry created from dimensioned data or sketches may tend to have partitions at the centre line of walls and the inner face of a facade. The good news is that such differences typically have little or no impact on predicted performance. The solver knows from the thermophysical composition of the partition whether or not the two faces are separated in the co67

ordinate system or lie in the same plane. There are exceptions which are covered elsewhere. If the user is constrained in time, the user could form the base of the roof space by copy and invert the existing ceiling surfaces and then create the sloped roof above that (see Figure 4.2). This approach results in a model that is crude visually. The surface of the roof is at the correct slope, but the height of the building is not correct.

Figure 4.2: Constrained model Given a bit more time the user could add a number of perimeter surfaces so as to raise the roof (at the expense of an inaccurate air volume) as in Figure 4.3. Such trade-offs might not alter the overall performance of the building but may be useful to make the model less crude visually.

Figure 4.4: Surface transform options

Figure 4.3: Variant placing roof at correct height To move from treating the ceiling as a geometrically thin plane towards a model that uses explicit coordinates requires an additional step. The initial copy and invert of surfaces is followed by a surface transforms (along the surface normal). This facility, and several other types of rotation and transform are available in the interface (see Figure 4.4). If you nd it difcult to see all of the lines or labels in the wireframe view use the GTK view facility to rotate or highlight portions of the model (see Figure 4.5). If there is a gap between the roof zone and the occupied zone (as in Figure 4.6) this might be visually confusing to some users and their clients (if the ESP-r model was exported to Radiance). This gap could be lled with an appropriately sized solar obstruction block. 68

Figure 4.5: Wire frame control dialogue.

Figure 4.6: Variant using coordinates.

The above approach might be a reasonable thermophysical representation. It is, none-the- less quite abstract for users expecting a CAD representation. To approximate the 3D geometry of an actual roof requires that the initial copy, invert, transform of the ceiling polygons is followed by the addition of surfaces to represent the roof overhang as in Figure 4.7.

would be tedious to retrot into the existing zones shown in Figure 4.1. As mentioned in the introduction, the air within the overhang could be at a different temperature than the roof space. If such temperature differences were an issue, the overhang could be represented as a separate zone as in Figure 4.8. This overhang zone could wrap around the main roof space zone (one overhang zone could represent the overhangs on the North, South, East and West. Again the existing wall will have to be revised to represent the connection to the outside and the connection to the overhang. One could be pedantic and argue that the temperature of the North overhang might differ from that of the South overhang and require separate zones. Few users would be confronted by projects where such detail is warranted.

Figure 4.7: Variant extending overhang. Note that the surfaces forming the overhang do not (in the current version) shade the wall. Shading requires the use of shading obstruction blocks (as included in the earlier gures). And this more-explicit approach introduces a problem for the occupied space. The overhang, as drawn in the building section is in contact with the upper portion of the wall. The geometry of the walls should be adapted to sub-divide the wall into surfaces that face the outside and surfaces which connect to the overhang. Clearly this 69

Figure 4.8: Variant with separate overhang zone.

Investing resources to increase model resolution is a decision that should not be made lightly. Some differences in performance predictions can be subtle rather than dramatic. A user who wishes to explore this could dene variant models at different levels of resolution to test the sensitivity of predictions. 4.2 Steps to create a roof space

A tactical approach to simulation reuses existing entities where possible. This roof is one example of using the existing ceilings to compose the base of the roof space. Experienced users plan their work for maximum re-use! A low resolution model of a roof space over the occupied rooms shown in Figure 4.1, and making use of the existing ceiling surfaces, and which follows the pattern of Figure 4.2 has the following critical dimensions: the height at the peak of the roof 4.35m the lower face of the ceiling 2.35m the width of the overhang 0.6m The following sequence will minimize keystrokes and limit the risk of error. Other sequences are possible - so try variants until you evolve a sequence that works for you. Enter the menu browse/edit/simulate -> composition -> geometry & attribution menu and

review their contents and ensure that the ceiling surfaces are attributed (to save time in later steps). Next in the geometry & attribution menu select add/delete/copy. After electing to add a zone, select input dimensions and enter a name such as roof_space as well as a description to clarify to others the intent of this zone. Because most of the initial surfaces will be borrowed from the existing zones it saves time to use the general 3D option for the initial shape. The initial X Y Z position of the rst surface is not applicable so just accept whatever is included in the dialogue because this surface will be deleted later on. Ignore the warning about the volume of the zone being zero. An initial wire-frame image with a single surface will be displayed (see Figure 4.10). Your rst task is to go into the surface list & edges menu and select + add/insert/copy surface. Use the copy surface(s) from another zone option several times to form the base of the roof_space zone. It does not matter what order you copy the surfaces as long as your work pattern avoids duplication and ensures that all of the ceilings are copied.

select each of the existing zones and 70

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

Figure 4.10: Initial dummy surface in roof_space.

71

Figure 4.11: After import and inversion of a surface.

Figure 4.12: roof_space with imported ceilings.

Figure 4.13: roof_space with two ridge vertices. 72

Figure 4.14: Zone with roof surfaces.

Figure 4.15: Better QA via combined wireframe and text report. For each surface being copied, the wire frame view is updated to show the other zone as an aide to selecting the correct surface. It helps if the surfaces in such lists are clearly named. Remember to select the invert option as seen in Figure 4.15. After the rst copy the roof space will look like 73

When you select a surface in another zone you will be asked if there are any transforms to apply. The key transform is invert which takes the polygon dened in the other zone and reverses the order of the edges so that it faces the correct way within the roof_space.

Figure 4.10.

Figure 4.15 The invert dialogue. During the import you might nd a source surface with a duplicate name. You will be asked to specify a new unique name. Tactical hint: if you follow a clear naming strategy, subsequent tasks will go faster. At some point remember to remove the initial dummy surface. When all of the ceilings have been imported the roof_space will look like Figure 4.11. Each surface name provides a clue as to what is on the other side of the ceiling. Typically, each imported surface will require between 5 and 10 seconds for an experienced user and if there are name clashes it might require 20 seconds per import. There are a number of steps which you can take at this point which will prevent the propagation of errors. For example, the wire frame image will have open circles drawn at each vertex that is referenced once - so open circles are to be expected at the borders. The wire frame image will have solid circles at vertices not referenced by any surface. You will see four such circles in the wire frame - these are orphan vertices associated with the initial 74

dummy surface. It will save time and limit confusion if you exit from the Surface topology menu and go into the vertex coordinates menu and identify vertex 1, 2, 3 and 4 for removal. While you are in the Vertices in menu take a note of the Z values. The current position of the surfaces is at 2.35m. We want the ridge of the roof to be 2m above this point. The roof is a hip type and the dimension from south to north is 7.2m so the so the ridge will start 3.6m from the East and West and South edge of the building facade. These two coordinates are then: left ridge point X=3.6, Y=3.6, Z=4.35 right ridge point X=15.77, Y=3.6, Z=4.35 For a gable roof the X co-ordinate would not be altered to form a pair of triangular walls. The next step is to + add two more vertices to the roof_space zone. The result should look like Figure 4.13 (look for v17 and v18). The next step is to compose the South, East, North and West surfaces of the roof by creating new surfaces made up of existing vertices. With reference to Figure 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.

 west surface should include vertices 8 1 17. There are patterns in the above denitions. What are they? Each surface is dened in an anticlockwise order (looking from the outside) the rst edge is horizontal and the second edge is not horizontal intermediate vertices (e.g. 2 and 9 and 15 etc.) are included in the list The rst edge horizontal rule is required by the shading and insolation analysis. Look at the surfaces in any of the simple exemplar models and you will see this pattern. With simple shaped surfaces there is usually only one edge along the base of a wall and for such surfaces the normal rule of start from the lower left edge going anti-clockwise applies. In this case because there are several edges in sequence so the rule has to be adapted. If you miss out one of the intermediate vertices (e.g. vertex 15 along the east faade) ESP-r will detect a mismatch and warn you to check the polygon edges. If you followed these steps, the interface should look like Figure 4.14. An experienced user will require about 10 seconds to create a new surface from existing vertices and will also be double checking that data glitches are caught early and corrected before progressing to the next task. Practice until you feel condent with the technique! Notice the enclosure: properly bounded message at the top of the menu. This signals that all of the edges in the zone are following the rules of 75

syntax and order and that the zone if fully bounded by polygons. A further check could be done by turning on the surface normal arrows in the wire frame drawing (in the X11 interface this is found in the wire-frame button and in the GTK interface the option is within the pop-up dialogue (as in Figure 4.5). Almost nished. Now is a good time to contrast the visual information in the wire frame with the zone & surface details report (see Figure 4.14). The few seconds that it takes to generate this report and review it with the wire frame will typically save tens of minutes later. Having created the polygons and given them names, the next task is to attribute the surface composition. A copied surface already has inherited attributes. The new surfaces of the roof are partially attributed at this point. Remember that there is a automated process which looks at the co-ordinates of each surface to nd thermophysical adjacency. It may be quicker than attributing each surface in the roof_space manually. Generate a QA report and check the contents before you continue.

Chapter 5

SCHEDULES

5 Schedules The form and composition of a model is one part of the simulation process. Many users think they have almost completed their work when the geometry is done. Far from it, buildings are almost always places where people are coming and going and lights are being turned on and off and all manner of electrical devices are found. Usually we lack both the detailed information and the resources to undertake an exhaustive denition. It is, however, in our interest to dene the essential characteristics of what goes on in a building and learn from the performance patterns that emerge sufcient clues to imagine the circumstances where the building would perform poorly. ESP-r supports zone operational characteristics in terms of weekdays and two separate weekend days (typically labelled as Saturday and Sunday). Work is underway to implement more day types but for this exercise lets stick with the basics. It is also possible to dene unique values for each time-step of a simulation, but lets not go there yet. Casual gains (e.g. people, light, small power) are one operational characteristic of a zone and schedules of inltration (air from the outside via intentional sources such as fans or unintentional sources such as cracks in 77 the facade) and ventilation (air from another thermal zone) and there are a limited number of controls you can impose on inltration and ventilation schedules. What are casual gains in ESP-r? The lower portions of Figures 1.9 and 1.10 show the attributes of the casual gains each has a day type (Wkd/Sat/Sun) a casual gain type label (Occupt/Lights/Equipt) a period (start hour and end hour) a sensible and latent magnitude, and for the sensible portion the fraction of the gain which is radiant and the fraction which is convective. The convective and radiant fraction defaults should be adjusted to reect the properties of specic light ttings and occupants. Just before creating a schedule be aware that groups who frequently work with a particular building type will likely have historical data as well as prior models which could contain useful patterns of occupancy and small power use. There are several techniques for helping to re-use such information and this will be covered later in this section. To give you more practice with creating zone schedule also have a look at Exercise 13 in the Cookbook Exercises volume.

For the current building a brief description was given in the How the building is used section, specically Figure 1.10 and 1.11. Re-read that section. Also look at Figure 53 for reception data. Before we dene the operational characteristics of the reception and examination room within the Project Manager a bit of planning will (you guessed it) save time and reduce the chance of errors later on. In the reception there is one staff and up to 3 visitors with 10W/m2 lighting and 1 50W From the gure it is clear the occupancy changes throughout the day (ramping up from 7h00 and with a dip for lunch and almost nothing happening after 17h00) but the lights are on during ofce hours plus some time for cleaning staff (8h00-19h00). In the examination room there is one staff and one visitor with 10W/m2 lighting and 1 100W computer . From the gure it is clear that occupancy varies during the day and that both lights and small power (labelled as equipment) are on from 8h00-19h00 and nothing happens on the weekend. Why bother with varying the occupancy during the day? Several reasons - full time peak loads usually do not happen in reality so a bit of diversity is more realistic, reducing the load during a lunch hour allows us to check whether the building is sensitive to brief changes in gains and the ramp-up just before ofce hours and the rampdown after ofce hours approximates transient occupancy. The peak demands are long enough to indicate whether heat will tend to build up in the rooms. Such patterns will also 78

exercise the environmental system and perhaps provide an early clue as to the relationship between building use and system demands. Quite a lot of value for a few minutes thought at the planning stage. In the reception the peak occupant sensible gain is 400W and in the examination room the peak is 200W equating to 100W per person. The latent magnitude is roughly half the sensible value. Such assumptions, if documented, really do help clarify the numbers held in the le and can speed up later QA tasks. One of the rst questions you will be asked when you begin to dene the operational characteristics of zones is the number of periods for each day type and the start time of each period. For weekdays the reception has 8 occupant periods and 3 periods for lighting and 3 periods for small power. According to Figure 1.9 the occupant periods would start at 0, 7, 8, 9, 12, 14, 17 and 21 hours. On Saturday and Sunday there are zero periods. In the Project Manager go to Model
Management - browse/edit/simulate -> composition -> operational details. Select the zone

reception and you will be presented with an initial le choice with an option to browse for an existing le within your model (you could use this if you have several rooms which use the same pattern). The le name is suggested based on the name of the zone. Accept the suggested name and then you are presented with a number of options for how to dene the schedules (Figure 5.1).

Figure 5.1 Options for generating schedules. For this exercise we will use the start from scratch option. You can also import patterns from other existing zones in your model as well as from zone operation les that have been placed in a standard pattern folder. You will be reminded about planning your schedules (do read this because it is a useful reminder). And then for each of the day types you will be asked for the number of periods for occupants, lights and small power. This will be followed by dialogues which ask for the start hour of each of the periods for each of the casual gain types (get this from your notes). Do the same for for Saturdays and Sundays. You are now presented with the menu in Figure 5.2.

Figure 5.2 Opening zone operations menu. Fill in the description of the zone operations using words and phrases which will clarify what is happening (note the X11 editing box has < > arrows so you can scroll to a more text). Next select option c to ll in the rest of the casual gain period details. You will be presented with a menu with period data which you need to ll in based on your notes. As you were lling in the period data you will note that you have a choice of units. From the notes occupants are Watts, lighting would be 3.75 W/m2 if we used that unit (the notes say 150W and the oor area is 40m2), and small power as Watts. After you have dened the magnitude of the sensible and latent gains and accepted the default radiant and convective split you should see something like Figure 5.3.

79

Figure 5.3 Weekday casual gains.

Figure 5.4 Weekday inltration schedules. Using the information on your notes you could also dene the casual gains 80

for the examination room. 5.1 Scheduled air ows Early in the design process building details may not support a detailed description of how air moves within buildings or how tight the facade might be so engineering approximations are often used. The brief didnt actually mention anything so an initial assumption needs to be made. In an actual project discussions would be made within the design team to quantify this gure. For purposes of this exercise lets have a rather leaky facade and assume that the doors are closed between the reception and examination room. We can represent this with one period each day covering the 24 hours with a value of 1 ac/h inltration and no ventilation (see Figure 5.4). Use the add/delete/copy import flow option and select add for all day types. Later we might decide to lower the inltration rate to see if the building is sensitive to an upgrade in the quality of the facade. Other sections of the Cookbook outline options for treating air movement via mass ow networks which can assess pressure and buoyancy driven ows between thermal zones or via Computational Fluid Dynamic Domains. 5.2 Importing operation schedules Creating zone operations from scratch is time consuming so many users will collect their best zone operation patterns and store them in the pattern 81

folder (located with the training models). If you have already lled in the schedules for the examination room repeat the process but change the name of the le slightly so as not to mess up your prior work. When the selections in Figure 5.1 are shown pick air and gains < from pattern and a list of les will be shown. Select one of them (remember which one) and look at the summary and answer the questions about air ow and then about casual gains. Since it does not know the volume or the oor area associated with the pattern le it needs information from you. If the author of the le you are getting the pattern from was really clued-up such information would be included in the documentation. You will have a opportunity to edit the documentation and this is you chance to ensure that what is included in your model is clearly dened, especially if you need to scale some of the values. Figure 5.5 is the result of importing a pattern le. Such patterns can be altered easily - note that the peak value for occupants and lighting and small power are each 100W. To upscale the small power for use in your current zone would require only that you select the scale existing gains option and provide a scaling factor.

Figure 5.5 Imported pattern le data.

Once a model includes the zone geometry and the thermophysical data les and the schedules of use it is possible to run a simulation. If you think you are at this point then have a look at Exercise 15 in the Cookbook Exercises volume and see if you can assess your models performance. If you have not dened environmental systems then the assessment will be based on a free oat assumption.

82

Chapter 6

CLIMATE DATA

6 Climate data ESP-r has a number of facilities which allow us to scale our models and assessments - so we get, for example, annual heating and cooling for a whole building without simulating every day of the year or every oor of an ofce building. These facilities evolved over time based on observations about how practitioners adapted their models and the assessments they commissioned to t within their computational and staff resources. For many building types there is a strong correlation between predictions over one or two typical weeks in each season and seasonal heating and cooling demands. This can be demonstrated by commissioning short period assessments and full season assessments and looking at the relationship between the two performance predictions. Commissioning full season assessments to determine scaling for a building does take time and so alternative methods were investigated. Over scores of projects it emerged that there were relationships in the climate data that could be used to identify suitable short assessment periods. The key to this was in the practitioners denition of the extent of each season and search criteria for typical periods. For many readers seasons are demarcated by four month intervals or by 84 notes in a reference guide. If we pause to consider what constitutes winter in Hong Kong we might conclude that it is triggered by something other than temperature. The start of spring might be a day on a calendar but often there are cultural clues such as cherry blossoms which trigger changes in how we dress and how we operate our buildings. Astute practitioners leveraged this insight when they reviewed their climate data. Before we had access to computers which supported numerical simulation simplied methods such as heating degree day (HDD and later cooling degree day CDD) methods were used. We observed that practitioners often did a quick check of HDD and CDD to judge, for example the onset of demand for environmental controls or the likely period that the building might be allowed to free oat with minimal loss of comfort. To nd out if such indicators were a possible shortcut to explicit seasonal assessments we looked at the ratio between short/seasonal HDD and the project assessments and found similarities. A better t was possible if solar radiation was taken into account.

Figure 6.1 Season HDD, CDD, Radiation summary.

Figure 6.2 Winter t criteria. listing Figures 6.1-6.3. Climate data is scanned week by week for the average The method embedded in the ESP-r HDD and CDD for each day and the climate module codies the manual total for each week as well as the daily techniques and is illustrated in the 85

mean direct and diffuse solar radiation. To allow ne-tuning of the scan the user can provide weighting factors for HDD, CDD and solar radiation as well as the base temperature for HDD and CDD. The weekly data are then compared with the average and total values for the season and the week with the least deviation is suggested as the best t. Model calibration exercises that use such best-t weather patterns in each season can provide a reality check which is both constrained in computational time but sufciently focused for staff to notice patterns that would not be evident in a worst day winter/summer assessment. To make it easier for practitioners to use selected weather patterns climate data sets can be supplemented with information about seasons (early-year winter, spring, summer, autumn, lateyear winter in the Northern Hemisphere, early-year summer, autumn, winter, spring later-year summer in the Southern Hemisphere) as well as typical assessment periods. 6.1 Importing climate data To better understand how this works our rst task is to install a new climate le and specify the days in each season and then use clm facilities to discover typical assessment periods in each season. After this we will derive scaling factors for heating, cooling, lighting, small power etc. demands to use in our model. Downloading a new climate data set from a United States DoE web site (on one line) 86

<http://apps1.eere.energy.gov/ buildings/energyplus/ cfm/weatherdata.cfm>. The site

offers US locations, Canadian Locations and International Location. Lets choose an international location Geneva Switzerland. The le for this site is CHE_Geneva_IWEC.zip. Download it and save to a convenient location and unpack the zip le. One of the les will be CHE_Geneva_IWEC.epw. Most current EPW les can be imported directly into the ESP-r clm module.

For Linux/Mac/Unix use a command window, go to the location of the EPW le and issue the command (as one line): clm -mode text
-file CHE_Geneva_IWEC -act epw2bin silent CHE_Geneva_IWEC.epw.

This creates a new ESP-r climate le CHE_Geneva_IWEC. The message error reading line 1 is sometimes seen when doing the conversion, but does not usually affect the conversion. The command given to the clm module includes the name of the new binary climate le to be created after the key word -le. The words -act epw2bin silent tells it to undertake the conversion without further interactions.

For the Native Windows version you will have to start up the clm.exe module interactively and provide a new ESP-r climate le name and provide the name of the EPW le in the import option. To check that the conversion worked, invoke the clm module with the new le or use the le browser to locate the new le:
clm -file CHE_Geneva_IWEC

If the conversion was correct you should see the lines

Climate data: GENEVA CHE 46.2N 8.9W: 1984 DN

in the text feedback area of the interface. And for good measure try to graph temperatures and solar radiation. If there is an issue with the le then open it in a text editor (nedit is used in Figure 6.3). There are several changes you might need to make in the le. Line 6 might include a # character before the WMD number and this should be replaced by a blank character so it is not treated as a comment. Some EPW les have a blank line at the end of the le (line 8769). Remove this line, save the le and try importing again. Further instructions for working with EPW les will be found in the ESP-r source distribution in the climate folder.

6.2 Dening seasons and typical periods Our next task is to dene the days associated with each season. There are any number of approaches one might take. For this exercise we will use a combination of looking at the patterns of temperatures over the year and the solar radiation. In the climate module choose graphical analysis from the menu options. Then pick dry bulb temperature and draw graph to get a display similar to that in Figure 6.4. The axis at the bottom of the graph is weeks. There are extreme low temperatures in weeks 4, 9, 46 and 52. There is a late cool period in week 12. In week 14 it reaches 22C. The warmest period is between week 26 and week 32. Another way to look at climate information is to look at weekly heating and cooling degree days. To to this select synoptic analysis and then choose dry bulb temperature and then degree days and then weekly. Take the default base heating and cooling temperatures This will produce a table as Figure 6.5.

87

Figure 6.3 Editing of EPW le.

Figure 6.4 Annual dry bulb temperatures. off of about 10 then the denition of seasons is straightforward. The average heating degree days is Before we actually set the dates, note roughly 15.0 for the rst nine weeks that 1 January is on a Sunday and the and then drops to roughly 8.0 (except start of each subsequent week is also a for week 13). Weeks 27 to 34 have Sunday. Later, when we search for typcooling degree days between 10 and ical weeks they will begin on a Sunday. 23. This follows the same pattern as Some practitioners prefer to run assessseen in the graph. If we set a winter ments that begin on Mondays and end heating degree day cut-off point of 12 on Sundays. If we wanted to enforce and a summer cooling degree day cut88

To record this information go to the manage climatelist option on the main menu. You will be presented with the options shown in Figure 6.6. What is shown are initial default dates for seasons and typical periods which you will need to update. If the menu string item and the menu aid are not clear then start by editing the menu selection and documentation text. For example the menu aide memoir could be Geneva CHE was source from US DoE. Menu option c is the full path and name of the climate le that ESP-r will access after it has been installed in the standard location. For the le we have been working with this is /usr/esru/esp-r/climate/ CHE_Geneva_IWEC. Menu option d is a toggle which tells ESP-r whether the le is ONLINE or OFFLINE. Set this to ONLINE. If it is OFFLINE then others will not see this le. The section of the menu under seasons allows us to edit the beginning and ending date of each season. After dening each season we can then use the scan climate for best-t weeks to search for weeks that are closest to the seasonal average conditions. Notice Figure 6.5 Heating and cooling degree days. that in this case, each season begins on the same day of the week. You could Using these cut-offs the seasons are as: also dene seasons that do not start at early-year winter 1 January - 11 the same day of the week. March spring 12 March - 24 June summer 25 June - 26 August autumn 27 August - 18 November late-year winter 19 November - 31 December. that preference what we need to do is to change the year of the climate set so that January happens on a Monday (e.g. 2001). This change can be found in the edit site data menu option of the main clm menu. Once this is changed, return to synoptic analysis and ask for the weekly degree day table again. 89

eight which starts on Monday 19 February. This method can result in a good estimate of the energy use over a season although it will be less accurate for worst case peak assessments. Use the scan climate for bestbit weeks option to search for the typical weeks. After conrming each of the seasonal suggestions the interface will updated as in Figure 6.7.and selecting the graph ambient T and seasons option the graph should look like Figure 6.8.

Figure 6.6 Menu for creating a climatelist entry. The criteria for heating and cooling are based on a combination of heating and cooling degree days and solar radiation. For example, the seasonal average weekly heating degree days and cooling degree days (102 and 0 for early year winter) as well as the solar radiation (11.05). It will then look for the week with the least deviation after conrming the weighting we want to give to heating DD, cooling DD and radiation. These are initial set to 1.0 to give an equal weighting (but you can change this if you want). It nds the smallest deviation (0.14) for the week 90

Figure 6.7 After editing climatelist entry.

Figure 6.8 Seasons of the year. newly created climate le to the standard folder. The next time ESP-r is used the new climate le should be available and the seasons and typical weeks should be registered. Before closing the clm module, it is useful to save the ESP-r climate data into an ASCII format le. Do this via the export to text file option of the main menu. Accept the default le name CHE_Geneva_IWEC.a and the period. The climate le CHE_Geneva_IWEC should be placed in the standard folder (e.g. /usr/esru/esp-r/climate) and the ASCII version CHE_Geneva_IWEC.a should be kept as a backup in case the binary climate le becomes corrupted. Again, on some systems, you may have to ask administrative staff to copy to le to 91

6.3 Climatelist entries The nal tasks are to record this information via the list/generate/edit documentation option initialize option and then use the save option to write out the data to a le. It will give it a name based on the original climate le with a .block extension. The block of text that was generated is listed below. It needs to be pasted into the so-called climatelist le. There is an edit option. Also open the block le, check the entries and to add any text you want to have displayed to users (in the *help_start to *help_end). Insert the text (carefully) between an existing *help_end and *item line and save it. Dont forget to copy your

/usr/esru/esp-r/climate (or wherever the le climatelist is located on your machine).

*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_start Climate is GENEVA - CHE Location: 46.25N 8.87W : 2001 Month Minimum Time Maximum Time Jan -6.8 @ 4h00 Fri 26 11.1 @16h00 Sun 14 Feb -5.8 @ 7h00 Tue 27 11.7 @16h00 Wed 7 Mar -2.7 @ 7h00 Tue 27 16.8 @16h00 Sat 10 Apr 1.4 @ 7h00 Wed 11 22.4 @16h00 Wed 4 May 1.6 @ 4h00 Tue 8 25.5 @16h00 Tue 15 Jun 7.7 @ 1h00 Tue 19 29.0 @16h00 Mon 25 Jul 10.5 @ 4h00 Thu 5 32.1 @16h00 Mon 9 Aug 7.1 @ 4h00 Thu 30 31.4 @13h00 Wed 22 Sep 8.3 @ 7h00 Fri 7 27.6 @16h00 Sat 22 Oct 0.1 @ 7h00 Wed 31 21.1 @13h00 Mon 1 Nov -4.1 @ 7h00 Sun 25 14.7 @16h00 Fri 2 Dec -4.0 @22h00 Mon 31 9.8 @13h00 Mon 17 Ann -6.8 @ 4h 26 Jan 32.1 @16h 9 Jul 10.4 ---Seasons & typical periods--Winter season is Mon 1 Jan - Sun 11 Mar Typical winter week begins Mon 19 Feb Spring season is Mon 12 Mar - Sun 24 Jun Typical spring week begins Mon 21 May Summer season is Mon 25 Jun - Sun 26 Aug Typical summer week begins Mon 6 Aug Autumn season is Mon 27 Aug - Sun 18 Nov Typical autumn week begins Mon 1 Oct Winter season is Mon 19 Nov - Mon 31 Dec Typical winter week begins Mon 17 Dec *help_end

# col 6: Relative humidity (Percent) GENEVA - CHE # site name 2001,46.25,-8.87,0 # year lat ... 1,365 # period (julian days) * day 1 month 1 0,-24,0,10,250,81 0,-18,0,8,250,85 0,-14,0,7,250,88 0,-14,0,5,240,90 0,-15,0,12,240,91 0,-17,0,19,240,93 0,-18,0,26,240,90 0,-14,0,17,240,90 11,-10,0,9,240,90 81,-6,53,0,0,89 94,1,361,3,0,89 155,9,130,7,0,91 77,16,0,10,240,92 72,18,0,12,240,92 55,20,0,13,240,92 30,22,0,15,240,92 6,19,0,12,240,93 0,15,0,8,240,93 0,12,0,5,320,93 0,7,0,7,320,92 0,3,0,8,320,91 0,-2,0,10,310,92 0,-5,0,10,310,92 0,-7,0,10,310,92 * day 2 month 1 0,-10,0,10,260,92 0,-12,0,8,260,92 0,-13,0,7,260,92 0,-15,0,5,10,91 0,-20,0,5,10,91 0,-25,0,5,10,91 0,-30,0,5,360,91 . . .

It might also be necessary to import climate data from a le that does not conform to the EPW standard. The other le format that ESP-r understands is its own ASCII version. If possible convert your climate data into a format similar to that dened below:

*CLIMATE # ascii climate file # defined in: CHE_Geneva_IWEC.a 2001,46.25,-8.87,0 # year lat, ... # col 1: Diffuse solar horiz (W/m**2) # col 2: Ext dry bulb T (Tenths DEG.C) # col 3: Direct normal solar (W/m**2) # col 4: Wind speed (Tenths m/s) where the rst token is the year, the # col 5: Wind direction (clockwise deg north)

The comment lines (start with # ) are optional. Notice also that there are lines that start with * day. These are called day demarcation lines and they are also optional (the clm module will ask you if there are day demarcation lines included in your le). The rst line of the le should be *CLIMATE and the next non-comment line is interpreted as the site name (up to 40 characters are used). The site name line is followed by a site-data line. Included on the line

second token is the latitude (positive

92

degrees is Northern hemisphere and negative degrees is Southern hemisphere), the third token is the degrees from the climate data site to the nearest time meridian and the last item is a zero if the solar data was measured as direct normal solar and the value 123 if the solar data was measured as global horizontal. The line after site-data is assumed to contain two numbers which dene the period of the climate le. Normally climate data begins on the 1st of January and ends on the 31st of December. If your import le is for a shorter period then the other hours of the year will have zero data. Notice that data are all integers and they are comma separated. You can use a space to separate data if that is more convenient. The column order must follow the pattern shown above. The integer values for diffuse solar, direct solar, wind direction and relative humidity are converted directly into the nearest Watt, degree or percentage. Take care with the dry bulb temperature and wind speed. -18 becomes -1.8 degrees and 8 becomes 0.8 m/s.

93

Chapter 7

ZONE CONTROLS

7 Zone controls

7.1 Introduction As stated at the beginning of The Cookbook, the use of simulation can test the beliefs of the design team. The design of environmental controls is particularly rich in beliefs. For example: Some Architects and Engineers operate on the assumption that buildings constantly require mechanical intervention. Is this assumption true? Many design methods focus on extreme conditions and ignore what happens at other times. What is the cost of this? Some design methods assume that changes dictated by value engineering have little or no impact on systems and control response or running costs or comfort. Is this a low-risk assumption? The Cookbook approach limits the cost of design by ensuring that such questions are dealt with as early as possible. It also provides opportunities to notice patterns that lead to breakthroughs.

Understand options for controlling a building by observing how it works without mechanical intervention. Focus on demand side management exploring architectural options and alternative operational regimes. Focus on transition seasons and environmental controls that can efciently cope with part-loads and intermittent demands. Discover patterns that stress the building and explore how interventions that mitigate the extremes can be integrated with the results of the prior steps in the methodology. Re-check demand-side management options and iterate as required.

7.2.1 Abstract representations In ESP-r, environmental control systems can be represented as either idealized zone controls or as a network of system components (often called a plant system within the interface). The choice of which approach to take is dependent on the stage of the design process, how much detail is needed to assess performance and how much information is available. There is also the issue of time. Control based on system components tends to take longer to 95

setup and can be more difcult to calibrate. The rst step in understanding how ESP-r deals with idealized zone controls is to decode the jargon. The interface does not present you with a list of entities such as perimeter trench oor heating. What you see are choices relating to: what is sensed e.g. temperature, humidity, radiation, ux where is the sensor e.g. zone air node, within a construction, within a component what control logic is applied to the sensor signal at different times of the day what action is taken e.g. ux injection or extraction, where is the point of interaction e.g. zone air node, within a construction, within a system component

Sensor (location)

Actuator (location)

Control Law (schedule)

Figure 7.1 sensor - law - actuator. Together these form a control loop. Zone control loops in ESP-r are abstract. Control engineers would view the approach as idealized because there are no time lags in the control system although there may be lags in response due to heat storage etc. 96

heat injections and extraction are based on user supplied capacity ranges rather than performance curves and fuel ow rates. there are no attributes such as the spacing of ns in a fan coil unit, rather you dene the location and the radiative and convective split associated with the actuator. performance is in terms of ux added or extracted at the point of actuation. Parasitic electrical use and part load efciency is a postprocessing task. There are basic controllers which can be used to identify demand patterns. Other controls represent real-world scenarios such as equipment with minimal cycle times or multiple stages of capacity. Typically a number of zone control loops are specied for the building, each one having a unique index. These loops are then linked to one or more building zones. Zone control loops can exhibit near-real-time response. With a one minute time-step, the response of a PID controller to a step change in demand may demonstrate many of the artefacts which would be observed in a real control device. A controller which is critically undersized can provide useful clues as to whether the building is capable of absorbing brief extremes in boundary conditions or building use patterns. In buildings where air movement is important models may require a mix of zone controls and air ow controls. This is especially true in buildings with hybrid ventilation systems.

ESP-rs abstract approach was initially designed for exibility and the ability to represent the performance characteristics of a number of environmental control systems at an early stage of the design process. In a European context, where there are few standard approaches to environmental controls, such exibility was pragmatic. If one were to look at the code of simulation tools which do not use discrete components to represent environmental controls, one would see that their system template descriptions are being translated into instructions which are roughly equivalent to the control loops of sensors, control logic and actuators used in the ESP-rs zone controls. You are asked to manually dene what other tools infer from high level descriptions. So what is this process like and how does it compare with a component based approach (see Chapter 13)? 7.2.2 Abstract example Imagine that you wanted to test the idea of a oor heating system which was capable of injecting 40W/m2 into the middle of the top layer of the oor slab during ofce hours and which sensed the air temperature of the room as in Figure 7.2. Your other option might be to use radiators in the room. Although the boiler and thermostat might be the same, the two choices required different components and different controls. We could either dene networks of components for the two designs or we could represent their general characteristics via sensor - law 97

- actuator denitions. The component based approach is complicated by the dozens of possible combinations of boiler, pump and heating circuit layout and is burdened by the need to attribute each of the components. At an early design stage such details are a distraction from what is essentially a high level decision. An abstract approach allows us to delay our investment in detail. It also allows us more time to understand the patterns of demand and thus make more informed decisions during the detailed design stage.

zone_node window

Sensor (location)

Actuator (location)

Control Law (schedule)

Figure 7.2 representing an abstract oor heating system. The data required by a control loop is as in Figure 7.3. In the case of oor heating the sensor location is at the air node of the zone, the schedule is a freeoat at the start and end of the day with

a ramp-up period in the morning prior to the occupied period. The control law during the occupied period could be a basic controller with 4kW of heating capacity and a set-point of 20C. The actuator is in a specic layer of the oor surface of the zone. During the simulation 4kW will be injected until the room air temperature reaches 20C and then a reduced ux will be injected to maintain the set-point. Although it is abstract, it has many of the characteristics of a oor heating system. Both the time lag and the altered radiant environment of the room are part of the simulation. If the response is not optimal then altering the control attributes allows design variants to be checked. For example, if the response is slow, the position in the slab of the heat injection could be raised by re-dening the location of the actuator. Once the required characteristics of the oor heating system have been assessed then these can be used in the detailed design stage if the resources and goals of the project warrant it. The down side of this abstract approach is that some performance criteria are not available and some aspects of the thermophysical response are simplied. For example the time taken by a real system to alter the temperature of the working uid is absent. The minimum time-step for a zone control is one minute so systems that respond in the order of seconds are not well represented. There are some control regimes which cannot be represented e.g. a chilled ceiling would be controlled both for the room temperature 98

but limited so as not to cause condensation. Some control combinations found in BEMS are difcult, if not impossible to represent.
Sensor (deg C @ air point) Actuator (heat injection @ floor)

Control Law Algorithm/logic

Control data Capacity, set points

Timing data periods, start times

Figure 7.3 data requirements.

Delaying details until after we see the pattern of demand and interaction with an abstract environmental control can help us make informed choices of system type and components. Conventional approaches force us to be specic before we have reached an understanding of supply and demand patterns. Testing via abstract representations increases the chance that environmental controls and buildings are better matched. Readers who are working with other simulation environments may also have options in how they approach environmental controls. There are almost always options to delay detail.

7.3 Zone control laws The following is a summary of the most often used control laws. basic control is an ideal controller which will exactly maintain a setpoint if it has sufcient capacity. This is often used to identify demand patterns. The attributes are: maximum and minimum heating capacity, maximum and minimum cooling capacity, heating and cooling set-point. Humidity control is optional and is achieved via moisture injection or dehumidication at a maximum g/s rate. There is an option to relax temperature control in order to maintain humidity control. free oat disables control for the period. There are no attributes for this controller. xed injection or extract implements a control with a xed heating or cooling rate if the logic requests an ON state. Many heating and cooling devices are not able to adjust their operation and respond to transient conditions with an ON/OFF control action. This controller is sensitive to the simulation time-step (which should be modied to represent the response of the device). The attributes of this control are heating injection, heating set-point, cooling extraction and cooling set-point. basic proportional control is an proportional controller which works within in a throttling range and optionally implements PI control with an integral action time or a PD control (dangerous) with a derivative action time or a full PID 99

specication. This control can be as unstable as a badly tuned real controller. The attributes are: maximum and minimum heating capacity, setpoint and throttling range, maximum and minimum cooling capacity, cooling set-point and throttling range. Integral and derivative times are optional. linkage with plant component is a zone controller that is used in conjunction with a plant component network to identify interactions between the plant network and zones. The attributes of this control are the component in the network and the node of the component and the type of coupling. If the air stream of the system components interacts with a zone then the source component and down-stream components are identied. multi-stage with hysteresis implements a staged controller in which additional capacity is brought online if the set point is not reached. There are three stages for heating and three stages for cooling. The attributes include a heating and cooling set-point as well as a delta temperature for heating and cooling capacity changes. separate ON/OFF ux is a controller which implements a heating-onbelow and heating-off-above logic as well as a cooling-on-above and cooling-off-below strategy. This approximates a classic thermostat response pattern. The attributes are heating and cooling capacity as well as two set-points for heating and two setpoints for cooling.

 temperature match (ideal) implements a controller which will attempt to match the evolving temperature at another location or a weighted temperature at several locations. This is useful in validation or calibration studies where recorded boundary conditions need to be matched. To represent a well ventilated roof space, a control can heat or cool the roof space to match the current ambient temperature. Another example is to force an abstract boundary zone for a ceiling void to match the current temperature of a fully dened ceiling void found elsewhere in a model. The attributes are a maximum and minimum heating and cooling capacity, the number of sensors to pay attention to and their locations. temperature match (ON/OFF) implements a controller which will attempt to match a temperature at another location via an ON/OFF control action. Attributes are similar to the above control. optimal start implements an optimal start heating controller which attempts to reach a desired temperature at a specied time. This controller works by trying one scenario and if it fails it re-winds the simulation to the start of the day and then attempts a different scenario. It can be operated with a 4h00 start or a user dened start or a start time tested by iteration. The attributes are heating capacity and set-point, the desired time of arrival, minimal time difference and temperature difference for testing. 100

multi-sensor controller is designed to implement a control in one location based on actions taken in another location. An example of this is to represent a HVAC system as a mixing box which is controlled between a range of temperatures in order to control conditions in another zone linked to it via an air ow network. Another use of this control is to abstractly represent a oor heating system as a geometrically thin thermal zone into which heat is injected in order to control the temperature of an occupied space. The attributes of this controller are minimum and maximum heating and cooling capacity, heating set-point, cooling set-point and number of auxiliary sensors and their locations. slave capacity controller implements a common residential control strategy where a thermostat in one part of a residence controls the operation of HVAC in other rooms. Typically such controls, if not carefully balanced, will result in poor control in some of the slave zones. Several control loops are required to implement a master-slave control in a building. One control loop represents the master control and there is one slave control loop for each of the slave zones. The attributes of the controller are the index of the control loop that represents the master controller and the slave heating capacity and slave cooling capacity. variable supply temperature implements a controller for a constant volume air supply rate which adjusts

the supply temperature to maintain a room set-point. This controller is abstract (it is not part of an explicit air ow network). Details of the performance are available if the simulation trace option is invoked. The attributes are maximum supply temperature, minimum supply temperature, air ow rate, room heating setpoint, room cooling set-point. VAV with CAV heating implements a controller which uses VAV for cooling and CAV for heating. This controller is abstract (it is not part of an explicit air ow network). The controller assumes a constant supply temperature and uses a terminal reheat. It is intended for early design stage studies of VAV characteristics. Details of performance are available via simulation trace functions. The attributes are reheat capacity, air supply temperature, room set-point, maximum air ow rate, minimum air ow rate. 7.4 Exploring building control issues The ESP-r distribution includes exemplar models which implement various zone control regimes. Example models are a good starting point for exploring the use of zone controls as well as understanding interactions between buildings and environmental controls. After selecting an exemplar and studying the documentation, run assessments at different times of the year to characterize the temporal response of the building and controls. Remember, an exemplar model contains one expression of the attributes of 101

a control loop. Attributes can be adjusted to better approximate the characteristics of environmental controls. Sometimes performance is best understood by altering the control description and looking at how predicted performance evolves.

Explore controls with simple models before implementing them in full scale models or using them in consulting or research projects. Spend time with the results analysis module. Look at a range of performance metrics and forms of reporting. Those who have experience will be looking for conrmation of expectations, whether it needs calibration or is unsuitable. Working practices in simulation groups should ensure that each likely control is tested and notes on their use is recorded so that it can be available for review during the planning stage. 7.4.1 Basic (ideal) control Lets have a look at the zone control facilities by exploring an example model which uses a combination of free-oat and basic controllers. The model conguration le is cellular_bc/cfg/cellular_bc.cfg and in the list of exemplar models it is in the technical features menu as the rst item.

coridor

manager_a

manager_b

Project: base case model of two adjacent cellular offices

Figure 7.4 Basic mechanical ventilation system. The intent of this environmental control is to heat each of the rooms to 19C during ofce hours and 15C at other times of weekdays. On Saturday the timing is different and after 17h00 the temperature is allowed to free-oat. On Sundays there is only a frost protection heating to maintain 10C and an overheat control which cools the room if the temperature goes over 30C. There is 2500W of sensible heating capacity and 2500W of sensible cooling capacity and no humidity control. The control loop that implements this specication has a number of attributes. These are held in a le in the model and both the interface and the model contents report uses a standard reporting convention to describe control loops (see next report fragment):

102

The model includes ideal controls as follows: Control description: Ideal control for dual office model. Weekdays normal office hours, Saturday reduced occupied hours, Sunday stand-by only. One person per office, 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 zone The function day types are Weekdays, Saturdays & Sundays Weekday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heating set-point 15.00C cooling set-point 26.00C. 2 6.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heating set-point 19.00C cooling set-point 24.00C. 3 18.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heating set-point 15.00C cooling set-point 26.00C. Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heating set-point 15.00C cooling set-point 26.00C. 2 9.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heating set-point 19.00C cooling set-point 24.00C. 3 17.00 db temp > flux free floating Sunday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min heating capacity 0.0W. Heating set-point 10.00C cooling set-point 30.00C. Zone zone zone zone to control loop linkages: ( 1) manager_a << control ( 2) manager_b << control ( 3) coridor << control 1 1 1

The contents report parses the data associated with each control loop and expresses this as a short statement. Some abbreviation is needed because the length of each statement is constrained. The use of abbreviations also happens in the interface - there is not 103

enough room to display many words so the menu presents numbers and echoes the longer phrases in the text feedback area. Each control loop is divided into sections that describe the sensor and actuator as well as data for each period in each day type. What you might notice

is that there is repetition of the capacity information at each period. The data structure allows all attributes to change at each period although most models only alter set-points. Notice that on Saturday, the last period of the day uses a different control law to signal a change from controlled to free oating conditions. The last item in the report is the linkages between the dened control loops and the zones of the model. In this case one control loop is dened and the pattern it represents is used in all of the zones of the model. Note that the description of the sensor and actuator in the above control loop uses the phrase in the current zone. The column in Figure 7.5 marked day type allows the user to implement different control actions based on the concept of day types. A hospital emergency room is a classic example of a single day type. Often it is convenient to treat weekends differently from weekdays and ESP-r offers this option. Day types can be used to dene, for example, a different control pattern for each day of the week, but doing this for a period longer than about ten days is impractical. Work is underway to link the concept of day types to the calendar of the model. A holiday day type could then be assigned to specic days of the calendar. To explore how this basic control appears in the interface go to
browse/edit/simulate -> controls -> zones and the interface

There are menu items for describing the included controls, linking specic controls to specic zones in the model and managing the controls (add/delete etc.), checking controls and saving the control denition to le. As with other facilities in ESP-r, documentation is an integral part of the model. Working practices should enforce documentation to set the context of the many arrays of numbers that make up control loop denitions.

Figure 7.5 Top level zone control menu. There is a centre section of the menu which allows access to the specics of the each control loop. On rst glance it is difcult to make sense of the numbers and abbreviations. The three numbers under the sensor location column and the actuator location columns dene the specic location based on user selections. Selecting the control law brings up the choice of
sensor details, actuator details, period of validity and period data.

will look like Figure 7.5 104

Each control loop has one dened location for its sensor (although some control laws will supplement this denition) and one location for the actuator. There are a number of choices for a zone control loop sensor (shown in Figure 7.6). Once you select the choice and answer some supplemental questions the three indices are generated.

will require separate control loops with specic location information for sensors and actuators. And you can also dene control loops which are not linked to any zone in the model, but which are available as alternatives to link to at a future point in time. The references temporal file item allows you to associate a sensor with time-step based data. There are fewer choices for the actuator of an ideal control. Unlike other domains which might control two phase ow or a damper position, a zone control either adds or removes ux from a node within the simulation solution matrix as shown in Figure 7.7.

Figure 7.6 Sensor choices. There are two choices senses current zone db temp and senses temp in a specific zone which need clarication. Some controls are generic and could be referenced by many zones in which case the former choice is used. If you have a control that senses conditions at a specic surface then the latter is needed. There are some control laws that also require that a specic zone be identied for the sensor and actuator location. Some models will be able to use generic control loops and other models 105

Figure 7.7 Actuator choices. Periods (Figure 7.8 and 7.9) are dened by their start time and the control law to use during the period. Control logic is used until there is a subsequent period statement or until the end of the day (which ever comes rst). Some control laws have few attributes and other have upwards of twenty attributes.

Figure 7.8 Control periods. 7.4.2 Interpreting control predictions The winter performance of this model should indicate rooms are controlled during ofce hours and a set-back temperature is maintained overnight with a free oat from late Saturday till early Monday. Most of these expectations are conrmed in the performance data included in Figure 7.10. Note that the set-point in the two ofces is maintained or slightly exceeded on most days and the night time temperature drifts down to the setback. The corridor is warmer than the heating set-point and even reaches the cooling set-point for a few hours. There are two deviations in the control which need to be explained. Why is Wednesday sufciently warm in the room to reach the cooling set-point and should the free-oat condition on Sunday coincide with the warmest predicted temperatures in addition to the expected coldest temperatures? 106

Figure 7.9 Control period details.

Figure 7.10 Winter performance predictions.

Figure 7.11 Winter performance predictions.

107

Figure 7.12 Winter heating and cooling peak statistics.

Figure 7.13 Winter heating and cooling energy delivered.

heat/cool/humidify report

Strategies for what-else-do-I-look-at are covered in Chapter 10. Essentially, we are looking for something that is happening at the same time that might cause the thermophysical state that we are trying to explain. Those with experience will have opinions as to the usual suspects. In the case of this model, the lightweight construction and the large area of glazing would suggest that one of the usual suspects for overheating is solar radiation. The graph in Figure 7.11 shows that there is a peak solar occurrence that coincides with Wednesday and Sunday. One might conclude that these ofces are sensitive to solar gains. If we want to evaluate the capacity required in these rooms we can use the
Summary Statistics ->

which is reproduced in Figure 7.12. The information in this report should be used in conjunction with the graph in Figure 7.10 when considering the capacity needed. The statistics provide a value and a time of occurrence. As in most buildings the peak condition happens at different times in different rooms. The total is a diversied total which is based on the simultaneous peak rather than a summary of the individual peaks. The graph is important because the shape of the response of the environmental control allows us to better interpret the statistics as well as providing an early clue as to likely equipment choices or architectural interventions. The heating pattern is an early morning peak which rapidly decreases. The cooling demand is also a brief peak 108

which decreases over several hours. In this case there not a sustained demand for either heating or cooling. The graph indicates a classic pattern for which there are several classic solutions. The other report which may be of interest is the integrated energy demand which is found in the Enquire about -> energy delivered report (Figure 7.13). In this report the heating and cooling is expressed in kWhrs and the number of hours that heating and cooling were active. Those with experience will be looking for options to deal with intermittent system use. There are stand-by costs and start-up costs which may need to be considered. Where the average rate of delivery is considerably different than the peak then there are a number of classic solutions which experienced practitioners will want to begin to consider. If we turn our attention to a typical spring week we nd that in Figure 7.14, there are few hours that heating is required (briey on Wednesday morning and Friday morning) and, depending on the temperature outside, quite a few hours when cooling is required in all rooms. The graph in Figure 7.14 indicates that there are only brief requirements for heating and there is a short time between the demand for heating and the demand for cooling. This poses several issues for the design team. An experienced practitioner might consider several alternative scenarios for spring: 109

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 on the facade adding internal mass to the room to reduce the rapid change in temperature. The temperature pattern in the corridor is also instructive. The rise in temperature after the control period indicates that there is excess heat stored in the fabric of the corridor. On warm days (say above 15C) the subsequent day nds the corridor temperature just below the cooling set-point. It is likely that this pattern will also be found in the summer and thus cooling will be required from the start of business. Once a model exists the marginal cost of testing ideas tends to be low. It takes only moments to run focused simulations. It also only takes moments to use the results analysis module to generate and capture a sequence of graphs. Such patterns of performance can be valuable feedback to the design process. In the early chapters of the Cookbook the planning process included a review of climate patterns and if the selected periods are included in the model then it is easy to re-run assessments as the design and the model evolve. Experienced practitioners use such techniques to support interactive explorations.

Figure 7.14 Spring performance predictions.

Figure 7.15 Spring switch from heating to cooling.

110

7.5 Controls implementing boundary zones One of the strategies of the Cookbook is the use of focused models. Models which represent a portion of a building are predicated on robust boundary conditions. A classic case is an ofce building with a suspended ceiling which acts as a return plenum and which has gains from ducts and pipes and lighting ttings. Below the occupied level is likely to be another ceiling plenum. The temperature in the ceiling voids will tend to deviate from the air temperature of the occupied space. Thus the standard boundary condition of dynamic (similar) which is offered by ESP-r is less accurate than the boundary conditions provided by a fully described zone. Indeed, if the design question focused on whether a night purge of the ceiling void might provide useful structural cooling, the boundary condition above the suspended ceiling is critical. One technique to reduce the number of fully dened zones is to dene an abstract representation of the lower ceiling void as well as the upper occupied space as in Figure 7.16. If the occupied space and the ceiling void above it are well represented we can use a control law to force the lower ceiling void to follow the predicted temperature of the well represented ceiling void. We can dene another control which takes the mean temperature of the manager_a and manager_b rooms and conditions the 111

upper low-resolution occupied space to follow the predicted temperature of the dened occupied space. The approach is as follows: Create a basic (ideal) controller for the occupied space manager_a which is the same as that used in the previous example. Create a variant of the manager_a controller for manager_b which uses a smaller dead-band. Create a control law for floor_below which uses an ideal temperature match controller which pays attention to the current temperature in ceiling_above and forces floor_below to the same temperature. Create a control law for boundary_up which uses an ideal temperature match controller which pays attention to the current temperatures in manager_a and manager_b and forces boundary_up to the mean temperature. To demonstrate the temperature match, the temperature in boundary_up is show in Figure 7.17 as the mean of the current temperatures in manager_a and manager_b. The use of a mean temperature of several rooms for the boundary condition above the slab is one approach. If there are substantial differences in temperature expected it might be necessary to create multiple upper boundary zones. For those who are attempting to push the boundaries of simulation such exibility may be useful.

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 per office, 100W lighting and 150W small power. Tighter set-points for manager_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 ceiling zone (to act as a boundary). The boundary_up zone is controlled to the mean temperature 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 zone The function day types are Weekdays, Saturdays & Sundays Weekday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C. 2 6.00 db temp > flux basic control

112

basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 19.00C cool set-point 24.00C. 3 18.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C. Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C. 2 9.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 19.00C cool set-point 24.00C. 3 17.00 db temp > flux free floating Sunday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 10.00C cool set-point 30.00C. The sensor for function 2 senses dry bulb temperature in floor_below. The actuator for function 2 is the air point in floor_below. There have been 1 day types defined. Day type 1 is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods. Per|Start|Sensing |Actuating | Control law | Data 1 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 min heat cp 0.W Aux sensors 1. mean value @senses dry bulb T in ceiling_abv. scale 1.00 offset 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 | Data 1 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 min heat cp 0.W Aux sensors 2. mean value @senses dry bulb T in manager_a. & senses dry bulb T 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 zone The function day types are Weekdays, Saturdays & Sundays Weekday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 16.00C cool set-point 26.00C. 2 6.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 20.00C cool set-point 23.00C. 3 18.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 16.00C cool set-point 26.00C. Saturday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 15.00C cool set-point 26.00C. 2 9.00 db temp > flux basic control basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 19.00C cool set-point 24.00C. 3 17.00 db temp > flux free floating Sunday control is valid Sun-01-Jan to Sun-31-Dec, 1967 with 1 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control

113

basic control: max heating capacity 2500.0W min heating capacity 0.0W max cooling capacity 2500.0W min cooling capacity 0.0W. Heat set-point 10.00C cool set-point 30.00C. Zone zone zone zone zone zone zone to control loop linkages: ( 1) manager_a << control ( 2) manager_b << control ( 3) coridor << control ( 4) floor_below << control ( 5) ceiling_abv << control ( 6) boundary_up << control 1 4 1 2 0 3

Figure 7.17 Mean temperature in boundary_up zone. scaling of focused model predictions. And by delaying the requirement for specic details it may allow for a broader exploration of design ideas during the early design stages.

In summary, the exibility of zone control loops has both costs and advantages. There are currently no wizards to automate the process so some tasks are tedious. Care and attention to detail is needed to ensure that the control logic is working well under a variety of operating regimes. The advantage of a exible approach is that the facility can support the early exploration of novel design ideas. It may also reduce the complexity of other aspects of the model and support 114

Chapter 8

THERMOPHYSICAL RESOLUTION

8 Thermophysical resolution In ESP-r there are essential elements of the model description which must exist for the simulator to be invoked. These relate to the form and composition of the model, schedules of occupancy, lighting and small power and optionally environmental control systems. And the tag-line for ESP-r has long been: functionality follows description This chapter discuss optional facilities to alter the thermophysical resolution of a model so that, for example, radiation exchange is represented explicitly or convective heat transfer is evaluated by an alternative computational approach. There are many such choices available within simulation tools. They are typically invoked by including additional descriptive terms in the model and/or additional directives to the numerical engine. They are often treated as optional facilities because there are resource (computing and staff time) implications in invoking them. The user is confronted with the need to understand the functionality of such facilities. This chapter will provide an overview of optional facilities available within ESP-r. And, because this is The Cookbook, we are going to balance functionality with methods for deciding 116 when additional thermophysical resolution is required, techniques to determine the resources needed and then back to methods for taking advantage of the additional information. ESP-r, like other simulation tools is over-functional. It is also a general tool that can be coerced to carry out either something close to magic or end up lling up hard disks for little or no benet to the simulation team. Tool-driven practitioners push buttons because they exist. Readers of the Cookbook might be more inclined to be selective in their button pressing. 8.1 Shading and insolation One thermophysical extension to ESP-r is to replace the default assumption that solar radiation enters rooms and is diffusely distributed within the zone based on the area and absorption characteristics of the surfaces with a temporal distribution based on ray tracking computations. These are termed insolation calculations and are based on user directives (held in the zone geometry le) and carried out by the ish module. Another extension is to adjust the assessment of radiation falling on the building facade to take into account solar obstructions. Solar obstructions initially were constrained to rectangular bodies (dened as an origin,

rotation about the Z axis and length, width and height dimensions). This basic type has been extended to allow a second axis of rotation (i.e. a tilt directive) as well as allowing the coordinates of the eight corners of the initial box shape to be individually edited. The exemplar model
training/simple/cfg/bld_simple_shd.cfg includes a number of

solar obstruction types which together represent an adjacent building and a tree (Figure 8.1).

Figure 8.2: Shading & insolation directives. The middle section of the directives menu instructs calculations for shading and insolation to be done for all applicable surfaces in the zone. Applicable surfaces are surfaces which conrm to the standard rules - shading only on surfaces which face the outside and insolation sources must be transparent outside facing surfaces. There are several places in the interface where shading and insolation analysis may be requested. The rst is within the directives menu, the second is in the Zone
composition -> options -> shading & insolation.

Figure 8.1: Room with collection of solar obstructions. The interface for dening shading directives and solar obstructions is found in the zone geometry menu in
solar dist. & calc directives and solar obstruction.

Any zone which has surfaces which face the outside can include an insolation calculation and any zone which also has solar obstructions dened can include shading calculations. The directives menu is shown in Figure 8.2

Shading calculations are dependant on the zone composition as well as the model location and if either of these change you are offered the option of re-calculating shading. 117

Lets look at the solar obstructions which are included in Figure 8.1 via the solar obstructions menu (Figure 8.3)

the model is exported to a visual simulation tool such as Radiance. The lower portion of the menu supports management functions as well as providing direct access to the shading directives menu. The data which dene basic solar obstructions are available by selecting an obstruction. The data for blk_1 is shown in Figure 8.4.

Figure 8.3: Solar obstruction menu. The upper portion of the menu sets the gridding resolution for solar calculations. This defaults to a grid of 20 x 20 points placed on each surface in the facade. Some complex surfaces, e.g. a thin frame around a window, might require a ner grid in order for shading to be properly calculated. The centre portion of the menu includes a list of solar obstructions. Each has a short name for purposes of identication (they must be unique within the zone) as well as a composition. The composition name is used if 118

Figure 8.4: Simple obstruction detail menu. There are several options for editing the origin of the block as well as its size. It is also possible to apply one or two rotations to the block. The option to convert to general polygons allows you to further customize an existing obstruction block to represent more complex shapes.

An example of a complex shape is the block named tree which began as a simple shape and then the upper corners were edited (see Figure 8.5).

Figure 8.5: Tree shaped obstruction detail menu. 8.2 Shading predictions Once shading obstructions and shading directives are dened for a zone the computations can be undertaken. These are carried out by the ish module as shown in Figure 8.6. The primary selections are calculate shading and shading synopsis or shadow image for shading and the calculate insolation and insolation synopsis for insolation. If you toggle the sky type to non-isotropic the computational time increases quite a bit. Recent versions of ESP-r also support the calculation of diffuse 119

shading. If you request shading you are asked to conrm the period of the assessment (typically month one to month twelve). In the X11 interface you will see some feedback as the calculations progress but in the GTK interface the process is largely silent until it is complete (the screen does not seem to refresh as often with GTK). You can then ask for a shading synopsis (see Figure 8.7). After shading has been calculated the insolation analysis can be invoked (it needs to take account of the shading analysis data). The insolation calculations also grid the model surfaces and detect, for each source of insolation, the percentage of entering direct radiation that falls on each of the surfaces of the room. This information is recorded in the shading predictions le for use in simulations. You can ask for a synopsis of the insolation patterns (see Figure 8.8). The rst column is the time, the second column is the calculated shading, the third column includes the names of the surfaces that were insolated at that time and the fourth column provides the associated percentage of the radiation.

Figure 8.6: Shading module. And you can also conrm visually the patterns of shading by requesting a view from the sun at a specic time of day and day of the year (Figure 8.7). The screen capture below is for 10h00 on a typical day in January. What you see if what-the-sun-sees. What you cannot see is in shade. This type of view is also available from the Project Manager! Figure 8.7: Visual conrmation of shading.

120

Figure 8.8: Synopsis of shading. 8.3 Radiation view-factors Although many users are familiar with the idea of convective heat transfer between the air in a room and the surfaces surrounding the room, the longwave radiant transfer between surfaces tends to get much less attention. Some practitioners consider that radiant exchange is of minimal concern in well insulated buildings. Those who are working with buildings or systems where radiant transfer is considered important will nd the following discussion of interest. Firstly, radiant transfer between surfaces is part of every simulation assessment 121

carried out by ESP-r. It is part of the energy balance] of each surface at each time-step of the simulation. Many simulation tools treat long-wave radiant exchange explicitly but these features are largely hidden from the user. In ESP-r there are points for user interaction and options that allow detailed comfort assessments. The default assumption in ESP-r is that long-wave radiant exchange between surfaces in rooms is diffusely distributed based on the emissivity of the surfaces and their area. This assumption is appropriate for highly cluttered spaces or where comfort is not an assessment criteria. As rooms depart from simple rectangular shapes the diffuse distribution assumption becomes less valid. If radiant heating systems are employed the default assumption is inappropriate as would be the case if detailed thermal comfort is of interest. Sometimes we may simply want more information. For example, if there is explicit internal mass in the room or if sunlight falls on lightweight constructions then we might want to see if other surfaces are impacted. The functionality follows description approach used elsewhere in ESP-r applies to the computational resolution of radiant exchanges within rooms. If the default assumption is not appropriate for your model then you can request for an explicit calculation of how much each surface sees the other surfaces in the room (and manage these values thereafter). View-factor computations are currently carried out in a utility module which

uses ray-tracing calculations. The results of the calculations are recorded into a zone view-factor le (typically with the le ending vwf). During the simulation the current temperature of each zone surfaces is used with the calculated or area-weighted view-factors to evaluate the radiant transfer within the room. The computing resource required is roughly in line with the number of surfaces in the zone. An eight surface box will take a few seconds and a room at the current geometric limits then one or two minutes might be required. How might one know if these calculations are justied? One approach would be to create a virtual experiment using identical rooms with and without calculated view-factors and spend time considering the differences in the performance predictions which result. In projects where thermal comfort is of particular interest ESP-r provides facilities to dene block shaped radiant sensors within a room and to calculate how much that sensor views the other surfaces in the room. This information is used in the results analysis module to generate radiant asymmetry values. To demonstrate the surface view-factor calculations and the denition of radiant sensors lets look at a simulation model for a private room in a hospital. Two competing designs of radiant heating panels in room were under consideration. One design was claimed to be less costly to install (rectangular unit at the facade) and the other design was claimed to provide better comfort for the doctor and patient (radiant heat better distributed in the room and a lower 122

temperature required).

Figure 8.8: Radiant panel room model. The model (Figure 8.8) was designed as a classic side-by-side virtual experiment. The resolution of the model was dictated by the thermophysical characteristics of the entities within the rooms and possible interactions. The design was also dictated by the need to complete the model while the client was available to supply details and so the extent of the initial model was carefully considered. The critical performance metrics were the comfort for a tall doctor standing at the window and for the patient in the bed as well as the frequency the panels were on and how well they were able to control temperatures within the room on moderately cold days. In support of this two radiant sensors were dened in each room - one at the location of the patients head and the other a doctor standing near the window (Figure 8.9).

Figure 8.9: Locations of radiant sensors. In both rooms the bed was represented as internal mass, the radiant panels were represented via a thin-zone approach and the ceiling plenum above and below the rooms were represented as rooms. Diversity was included in the schedules for each zone and in particular the heat output of clinical lighting during the doctors visit was included. The adjacent wards were assumed to be at the same temperature as the rooms being investigated. The temperature of the upper ceiling void is critical because heat leakage from the panel was likely to result in a warmer void. This approach would allow changes in the thickness of upper insulation to be studied. The lower ceiling void was controlled to the same temperature as the upper ceiling void in order to form a representative boundary condition in the patients room.

Figure 8.10: Thin-zone radiant panel. The thin-zone approach (Figure 8.10) treats a heat generation device explicitly as a zone rather than a system component. Briey, a zone is created which represents the shape of the radiant panel and the lower surface is metal and the upper surface is an insulated metal panel. High heat transfer coefcients are set within the thin zone so that any heat injected into the air will be transferred to the surfaces. This approach was used because setting up system components would have required additional time and the potentially simpler injection into a ceiling construction could not be used because it was located between two zones (a rather irritating and persistent limitation). For purposes of this assessment the approach was seen to represent the expected panel temperatures and response time while the explicit shape of the panel surfaces worked well in the subsequent detailed comfort assessments. The left patient room includes an "L" shaped heating panel 400mm wide and 123

the right patient room uses a rectangular panel 600mm wide at the facade. The panels were controlled via a multisensor controller which regulated the room temperature to 21 C based on allowing the thin-zone to rise to 74 C. To reect the response time of the heating circuit the simulation time-step was set to one minute. After composing the model calibration assessments were run to tune the heat injection so that it matched the expected panel surface temperatures. Surface long-wave view-factors were computed for the patient rooms. It was not considered necessary to compute view-factors within the radiant panel zones (the high heat transfer at the surfaces would tend to limit temperature differences). The Project Manager interface after the computations were completed is shown in Figure 8.11 The primary selections for most users would be Calculate zone or MRT view-factors and if there were any radiant sensors then the Add a MRT sensor requests the origin and size of the sensor. Note that existing sensors are not drawn in the wireframe unless you actually select that item to edit. Once you have the sensors dened request the calculation and a utility module will be passed the relevant information and provide the options seen in Figure 8.12. The options you may be interested in are grid division and patch division which dene the density of the gridding which is used in the calculations. The default is 10 and with this default the computational time is constrained. If the zone has small surfaces 124

or surfaces with small dimensions the default may not be adequate. You will be notied if this is the case if some surfaces have a view-factors that sum to a value which is not close to 1.0. If this is the case you can re-set the grid and patch divisions and try again. Remember to request both calculations before you exit the utility application. When you return to the Project Manager you will be asked whether you want to use the newly computed values. Overall the model was up and running during the visit to the clients ofces and the predictions and ne tuning were carried out with feedback from the client. Assessments indicated that both designs resulted in substantially similar comfort levels for the doctor as well as the patient (see Figures 8.13 and 8.14). There was a slightly increased risk of radiant asymmetry discomfort for the case of the 600mm wide panel design. It was also clear, however that the 600mm wide panel was ON more often and tended to work at a higher temperature than the 400mm wide panel approach.

Figure 8.11: Prj interface to view-factors.

Figure 8.12: View-factor calculation interface. Another nding was that a 70-74 C working uid is often not required and room comfort can often be maintained at panel temperatures of 40-60 C. 125

Figure 8.13: Predicted temperatures in left zone.

Figure 8.14: Predicted temperatures in right zone.

126

Figure 8.15: Predicted dissatised in both zones. 8.4 Convective heat transfer regimes This section will be completed at a later date.

127

Chapter 9

PREPARATION FOR SIMULATION

9 Preparation for simulation In ESP-r the model description can include a number of directives about the nature of the numerical assessments to be carried out as well as where to store the performance predictions for each of the analysis domains. There are a number of reasons to embed such information in the model: decisions made in the planning stage can be recorded working practices are made explicit support for subsequent automation and production tasks to allow performance predictions to be re-generated at a later date information embedded in a model is safer than scraps of paper The idea of simulation directive sets came about because a highly competent user of ESP-r was asked by a client to re-run a historical project to extract some additional information. The archive of the model was found and the notes about the project were scanned and the simulation was re-run but the predictions had changed. A straightforward task became complicated and frustrating. What had changed? Where did the fault lie? Had the model become corrupted? Had the numerical engine changed in a way that would cause different 129 predictions? Eventually the causal factor was found to be the number of presimulation days that were used. That particular value had not been recorded in the project notes. And thus it became clear that the description of the model would be much more robust if it included a description of the specic assumptions and directives used by the simulation engine. This simplies the task of carrying out production runs and reduces the chances of errors. It also supports the idea of implementing the plan. If, at the planning stage, the team decide that specic weeks will be a good test of building performance the facility makes it very easy to implement the test. In the Project Manager these preferences are managed in the
Browse/Edit/Simulate -> Actions -> Simulate -> simulation presets menu. The current

values for the active simulation preset are included in the upper portion of the Simulation Controller menu (Figure 9.1).

Figure 9.1: Simulation parameter sets. Menu options include: set name - identifying tag for the simulation e.g. winter, june or monsoon start-up days - pre-simulation period used to condition the model from its initial state. The initial value is based on a scan of the model composition. Users can increase it to improve model stability during the initial hours of an assessment or reduce it to improve run-times. zone time-steps/h - the solution frequency and how often data are recorded (see discussion below). plant time-step/(bldg ts) - the system component solution frequency as a multiplier of the zone time-step. This should reect the nature of the 130

components and the control applied to them (see discussion below). result save level - denes how much information is recorded (see discussion in section 9.2). period of simulation - start and end date of the simulation (one day to whole year) zone results - the le name to hold zone performance data ow results - the le name to hold mass ow performance data plant results - the le name to hold system component performance data moisture results - the le name to hold the moisture states electrical results - the le name to hold power performance data Simulation time-steps dictate the frequency of the numerical solution and in ESP-r this can range from one minute to one hour. Clearly your choices will have an impact on the time it takes to run the simulation, the size of the performance data les that are generated during the simulation as well as the speed with which performance data can be extracted (and its temporal detail). The frequency should also reect the nature of the building composition and the control applied within zones as well as the types of system components used and the control applied to them. If, for example, you use an ON/OFF controller which has a response time of around a minute then a 15 minute timestep is going to result in a VERY STICKY CONTROL. If you have an air ow network with large openings between rooms you would expect that

the ow between the rooms will tend to moderate the temperature differences between the two zones. A simulation with a 30 minute time-step can result in un-natural differences in temperatures between adjacent rooms which are then resolved via the ow solution as a brief typhoon. It may be necessary to run assessments a different frequencies to nd out an appropriate compromise. File names for the result les are included in the simulation parameter sets so that each run generates known le names. This reduces confusion and is helpful for automation of simulation work. For example it is possible to issue a command in the form: bps
-file hospital.cfg -p monsoon silent which will run the hospital

model using the simulation parameters associated with the concept monsoon and create the specic results les and it will to this silently. A group in Denmark once commented we have two kinds of winter weather patterns that we always check - the cloudy windy (but not so cold) storm and the very cold but sunny. For these observant users there is no single worst day and not even a single worst week and they want to embed this knowledge into their working practices and into their models so that it is really easy to ensure these checks are made. 9.1 Integrated performance views Observant design teams also tend to have a checklist of performance indicators that they want to be continually reminded of as they evolve their 131

designs so that the un-intended consequences of their latest brilliant ideas are exposed. Others would describe this as multi-criteria assessments and this is supported in ESP-r via a facility known as the Integrated Performance View (IPV). IPV directives describe what we want to measure and where we want to measure it and what assessment periods are required. Directives are held in the model conguration le. These directives are similar to the meters implemented in other tools. The difference is in the information content and format of the requested data. Each request for a performance data type (e.g. zone resultant temperature, solar entering the zone in Figure 9.2) results in a statistical report, tabular data and a summary (because different users recognize patterns in different forms).

Figure 9.2: IPV performance metrics set interface. The following performance metrics can be included in IPV directives: zone resultant temperature zone dry bulb temperature zone relative humidity zone inltration load

 zone ventilation (from other zones) load zone casual gains (all) zone solar radiation entering from outside zone solar radiation absorbed in room This list might be extended to include other data types selectable within the results analysis module. There is a separate selection process for requesting information on environmental systems demands (Figure 9.3). The facility allows you to identify sets of zones which you want to associate with a concept - for example south_ofces might include 15 separate zones for which one aggregate report is requested.

Figure 9.3: IPV demands set interface. It is also possible to specify a multiplier for environmental systems demands. For example, a specic perimeter ofce in your model might be representative of a dozen ofces and a scale of 12 could be applied to the performance of the specic ofce when deriving the overall performance of the building. This is a particularly useful feature of an IPV. 132

After the performance metric sets and environmental demand sets have been dened the task turns to the nature of the assessments to be run. An IPV has the concept of the following kinds of assessments: single annual (or use dened) assessment three assessments (winter, transition, summer) which can be a typical week in each season or all days in each season ve assessments (winter starting 1 Jan, spring, summer, autumn, winter ending 31 Dec) which can be a typical week in each season or all days in each season The IPV denition also supports the idea of scaling performance predictions. If you selected a typical week then you have the option to undertake the same kind of search-for-best-tweeks as is done in the ESP-r climate module. Once the best-t-weeks have been determined you have the option to use the HDD/CDD/solar ratios (as in the climate module) to determine an initial scaling for heating and cooling. The values for lights are scaled by the ratio of days in the short simulation to that of the whole season (Figure 9.4).

Figure 9.4: IPV interface with ve typical assessments. Once the IPV directives have been dened the information is saved to the model conguration le and the denition of simulation parameter sets are updated to match that of the IPV directives. You may then use the Integrated Performance View directive in the Simulation menu to automatically run the required assessments and, optionally to extract the requested performance metrics (and their statistics and tabular and summary subreports) to a so-called IPV report. These simulations will also generate the standard results les which can be interrogated interactively for 133

information not available with the IPV report itself. Many users make use of the framework of the IPV to automate the production of simulation runs. It is also useful for large models where a single simulation would generate a results le greater than one gigabyte (which tends to be the limit for robust results sets). If you ask to extract data then the results analysis module will be invoked with a command line that directs it to extract the requested data. If there are multiple assessments then the reports will be conated and an overall summary will be produced. The overall summary takes the data from each season and the seasonal scaling factors included in the IPV denition in order to arrive at annual performance. If your project involves energy demands that are not directly derived from the zone descriptions such as lifts and domestic hot water the IPV will scan a so-called demands le (also found in the model context menu and include it in the IPV report. A sample of an IPV report for the collection of zones named ofces is included in Figure 9.5. Diversied capacity is the instantaneous peak while the distributed capacity is the peak in each zone added together. And the integrated demand does what it says on the tin.

. . . *assessment, 1,cellular_shd 1st winter run *report,70,diversified,capacity,offices *title,Diversified capacity,W *format,table,1,7 *fields,Heating Cooling Lighting (unctld) Lighting (ctld) Fans Small Power Hot water *data,1034.4,767.8,0.0,0.0,0.0,0.0,0.0 *end_report *report,70,diffuse,capacity,offices *title,Diffuse capacity,W *format,table,1,7 *fields,Heating Cooling Lighting (unctld) Lighting (ctld) Fans Small Power Hot water *data,1034.4,767.8,0.0,0.0,0.0,0.0,0.0 *end_report . . . *report,70,demand,integrated,offices *title,Integrated demand,kWhr *format,table,1,7 *fields,Heating Cooling Lighting (unctld) Lighting (ctld) Fans Small Power Hot water *data,32.99,4.65,0.00,0.00,0.00,0.00,0.00 *end_report . . .

cumulative_distrib cumulative_percent *data 0,<12.0,0,0.0,0.0,0.0 1,12.0-14.0,0,0.00,0,0.00 2,14.0-16.0,4,1.96,4,1.96 3,16.0-18.0,19,9.31,23,11.27 4,18.0-20.0,91,44.61,114,55.88 5,20.0-22.0,43,21.08,157,76.96 6,22.0-24.0,27,13.24,184,90.20 7,24.0-26.0,20,9.80,204,100.00 8,26.0-28.0,0,0.00,204,100.00 9,28.0-30.0,0,0.00,204,100.00 10,30.0-32.0,0,0.00,204,100.00 11,>32.0,0,0.0,0.0,0.0 *end_report *report, 6,stats,comfort,ocup_zones *title,Resultant temperature,degC *format,table,1,3 *fields,maximum,minimum,average *data,25.727,14.552,20.266 *end_report

Figure 9.6: IPV comfort reports Another metric that was requested was the inltration into the set of zones named inl_zones (see Figure 9.7). This is typical of the data included for such metrics.
*report,11,stats,Infil,infil_zones *title,Infiltration load,W *format,table,1,7 *fields,maximum,minimum,average diversified_max,distributed_max diversified_min,distributed_min *data,-62.752,-88.499,-40.327,0.000,-62.752, -176.673,-178.132 *end_report

Figure 9.5: IPV data processed for display There are comfort reports embedded in the output as well. The data in Figure 9.6 is for a collection of rooms called ocup_zones. The format of the frequency report is not particularly human readable - it contains the same information as is found in the results analysis frequency bin reports.
*report, 6,distribution,comfort,ocup_zones *title,Resultant temperature,degC *format,frequency,12,5,12.0,2.0,30.0 *fields,range distribution percent

Figure 9.7: IPV report on inltration Another format of report is a time-step listing for a typical day in the season. Figure 9.8 is such a listing for the heating demand for the collection of zones named ofces. The rst column is the julian day of the year and the fraction of the day (12h00 equals 0.5). This could be cut and pasted into a spreadsheet for display.
*report,70,demand,per_unit_time,offices

134

*title,Energy Demand per Unit Time,W *format,tabular,24,7 *fields,Time Heating,Cooling,Lighting Fans,Small Power,Hot water *data 38.0208,76.0,0.0,0.0,0.0,0.0,0.0 38.0625,365.7,0.0,0.0,0.0,0.0,0.0 38.1042,342.8,0.0,0.0,0.0,0.0,0.0 38.1458,299.6,0.0,0.0,0.0,0.0,0.0 38.1875,286.3,0.0,0.0,0.0,0.0,0.0 38.2292,413.2,0.0,0.0,0.0,0.0,0.0 38.2708,973.8,0.0,0.0,0.0,0.0,0.0 38.3125,862.6,0.0,0.0,0.0,0.0,0.0 38.3542,649.2,0.0,0.0,0.0,0.0,0.0 38.3958,521.5,0.0,0.0,0.0,0.0,0.0 38.4375,396.9,0.0,0.0,0.0,0.0,0.0 38.4792,298.6,0.0,0.0,0.0,0.0,0.0 38.5208,249.4,0.0,0.0,0.0,0.0,0.0 38.5625,220.1,0.0,0.0,0.0,0.0,0.0 38.6042,177.9,0.0,0.0,0.0,0.0,0.0 38.6458,169.2,0.0,0.0,0.0,0.0,0.0 38.6875,246.6,0.0,0.0,0.0,0.0,0.0 38.7292,331.7,0.0,0.0,0.0,0.0,0.0 38.7708,36.9,0.0,0.0,0.0,0.0,0.0 38.8125,2.9,0.0,0.0,0.0,0.0,0.0 38.8542,54.8,0.0,0.0,0.0,0.0,0.0 38.8958,137.8,0.0,0.0,0.0,0.0,0.0 38.9375,196.7,0.0,0.0,0.0,0.0,0.0 38.9792,231.8,0.0,0.0,0.0,0.0,0.0 *end_report

*format,table,1,6 *fields,Heating,Cooling,Lighting, Fans,Small Power,Hot water *data,32.718,37.636,2.379,0.000,0.000,0.000 *end_report *report,74,power,capacity,aggregate *title,Maximum building capacity,kW *format,table,1,6 *fields,Heating,Cooling,Lighting, Fans,Small Power,Hot water *data,1.16,1.33,0.08,0.00,0.00,0.00 *end_report

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

Figure 9.8: IPV timestep report At the end of the IPV report is a summary of performance which has been seasonally-scaled and zone-scaled and which include non-zone demands. This kind of report (see Figure 9.9) is only available within the IPV.
*Summary *report,98,energy,performance,aggregate *title,Integrated demand,kWh/m2.a *format,table,1,6 *fields,Heating,Cooling,Lighting, Fans,Small Power,Hot water *data,20.796,26.027,10.385,0.000,0.000,0.000 *end_report

Figure 9.9: IPV report on inltration Note that the raw data is expected will be interpreted for display via a third party application (see Figure 9.10). Users should keep in mind that the IPV has similar risks to any prior-specication scheme. If it does not include a relevant range of topics for the current project it will fail as technique for enforcing multi-criteria assessments. Many of the exemplar models that come with the ESP-r distribution include IPV descriptions. Use them to explore the facility!

*report,98,energy,building_performance,aggregate *title,Integrated building demand,kWh/a *format,table,1,6 *fields,Heating,Cooling,Lighting, Fans,Small Power,Hot water *data,736.2,921.4,367.6,0.0,0.0,0.0 *end_report *report,74,power,capacity,aggregate *title,Maximum capacity,W/m2

135

Figure 9.10: IPV data processed for display simulations are invoked with directives that involve the creation of the bespoke results database les for each solution 9.2 Results libraries and reports domain (zone ux, mass ows, electriESP-r differs from other simulation cal power ow, detailed system compotools in how it records performance nents, computational uid dynamics). data and subsequently supports access For these users, the ESP-r results analto that data. The simulator includes ysis module is their gateway to underoptions for recording performance metstanding the thermophysical state of rics as comma separated timestep data the model. in text les, as XML reports, as sumEach save level species a pre-dened mary reports or as elds within set of performance data to be written. bespoke results database les. The following is a synopsis for each: One of your choices prior to invoking a Save level 0 - a text report is generated simulation in the project manager or by the simulator if the user requests it within the simulator is to set the soafter the assessment has been run. A called save level. For many users, 136

sample of this report (for one of the exemplar models and an annual simulation) is shown in Figure 9.11. Save level 1 - zone heating/cooling, zone control point temperature, zone dry bulb temperature into bespoke binary le. This is the smallest bespoke binary le and has minimal overhead when generated but is rarely used because of its limited contents. Save level 2 - zone heating/cooling, the zone dry bulb temperature, zone control point temperature, surface inside face temperatures, inltration, ventilation, surface convective heat transfer at inside faces, casual gains (radiant, convective, latent), solar entering room, solar absorbed in zone, solar absorbed at inside face and outside face of each surface, relative humidity, latent load, linear thermal bridge ux. This le has somewhat higher overhead while it is being written and also results in a somewhat larger bespoke binary le. This save level is useful for general investigations that do not require nodal temperatures or energy balance reports. Save level 3 - in addition to save level 2 data elds this save level includes additional records which hold the temperatures at each node of each surface in the model. This is useful for ploting temperature proles within constructions. Save level 4 - in addition to save level 2 data elds this save level includes additional records which hold the ux paths which represent the zone energy balance as well as surface energy balances. This is the default save level and although it generates a larger le it 137

provides the most exibility for ad-hoc investigations. Save level 5 - used by the Hot3000 home rating interface from Natural Resources Canada (HK) as well as in the formal testing procedures used by the ESP-r development community. An example of the H3K le is shown in Figure 9.12. It is clearly a variant of the save level zero le with additional data elds. The specic contents of the XML le which is generated are determined by a input.xml le which is assumed to be located in the model conguration le folder. Possible patterns in the input.xml le are discussed in section 9.3. Save level 6 - this is a relatively compact XML report which includes monthly data summaries. It is used by several third party tools to access predictions from ESP-r. It is also used when ESP-r is being used to run UK National Calculation Method assessments for code compliance purposes. Portions of a save level six le are shown in Figure 9.13. The rst token in each line is the model conguration le name, the second token is either the zone name or a key word (e.g. Total_DHW), the tokens such as MH1 stand for monthly heating january, MC2 would be monthly cooling february. Key words such as z_DHW_Month_1_MJ and z_DHW_Month_1_kWh are zone monthly kWh or MJ for a specic topic.

Performance assessment report Results library cellular_bc_save0.txt Climate file /Users/jon/esru_jwhn/esp-r/climate/clm67 Configuration file cellular_bc0.cfg Configuration descr base case model of two adjacent cellular offices Period Sun-01-Jan to Sun-31-Dec Year 1967 Zone manager_a manager_b coridor Zone manager_a manager_b coridor All zones: Max_Temp Min_Temp Max_Heat Max_Cool max air T (occurrence) 30.00 Sun-14-May@14.75 30.00 Sun-11-Jun@13.75 30.00 Sun-23-Jul@19.25 max 0.79 0.79 0.32 30.0 10.0 0.8 -1.8 in in in in heat (kW) Mon-09-Jan@ 6.75 Mon-09-Jan@ 6.75 Mon-09-Jan@ 7.25 manager_a manager_a manager_b manager_a on on on on min air T (occurrence) 10.00 Sun-01-Jan@ 4.25 10.00 Sun-01-Jan@ 4.25 13.68 Sun-01-Jan@ 7.75 max cool (kW) heating (kWhr) cooling (kWhr) -1.76 Mon-21-Aug@12.75 271.9 -797.9 -1.76 Mon-21-Aug@12.75 271.9 -797.9 -0.58 Mon-21-Aug@13.75 10.5 -480.9

Sun-14-May@14.75 Sun-01-Jan@ 4.25 Mon-09-Jan@ 6.75 Mon-21-Aug@12.75 1995.6 (MJ) -7475.9 (MJ)

Total heating requirements Total cooling requirements Monthly metrics: Month Heating Month (kWhr) Jan 164.5 Feb 76.8 Mar 25.0 Apr 24.8 May 2.8 Jun 0.0 Jul 0.0 Aug 0.0 Sep 2.4 Oct 9.1 Nov 101.4 Dec 147.6 Cooling (kwhr) -11.4 -38.7 -179.1 -118.2 -274.8 -323.3 -433.4 -409.6 -124.7 -120.3 -28.4 -14.9

554.3 (kWhr) -2076.64 (kWhr) Heating (MJ) 592.1 276.4 90.0 89.1 10.1 0.0 0.0 0.0 8.5 32.8 365.0 531.5 Cooling (MJ) -41.0 -139.3 -644.7 -425.5 -989.2 -1163.9 -1560.3 -1474.7 -448.9 -432.9 -102.1 -53.5

Figure 9.11: Save level zero report

Performance assessment report Results library HC_no-ISO.bres Climate file /usr/esru/esp-r/climate/uk_gatwick_iwec Configuration file HC_no-ISO_temp.cfg Configuration descr Comparison model for hc ISO 15099 w/o .htc file (default hc-s) Period Tue-09-Jul to Mon-15-Jul Year 1991 Zone TheSpace hungCeiling TheChannel mixBottom mixTop Zone TheSpace hungCeiling TheChannel mixBottom max air T (occurrence) 26.05 Tue-09-Jul@14.45 27.17 Tue-09-Jul@14.95 39.50 Thu-11-Jul@13.55 32.30 Sun-14-Jul@15.05 37.91 Thu-11-Jul@13.65 max heat (kW) -0.29 Tue-09-Jul@ 0.00 Tue-09-Jul@ 0.00 Tue-09-Jul@ 0.00 Tue-09-Jul@ 0.05 0.05 0.05 0.05 min air T (occurrence) 24.00 Thu-11-Jul@ 5.75 24.85 Sat-13-Jul@ 6.45 14.90 Thu-11-Jul@ 4.05 11.98 Thu-11-Jul@ 3.95 15.65 Thu-11-Jul@ 4.15 max cool (kW) heating (MJ) cooling(MJ) -1.00 Tue-09-Jul@11.05 -0.1 -257.2 0.00 Tue-09-Jul@ 0.05 0.0 0.0 0.00 Tue-09-Jul@ 0.05 0.0 0.0 0.00 Tue-09-Jul@ 0.05 0.0 0.0

138

mixTop All zones: Max_Temp Min_Temp Max_Heat Max_Cool 39.5 12.0 0.0 -1.0

0.00 Tue-09-Jul@ 0.05 in in in in

0.00 Tue-09-Jul@ 0.05

0.0

0.0

TheChannel on Thu-11-Jul@13.55 mixBottom on Thu-11-Jul@ 3.95 hungCeiling on Tue-09-Jul@ 0.05 TheSpace on Tue-09-Jul@11.05 -0.1 (MJ) -257.21 (MJ)

Total heating requirements Total cooling requirements

Monthly metrics: Month Heating (MJ) Cooling (MJ) Jul -0.1 -257.2 ********BUILDING INFORMATION******** ********SYSTEMS INFORMATION********* FAN, HRV, AND PUMP ELECTRIC ENERGY MONTH FAN_ENERGY MJ HRV ENERGY MJ JUL 0.0000 0.0000 TOTAL ELEC ENERGY 0.0000 0.0000 **********ZONE INFORMATION********* Zone( 1) TheSpace Month Aver.Temp (oC) Jul 24.1167 ... Sol Abs Opq.(MJ) 203.4809 Zone( 2) hungCeiling Month Aver.Temp (oC) Jul 25.6227 ... Sol Abs Opq.(MJ) 0.0000 Solar Extern(MJ) Solar Intern(MJ) Sol Abs Trans(MJ) 0.0000 217.4513 5.0579 Casual Rad. (MJ) Casual Conv. (MJ) Fndtn Losses(MJ) 0.0000 0.0000 0.0000 Solar Extern(MJ) 0.0000 Casual Rad. (MJ) 0.0000 Solar Intern(MJ) Sol Abs Trans(MJ) 0.0000 0.0000 Casual Conv. (MJ) Fndtn Losses(MJ) 0.0000 0.0000 GSHP_PUMP MJ 0.0000 0.0000 GCEP_PUMP MJ 0.0000 0.0000

Zone( 3) TheChannel Month Aver.Temp (oC) Solar Extern(MJ) Solar Intern(MJ) Sol Abs Trans(MJ) Jul 22.7131 692.8182 8.9125 172.7284 ... Sol Abs Opq.(MJ) Casual Rad. (MJ) Casual Conv. (MJ) Fndtn Losses(MJ) 224.6422 0.0000 0.0000 0.0000 ... SDHW Data Month Tank Elec (kWhr) JUL 0.0000 Total 0.0000 Tank Fuel (kWhr) Solar Gain (kWhr) 0.0000 0.0000 0.0000 0.0000 Pump Elec (kWhr) 0.0000 0.0000

Figure 9.12: Save level ve H3K report

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

139

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

Figure 9.13: Save level six report 9.3 XML output directives XML and CSV reports which are generated based on instructions in an input.xml le which is assumed to be located in the same folder as the model conguration le if the user has selected save level 5 or 6. Comma separated data is simply dumped into columns in a text le and relies on postprocessing by the user. 140

Each option for recording building and system performance during a simulation must be matched by a procedure to extract useful information. For save levels two, three and four this will primarily be the results analysis module discussed in Chapter 10.

XML reports benet from the added structure of XML and thus is more ammenable to post-processing tasks. The formal testing of source code changes relies on XML reports to identify differences in predictions. XML reports are, by their nature much more verbose than the equivalent csv le and rely on the user for post-processing. The simple input.xml le in Figure 9.14 was taken from one of the standard source code testing models.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <hierarchy>tree</hierarchy> <dump_all_data>true</dump_all_data> <time_step_averaging>false </time_step_averaging> </configuration>

Figure 9.14: Minimal input.xml le dumping everything This le is short and includes a directive to dump_all_data and thus creates an extensive output based on the complete XML data dictionary e.g. the data types within the simulation process that are able to be exported via XML protocols. Note that only a subset of the simulation variables have XML protocols enabled. Figure 9.15 includes a portion of a data dictionary which was generate by the simulator for a model. Figure 9.16 is the header of the csv le for a simple model with the dump_all directive and indicates the nature of the (potentially hundreds) of data items. The single long header line has been warped so that the data elds can be seen. This is followed by the initial columns of data, each row is one timesetep. 141

If we are not interested in everything the phrases in the out.dictionary le above provide the syntax for ne-tuning the output. For example if we wanted to discover what information was available at the air node of zones we might search for this using the pattern matching tool grep (see Figure 9.17). This indicates that there are three zones that the simulator has detected and it can report on relative_humidity or temperature. Thus if we wanted a timestep listing of the air temperatures in each of the rooms in the model we could adopt the following conventions in the input.xml le in Figure 9.18. The zone_* is a wild card in Figure 9.18 allows matching for multiple zones. The day and time variables are useful for plotting the temperatures. This yields the focused report with seven columns of data in Figure 9.19

Building/Ground_Reflectivity: Reflectivity of the ground for solar radiation dimensionless Climate/SnowDepth: Depth of the snow on the ground cm

building/all_zones/energy_balance/net: Energy balance in building (Gains + Plant interaction - Loads; all zones). (W) building/all_zones/envelope/all_components/heat_loss: Heat lost through all components of envelope (all zones) (W) building/all_zones/envelope/all_components/net_flux: Net heat lost through all components of envelope (all zones) (W) building/all_zones/envelope/ceilings/heat_gain: Heat gain from surroundings through ceilings (all zones) (W) building/all_zones/envelope/ceilings/heat_loss: Heat loss to surroundings through ceilings (all zones) (W) . . .

Figure 9.15: Portion of the XML data dictionary

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

142

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

Figure 9.16: Fragments of matching csv output le

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

143

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

Figure 9.17: Searching for patterns in out.dictionary

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

Figure 9.18: input.xml with wild cards and focus on zone air temperature
building:day:future (day), building:day:present (days), building:time:future (hours), building:time:present (hours), building:zone 01:air point:temperature (oC), building:zone 02:air point:temperature (oC), building:zone 03:air point:temperature (oC), 37.020832, 37.000000, 0.50000000, 24.000000, 14.642880, 14.654573, 19.864250, 37.041668, 37.020832, 1.0000000, 0.50000000, 14.468969, 14.481015, 19.701271, 37.062500, 37.041668, 1.5000000, 1.0000000, 15.000001, 15.000000, 19.546917, 37.083332, 37.062500, 2.0000000, 1.5000000, 14.999999, 15.000001, 19.402882, 37.104168, 37.083332, 2.5000000, 2.0000000, 15.000000, 15.000000, 19.276993, 37.125000, 37.104168, 3.0000000, 2.5000000, 15.000000, 15.000000, 19.168110, 37.145832, 37.125000, 3.5000000, 3.0000000, 15.000000, 15.000001, 19.065680, 37.166668, 37.145832, 4.0000000, 3.5000000, 15.000000, 15.000000, 18.966738, 37.187500, 37.166668, 4.5000000, 4.0000000, 15.000000, 15.000000, 18.871716, 37.208332, 37.187500, 5.0000000, 4.5000000, 14.999999, 14.999999, 18.780247, . . .

Figure 9.19: out.csv focused on zone air temperature

9.4 XML user interactions Unlike the denition of the Integrated Performance View (IPV) which is dened within the Project Manager the setup for the H3K reporting is in the simulator itself in the opening menu which is visable after the model has been scanned in (see Figures 9.20 and 9.21). 144

Figure 9.20: H3K Reports setup First select enable H3K reports and then you are presented with the full list of options.

The initial input.xml le after you select to enable H3K reports and select a tree structure for the XML and turn on timestep averaging is shown below. The listing shown in Figure 9.22 does not specify what data to include in the report. User editing of the le is needed. Once dictionary output has been enabled in the interface, the next time you run a simulation with this model an out.dictionary le and out.xml will be created. out.dictionary is a aide for users and out.xml is used by the simulation engine. The H3K reporting (save level 5) allows for a number of styles of predened output from a generic summary and generic html based summary to a H3K specic summary or csv le format. These are found in the ESP-r distribution folder xsl: fc_stylesheet.xsl - a template for fuel cell models generic_summary.xsl - a typical monthly summary report generic_summary_html.xsl - a typical monthly summary as html h3k.xsl - a template for use with H3K projects h3k_csv.xsl - a template for csv reporting of H3K projects h3k-pretty-print.xsl a html output for use with H3K Once you have entered the full path to the xsl le folder the interface will change and include specic XSLT formatting options as in Figure 9.23.

Figure 9.21: H3K Reports options 145

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

Figure 9.22: initial input.xml with nothing to write

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

A typical html output would look like Figure 9.24 (but would typically include more months data). If you return to the simulator SIMUL menu and switch to save level 5 (H3K output) and run a simulation you will get a <model_root_name>.h3k le. If you switch to save level 6 and have an input.xml le in your model folder you will get an out.xml and out.csv and an <model_root_name>.txt le. Having discussed the process of setting up a simulation to record what we want the next chapter focuses on how we might use the recorded information to understand how a design performs.

Figure 9.23: H3K Reports XSLT options After selecting, for example the generic_summary_html.xsl style sheet the input.xml le is expanded (see below): 146

Figure 9.24 HTML output based on XSLT style sheets.

147

Chapter 10

UNDERSTANDING PERFORMANCE PREDICTIONS

10 Understanding performance predictions As ESP-r workshops have evolved over the years a pattern has emerged. Participants end up spending almost as much time in the task of understanding the performance of models they created as they did in creating the model. This same pattern is also found in simulation teams that deliver information that exceeds client expectations. Understanding performance predictions is critical for testing that the semantics of the model are correct. Essentially, we invest our time and energy in the creation of models in order to get to the point where we can explore the temperatures and ux and ow that were generated by the simulation engine. The better our skills as identifying patterns and looking at the chain of thermophysical dependencies within our virtual world the better we can reach that AH! point where we can tell someone else a good story about what we have found. ESP-r differs from other simulation tools in that it records the thermophysical state of the model at each time-step into one or more random access les (depending on the number of analysis domains processed by the simulation engine). Some would call these random access les databases. The ESP-r suite includes a module res which is able to recover the values of the 149 thermophysical state and present them in graphical, statistical and tabular form. Other simulation tools tend to write out pre-selected performance data and rely on third party applications to parse and process and display such information. This is also the case for the XML and CSV reports of ESP-r. The essential difference in the results analysis module of ESP-r is philosophy. In one case you tell the the simulation engine exactly what to record before you run the simulation and in the other case the user directives are essentially delayed until the point of data extraction. Risk: if the simulation engine only records what you ask it to record unintended consequences or opportunities may not be identied Risk: performance data needed for clarication may not be available and require altering the directives and re-running the simulation Benet: for standard reports and I know what I want user directives and post processing via third party tools is efcient. 10.1 The res module Res is a tool for interactive exploration. It allows users to create ad-hoc collections of performance metrics and view

them in different formats or perform statistical operations on the data and display it in various forms. So, for example, the temperature at the inside face of a surface can be the subject of statistical reports, time-step listings or graphed. Such facilities are used by practitioners to react to ad-hoc questions and to explore dependencies within the model. And, of course, experienced users have methodologies of exploration which they use to identify unintended consequences as well as opportunities. Because the display of graphs and tables and tabular data is optimized for interactive work it tends not to be suitable for presentation reports and the typical approach taken is to export the relevant data in a format that can be processed by a third party application. The number of choices in the res module is extensive so a review of the menu hierarchy is the rst step in mastering this tool. The top level choices are listed in Figure 10.1.
results analysis: 1 Select result file 2 Select result set 3 Define output period 4 Select zones ------------------a Graphs c Time-step reports d Enquire about e Plant results f Indoor env. quality g Electrical results h CFD i Sensitivity j IPV ------------------r Report >> silent * Preferences ? Help - Quit

Figure 10.1: High level choices in res module If you request a results analysis in the project manager the res application will be passed the name of the zone results le. You have the option of nominating a different le name from within the application or to start res with a command line option of a specic results le. A zone results le can contain more than one period of performance data (e.g. a winter week and a summer week). If more than one set is included then res must be instructed as to which set to use (option 2 in Figure 10.1). Note that the ow and systems results les can only hold a single period. Many users prefer to use separate results les for different periods (this is the pattern used by the IPV for seasonal assessments, each season gets a unique le name). Many of the menus in res include an option to dene the output period from the whole period of the assessment to selected days of the assessment. This would cause graphs to zoom in or statistics to be generated for the selected days. The primary choices for how you want to view the performance information are found in choices: Graphs Time-step reports Enquire about (see section 10.1.1). The Plant results choice opens a separate system results le while the Electrical results opens and scans a power predictions le and the CFD option opens and scans a CFD domain 150

specic le. The option IPV is typically not selected by users because the Integrated Performance View facility is controlled from the project manager via a command line syntax when res is invoked. 10.1.1 Enquire about Several classes of statistical report are found in the Enquire about menu structure shown in Figure 10.2.
Enquire about: 2 select result set 3 define output period 4 select zones ------------------a summary statistics b frequency table ------------------c hours above a value d hours below a value ------------------f energy delivered g casual gains distrib h zone energy balance i surface energy balnc j surface condensation k intrstl condensation ------------------l monthly gains/losses m monthly temp. stats ------------------> output >> screen delim >> normal ? help - exit

f g h i j k m n o p > & + * ? -

-----------------Zone flux Surface flux Heat/cool/humidify Zone RH Casual gains Electrical demand -----------------Renewables/adv. comp. Network air/wtr flow CFD metrics Measured:temporal -----------------Display to >> screen Data: as values Filter >> none Time >> 10h30 Delim >> normal Help Exit

Figure 10.3: Summary statistics choices Summary statistics reports take the general form shown in Figure 10.4. The extreme values and time of occurrence are reported along with the mean and standard deviation for each item and the last line of the report is the overall peak and mean. The time of occurrence is a particularly valuable part of the report. For example a peak temperature of 27C during occupied hours is likely to be of greater concern than the same peak if it happened at 23h00.

Figure 10.2: Enquire about choices The number of different performance metrics which are available via summary statistics can be seen by the choices offered in the Figure 10.3.
Summary statistics: 2 Result set 3 Display period 4 Select zones -----------------a Climate b Temperatures c Comfort metrics d Solar processes

151

Lib: cellular_bcwin.res: Results for cellular_bc Period: Mon-09-Jan@00h15(1967) to Sun-15-Jan@23h45 : sim@30m, output@30m Zone db temperature (degC) Description manager_a manager_b corridor All Maximum value occurrence 23.979 14-Jan@14h15 23.979 14-Jan@14h15 24.004 14-Jan@17h15 24.004 -Minimum value occurrence 10.000 09-Jan@00h15 10.000 09-Jan@00h15 13.981 09-Jan@00h45 10.000 -Mean value 16.598 16.598 19.639 17.612 Standard deviation 2.6780 2.6781 2.0037 --

Figure 10.4: Typical summary statistics report The sub-sections of the summary statistics are seen in Figure 10.5.
Climate choices:: a Ambient temperature b Solar Dir N c Solar diffuse d Wind speed e Wind direction f Ambient RH g Sky illumunance ____________________ ? help - exit this menu Temperature choices:: a Zone db T b Zone db T - ambient db T c Zone db T - other zone db T d Zone control point T e Zone Resultant T f Mean Radiant T (area wtd) g Mean Radiant T (at sensor) h Dew point T i Surf inside face T j Surf T - dewpoint T k Surf outside face T l Surf node T __________________________ ? help - exit this menu Comfort choices:: a Predicted Mean Vote (PMV) b PMV using SET c Percentage Dissatisfied (PPD) d Local delta T head-foot e Dissatisfied due to floor T f Diss. warm/ cool ceiling g Diss. wall rad T asymmetry __________________________ ? help - exit this menu Select a solar flux metric Solar choices:: a Solar entering from outside b Solar entering from adj c Solar absorbed in zone __________________________ ? help - exit this menu

Figure 10.5: Climate, temperature, comfort and solar choices Some of these directly match the data types set out in section 9.2 and others such as Zone db T - ambient db T and Predicted Mean Vote (PMV) are derived values. The second section of the summary statistics menu includes zone ux and surface ux and these expand to the constituent parts of the zone and surface energy balance which were written into the le store (Figure 10.6):
Zone flux options:: a Infiltration (from outside) b Ventilation (adj zones) c Occupant casual gains (R+C) d Lighting casual gains (R+C) e Small power casual gains (R+C) f Controlled casual gains (R+C g Opaq surf conv @extrn h Opaq surf conv @partns i Tran surf conv @extrn j Tran surf conv @partns k Total surface conv __________________________ ? help - exit this menu Surface fluxes: a conduction (inside) b convection (inside)

152

c d e f g h i j k l m n o p q r 0 < ? -

LW radiation (inside) SW radiation (inside) radiant casual occup radiant casual light radiant casual equip contrld casual gains heat storage (inside) plant inj/extr (inside) conduction (other face) convection (other face) long wave > buildings long wave > sky long wave > ground SW rad abs (other fc) SW rad incid (other fc) heat storage (other fc) Page part: 1 of 2 index select help exit this menu

? help - exit this menu

Figure 10.6: Zone and surface energy balance choices These zone and surface energy balance ux path reports complement the full zone and surface energy balance reports (see section 10.1.4) and can be used to detect extreme occurrences. 10.1.2 Environmental systems reporting There are several approaches to dening environment systems in ESP-r - as ideal controls or as detailed system components. In the results analysis if you want to see the environment system loads you would use the Heat/cool/humidify option. If you used detailed components then additional information will be available in the plant reporting. The current choices are shown in Figure 10.7.
Load choices:: a Sensible heating load b Sensible cooling load c Dehumidification load d Humidification load e All sensible loads f All latent loads g All Sensible + latent load __________________________

Figure 10.7 Heat / Cool / Humidify options. You can report on heating separately from cooling or conated together. Although in any zone you would not get a controller to simultaneously provide heating and cooling at the same time-step, there could be heating on one zone and cooling in another zone at a point in time. The latent loads will be reported if you have specied humidity control, otherwise the latent loads are zero. 10.1.3 Casual gains The reporting of casual gains in zones takes many forms because casual gains are made up of sensible and latent components as well as convective and radiative fractions of the sensible gains and there are (currently) three types of casual gains that can be tracked in each zone. The selection list is shown in Figure 10.8.
Casual sensible and latent: a all sensible (conv+rad) b all sensible convective c all sensible radiant d all latent e occupant (conv+rad) f occupant convective g occupant radiant h occupant latent i lighting (conv+rad) j lighting convective k lighting radiant l lighting latent m equipment (conv+rad) n equipment convective o equipment radiant p equipment latent q controlled fraction r controlled (conv+rad) 0 Page part: 1 of 2 < index select ? help - exit this menu

153

Figure 10.8 Casual gain options. Currently it is possible to apply control to lighting casual gains by dening a lighting control regime, the details of which are held in a casual gain control le. The control fraction is supposed to match the output of the lighting control regime. 10.1.4 Zone energy balances ESP-r provides a powerful analysis capability via zone air node energy balance reporting as well as surface energy balance reporting. If save level 4 is selected, for each time-step of the period for which a simulation is undertaken the individual ux paths which make up the air node energy balance are recorded. A typical report is shown in Figure 10.9. Notice the TOTAL line which reports the sum of all gains and the sum of all losses and these should balance each other closely (to a Whr) if the model is correct.
Zone energy balance (kWhrs) for manager_b Infiltration air load Ventilation air load Uncontrd casual Occupt Uncontrd casual Lights Uncontrd casual Equipt Thermal bridge (linear) Storage at air point Opaque surf convec: ext Opaque surf convec: ptn Transp surf convec: ext Transp surf convec: ptn Convec portion of plant Totals Gain 0.000 0.000 2.430 0.000 0.000 0.000 0.616 0.106 4.285 0.001 1.132 23.411 31.981 Loss -10.600 0.000 0.000 0.000 0.000 0.000 -0.627 -1.406 -8.522 -10.344 -0.471 -0.011 -31.981

Figure 10.9: Zone energy balance report An energy balance (from the point of view of the zone air node) of all of the ux entering & leaving the air node 154

should balance at each time-step of the sim- ulation. The report is an integration of each of the above types of ux over the period of the assessment. A ux is positive if it adds heat to the air node of the zone and is negative if it removes heat from the air node of the zone. For example, if exterior surfaces which are opaque are always colder than the air temperature then the report will include losses for interior surfaces. The details of the ux paths are: The inltration air load is the kWhr gain or loss implied by the movement of air from the outside air and the zone. An integrated report will often include both gains and losses. Note that air which leaves the room and arrives at the outside is not counted in the zone energy balance. No energy balance is reported for the outside environment. The ventilation air load is the kWhr gain or loss implied by the movement of air from other zones of the model into the room. Air leaving the room to another zone is reported in the energy balance of the other zone. Convective gains from occupants, lights and small power devices are separately reported in the zone energy balance report. The radiant component is found in the surface energy balance report. Linear thermal bridges dened in the zone are part of the zone energy balance. Although users are able to dene a number of linear thermal bridges the aggregate gains or losses (in kWhr) are reported.

 Because the starting and ending temperature of the air over the period of the assessment may be different the energy balance includes a storage term for the air point. Convection at the inside face of surfaces of the zone can be signicant ux paths and are reported in four separate lines - convection at opaque surfaces which have an exterior boundary condition, opaque surface which have any OTHER boundary condition (ground, similar, partition, constant, basesimp), transparent surface which have an ambient boundary condition and transparent surfaces which have any other boundary condition. Experts considering how to improve the performance of a design will often look at the zone energy balance for clues. For example to reduce heating in cold weather they would check to see what were the biggest losses and they would focus on the biggest gains in hot weather. In the above report the losses from inltration and via convection at transparent surfaces facing the outside are almost the same. Is it less expensive to make the facade more air tight or to put in better quality windows? The energy balance makes very clear that improvements to the opaque portions of the facade will have very little impact on the heating demands. 10.1.5 Surface energy balances A surface energy balance (see Figure 10.10) reports ux gains & losses at the inside face of the surface. For surfaces which have an exterior boundary 155

condition, the other-side face energy balance is also reported. An energy balance from the point of view of a surface of the ux entering and leaving at each face should balance at each time-step of the simulation. The report is an integration of each of the above types of ux over the period of the assessment. A ux is positive if it adds heat to surface and is negative if it removes heat from the surface. For example, if exterior surfaces which are opaque are always colder than the air temp the the surface energy balance report will indicate gains at the inside face. The surface balance includes: conduction (heat moving through the construction) at a point just below the surface layer (halfway between the surface layer and the next node), convection (heat transfer to the air) at the face, long-wave radiation exchange with other surfaces in the room, long-wave radiation from the otherside face of the surface to to other buildings/ the ground/ the sky (if the surface is facing the outside), radiant portion of casual gains from occupants/ lighting/ small power loads, heat stored in the construction (at the same radiant portion of any environmental systems associated with zone There is a TOTAL line which reports the sum of all gains and the sum of all losses and these should balance each other closely if the model is correct.

Causal energy breakdown (Whrs) for part_glaz (10) in manager_a ( 1) Surface is trnsp., area= 4.48m2 & connects to surface 9 in zone 3 Facing manager_a Gain Loss 4985.42 -59.43 470.62 -1132.32 46.10 -4502.90 ------59.00 0.00 141.12 0.00 0.00 0.00 0.00 0.00 0.00 145.79 0.00 5848.05 0.00 -153.39 0.00 -5848.04

Conductive flux Convective flux Long-wave rad int LW rad ext >bldg LW rad ext >sky LW rad ext >grnd Shortwave rad. Occupt casual gn Lights casual gn Equipt casual gn Controlled casual Heat stored Plant Totals

For surfaces facing the outside the energy balance is reported as follows:
Period: Mon-09-Jan@00h15 to Sun-15-Jan@23h45(1967) : sim@30m, output@30m Causal energy breakdown (Whrs) for spandrel ( 7) in manager_a ( 1) Surface is opaque MLC, area= 2.70m2 & connects to the outside Facing outside Gain Loss 3198.10 -354.00 2033.87 -3531.10 --342.02 -87.26 0.00 -7315.40 60.73 -1209.33 6872.32 0.00 --------194.55 -203.53 0.00 0.00 12701.58 -12700.62

Conductive flux Convective flux Long-wave rad int LW rad ext >bldg LW rad ext >sky LW rad ext >grnd Shortwave rad. Occupt casual gn Lights casual gn Equipt casual gn Controlled casual Heat stored Plant Totals

Facing manager_a Gain Loss 0.27 -2853.92 1054.75 -80.06 1395.28 -209.51 ------612.81 0.00 84.03 0.00 0.00 0.00 0.00 0.00 0.00 0.00 87.40 -90.71 0.00 0.00 3234.53 -3234.20

Figure 10.10: Surface energy balance reports constrained by the low air velocity in the room). And experts would also check surface energy balances to determine what 10.1.6 Hours above and below change might be appropriate. In the During performance evaluation sesabove case the primary loss in the sions it is common to have questions in spandrel is conductive so there is room the form "how often is it warmer than for improvements in insulation levels. X" or "how often is solar radiation on As expected the biggest loss for the that surface more than Y Watts/m2". To inside partition glazing is via conducanswer such questions quickly for any tion (the convective exchanges are 156

of the standard performance metrics the Enquire about menus have an option for hours above and hours below. The choices are shown in Figure 10.11.
Hrs above query point: 2 Result set 3 Display period 4 Select zones -----------------a Climate b Temperatures c Comfort metrics d Solar processes -----------------f Zone flux g Surface flux h Heat/cool/humidify i Zone RH j Casual gains k Electrical demand -----------------m Renewables/adv. comp. n Network air/wtr flow o CFD metrics p Measured:temporal -----------------> Display to >> screen & Data: as values + Filter >> none * Time >> 10h30 Delim >> normal ? Help - Exit

written at the end of the report. The hours required may provide evidence of systems being used at low capacity for many hours. Another report which includes the energy delivered is the monthly gains and losses report (Figure 10.13). Many users mistake this as a monthly energy balance report bit it only includes a subset of the information included in the zone energy balance report.

Figure 10.11: Hours above options 10.1.7 Energy delivered Some performance questions relate to capacity and these are typically covered in the summary statistics reports. If the performance question is how often was heating or cooling required and how many kWhr were delivered during the assessment period then there are other choices such as the Energy delivered reports (Figure 10.12) which provide this information. There are several items of interest in the energy delivered report. For each zone the sensible values for reported and the total for the included zones is 157

The energy delivered menu offers the following report: Lib: cellular_bcwin.res: Results for cellular_bc Period: Mon-09-Jan@00h15(1967) to Sun-15-Jan@23h45(1967) : sim@30m, output@30m Zone total sensible and latent plant used (kWhrs) Zone Sensible heating Sensible cooling id name Energy No. of Energy No. of (kWhrs) Hr rqd (kWhrs) Hr rqd 1 manager_a 23.41 117.5 -0.01 1.0 2 manager_b 23.41 117.5 -0.01 1.0 3 coridor 1.95 22.0 -0.04 3.5 All 48.78 257.0 -0.07 5.5 Humidification Energy No. of (kWhrs) Hr rqd 0.00 0.0 0.00 0.0 0.00 0.0 0.00 0.0 Dehumidification Energy No. of (kWhrs) Hr rqd 0.00 0.0 0.00 0.0 0.00 0.0 0.00 0.0

Figure 10.12: Energy delivered report

Lib: cellular_bcwin.res: Results for cellular_bc Period: Mon-09-Jan@00h15(1967) to Sun-15-Jan@23h45(1967) : sim@30m, output@30m Monthly selection of gains & losses (to nearest 100Wh). Period|Transp surf|Opaque surfs|Casual Gain|Infil|Vent| Plant |Solar radiation| in |exter|other|extern|other|conv radnt| | |Heat|Cool|absor |entering| |facng|facng|facing|facng| | | | | |inside|zone | manager_a Jan -39. 4. -4. -4. 11. 11. -42. 0. 80. -5. 52. 59. Feb -29. 6. 0. 28. 10. 10. -38. 0. 38. -16. 96. 109. Mar -22. 11. 8. 93. 11. 11. -44. 0. 13. -69. 210. 240. Apr -20. 9. 5. 69. 10. 10. -41. 0. 12. -45. 159. 181. May -9. 12. 11. 116. 11. 11. -38. 0. 1. -105. 228. 259. Jun 2. 11. 12. 118. 11. 11. -30. 0. 0. -124. 208. 237. Jul 12. 11. 15. 139. 11. 11. -20. 0. 0. -169. 225. 256. Aug 8. 12. 15. 140. 11. 11. -25. 0. 0. -161. 233. 266. Sep -11. 7. 5. 56. 11. 11. -25. 0. 1. -43. 117. 133. Oct -17. 9. 5. 64. 11. 11. -33. 0. 5. -43. 141. 161. Nov -30. 6. -1. 16. 11. 11. -39. 0. 50. -12. 66. 76. Dec -37. 5. -3. 2. 11. 11. -43. 0. 72. -6. 50. 57. manager_b Jan -39. 4. -4. -4. 11. 11. -42. 0. 80. -5. 52. 59. Feb -29. 6. 0. 28. 10. 10. -38. 0. 38. -16. 96. 109. Mar -22. 11. 8. 93. 11. 11. -44. 0. 13. -69. 210. 240. Apr -20. 9. 5. 69. 10. 10. -41. 0. 12. -45. 159. 181. May -9. 12. 11. 116. 11. 11. -38. 0. 1. -105. 228. 259. Jun 2. 11. 12. 118. 11. 11. -30. 0. 0. -124. 208. 237. Jul 12. 11. 15. 139. 11. 11. -20. 0. 0. -169. 225. 256. Aug 8. 12. 15. 140. 11. 11. -25. 0. 0. -161. 233. 266. Sep -11. 7. 5. 56. 11. 11. -25. 0. 1. -43. 117. 133. Oct -17. 9. 5. 64. 11. 11. -33. 0. 5. -43. 141. 161. Nov -30. 6. -1. 16. 11. 11. -39. 0. 50. -12. 66. 76. Dec -37. 5. -3. 2. 11. 11. -43. 0. 72. -6. 50. 57. coridor Jan 0. -12. 0. -25. 34. 34. 0. 0. 5. -2. 7. 0. Feb 0. -9. 0. -15. 31. 31. 0. 0. 1. -7. 13. 0. Mar 0. -2. 0. 9. 34. 34. 0. 0. 0. -41. 29. 0. Apr 0. -5. 0. -1. 33. 33. 0. 0. 0. -27. 22. 0. May 0. 4. 0. 27. 34. 34. 0. 0. 0. -66. 32. 0. Jun 0. 7. 0. 35. 33. 33. 0. 0. 0. -75. 29. 0. Jul 0. 11. 0. 51. 34. 34. 0. 0. 0. -96. 32. 0. Aug 0. 9. 0. 44. 34. 34. 0. 0. 0. -88. 33. 0. Sep 0. -2. 0. 6. 33. 33. 0. 0. 0. -38. 16. 0. Oct 0. -3. 0. 4. 34. 34. 0. 0. 0. -35. 20. 0. Nov 0. -11. 0. -20. 33. 33. 0. 0. 2. -4. 9. 0. Dec 0. -12. 0. -24. 34. 34. 0. 0. 3. -2. 7. 0. All zones Jan -78. -4. -8. -34. 55. 55. -85. 0. 164. -11. 111. 118. Zone

158

Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Annual

-57. -44. -40. -17. 4. 25. 16. -21. -33. -60. -74. -381.

4. 20. 14. 27. 28. 34. 34. 13. 14. 1. -3. 182.

1. 15. 11. 22. 25. 30. 29. 9. 10. -2. -6.

40. 195. 137. 260. 271. 330. 325. 119. 132. 12. -20.

50. 56. 53. 56. 54. 55. 56. 54. 55. 54. 55. 656.

50. 56. 53. 56. 54. 55. 56. 54. 55. 54. 55. 656.

-76. -89. -81. -76. -59. -40. -50. -51. -66. -78. -85. -836.

0. 77. 0. 25. 0. 25. 0. 3. 0. 0. 0. 0. 0. 0. 0. 2. 0. 9. 0. 101. 0. 148.

-39. -179. -118. -275. -323. -433. -410. -125. -120. -28. -15.

205. 450. 340. 487. 446. 481. 498. 250. 302. 142. 107.

218. 480. 361. 518. 473. 512. 531. 266. 322. 151. 114. 4066.

135. 1766.

0. 554. -2077. 3820.

Figure 10.13: Monthly gains and losses report 10.1.8 Condensation reports If we know the air temperature and the The monthly gains and losses report humidity as well as the surface temperincludes the following: ature it is possible to report how often convective surface exchanges for condensation would form on surfaces transparent surface which face the in a room. The report does not say outside or something not-the-outside whether the condensation is a light convective surface exchanges for misting or is severe enough to cause opaque surfaces which face the outwater droplets to form, simply that side or something not-the-outside conditions exist for some degree of sum of all casual sensible convective condensation. There are several options gains that can enhance the report. Firstly the actual humidity in the room can be sum of all casual sensible radiant used. For tests of sensitivity the user gains can also nominate a specic humidity aggregate gains or losses associated and base the report on that. with inltration (air from the outside The condensation report takes two either natural or forced) forms - a summary that includes the aggregate gains or losses associated number of hours of condensation for with ventilation (air exchanges with each of the surfaces and a detailed other thermal zones either natural or time-step-by-time-step listing of occurforced) rences for each surface in the zone. heat delivered to the zone These are shown in Figure 10.14. cooling extracted from the zone Surface condensation report (summary form): Summary condensation report for: coridor solar radiation absorbed at surfaces Surface occurrences hours right 170 85.00 in the zone wall 167 83.50 left 170 85.00 solar radiation entering the zone ceiling 169 84.50 floor 168 84.00 from the outside
door ptn_corid part_frame part_glaz 325 318 273 324 162.50 159.00 136.50 162.00

159

part_frameb 278 139.00 door_b 325 162.50 ptn_coridb 318 159.00 part_glazb 324 162.00 Figure filler 170 85.00 Total occurrences & hours in coridor 327 163.50 If a time-step condensation . . . 13h15 X X X X X X X X X X X 13h45 X X X X X X X X X X X 14h15 X X X X X X X X X X X 14h45 X X X X X X X X X X X 15h15 X X X X X X X X X X X 15h45 X X X X X X X X X X X 16h15 X X X X X X X X X X X 16h45 X X X X X X X X X X X 17h15 X X X X X X X X X X X 17h45 X X X X X X X X X X X 18h15 X X X X X X X X X X X 18h45 X X X X X X X X X X X 19h15 X X X X X X X X X X X 19h45 X X X X X X X X X X X 20h15 X X X X X X X X X X X 20h45 . . . . . X X . X . X 21h15 . . . . . X X . X . X 21h45 . . . . . X X X X X X 22h15 . . . . . X X . X X X 22h45 . . . . . X X X X X X 23h15 . . . . . X X X X X X 23h45 . . . . . X X X X X X

<< gure to be added >> 10.15 Interstitial condensation reports.

10.2 listing is requested:

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .

Time-step reporting Where graphs are good at indicating patterns they do not provide sufcient resolution to determine the specic values at a specic time. For each item that is subject to a statistical report or might be included in a graph there is another option to view the item or a user dened collection of items in columns time-step-by-timestep. The interface options for timestep reporting are shown in Figure 10.16. The performance metrics options should look familiar!
Tabular Output: 2 select result set 3 define period 4 select zones ___________________ g performance metrics h special material data i network air/wtr flow ___________________ formatting... > output >> screen * time >> 10h30 * labels >> multiline delim >> normal ? help - exit Performance metrics: 2 Result set 3 Display period 4 Select zones -----------------a Climate b Temperatures c Comfort metrics d Solar processes -----------------f Zone flux g Surface flux h Heat/cool/humidify i Zone RH j Casual gains k Electrical demand -----------------m Renewables/adv. comp. n Network air/wtr flow

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

Figure 10.14 Summary and detailed condensation reports. Condensation within a construction is also a topic of concern for some assessments. If save level 3 is used (nodal temperatures are recorded) then it is possible to plot temperature proles over time as well as identify the point where interstitial condensation would occurr (see Figure 10.15). 160

o CFD metrics p Measured:temporal -----------------> & + * ! ? Display to >> screen Data: as values Filter >> none Time >> 10h30 Delim >> normal List data Help Exit

15.1979,2.20,13.90,13.90,18.63 15.2188,2.20,13.76,13.76,18.50 15.2396,2.20,13.64,13.64,18.38 15.2604,2.20,13.51,13.51,18.26 15.2813,2.20,13.40,13.40,18.14 15.3021,2.20,13.29,13.29,18.02 15.3229,2.20,13.18,13.18,17.90 15.3438,2.20,13.09,13.09,18.15 15.3646,2.20,13.01,13.01,18.68 15.3854,2.20,12.97,12.97,18.85 15.4063,2.20,12.98,12.98,18.91 15.4271,2.05,13.03,13.03,19.03 . . .

Figure 10.16 Time-step options. Time-step listings are also a useful facility for exporting data into comma separated or tab separated columns in a le for processing in a third party application. At the bottom of the menu are options to redirect the output from the screen to a user nominated le. There is also a toggle for time to be written in an 10h30 form or as 0.4375 fraction of the day. The options for labels on one line (e.g. for inclusion in a spreadsheet) as well as for setting the delimiter from a space to a tab or a comma allow reports to be more easily accepted by 3rd party tools. The listing in Figure 10.17 has the time in the rst column, the outside ambient temperature in the 2nd column and each zone resultant temperatures in the remaining columns.

Figure 10.17 Time-step reports. The time-step listing facility can, of course be scripted as can other textbased reporting if you invoke the results analysis application in text mode at the command line (see section 17.1). 10.3 Graphic reporting ESP-r offers a number of forms of graphic display for data. The high level options are shown in Figure 10.18.
Graph facilities: 2 Select result set 3 Define output period 4 Select zones ------------------a Time:var graph b Intra-fabric c 3D profile d Frequency histogram e Var:Var graph f Network air/wtr flow ------------------? Help - Exit

# Time-step performance metrics. # Lib: cellular_bc_ann.res: Results for cellular_bc # Period: Sun-15-Jan@00h15 to Figure Mon-16-Jan@11h45(1967): sim@30m, output@30m #Time AmbientdbTmp(degC) manager_aResT(degC) manager_bResT(degC) coridorResT(degC) 15.0104,3.15,15.27,15.26,19.85 15.0313,2.85,15.21,15.21,19.69 15.0521,2.70,15.05,15.05,19.54 15.0729,2.70,14.82,14.82,19.40 15.0938,2.70,14.66,14.66,19.27 15.1146,2.70,14.52,14.52,19.14 15.1354,2.58,14.35,14.35,19.01 15.1563,2.33,14.20,14.20,18.88 15.1771,2.20,14.05,14.05,18.75

10.18 Graphic report options.

161

Figure 10.19 Example multi-axis graph.

Figure 10.20 Example focused multi-axis graph. graphs with multiple axis as seen in Figure 10.19. Here twelve days in January are graphed with the zone dry bulb temperatures of three zones shown along with the ambient outside temperature and the direct solar radiation (from the climate data). 162

10.3.1 Variables against time The Time:var graph includes essentially the same list as is found in the timestep listings and the enquire about facility. It supports ad-hoc creation of

It is clear in the graph that on weekday nights the temperature in the rooms falls to at 15 degree night set-back temperature and at the weekends there is a frost protection setting at 10 degrees. On the initial days of the simulation the room temperature rises to the cooling set-point and to determine if this was due to solar radiation entering the rooms the solar radiation plot was added to the graph. For days where there is little direct solar radiation the un-conditioned corridor room is cooler when it is cooler outside and warmer when it is warmer outside. In Figure 10.20 the user has focused the graph on the rst three days of the assessment and restricted the graph to the manager_a zone and has added into the graph the inside face surface temperatures of all the surfaces in manager_a. Most of the surface temperatures track within a 3-4 degree range, except for the glazing which gets hottest at mid-day and coldest overnight. And the graph is somewhat confusing in that the names of the lines for the surface temperatures overlap and it is not all that clear which one is the room dry bulb temperature. This might be a good reason for switching to the timestep listing report so that the specic temperatures can be seen or even to ask for statistics on surface temperatures. 10.3.2 Frequency bin Earlier the discussion pointed out that the time of occurrence of extreme values can be important in assessments. 163

Some users are also interested in the frequency distribution of values in rooms. For example, regulations might prescribe the number of hours in the summer that temperatures are allowed to go above 25 degrees. A frequency bin is a quick way to determine the rarity of extremes. In Figure 10.21 is the annual distribution of dry bulb temperatures in the manager_a room. Because the data was not ltered by occupancy (e.g. for occupied hours) there is a range of 10 30 degrees with a bit over 20% of the time near 24 (the cooling set-point), 16% near 19 (the heating set-point) and about 10% of the time near 15 degrees (the night setback). Often a frequency bin will demonstrate a recognizable normal distribution and the task becomes to choose points of signicance at the upper and lower boundary of the range. For example, if there are 5% of delivered heating is above 15kW with a peak at 19kW then some users might explore the possibility of designing for 15kW with an adaptive control scheme. 10.3.3 3D surface plots An alternative to a at graph is a 3D surface plot where time is seen on the right axis, days are on the left axis and the value is shown as a height. In Figure 10.21 the convective casual gains for the room manager_a are shown in a 3D plot. The dip at mid-day for lunch breaks can be seen as can the weekend breaks along the day axis. This is a particularly good form for checking the impact of lighting controls.

Figure 10.21 Example frequency bin.

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

164

Figure 10.21 Example variable vs variable graph. understand performance in different ways and have preferences for information presentation types and the choices for presentation reect this. Those who deliver exceptional value into the design process tend to have exception pattern matching skills as well as a solid grounding in the underlying physics of buildings and systems. The ad-hoc nature of interactions in the results analysis module gives such users scope for identifying the underlying issues. So in Figure 10.19 the user initially plotted the room temperatures and then added the ambient temperature to conrm a sensitivity to the outside. The need for cooling in January was noticed and the question of what could make it warm lead to a guess that solar radiation might be the core issue and so this was added to the graph. The next step was to look at the surface temperatures in a typical room to see what was getting warm. And one might also follow this with a quick 165

10.3.4 Variable vs variable graphs The correlation between two variables can be expressed via statistics and it is also possible to visualize the relationships between two variables if they are plotted with the rst variable on one axis and the second variable on the other axis. In Figure 10.22 there would seem to be a fair correlation between the dry bulb temperature in the rooms and the resultant temperature in the rooms. There are occasional deviations near 15 and 19 degrees as might be expected because of the cycling of the heating in the rooms. 10.4 Methods for exploration of data sets The discussion thus far has reviewed the types of information that can be accessed in the results analysis module of ESP-r and shown sample of many of the possible reports. Different users

review of the zone energy balances. Pattern matching is a skill that can be acquired. With practice and guidance from experienced users novices (and even Architectural students) to begin to recognize patterns and follow these to likely causal elements in their designs. It may take a number of iterations to accomplish this but it is one of the most important of simulation skills.

166

Chapter 11

FLOW

11 Flow Where there is strong coupling between heat and air ow, e.g. stack and wind driven ow Where there are highly dynamic variations in ventilation rate, e.g. natural ventilation Where control strategies are important, e.g. opening or closing windows based on temperature and/or wind speed. If these are descriptive of your design then consider ow networks as a way to better represent the dynamics of ow interactions. 11.2 Fluid Flow Networks Fluid ow networks offer considerable exibility in describing a range of designs and the potential to increase the resolution of models to support assessments which are dependent on the movement of mass or ux or power within a model. Rather than imposing ows, a network describes possible ow paths (e.g. doors, cracks, fans, ducting, pipes, valves), points where boundary conditions apply (e.g. an opening to the outside) and locations where measurements of ow performance are required (e.g. internal and boundary nodes). ESP-rs ow network solver dynamically calculates the pressure-driven ows within zones and/or 168

This Chapter focuses on airow modelling techniques in ESP-r: overview of network air ow modelling; the art of planning ow networks; dening and calibrating ow networks; control of ow networks; project management. At the simplest level, air ow within an ESP-r model can be imposed via schedules of inltration and ventilation. For example a user could stipulate 0.5 air changes of inltration for all days and all hours or a schedule that changes at each hour for each day type. These schedules may be subjected to control (e.g. increase inltration to 1.5 air changes if zone temperature goes over 24 C). Scheduled ow is appropriate for engineering approximations, initial design studies and basic operational regimes. 11.1 Limitations of Scheduled Flow The critical word above is imposed. Schedules impose a ow regime which may have no basis in the physics of buildings. This is particularly true in the following cases:

environmental control systems that are associated with the network. The ows at nodes are a function of nodal pressures and the connected components characteristics. The mass balance at each node is solved using a customized Newton-Raphson approach. The solution iterates until it converges and the pressure at each node and the mass ow through each connection are saved. The solution takes into account the change in driving forces as conditions within the building and boundary conditions evolve. Information exchange between the domain solvers ensures that changes in ow will inuence conditions in associated zones, controls, systems and CFD domains within a model. For example, opening a window on a cool day introduces cool air into a zone, which depresses the temperature of the walls which then alters the buoyancy forces driving the ow. Although the ow of air in real building continually adapts to conditions and self-balances, simulation re-evaluates conditions at xed intervals. Thus there is the possibility that differences in temperatures can build up during the simulation time step which would not be observed in real buildings. This results in exaggerated air ows, or oscillating ows, especially for large openings between thermal zones. Thus the choice of simulation time step is a topic worthy of discussion. Those who wish to know more about the solution technique should look at publications page on the ESRU web site. For example, On the Conation of Contaminant Behavior within Whole 169

Building Performance Simulation (A Samuel, 2006), Energy Simulation in Building Design (J A Clarke 2001), The Adaptive Coupling of Heat and Air ow Modelling Within Dynamic Whole-Building Simulation (I Beausoleil-Morrison 2000), On the thermal interaction of building structure and heating and ventilating system (J L M Hensen 1991) are books or PhD thesis which discuss some aspects of ow simulation. An ESP-r model may have one or more de-coupled ow networks - some describing building air ow and others representing ow in a hot water heating system. In models which include separate buildings the ow network can include one or more of the buildings. The solver is efcient and thus, even with scores of nodes and components, there is only a slight increase in computational time. Assessing thousands of time-steps of ow patterns in support of natural ventilation risk assessments is one use of ow networks. Flow networks are often used as pre-cursors to CFD studies. The exibility of ow networks brings both power and risk. The discussion that follows presents methodologies to help you decide when networks are called for, planing tips for ow networks and techniques for understanding the predicted patterns of ow within your model. ESP-r differs from some other simulation tools in that it asks the user to dene ow networks explicitly. An explicit description allows knowledgeable users to control the resolution of the network as well as the choice of

ow components and their details. This approach assumes that the user has opinions about ow paths as well as access to relevant information about the ow components used in the network. As with the geometric resolution of a model, creating ow networks is as much an art as it is a science. Scaling up skills and working practices to cope with the level of complexity found in realistic projects has traditionally been accomplished via mentors or workshops. This has limited the deployment of the facility. The Cookbook aims to de-mystify the topic of ow networks as well as providing hints about where the dragons tend to hide. 11.3 Building blocks The building blocks we can use to dene a mass ow network are ow nodes, ow components and ow connections. The least complex network that the solver will work with includes a zone node and two boundary nodes connected by two components (see Figure 11.1).
component component

boundary node zone_node

boundary node

internal unknown pressure; internal known pressure (rarely used); boundary known pressure (rarely used); boundary with wind induced pressure (air only). A ow node has one temperature just as the volume of air associated with a thermal zone has one temperature. Typically there will be a one-to-one mapping between thermal zones and ow nodes. Internal nodes can either take their temperature from a thermal zone or they can be dened to track the temperature of a specic ow node. Lets call the former real nodes and the latter extra nodes. Wind induced boundary nodes represent wind pressure at one point on the facade of a building. It is a function of the wind velocity, direction, terrain, building height, surface orientation and position within the facade. Typically, a ow network would include a boundary node for each location where air may ow into a building. Good practice places a boundary node at the height of each opening to the outside. If you follow this pattern the process of locating ow components representing the opening is simplied. Pressure coefcients The jargon we use to express changes in pressure due to changes in wind direction is a pressure coefcient Cp. In ESP-r, Cp values for standard angles of incidence (16 values to represent 360) for a specic location are held as a set. 170

Figure 11.1: The least complex network. Flow Nodes Nodes in a ow network are measuring point for pressure, temperature and rate-of-ow. These bookkeeping entities are of four types:

ESP-r has a database of Cp coefcient sets for different types and orientations of surfaces derived from the literature. Lets be clear about this, one of the greatest points of uncertainty in ow simulation is in the derivation of pressure coefcient sets. Some groups reduce this uncertainty by undertaking wind tunnel tests or creating virtual wind tunnel tests via the use of CFD. ESP-r offers a so-called Cpcalc function to generate pressure coefcients but it is one of those places where dragons live. Wind Speed Reduction Factors The ratio of the climate wind velocity (usually at a standard height of 10m) and wind in the locality of the building is known as the wind speed wind reduction factor such that
V = Vclim x Rf

Rf is calculated from some assumed wind speed prole and accounts for differences between wind measurement height and surrounding terrain (urban, rural, city centre) and building height and surrounding terrain. Wind proles can be calculated using three different models: power-law, LBL, logarithmic. Caution is advised in the use of Rf values as the proles they are derived from are invalid within the urban canopy. In such cases, it is advisable to use a small value for Rf in cooling/air quality studies and high values for inltration heating studies to represent worst case conditions.

11.3.1 Flow components Flow components (e.g. fans, pumps, ducts, cracks, valves, orices etc.) describe the ow characteristics between ow nodes. Flow is usually a non-linear function of the pressure difference across the component based on experimental and analytical studies taken from the literature. ESP-r has a set of in-built ow components including ducts, pipes, fans and pumps as well as cracks, orices and doors. Generic xed volume or mass ow components as well as quadratic and power law resistance models are also included. Details of the methods used are included in the source code in the folder src/esrumfs. Some commonly used components (reference numbers in brackets) are: Power law volume ow (10) can be used where ow is well described by a power law Self regulating vent (11) is a European vent to embed in a window frame which moderates ow across a range of pressures Power law mass ow (15 & 17) can be used where ow follows a power law. Quadratic law volume (20) and mass (25) can be use where ow follows a quadratic t. Constant volume ow (30) and mass ow (35) are abstract representations of a fan (can be controlled to approximate variable speeds). Common orice (40) can be used for openings with a user dened discharge coefcient 171

 Specic air ow opening (110) has a xed discharge coefcient and only requires an area. Specic air ow crack (120) is useful for openings up to 12mm wide. Bi-directional ow component (130) is useful for doors and windows which are door shaped where temperature and pressure differences can result in ow in two directions. Roof outlet/cowl (211) is based on measurements of typical ceramic units found in Europe. Conduit with converging 3-leg (220) and diverging 3-leg (230). There are lots of parameters needed to describe this and dragons live here. Conduit with converging 4-leg (240) and diverging 4-leg (250). There are lots of parameters needed to describe this and dragons have been sighted here. Compound component (500) points to two components e.g. an opening and a crack with parameters needed for control actions. 11.3.2 Flow connections Flow connections link the nodes and the components via a descriptive syntax that takes the form: boundary node south is linked to internal node ofce via component door. A connection also denes the spacial relationship between the node and the component e.g. that a oor grill is 1.5m below the node. If nodes and connections are at different heights, then the pressure difference across the connection will also include stack effects. 172

Good practice places a boundary node at the height of each opening to the outside. If you follow this pattern the delta height is zero for components from the point of view of the boundary node. In the upper part of Figure 11.2 is a crack under a door that connects to zones (where the zone nodes are at different heights). In the lower part of Figure 11.2 is a representation of a sash window (where there is one ow component representing the upper opening and another representing the lower opening. The sash window is associated with two separate boundary nodes.
door zone_node !1.5m !1.2m zone_node

crack under door

boundary node sash window boundary node zone_node

Figure 11.2: A crack under a door and a sash window. Some people nd the syntax used to describe the relationship between nodes and components a bit of a challenge. Here is one technique that works for quite a few users.

Imagine yourself at the position of the ow node (e.g. in the centre of the zones air volume) and looking at the component. If you are looking horizontally then the height difference is zero. If you are looking up then the height difference is positive. If you are looking down (e.g. to the crack under the door) then the height difference is negative. For example, if a zone node is at 1.5m above the ground and the lower window opening is at 1m above the ground and the upper window opening is at 2.1m above the ground. Look at the lower window opening from the point of view of the zone node it is 0.5m below the zone node and at the same height as the lower boundary node. The upper window opening is 0.6m above the zone node and at the same height as the upper boundary node. Path to boundary The other rule about creating networks is that every internal node must somehow have a path to a boundary node. The solver treats air as incompressible (for all practical purposes) and the solution is of the mass transfer within the network. When the temperature changes the volume must change and if the pressure has no point of relief then the solver breaks. The design of the network must take this rule into account, especially if control applied to components would have the effect of totally isolating a node. The risk of breaking the rule increases with network complexity so the Cookbook emphasises working procedures 173

which are robust enough to scale with the complexity of the models we create. Parallel and sequential connections Figure 11.3 is a portion of a network which uses a common orice to represent the window when it is opened as well as a parallel path with a crack. If the window is controlled and open then the crack has little or no impact on predictions. When the window is closed then the crack becomes the connection to the boundary node. Recent versions of ESP-r support the concept of a compound component which is made up of, for example, an opening and a crack. The use of compound components can simplify ow networks by reducing the need to parallel connections.

window crack window zone_node boundary node

compound window & crack boundary node zone_node

Figure 11.3: A crack & window and a compound component.

Up to this point the networks have been linked via a single component or components in parallel. Suppose we wanted to open a window if the temperature at the zone node was above 22C AND the outside temperature was below 19C. How might we implement the above AND logic? One technique is to use components in series. If zone_node is linked to boundary_node by component window and we wish to insert a second component control it would be necessary to create extra_node, assign it to track the temperature of zone_node. The new ow component control should be of a type that would present little resistance to ow when open. The existing connection would be re-dened and the second connection in the sequence would be created as in Figure 11.4. The window component would take one control logic and the control component would take the second control. The original window crack connection would remain.

ow actuator. If we observe ow rates oscillating it is usually in indicator that we need to shorten the simulation time step. 11.4 Steps in creating a network The ESP-r Cookbook recommends a methodical approach to the creation of network. It is possible to design networks of dozens of nodes and components which work correctly the rst time. Plan carefully and then implement the plan! Successful practitioners use the following set of rules: Rule one sketch out the network either as a 2D layout or as a 3D overly of the wireframe view of the model Rule two give informative names to the nodes and components on the sketch and use these same names when using the interface Rule three identify portions of the network where control will be applied Rule four if there are likely to be design variants, use overlays on the sketch to lay out alternatives and ensure that the sketch provides a summary of the intent of the overlay Rule ve if there is room on the sketch include critical attributes of the components, if there is not ensure you separately record component attributes before you start on the interface A good sketch is worth hours of debugging - trust us on this! 174

window crack window zone_node boundary node control extra node

Figure 11.4: Use of additional nodes and components for control When control is imposed, consideration should be given to adjusting the simulation time step to take into account the response of the sensor and

ESP-r does not graphically represent the network (yet). The sketch makes it easier to interpret the story told by the names of the nodes and components. When we plan a network we should account for how ow is induced or restricted, where control might be imposed as well as where we expect there to be differences in air temperature within a building. For example, if you believe that a perimeter section of an ofce will often be at a different temperature consider creating a separate zone for the perimeter. Some practitioners include additional vertices in the model and subdivide oor and ceiling surfaces in their initial model so that it is easy to subdivide a zone at a later stage. Experience indicates that last minute subdivision of zones can take longer than one might expect and require time for testing that has not been budgeted for. The design of the ow network should take into account what-we-want-tomeasure. Typically there is a one-toone matching of internal nodes and thermal zones. However, if there were many openings in a room on the east and to the south facades and we were interested in the aggregate ow at each facade then we might plan a network which had extra internal nodes as shown in Figure 11.5. In the sketch the west node and east node nodes take their temperatures from zone_node.

boundary node boundary node east_node zone_node west node boundary node

boundary node boundary node boundary node

Figure 11.5: network with extra nodes Linking the nodes and components is a critical step which benets from a methodical approach as well as consistent pattern for typical relationships. A good sketch is still worth hours of debugging! In deciding which components to use our initial task is to review the features of the available components and control options which can be applied to them as well as their data requirements. There is also the option of browsing existing models which include ow networks and running assessments and reviewing the predictions. A great way to understand how ow works is to take these exemplar models and systematically adapt the network and/or control description and observe the changed performance.

175

examination reception

Node Crack_under_doof Crack_at_wingow Window

Figure 11.6: simple network for doctors ofce mortar would not change the thermophysical state of the wall, but the air moving through the crack might be noticed. In ESP-r the description of the zone and the ow network can differ as long as we remember the intent of the difference. Air can also ow around the frames of the windows. It is difcult to know if there are differences in the leakage paths of the three horizontal windows. For this project lets assume that they have the same leakage characteristics. There are three locations on the facade with these windows - but each can be represented by the same crack component. The north window is a different size and lets assume that it has a different leakage characteristic so that needs to be a different component. 176

11.5 A simple network To illustrate the process lets create a simple network for the doctors ofce that you worked on earlier. Where could air ow Air can ow under the door between the reception and the examination rooms. When we created the initial zone a decision was made to exclude the door as being unimportant in terms of the overall heat ow in that portion of the building. An entrance to the reception would be place where air would ow. Does this require that we go back into the geometry and add a door? Not necessarily. Consider if there was a 5mm crack in the wall. The handful of missing

The next issue is how long is the typical crack and where is it. If we wished to be pedantic there are cracks at the top and bottom and left and right of each window. For this exercise lets assume the crack is along the centre line of the window and is the same length as the width of the window. What kind of window opening? If someone was to open a window then there might be ow IF there was someplace for the air to go. A mass ow network has limitations when attempting to represent single sided ventilation. In some cases it is possible to use a bidirectional component to represent a window (there are arguments in the community about the validity of such an approach). If two windows are opened the driving forces are better represented within a mass ow network. Depending on the size and physical details of the opening there are several ow components which might be useful. And before we look at the component details it is worth considering whether the windows in this doctors ofce will be operated by the staff and whether they will do this with a predictable logic (e.g. will they open the window if it reaches 22C and will they open the window fully)? For this project lets start with the assumption that we will eventually want to test out a window opening regime that involves opening the windows twenty ve percent. We can include the relevant components in our planning so that they will be easy to include at a later date. How the 177

window operates will determine the types of ow components we should use as well as the connections we establish within the ow network. ESP-r offers a pre-dened window component which only requires the opening area, it also includes a common orice which requires an area and a discharge factor. If one had the data the opening could be a polynomial or a power law. A sash window is two openings and some users also represent a horizontally pivoting window as two separate openings. Some windows have an width to height which is similar to a door and in that case some users may decide to use a bi-directional ow component (more on that later). For now, lets use the air ow opening component and assume that the component is centered within the window surface. What kind of extract fan? Air can be induced to ow by an extract fan. And here our choices begin to expand because there are both abstract and detailed components for the extractor. And since there are times when the extractor is not required we will need to control it. Early in the design process our tactic should be to conrm whether forced ventilation in the doctors ofce will help and the magnitude of the ow required and perhaps the turn-on set point. This is most quickly accomplished via an abstract volume ow rate component and a simple control law. Once we conrm the general characteristics and response of the building we can consider whether a specic fan curve should be applied to the model.

What kind of room? What else might require our attention? Looking back at the dimensions of the doctors ofce the sloped ceiling of the examination room increases the volume of the space and raises the centre of the air volume in comparison to the examination room. The earlier decision to represent the examination room as a single volume of air which is wellmixed (i.e. at a single temperature) does introduce an element of risk because there will be times when the air near the peak of the ceiling is at a different temperature to the occupied portion of the space. Given the initial design brief the single volume decision was appropriate. If the question becomes occupant comfort and ne-tuning of window opening or extract fan use then a subdivision of the physical space into multiple thermal zones could be done. For the current project lets not alter the zones. When we sketch out the network we will need names for the nodes and the components (Figure 11.6). At some point we must record the attributes of the components so that this information will be available when we create the network and we will also want to pass our notes to the person checking the model. This is also a good time to get out a calculator and focus the project manager on the geometry of the zones so that we can record the height differences between the nodes and components. The table below provides several of the relevant dimensions: Component names and locations. 178

node name - type height reception - internal 1.5m examination - internal 2.25m south - boundary 2.375m north - boundary 2.375m exam_north - boundary 3.75m exam_extract - boundary 3.0m east - boundary 0.1m component name - type data long_win - air ow opening 1.0m2 long_cr - crack 5mm x 3.0m door_cr - crack 10mm x 0.8m upper_win - orice 1.5m2 0.5 coef upper_cr - crack 5mm x 3.0m extract - volume ow 1 air change node - to - node component south to reception via long_win south to reception via long_cr north to reception via long_win north to reception via long_cr east to reception via door_cr exam_north to examination via upper_win exam_north to examination via upper_cr reception to examination via door_cr examination to exam_extract via extract height differences: long_win is 0.875m above reception long_cr is 0.875m above reception upper_win is 1.5m above examination upper_cr is 1.5m above examination door_cr is 1.5m below reception door_cr is 2.25m below examination Which connection comes rst? In addition to what we include in the sketch we also need to consider the order that we link the nodes and components. The connection associated with the extract fan should being at a

zone node and end at a boundary node so that the ow is outwards. For other connections the order is not numerically important. It does help to have a consistent policy with openings to the outside because a ow along a connection is reported as a positive number if it is in the same direction as the connection denition and negative if it is owing from the end point to the start point. If you conceptually consider air entering the building as positive ow then you would choose to dene connections with the outside as beginning at the boundary node and ending at the zone node. Our task is to record our decisions and attributes on the ow network sketch and then to use the interface to rst dene the nodes and then the components and then to link the network together. 11.6 To the keyboard Having planned and recorded the information associated with our network we can now use the interface to increase the resolution of the model. In the Project manager look for Model management -> browse/edit -> network flow and choose flow network (menu) and conrm the suggested le name and then choose make new file and then specify that the network is all air. And you will

the components and lastly the connections between the nodes.

Figure 11.7: interface at start of process Initial nodes Select the nodes option and allow an auto-generation of the nodes for the current zones. The initial list includes the two items shown in Figure 11.8. The auto-generate assumes that each thermal zone will have a node and the zone name is given to the node and the centre of the zone becomes the height of the ow node.

be presented with the initial menu as shown in Figure 11.7. At the start there are no nodes or components or connections and no nodes have been linked to the zones. The descriptive sequence is to dene the nodes rst and then dene 179

Figure 11.8: auto-generated nodes

Figure 11.9: adding boundary nodes

Figure 11.10: the completed components 180

browse network option to review the

data that you have provided. Boundary nodes The next step is to dene the boundary nodes. Do these based on the information in the table above. For each boundary node you will be asked to nominate a surface where the opening is found. This sets the orientation of the boundary node so that wind directions can be resolved. The centre of the surface becomes the height of the node. When asked to conrm the height check the notes (arent you glad you made a note of this). You will also be asked about which pressure coefcient set to use and for this exercise select 1:1 sheltered wall for each connection. The result should look something like Figure 11.9. This is a good time to save the network! Components The next task is to create the components. Do this based on the information in your notes. Each component requires a name and, depending on the type of component, there will be one or more attributes to dene. The order you create the components is not important. When you dene the extract fan as a constant volume ow rate component note the various ways you can dene the ow rate. The air changes per hour is particularly useful at an early stage so use that (which is equivalent to 0.01667m3/s based on the volume of the examination room). When the components are completed they should look similar to that shown in Figure 11.10. Save your network again. You may also want to use the 181 Connecting nodes and components The next step is to link the nodes and components together to form the network. Each connection has an initial node and component and a second node. You are asked to specify the height difference to the component from the point of view of each node. The order you give is not critical except for the extract fan. Flow in the direction of the initial to the second node is reported as a positive number. It does help to have a consistent pattern when dening connections. One common pattern for connections which involve boundary nodes - use the boundary node as the initial node so that ow into the room is reported as a positive number. Some users dene all of the links with boundary nodes rst and then they dene links between internal nodes. Another pattern is in the denition of height differences. The boundary nodes were dened at the height of the opening so that the delta height from the position of the boundary node is always zero. And if a connection uses a component where buoyancy will not be an issue (like the constant volume ow component) give zero as the height difference.

Figure 11.11: the completed connections

7 6 9 1.000 (nodes, components, connections, wind reduction) Node Fld. Type Height Temperature Data_1 Data_2 reception 1 0 1.5000 20.000 0.0000 120.00 examination 1 0 2.2500 20.000 0.0000 60.001 south 1 3 2.3750 0.0000 9.0000 180.00 north 1 3 2.3750 0.0000 9.0000 0.0000 exam_north 1 3 3.7500 0.0000 9.0000 0.0000 exam_extract 1 3 3.5000 0.0000 9.0000 90.000 east 1 3 0.10000 0.0000 9.0000 90.000 Component Type C+ L+ Description long_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.800000012 upper_win 40 3 0 Common orifice flow component m = rho.f(Cd,A,rho,dP) 1. 1.5 0.5 upper_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.a 1. 0.0166670009 +Node dHght -Node dHght via Component south 0.000 reception 0.875 long_win south 0.000 reception 0.875 long_cr north 0.000 reception 0.875 long_win north 0.000 reception 0.875 long_cr east 0.000 reception -1.500 door_cr exam_north 0.000 examination 1.500 upper_win exam_north 0.000 examination 1.500 upper_cr reception -1.500 examination -2.250 door_cr examination 0.000 exam_extract 0.000 extract

Figure 11.12: the ESP-r ow network le Take your time to avoid having to redene connections. For this exercise 182

there are three sets of parallel connections involving the windows and the cracks. The interface will ask for conrmation when you dene the parallel connection. The interface will ask you if you want to auto-generate the connections. For this exercise say no. Hint: as you create the connections, mark your sketch so that your progress is recorded. It is easy to duplicate a connection, or even worse, to miss out a connection. Checking your data The last step is to conrm the linkages between the ow nodes and the thermal zones. Look for the link nodes and zones option in the interface. When you have completed this it should look similar to that shown in Figure 11.11. Save the network again. After exiting the network menu it is also a good idea to generate a new QA report. When looking at the QA report pay particular attention to the Z values for the components. If the two Z values differ you might have made a mistake about the delta height from each of the nodes. The description of the network is written to an ESP-r le in the nets folder of your model. The le shown in Figure 11.12 is for the doctors ofce. 11.7 Calibrating ow models Having added a ow network to the model, lets see if the model will run and then if the predicted air ows make sense. What might we look for? The windows are open so we would expect signicant ows, especially on days with some wind where up to one air 183

change per minute might occur. We want to include in our assessment days that have a variety of wind speeds and directions. We might also wish to identify some days where overheating is likely so that after we add controls to the windows and extract fan we can simulate the same period when we are looking at how window opening or the use of an extract fan might improve conditions. For the initial assessment, select a simulation period of a week in April and reset the simulation time step to 10 minutes.

Figure 11.13: simulation parameters for a spring assessment We we ask for an integrated simulation a number of checks will be

carried out on the model to ensure that it it both syntactically correct and that the model dependencies are correct. During the simulation, if the monitoring is turned on (as in Figure 11.14) the inside temperatures is close to ambient (black line) in the reception (where there is cross ventilation) with higher temperatures in the examination room where the ow is constrained by the single sided ventilation and the crack under the door. Clearly there is a need to control the opening of windows to prevent chilling of the room. Graphs and tables Before adding control to the ow network, have a look at the predictions of ow to see which of the reports or graphs provide useful performance information. Start of the results analysis module and the last simulation predictions will be used. A good place to start is the graph facilities and the Time:var graph where we can look at the energy embodied in the movement of air. Selecting climate -> ambient temperature and temperatures -> zone temperature and zone flux -> infiltration will provide an overview (Figure 11.15). As expected the inltration cooling in the examination room is minimal. The inltration cooling (the energy implication of the air movement) in the reception varies between 0W and 1000W. As the temperature differences decrease the energy implication is reduced. And it is also the case that the volume of ow changes the magnitude of the energy implication. To look at that we 184

need to use a different graphing facility. Use the Network flow -> option and request volume flow rates -> total entering node for the two rooms. The ow rates shown in Figure 11.16 should be similar to the pattern you see in your model. Consider that time spent in the results analysis module working out for yourself which reports and graphs help you to understand the patterns of ow as an investment. Many a practitioner has be caught out by a cursory inspection of ow data! It is now time to introduce some control into our ow network so that windows are only open when appropriate. And if we nd that ows are insufcient then some control of the exhaust fan will be added.

Figure 6.14: temperatures during spring assessment

Figure 6.15: temperatures and air cooling during spring assessment

185

Figure 6.16: temperatures and air cooling during spring assessment to be used by the ow solver at the next time step. Control logic is tested at each time step. If we are approximating fast acting ow actuation devices then the simulation frequency should reect this as far as is possible within the constraints of the project. Currently a one minute time step is the highest frequency that is supported by ESP-r for the zone and ow domains. In terms of the doctors ofce, a 10 minute time step was used in the uncontrolled version of the model. This will result in a slightly sticky control so we should pay close attention to the predictions to see if this is an issue. Flow sensors and actuators In ESP-r a ow sensor is dened by its location and the values which it can sense. These include temperature, temperature difference, pressure, pressure 186

11.8 Flow Control As with ideal zone control, ow network control uses a sensor > controller > actuator structure to dene ow control loops. A control loop senses a specic type of data at a specic location, the sensed value is evaluated by a control law and the control actuation is applied to the component associated with a specic ow network connection. A day can be sub-divided into several control periods with different laws or control law details. A number of control loops can be used in sequence or in parallel to implement complex control regimes. At each simulation time step the ow solver takes the current conditions and predicts the ow. The ow predictions are passed to the zone solver which then generates a new set of conditions

difference, ow rates, humidity, etc. at nodes within the network. It is also possible to sense temperatures in zones or climate data. Most ow components are able to be controlled. Control is expressed as a modication to an attribute of the component. For example, a control actuation value of 0.6 applied to a window with an area of 1.0m2 would result in an opening area of 0.6m2. Control is imposed on specic instances of a component so it is possible to control the south facing window in the reception using different control logic from that used for the north facing window. Flow control laws The range of control laws includes on/off, range based and proportional control as well as a multi-sensor control where the control law can include AND or OR logic from several sensed conditions. An ON/OFF control has a single set point and attributes that determine if the control is direct-acting (ON above set point) or indirect (ON below set point) as well as the fraction of the nominal area to use when ON. A multi-sensor ow control is an ON/OFF controller which includes the denition of more than one sensed location as well as and AND or OR logic to apply. In some cases a multisensor ow control can replace a series of individual controls (as described in Figure 11.4). Range-based control uses the nominal area or ow rate of the component - but 187

switches to an alternative rate/area as a function of the sensed condition - low rate if below low set point; mid rate if above a mid-range set point; high rate if above maximum set point as is shown in Figure 11.17.

Figure 11.17: overview of range based control In terms of the doctors ofce, the initial ow network included window ow components that represented a fullopen state. In reality, occupants would probably open a window only as much as was necessary. Unlike automatic controls, occupants would tend to implement a sticky control (i.e. they delay adjustments). What types of

control could approximate this? ON/OFF with ON expressed as a fraction of nominal opening area this would be equivalent to closing the window below a set point value and open to X percent of nominal area above this value. Proportional control where the percentage opening area varies between two values. Some occupants would not exercise such ne (and continuous) control. Range based control could be used for a control that reduced the window opening area if the temperature in the room is close to the heating or cooling set points. In the dead-band between heating and cooling it would allow natural ventilation cooling by rst using the nominal area of the window and then additional opening area if required. It would be necessary to re-dene the nominal area of the window to represent slightly open rather than fully open. If occupants are manipulating the windows then the control periods should match the occupied period with an alternative control law for the unoccupied period. Some building may operate a policy of limiting window opening after hours to limit the potential for rain damage. If automatic dampers are manipulating the openings then it would be necessary to nd a combination of control law and simulation time step that reected the regime. Hint: once you specify a ow control loop it can be copied and then associated with other ow connections. 188

For our rst implementation of ow control lets use an ON/OFF control for each of the windows allowing them to open 25% of their dened area if the temperature rises over 22C. We will dene the control once and then copy the control loop and associate it with the other windows. And lets turn on the extract fan if the temperature in the Examination room goes over 24C. At night we will keep the windows closed by setting the set point for the windows to 100C. 11.9 To the keyboard... First things rst. Make a backup of your model. To dene ow controls use the Browse/Edit -> Controls network flow and accept the suggested control le name. Begin by editing the description line for the ow control and give a synopsis of the ow controls included. Add the rst loop which will be used to dene the window opening regime (closed at night and weekends and open 25% if over 22C) during 8h00-18h00 weekdays (Figure 11.18).

connection and then the relevant

Figure 11.18: control loop interface prior to adding periods

Figure 11.19: control loop interface after adding periods Select the wkd day type and dene the sensor and actuator for the ow connection for the window on the south of the reception (Figure 11.19). The sensor should be located at the reception ow node. And when asked about the ow actuator pick single flow 189

connection that uses long_win. Next edit the period data for the wkd. The rst period is unoccupied so use a high temperature for the set point. The interface should now look like Figure 11.20. When lling in the data for Saturdays and Sundays there is no need to redene the sensor and actuator (ow control loops use the same sensor and actuator location for all day types and periods). Once all the day types have been dened save the control le. To use similar logic for the north window in reception copy the rst loop and reassign the sensor and actuator. To use this logic again for the Examination room copy the second control loop and re-assign its sensor and actuator. It is a good idea to keep a note of which control loop is for each of the windows. The extract fan is probably a simple design with a thermostat that does not know what day it is. The control should reect this by having one day type and one period. This control will sense the temperature at Examination and act on the connection related to the extract fan. Update the control le, generate a new QA report and look at the details and your notes conrm the data. Re-run the simulation with monitoring turned on and you might see something like the Figure 11.21. Temperatures in both rooms are closer and they are both warmer than ambient. In the results analysis tool the ow entering the Reception is based on the crack component because the temperature did not go above the control set point.

Figure 11.20: control loop period details

Figure 11.21: spring simulation progress with controlled windows has almost no air movement until the extract fan turns on. The energy implications of the window opening is clearly seen if we plot zone flux -> infiltration in the results analysis module. The windows open briey except for the last day where they are open for several hours. The extract fan is also on for brief periods except for the warmest days where it also runs for several hours. 190

Select a warmer period of the year e.g. the rst week in July and conrm the control works. When monitoring the simulation (Figure 11.22) the Examination seems to peak at 24C (which happens to be the set point for the extract fan) and there are some rapid changes in the reception near the 22C temperature point. Because Examination is constrained by ow under the door it

Figure 11.22: warm period with controlled windows

part_frame ceiling part_glaz part_frame ceiling part_glaz part_frame ceiling part_glaz door door high_glz spandral glazing door

manager_bi
bi!glaz frame

manager_t_b
floor frame

glazing low_glz spandral

manager
floor frame

glazing

spandral

Project: Three offices with different window representations.

Figure 11.23: wire-frame of three test rooms The rst exercise used a simple representation of window openings. Many window types require that we adapt the 11.10 Window representations ow paths and components. The folThis section of the Cookbook is worklowing discussion uses a model with in-progress. 191

three adjacent zones (Figures 11.23 and 11.24) which differ only in the window details. The zone named manager has a simple window opening and component. The second zone has a sash window and uses an upper and lower connection to represent this. The third zone has a tall thin window where bi-directional ow is possible and a bidirectional component is used. In this case we will create an initial model in which the windows are in their open position. Because we may later add control the network includes two connections per opening, one for the window and one for a crack that can act as a bypass in case the window is fully closed. These window and crack combinations are seen in many of the example models. As long as the window is open (even partially) the crack has almost no inuence in the solution. If the window closes then the crack ensures that the closed state allows a constrained ow so the solver does not crash. And since windows which have no frame-related inltration are rare the crack component is a better representation of the ow path than dening a very small orice.

192

manager_bi
bi_ext

manager_t_b
hi_g_ext

manager

low_g_ext

g_ext

Basic network with windows

boundary node internal node

Figure 11.24: network in three test rooms which are separately dened. Manager_bi (with a bi-directional Each zone has a window-crack conow opening). The component nection to the outside. The crack (win_bi) is Xm wide, Ym tall, has a component (window_crack) is 2.0m discharge coefcient of 0.6 and the x 5mm and is used many times distance from its base to the adjacent Each zone has a door-crack to an node is X. Because the distance from adjacent space (which is not geometthe base of the door to the adjacent rically dened). This crack compozone node may differ it is necessary nent (door_crack) is 0.8m x 10mm to dene bi-directional components and is used many times for use in different contexts. The adjacent space node should be Boundary nodes are dened at the dened as using the current temperaspecic height of the opening or ture of the ow node in the manager. crack they are associated with. This Manager has one window opening allows a zero difference in height (window1.67) which is 1.67m2 is between the boundary node and the dened once and used once component. Manager_t_b (with upper and lower windows) needs 2 windows (win_up_.884 and win_low_.884) 193

8 6 7 1.000 (nodes, components, connections, Node Fld. Type Height Temperature Data_1 manager 1 0 1.5000 20.000 0. manager_t_b 1 0 1.5000 20.000 0. manager_bi 1 0 1.5000 20.000 0. gl_ext 1 3 1.9500 0. 5.0000 low_glz_ext 1 3 1.1500 0. 5.0000 hi_glz_ext 1 3 2.7500 0. 5.0000 bi_glz 1 3 1.9500 0. 5.0000 adjacent 1 0 0.50000E-01 manager Comp Type C+ L+ Description door_crack 120 3 0 Specific air flow crack 1.00000 5.00000E-03 0.800000 win_1.68 110 2 0 Specific air flow opening 1.00000 1.68000 win_low.84 110 2 0 Specific air flow opening 1.00000 0.840000 hi_win.84 110 2 0 Specific air flow opening 1.00000 0.840000 bi_win 130 5 0 Specific air flow door 1.00000 0.880000 1.88000 0.600000 0.600000 win_crack 120 3 0 Specific air flow crack 1.00000 5.00000E-03 2.00000 +Node dHght -Node dHght Comp Snod1 gl_ext 0.000 manager 0.225 win_1.68 low_glz_ext 0.000 manager_t_b -0.175 win_low.84 hi_glz_ext 0.000 manager_t_b 0.625 hi_win.84 bi_glz 0.000 manager_bi 0.225 bi_win adjacent 0.000 manager -0.725 door_crack adjacent 0.000 manager_t_b -0.725 door_crack adjacent 0.000 manager_bi -0.725 door_crack

wind reduction) Data_2 40.501 40.501 40.501 180.00 180.00 180.00 180.00 0. 40.501 m = rho.f(W,L,dP) m = rho.f(A,dP) m = rho.f(A,dP) m = rho.f(A,dP) m = rho.f(W,H,dP) m = rho.f(W,L,dP) Snod2

Figure 11.25: ESP-r network le for window opening model applied. Hint: mark you sketch as connections are made. Figure 11.25 is a copy of the completed le which includes the attributes of the nodes and the components and connections. When you are working on the network refer back to this listing. 11.10.1 Component selection Which window denition works best? an air ow opening does one-way ow only, so in cases of single-sided ventilation, ow can be restricted; a bi-directional component is intended for doors care is needed in using it in locations such as 194

Nodes can be automatically generated for each zone; data is inferred from the zone (volume, reference height, etc). Internal nodes are usually at an unknown pressure. Dene the boundary nodes to reect the position of the openings in the facade. Ensure your component names match the sketch! A component can be used several places. If control is to be applied - unique names of components and some duplication of components can be helpful (e.g. win_low.84 and hi_win.84). Connections should tell a story! Parallel connections e.g. an opening and a crack - are useful if control is to be

windows; bi-directional ow can be approximated with a pair of air ow openings. Stack effects are accounted for if heights are correctly dened; None of the available components takes into account high-frequency pressure changes which are one driving force in single-sided ventilation. When an assessment is carried out with this model, the simple window opening in the zone manager results in almost no ow. This is an artefact of this component type - ow is only supported in one direction at each time step. The limiting component is the opening under the door. The ow rates predicted for the sash window and the bidirectional ow component are more in line with expectations. This does not imply that simple ow components should not be used. Only that they are a poor representation in the case of single sided ventilation.

195

Figure 11.26: portion of an ofce building The client observation that there are many hours when outside conditions are suitable for mechanical ventilation rather than air conditioning. Are these conditions also suitable for mechanical dampers embedded within the facade to allow fan-free ventilation? The other feature of this design is the treatment of mixed open plan and cellular spaces. Many simulation teams and some simulation tools pretend that there is no air movement between perimeter and core spaces or across open plan spaces. This isolation of the perimeter discounts air transport which allows under heated spaces to borrow heat and spaces that are slightly undercapacity for cooling to borrow cooling from adjacent spaces.

11.11 Schedules vs networks This section of the Cookbook is workin-progress. Now we turn to a practical application of a network within a portion of an ofce building (which includes a reception, conference room, general openplan ofce and cellular ofce). Except for the cellular ofce, each of the spaces are substantially open to each other (the conference room is only occasionally closed). The facade is an older design and is assumed to be somewhat leaky. In terms of learning about air ow networks, the design is a good candidate for exploring options for conditioning of the space, including forced and natural ventilation. 196

Figure 11.27: inltration model within ofce building zone air movement a model variant with zone-to-zone In evaluating whether a ow network linkages and inltration paths (Figrather than a ow schedule is appropriure 11.27) ate: a model variant with zone-to-zone there can be considerable differences linkages, inltration paths and conbetween imposed inltration and the trolled dampers on each facade oripredicted inltration rates. entation (Figure 11.28). in an open plan ofce there are large These three variants are included as inter-zone ows, resulting in heatexample models (if you want. to ing/cooling being borrowed from explore ow issues). Review the model adjacent spaces. documentation, especially the sketches There are three stages to investigate of the ow networks. Compare this the model with scheduled ows and with the contents of the ow network the assumption that there is no intrale and the interface. 197

Figure 11.28: vent model within ofce building direction are now taken into account and there is a moderation of demands Scheduled ows in an open plan ofce as heating and cooling is distributed The version of the model with schedbetween zones. uled ows will yield predictions where Controlled vents and inter-zone ow the energy implication of inltration is Using the model variant with condependant on the temperature differtrolled vents and ow between zones ence and independent of wind speed, and running an assessment (as in Figwind direction and facade position. ure 11.31) indicates that the vents are Predictions will follow the pattern seen open slightly longer than necessary and in Figure 11.29. this has performance implications. The Inltration and inter-zone ow data also indicate that the conference The model variant with inltration and room is over ventilated, perhaps ow between zones transforms the prebecause it has two facade orientations dictions in several ways (as seen in and the cross ventilation is more than is Figure 11.30): wind speed and required. 198

Figure 11.29: scheduled ow performance Take your time when exploring ow results. Discovering approaches which yield clear indications of ow performance is an investment well worth making. The quantity of information can be large and there are several 199 different views of the ow prediction data as well as reports on the energy implications of ow.

Figure 11.30: predicted inltration performance network at a single point in time. Such a feature would speed up the discovery There is one substantial omission in the of patterns within a network. Currently reporting of ow - there is no overview users must manually collect this inforof what is happening throughout the mation. 200

Figure 11.31: predicted facade vent performance some users choose to integrate the results when running the simulation. Flows that oscillate at each time step This removes the oscillation but preare sometimes an artefact of the simuserves the general trend of ow. lation process. If the magnitude of the oscillation is likely to decrease, but there is not time (or disk space) to run assessments at a shorter time step, 201

11.12 Hybrid ventilation In 2000 the Chartered Institute of Building Services Engineers published Mixed mode ventilation CIBSE AM13 (ISBN 1 903287 01 4). This publication dened several types of mixed mode ventilation e.g. contingency mixed mode, complementary mixed mode and zoned mixed mode systems. At the time, there were few options for numerically assessing how mixed mode ventilation worked. The publication was also geared towards regions of the world where there was a tradition of natural ventilation as well as an economic incentive to create buildings which were future proof. One of the critical limitations to the simulation of designs which transition between natural ventilation, mechanical ventilation and full HVAC is the denition of air ow controls. Approximating the response of occupants to discomfort or changes in conditions is potentially complex. The response frequency of dampers and window actuation devices suggests that control logic needs to be tested at a relatively high frequency. Some people open windows while the environmental control systems are active in other buildings there is better coordination. Ideally, systems should be controlled differently if windows are open. Some ventilation regimes may need to sense indoor air quality. In theory, almost any control logic that can be dened via a network of parallel or sequential decision points (see Figure 11.4) can be implemented. The 202

need for additional bookkeeping nodes to dene such logic paths limits how well such controls can be scaled. Extending ow networks to accommodate such logic was more than a linear function of the number of openings and fans to be controlled. Simulating the transition between the modes dened in CIBSE AM13 places considerable demands on the facilities of simulation tools. Until 2008 it was difcult to switch off fans if windows opened, especially if the logic opening the windows was based on both inside and outside conditions. Recent versions of ESP-r include a multi-sensor ow controller. This allows, for example, a window to open if the ambient temperature is within a certain range AND the inside temperature is within a temperature range as in Figure 11.32.

Ambient below 25C AND Zone above 21C AND Ambient above 10C

Figure 11.32: control via multiple states Lets say there was a variant of the two cellular ofces side-by-side that

included two additional zones representing HVAC mixing boxes (one for the left zone and one for the right zone) as in Figure 11.33. Both mixing boxes are controlled to 16C and there is a ow network that can deliver 5 air changes to the ofce if required. This approximates a CV HVAC system in cooling mode. The left zone includes an upper and lower window opening which is controlled based on the logic shown in Figure 11.32. The fan associated with the mixing box uses an inverse description of the window control logic so that the fan turns on if conditions are not suitable for window opening. The right zone uses the mixing box during ofce hours. The return for the mixing boxes is via the corridor. If the left zone is able to open its windows there is a potential savings in fan power as well as cooling. Heat and humidity picked up by the return air stream is represented in this model. Unfortunantly, ESp-r does not report the electrical energy used by the fan ow component so some post-processing is required. The listing of the model control description below (Listing 11.34) shows the zone control used with the mixing box zones as well as the hybrid vent ow control. Looking at the performance of the left zone for one day in Figure 11.35 the time between 8h00 and 15h00 is ok for window opening and there is 300-400W of cooling equivalent associated with the air ow. The delta T between inside and outside is less than 5C so there is not much cooling from 203

air movement. At 15h00 the outside temperature goes over 25C and the windows close and the mixing box is used for a few hours until the outside temperature drops and the windows open again until the un-occupied period starts and both the fans and windows are reset to closed. Looking at the performance of the right zone in Figure 11.36, the CV representation controls the zone in the range of 24-25C. The dotted blue line is the amount of cooling in the mixing box. the dotted brown line is the cooling delivered to the zone. The difference in the cooling demand for the two mixing boxes is shown in Figure 11.37. The reduction in cooling for the left zone clearly indicates that a hybrid ventilation scheme has the potential to save running costs under some conditions.

Figure 11.33: ofces for hybrid vent and conventional HVAC Listing 11.34: control descriptions
Zones control strictly controls plant and plant-B temperature to 16degC The sensor for function 1 senses the temperature of the current zone. The actuator for function 1 is air point of the current zone There 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 1 0.00 db temp > flux free floating 2 6.00 db temp > flux basic control basic control: max heating capacity 99999.0W min heating capacity 0.0W max cooling capacity 99999.0W min cooling cap 0.0W. Heat set-point 16.00C cool set-point 16.10C. 3 18.00 db temp > flux free floating Zone zone zone zone zone zone to control loop linkages: ( 1) manager_a << control ( 2) manager_b << control ( 3) coridor << control ( 4) plant << control ( 5) plant-B << control 0 0 0 1 1

Flow control Windows open and fan shuts down for manager_a when ambient temp is between 10 and 21 degC and room temp is more than 21degC . The sensor for function 1 senses node (1) manager_a The actuator for function 1 is flow connection: 1 man_alow - manager_a via low_win There have been 1 day types defined. Day type 1 is valid Mon-01-Jan to Mon-31-Dec, 2001 with 3 periods.

204

Per|Start|Sensing |Actuating | Control law | Data 1 0.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000. 2 8.00 dry bulb > flow multi sensor on/off multi-sensor: normally closed with 3 sensors: For sensor 1 ambient T set-point 25.00 inverse action AND sensor 2 ambient T set-point 10.00 direct action AND sensor 3 sense node manager_a set-point 21.00 direct action. 3 17.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000. The sensor for function 2 senses node (1) manager_a The actuator for function 2 is flow connection: 2 man_ahi - manager_a via high_win There 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 1 0.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000. 2 8.00 dry bulb > flow multi sensor on/off multi-sensor: normally closed with 3 sensors: For sensor 1 ambient T set-point 25.00 inverse action AND sensor 2 ambient T set-point 10.00 direct action AND sensor 3 sense node manager_a set-point 21.00 direct action. 3 17.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000. The sensor for function 3 senses node (1) manager_a The actuator for function 3 is flow connection: 9 plant - manager_a via fan There 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 1 0.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000. 2 8.00 dry bulb > flow multi sensor on/off multi-sensor: normally open with 3 sensors: For sensor 1 ambient T set-point 25.00 inverse action AND sensor 2 ambient T set-point 10.00 direct action AND sensor 3 sense node manager_a set-point 21.00 direct action. 3 17.00 dry bulb > flow on/off set-point 100.00 direct action ON fraction 0.000. . . .

Figure 11.35: hybrid vent performance 205

Figure 11.36: CV performance

Figure 11.37: CV performance conditions. Temperature distributions within air volumes cannot be determined (e.g. stratication). Momentum effects neglected. Insufcient resolution for local surface convection determination.

11.13 Limitations of Network Airow Models Although network ow models are useful, they are limited for some applications: Large volumes represented by a single node, implying well-mixed 206

Chapter 12

DETAILED FLOW VIA CFD

12 Detailed ow via CFD Given the limitations of mass ow networks mentioned in the previous chapter, research began about a decade ago to extend ESP-r to support higher levels of resolution by incorporating a CFD solver. Although CFD is a mature eld of research, its implementation in building models poses a number of classic problems. First, ow velocities in buildings are low (in comparison to traditional applications of CFD) and likely to be within the transition range between ow that is considered turbulent and that which is considered laminar. The second issue is that boundary conditions such as surface temperatures and air temperatures and driving forces change over time. In buildings the movement of air changes surface temperatures and surface temperature changes alter the ow eld. That our virtual physics models do not represent this well has been a considerable irritation to the simulation community. Conversely, the building solver typically makes rough assumptions about the ow eld within the zone and the heat transfer at surfaces. Even in models which include a mass ow network we can only make crude guesses at the velocity that is implied by a given mass transfer. 208 Clearly, both whole building solvers and CFD solvers would have much to gain by enabling the two solvers to exchange information as the simulation progresses. What has been implemented in ESP-r is a radical approach to a difcult problem. It assumes that boundary conditions will change so it updates its boundary conditions at each time-step. It assumes that initial directives to the solution process may not be appropriate when conditions change and it reevaluates the ow eld to determine if different so-called wall functions should be used. It then creates new directives for the solver to follow to best represent conditions at that timestep and then passes information back to the building solver to use in evaluating heat transfer at the surfaces in the zone. Its default assumption is that the CFD domain is transient rather than static. The solution also takes into account connections between the CFD domain and a mass ow network. This allows changes in pressure or mass ow in other zones of the model to become new driving forces for the CFD solver. And because mass ow networks also include boundary nodes the CFD domain also has information on changes in weather patterns. And time-varying heat sources within rooms

from the zone operations schedules are noticed by the CFD solver and can be associated with blocks of cells.

should be exercised. This chapter will be completed at a later date.

Powerful stuff. And also utterly wrapped up in jargon which sounds like English but means something different. CFD is a place where dragons live. ESP-rs interface to CFD has a steep learning curve. The Cookbook is not a tutorial on the theory of CFD or the so-called conation mechanisms used by the solvers. There are several PhD thesis written on the topic which are available for download on the ESRU web site publications page at <<http://www.esru.strath.ac.uk>>. And there are any number of books on the subject. And the source code associated with CFD is heavily commented and can provide a number of useful clues. If you already have a solid background in CFD and are comfortable with what you found in the literature search mentioned above, then continue reading this chapter. If not, CFD will absorb both computing and mental resources at an painful rate. You have been warned. The chapter includes an overview of the entities and parameters which can be used to dene a CFD domain, methods for designing a griding scheme within the domain, and what to look for in the performance predictions. There are also some information boxes and dragon boxes where particular care 209

Chapter 13

PLANT

13 Plant In ESP-r environmental control systems can be represented as either socalled idealized zone/ow controls or as a network of system components which is often called a plant system. The choice of which approach to take is partly based on how much you want to know about the detailed performance of the environmental control system and partly on how much descriptive information you can acquire about the composition of the environmental control. The Cookbook does not cover the theory of component networks or the solution techniques used. It provides an outline strategy for using systems network facilities. Readers might treat this Chapter as an initial draft as there are many dragons lurking with this portion of ESP-r and there remain many gaps in the strategies. Networks of components offer the following facilities: the psychometric state within components and at points in the network is explicitly computed and is available for inspection interactions between components and/or controls are computed at subminutely intervals can be inspected in this time domain 211 those who have an interest in netuning the response of particular components or control devices within the network have many options for creating models which are close approximations those interested in high resolution of both system components and mass ows can link both the system component solver and the mass ow solver ESP-r provides feedback on the composition of such networks and a wealth of information about what is happening within and between components during simulations (via trace facilities) and different views of the state variables within the res module. Those who master the use of system components are able to address a range of questions that are not possible with other approaches and have access to a rich store of performance indicators. Tactical users of simulation do not rush to create networks of components until they have learned all they can from ideal controls. And they do this because creating networks of components: tends to take longer (more descriptive information and more linkages between components) such networks need tuning like real systems

 such networks fail in similar ways to real systems some system interactions are in the frequency of seconds or fractions of a second and so the volume of information increases greatly. much performance information is in a form that it difcult for many users to interpret the facility requires you to assemble a network that is both syntactically correct and physically correct In comparison with most of the ideal zone controls the use of networks of system components involves a steeper learning curve. Many tasks and much of the quality assurance in models with system components is the responsibility of the users. A methodical approach is essential. Rule one: start with zone and/or ow controls learn as much as possible about the pattern of demands and the likely control logic that is appropriate for the design Rule two: planning and sketches are essential. Rule three: walk before you run test out portions of the network and control options on a simple model before scaling the network. Rule four: document what you do. Rule ve: leave plenty of time for testing. For readers who are approaching the use of system networks in ESP-r with prior experience with component based analysis be aware that all components are entities within a single network. In ESP-r there is no conceptual difference 212

between components representing a duct, a valve, or a cooling tower. There is no concept of central plant and zoneside components. 13.1 Using a network to represent mechanical ventilation Mechanical ventilation is one aspect of building design which simulation can play a role. We will create several models of a mechanical ventilation design to explore such systems respond to changing demands and boundary conditions. The rst approach is to represent all aspects of a mechanical ventilation design within the component network (i.e. it uses a component as a simplied representation of a thermal zone). Although this will not provide a full accounting of the interactions between supply and demand sides it is an approach suited to early design stage questions where little might be known of the zones. Figure 13.1 shows a standard mechanical ventilation system which has a supply and an exhaust fan and a heater coil just up-stream from the supply fan. Two zones are supplied and the extracts from each zone are combined in a mixing box just before the exhaust fan.

Figure 13.1 Basic mechanical ventilation system. After the name of the component is a number in ( ) which is the component index within the plant network. Include this number on your sketch in addition to the component name. Why? Because there are a few places in the interface where you have to type in this index rather than selecting from a list of component names. Most components include an attribute for the total mass of the component. For these exercises this need not be exact. There is also a mass weighted average specic heat which tends to be either 500.00 or 1000.00. Each component also has a UA modulus. These parameters support calculations of how the casing of the component interacts with its surroundings. Ducts have additional parameters, including the length of the duct, crosssectional area and hydraulic diameter. If you pre-calculate these it will speed up your descriptive tasks as well as reducing mistakes (see Rule two).

Planning is essential, even for a simple model. Sketch out your network rst and decide on names for the components. Most of your work within the project manager will involve names of components and numbers representing component attributes and your sketch is essential for keeping track of your work, supporting QA tasks and communicating with clients. After sketching the network gather the component information. The list on the next page contains component information for the 12 components and you should refer to this as you create your network. Components have a sequence - the initial group goes from the returns from the zones to the exhaust and then come the idealized zones and then the inlet_duct to supply_duct. Adopting a sequence which proceeds from the return to the supply can make subsequent tasks easier.

213

Figure 13.2 Components (with attributes shown).

Figure 13.3 Connections between components. 214

The pattern for creating components is similar (see Figure 13.5). When you have nished dening the components you should see something like Figure 13.4. Save your network and take a moment to review the components listed in the interface menu with your sketch to ensure they are consistent.

Figure 13.1 - the heater is supplied by the supply_fan so when you set up a link the rst component in the link is the heater and the second component in the link is the supply_fan. Look again at the list in Figure 13.3 and draw this (a coloured line works well) on your sketch of the network. When this makes sense, start the process of adding connections and noting them on your sketch. The mass diversion for supply_duct ->zone_a and supply duct ->zone_b are 0.5 because each takes half of the output of the component supply_duct. Except for the receiving component inlet_duct, which takes its supply from ambient air, each of the other connection is with another component. When the connections are complete save the network.

Figure 13.4 Finished network. The next task is to link the components together. Linking plant components together is different from linking ow network components together. Clear your mind - the pattern is to begin your focus at a component that receives ow and gure out which component is sending the ow. Referring back to 215

Component: duct_ret_a ( 1) db reference 6 Modified parameters for duct_ret_a Component total mass (kg) : 3.7000 Mass weighted average specific heat (J/kgK): 500.00 UA modulus (W/K) : 5.6000 Hydraulic diameter of duct (m) : 0.12500 Length of duct section (m) : 2.0000 Cross sectional face area (m2) : 0.12270E-01 Component: duct_ret_b ( 2) db reference 6 Modified parameters for duct_ret_b Component total mass (kg) : 1.8500 Mass weighted average specific heat (J/kgK): 500.00 UA modulus (W/K) : 2.8000 Hydraulic diameter of duct (m) : 0.12500 Length of duct section (m) : 1.0000 Cross sectional face area (m2) : 0.12270E-01 Component: mixing_box ( 3) db reference 1 Modified parameters for mixing_box Component total mass (kg) : Mass weighted average specific heat (J/kgK): UA modulus (W/K) :

1.0000 500.00 3.5000

Component: duct_mix_fan ( 4) db reference 6 Modified parameters for duct_mix_fan Component total mass (kg) : 9.2500 Mass weighted average specific heat (J/kgK): 500.00 UA modulus (W/K) : 14.000 Hydraulic diameter of duct (m) : 0.12500 Length of duct section (m) : 5.0000 Cross sectional face area (m2) : 0.12270E-01 Component: exh_fan ( 5) db reference 3 Control data: 0.060 Modified parameters for exh_fan Component total mass (kg) : 10.000 Mass weighted average specific heat (J/kgK): 500.00 UA modulus (W/K) : 7.0000 Rated total absorbed power (W) : 50.000 Rated volume flow rate (m3/s) : 0.10000 Overall efficiency (-) : 0.70000 Component: exh_duct ( 6) db reference 6 Modified parameters for exh_duct Component total mass (kg) : 5.5000 Mass weighted average specific heat (J/kgK): 500 UA modulus (W/K) : 8.4000 Hydraulic diameter of duct (m) : 0.12500 Length of duct section (m) : 3.0000 Cross sectional face area (m2) : 0.12270E-01 Component: zone_a ( 7) db reference 25 Control data: -500.000 Modified parameters for zone_a Component total mass (kg) : Mass weighted average specific heat (J/kgK): Wall U value (W/m2K) : Total surface area of walls (m2) : Zone space volume (m3) : Inside heat transfer coefficient (W/m2K) : Outside heat transfer coefficient (W/m2K) : Outside air infiltration (ACH) :

10920. 1000.0 0.40000 78.000 45.000 5.0000 18.000 0.0000

216

Component: zone_b ( 8) db reference 25 Control data:-1000.000 Modified parameters for zone_b Component total mass (kg) : 7560.0 Mass weighted average specific heat (J/kgK): 1000.0 Wall U value (W/m2K) : 0.40000 Total surface area of walls (m2) : 54.000 Zone space volume (m3) : 27.000 Inside heat transfer coefficient (W/m2K) : 5.0000 Outside heat transfer coefficient (W/m2K) : 18.000 Outside air infiltration (ACH) : 0.0000 Component: inlet_duct ( 9) db reference 6 Modified parameters for inlet_duct Component total mass (kg) : 9.2500 Mass weighted average specific heat (J/kgK): 500.00 UA modulus (W/K) : 14.000 Hydraulic diameter of duct (m) : 0.12500 Length of duct section (m) : 5.0000 Cross sectional face area (m2) : 0.12270E-01 Component: supply_fan (10) db reference 3 Control data: 0.060 Modified parameters for supply_fan Component total mass (kg) : Mass weighted average specific heat (J/kgK): UA modulus (W/K) : Rated total absorbed power (W) : Rated volume flow rate (m3/s) : Overall efficiency (-) : Component: heater (11) db reference 5 Control data: 3000.000 Modified parameters for heater Component total mass (kg) : Mass weighted average specific heat (J/kgK): UA modulus (W/K) :

10.000 500.00 7.0000 50.000 0.10000 0.70000

15.00 1000.0 3.5000

Component: supply_duct (12) db reference 6 Modified parameters for supply_duct Component total mass (kg) : 1.8500 Mass weighted average specific heat (J/kgK): 500.00 UA modulus (W/K) : 2.8000 Hydraulic diameter of duct (m) : 0.12500 Length of duct section (m) : 1.0000 Cross sectional face area (m2) : 0.12270E-01

Figure 13.5 Typical component menu. 217

13.2 Dening containments Components exist in a context (or containment), such as surrounded by a xed or ambient temperatures. For purposes of this exercise we want to attribute each component with a xed temperature of 22C. Figure 13.6 shows what you should expect to see.

you to re-run this assessment without having to look around for scraps of paper. The parameters shown in Figure 13.7 are a good starting point. Once these are set commission an interactive simulation. The simulator will notice that the model includes only a network of components and will solve only a system only simulation. It will request conrmation for using zero start-up days (accept this), the default climate and the name of the results le to be created (write this name down, you will need it in a few minutes). The simulation should take a few seconds. Exit from the simulator and invoke the results analysis module. Note for some versions of ESP-r the initial results le name in the results analysis module is incorrect and needs to be edited.

Figure 13.6 Containments for each component. 13.3 Finishing off the model and testing At this point your interface should look like Figure 13.4. Notice that there is a place for you to include notes (Rule 4) before you forget what this network is about! Next we need to test the model to see if it is complete and syntactically correct. In the simulator interface look for the Simulation parameters option and provide the name of the results le, the period of the simulation and what sort of time-step to use. This allows 218

Figure 13.7 Simulation parameters. The results analysis facilities (see Figure 13.8) for network components allows you to toggle between tabular, psychometric chart, summary statistics, histograms and graphic plots. Items selected will be re-displayed as you switch views. Figure 13.9 shows the temperatures at return ducts a & b and Figure 13.10 statistics of temperature and enthalpy at return_duct_b. Spend a few moments browsing the reports and graphs in search of patterns that indicate how the ventilation system is working. Figure 13.8 Results analysis menu. The diversion ratio of 0.5 from the supply duct to zone_a and zone_b results in the return from zone_b being cooler than from zone_a. Edit the diversion ratios and see if the differences in temperature might be reduced. To save time, note the information for the two connections before starting the edit. And remember to save the component network le to a slightly different name when you make such changes so that you recover the original le. After saving the changes and commissioning another simulation check and see the change in performance (Figure 13.11).

219

Figure 13.9 Graph of return duct temperature.

Figure 13.10 Statistics at return duct b.

220

Figure 13.11 Temperatures in return ducts after adjustment. 2.4m deep x 2.81m high will be equivalent. If all surfaces in the rooms are attributed with the construction external_wall and face the outside then the overall UA will be similar to that of the component representation. These zones are rectangular and have no windows or doors, so the process of creating the geometry and applying attribution is straightforward. One option is to begin a new model and to build up both the zone and component network to match the requirements of the exercise. A second option would be to upgrade the existing model to include the zones and to adapt the existing network of components. Both options have benets and drawbacks and it is well worth exploring both.

13.3 Moving from ideal demands to thermal zone demands In the initial model demands that the mechanical ventilation had to respond to were via component representations of zones. You can also associate a network of environmental system components with thermal zones. In this case we need to add two zones to the model which will have the same volume and surface area and overall thermophysical properties as the component representations. The component zone_a has a volume of 45m3 and a zone which is 4m wide x 4m deep x 2.81m high will be equivalent in volume and surface area. The component zone_b has a volume of 27m3 and a zone which is 4m wide x 221

Figure 13.12 Component control types. want to modify. As soon as the model loads change the root name to mech_vent_2z and alter the model description phrase (as a reminder that this is a different model). The model has no zones, so go to the zone composition and create zone_a and then zone_b based on the information given above. At the end of this process you would see something like Figure 13.13 for zone_a and something like Figure 13.14 for zone_b. 222

For this exercise lets modify the existing model and the rst task is to make a backup copy of the model. If the original model folder is named mech_vent then give the following command: cp -r mech_vent mech_vent_2z Then go into the conguration folder of mech_vent_2z and restart the project manager with the conguration le we

Figure 13.13 Zone a details. between components) to supply_duct -> duct_ret_a (a connection between a component and thermal zone_a). In this case the receiving component becomes duct_ret_a, the connection type is from a building zone and then zone_a is selected from the list of available zones. The next question is about the supply for the zone and this remains component supply_duct with a diversion ratio of 0.5.

Schedules and other attributes The two zones need to be fully attributed in terms of composition and operational details. Keep these descriptions simple - 200W during ofce hours and 0.2 air changes of inltration will sufce. Modifying existing network of components takes several steps: rst make a backup copy of the existing network, second change the connection to supply_duct -> zone_a (a connection 223

Figure 13.14 Zone b details. containments. The same needs to be done with the connection supply_duct -> zone_b to become supply_duct -> duct_ret_b (a connection between a component and thermal zone_b). After these changes have been made the interface will look like Figure 13.15. The next step is to remove the now redundant connections g and h in the above gure and to nally go into the list of components and remove the ideal components zone_a and zone_b. The result will be a network of 10 components, 11 connections and 10 224

Figure 13.15 Connections after editing. ux connection control law (see Figure 13.16). While you are in the control facility there is an option to set (another type of) linkage between the control law loops you just created and the relevant thermal zone. When you have done this save the zone controls. Now return to the network of components and select the item link plant to zone. The control le will have been scanned and there should be two entries, the rst for connected zone zone_a and the second for connected zone_b, both with a convection type connection. The remaining elds dene the nature of the supply and whether there is an extract. The link for zone_a uses the component supply_duct as the supply and the duct_ret_a component is the extract. The link for zone_b uses the component supply_duct as its supply and the duct_ret_b as the extract. The interface will look like Figure 13.17 when this is completed. This is a 225

13.4 Links to zones and controls At the bottom of the network denition menu there is an option link plant to zone. Before we can use this facility we need to dene two zone controls and that requires saving the network of components and changing to the zone controls menu to initialize the controls and then return to the network component interface to complete the process. Perhaps a future version of ESP-r will include a wizard to sort this out... The rst zone control senses the temperature in zone_a and actuates at the air node of zone_a and has one day type and one period in that day and the control type to ux connection between zone and plant but skip lling in the details. The second zone control should sense the air temperature in zone_b and actuate at the air node of zone_b and have one day type and one period with the

good time to save the network of components. You will be asked whether the zone controls should be updated to reect the recent changes in the network of components (say yes). Almost nished. The zone controls need to be adjusted. The linkage function guessed at the capacity of the heater component and will have set the heating and cooling capacity of the zone control to a value which is incorrect (the actual value of the heater 3000W and 0W cooling). Up to this point we have used zone controls to establish the link between the thermal zone and network component domains and some of the parameters in the zone controls (e.g. the capacity) are based on information used during the denition of the network of components. We now have to dene the logic which will drive the heater component and for this we must dene a so-called plant control. There will be one control loop, it will sense node one within the duct_ret_a component and it will actuate node one within the heater component. The controller type is senses dry bulb actuates ux (from within the list shown in Figure 13.12). There is one day type and three periods during the day. From 0h00 to 7h00 the control will use a period switch off control, from 7h00 there will be an on-off control with a heating capacity of 3000W and a cooling capacity of 0W and from 18h00 a switch off control. The selection of control laws (see Figure 13.18) is somewhat terse, but the help message claries the relationship between the control law and the control 226

type. These relationships are required because some components work on ux and some on ow and the actuation needs to reect this. A word about the data for the on-off control period. There are seven parameters: mode of operation (1.00) off set-point (23C) on set-point (19C) output at high (3000W) output at low (0W) sensor lag (zero) actuator lag (zero) When the plant control is complete and saved it is a good idea to generate a fresh QA report for the model. This will provide additional feedback for checking that your model is consistent. After you have reviewed the QA report adapt the simulation parameter sets. Use a 15 minute time-step for the zone solution with the plant simulation at 10 time-steps per building time-step and ensure that there are names for the zone and plant results les lled in. Commission an interactive simulation. If all went well the simulation will take a few minutes to run (the plant is solving every minute). When you go to look at the performance prediction look for performance graphs such as in Figure 13.19. The upper olive-green lines are the heater temperature and ux output (labelled as other). The lines below are the temperatures at various points in the ducts. It is also worth looking at the performance characteristics reports for the zones.

Figure 13.16 Initial zone control settings.

Figure 13.17 Completed linkages between zones and components. parameters is to run a series of simulations typically changing one aspect of a control or a component parameter at a time. This process works even better if a friendly control engineer takes part in the exploration. Certainly an on-off control will result in different performance characteristics to a PID controller, but remember to walk before you run when it comes to PID controllers!.

One of the reasons one might need to use a network of components is to inquire into the internal state of the components so this is a good time to review what is on offer and, importantly, what information about the components are required to recover performance data. One way of discovering the performance sensitivity of networks of components to changes in control 227

Figure 13.18 Component control laws.

Figure 13.19 Performance predictions within model with thermal zones. at the tasks involved. The goal is to employ the most appropriate approach Judging the additional resources to a given simulation project and only needed in comparison with ideal zone using complex facilities where a less controls is best done once you have complex approach does not support the dened a couple of component netrequirements of the project. works and developed some prociency 228

Chapter 14

WORKING PROCEDURES

14 Working procedures Simulation teams who are attempting to deal with real designs in real time sometimes deliver less than they intended or exceed planned resources. There are many reasons for this: missing out a brief, but critical step in a sequence of tasks failure to review a model for inconsistencies as it evolves failure to record critical assumptions failure to locate notes about critical assumptions misunderstanding the nature of the assessments to be carried out failure to constrain model complexity altering model les for a quick change without documenting the change, checking its syntax or running calibration tests assuming that everyone else knows that ext_glas is intended for use on the only the south facade of the building These are self-inicted errors and omissions. Simulation teams who thrive have evolved working practices which limit errors and omissions. If properly designed, working practices can also compensate for the limitations of simulation tools as well as leverage the specic skills of the team. 230 ESP-r is designed for practitioners with strong opinions. It assumes that those who use it are aware of the rules and requirements of the entities used to create models as well as having a methodological approach to the planning, creation and use of models. Thus there are many places where users require guidance and much advantage to be gained in acquiring some of the attributes of opinionated users. Working procedures which encode such guidance and support up-skilling are thus critical to the deployment of simulation suites such as ESP-r. The following discussion is an expansion of ideas that the author and others contributed to Building energy and environmental modelling: CIBSE Applications Manual AM11: 1998 The Chartered Institution of Building Services Engineers, London, April 1998. The denition of QA & QC used in this document extends the traditional risk management and consistency checking found in AM11 to include procedures and organizational patterns that help identify opportunities for delivering additional value to the design process. They are based on a decade of observation of successful and un-successful simulation groups. They form a starting point for creating group-specic and

tool-specic working procedures. Many of these extensions require minimal resources and some are intended to reduce resource requirements. 14.1 How can the vendor help? Vendor marketing tends to emphasize productivity gains and ease of use and their brochures are full of astoundingly complex models. Vendors mount training courses which are optimized for keyboard skills, production tasks and rapid generation of models. They may offer a dictionary lled with details of the entities which can be used to create buildings and systems as well as a range of example models. Less attention is paid to the design of models. Vendors tend to view this as an esoteric skills or as not applicable to their software. Support may be available if you know who the ask and what to ask for. Interpretation of performance predictions is another esoteric skill set which involves domain knowledge, good pattern matching skills (when scanning performance data) and an in-depth knowledge of options for accessing performance data. It is critical in the deployment of simulation but is only lightly covered by most vendors. The design of a simulation tool and its interface impact working practices: Some tools use an if what you see looks correct it must be correct approach. Unfortunately, optical illusions abound in simulation so simulation teams must employ robust procedures to enforce model quality.

Some tools offer only one view of the contents of the model (the interface). Designing working procedures to adapt to the absence of model contents reports is a considerable challenge. Some tools constrain in-model documentation thus links with external documentation becomes an issue for working procedures to deal with. Some tools (including ESP-r) have limited un-do facilities. Techniques (and habits) to compensate for this are essential. Simulation model les are surprisingly fragile. Techniques for recovery are an essential part of working procedures The deployment of simulation must also take into account that simulation tools tend to be designed for individual use rather than team use. The needs of distributed work groups are largely unsupported. The implications of this are far-reaching. Manipulations of models which are substantially robust for an individual can be the cause of systematic failure if models are being accessed by multiple users. Simulation data models are among the most complex dreamt up by humans. One might expect robustness and enterprise class database management tools but this is the exception rather than the rule. It falls to users to manage diverse sets of supporting data. Each simulation tool presents a specic set of challenges. ESP-r provides multiple views of simulation entities and a number of opportunities for documenting models but there are exceptions 231

some limitations on names force users to be terse and networks for air ow and system components lack a graphical display of relationships. ESP-r users must also put up with minimal undo facilities. Although specic examples of working practices are given from the context of ESP-r, users of other software will nd much that is familiar. Adaptations to t the conventions and facilities of another tool are left to the reader. 14.2 Responsibilities within teams Although there are successful independent simulationists, simulation is most powerfully deployed in a team environment. Why would this be the case? Firstly, simulation demands a range of managerial, technical and communication skills. Second, projects can fail if errors in methods or descriptive details are not identied. Self-administered QA is an invitation to risk that is difcult to overcome. Third, simulation tools grown in complexity and it is increasingly difcult for an individual to be procient with all aspects of a tool or to manage the volume of detail in complex models. Individuals can work jointly in ad-hoc teams using some of the techniques employed by teams who are geographically distributed. For most projects, the challenge of a virtual team is not the speed of the internet, but the inability of simulation software to cope with asynchronous manipulation of models, as well as our 232

ability to maintain an audit trail of actions taken. In an ad-hoc or formal simulation team there are a number of participants: The team manager, who works from the perspective of project goals, client requests, resource limits, delivery dates and staff motivation The quality manager, who helps with calibrating the model, ensures the model is t for purpose, that predictions are as expected and who (ideally) is looking for opportunities to add value to the deliverables Simulation staff, who implement the work plan, coerce the tool to ts the needs of the project, commission assessments and carry out production related data extraction and interpretation of predictions Domain experts who advise on the modelling approach and identify opportunities as well as glitches in the procedures Mentors are also ad-hoc participants focused on creating new working practices and augmenting staff skills. Setting up a simulation team is not a trivial task as can be seen in section 4.2.1 of CIBSE AM11. The section on human resource requirements is essential reading. 14.3 Classic mistakes Simulation teams tend to underestimate the time required to create and evolve working procedures. Similar optimism pervades the task of maintaining and

extending staff skills. Bluntly stated - errors and omissions in management are no less important than errors and omissions in technical execution. First there is the classic mistake of confusing keyboard prociency with the recognition and delivery of useful insights into the performance of a design. Staff who are quick and have good domain skills are rare so teams with complementary skills are needed. A variant of this mistake is a belief that user friendly software allows junior staff to function with limited supervision and or limited training. Junior staff lack the self-restraint to avoid complexity and become driven by the tool. This ensures that only a fraction of the implied power of the software is realized. The next classic mistake is to rely on raw computing power rather than well formed working practices and well designed models. Yes, there are cases where computer power limits productivity, and the majority of simulation tasks are constrained by other factors. Another classic mistake is to equate the ability to generate reports and graphs with an understanding of the patterns within reports and graphs sufcient to add value to the project. Valuable patterns within a data set can remain hidden just as errors can pass unnoticed. Just because the tool interface includes a WOW feature, you still need a good reason to select it. Auto-generation or auto-sizing should not be invoked on a casual basis until the team reviews such facilities. 233

A perfect storm for a simulation team is a manager who gives an inappropriate directive to a novice who either does not have the background to recognize the directive is suspect or the condence to request clarication. The novice thus works very hard at digging a hole for the team to fall into and lack of attention ensures the pain is distributed.

14.4 Planning simulation projects The author once had a consulting project to evaluate whether mechanical dampers could be used in the facade of an ofce building to provide natural ventilation during transition seasons. The model included eight zones, internal mass, shading devices, two variants of air ow network and three control schemes. How much resource should be allocated for such a task? How long should a client expect to wait for feedback? In the even, a synopsis of the ndings was available ve hours after the plans and sections were rst opened. This model was converted into an exemplar and can be browsed from within the project manager in the real projects category of exemplars. This was possible because the rst hour and a half was devoted to planning the model: establishing what needed to be included in the model dening the extent of the model and its resolution establishing critical co-ordinates in plan and section planning the zoning of the model review available construction databases and identify additional elements needed planning the sequence of tasks that would limit error and allow for entities to be re-used planning the calibration tests to be carried out

sketching out the model, deciding a naming strategy sketching out the air ow network and gathering relevant data reviewing an exemplar model which used the same control logic With this information the task of creating the initial cellular ofce and facade elements was straightforward and attribution proceeded without interruptions. It was then possible to re-use these elements in many other parts of the model. There was no need to use a calculator or pause during the input process because all of the critical dimensions and attributes were available for checking. About one and a half hours was spent creating the model and a half hour was spent in calibration. The remaining time was living with the model and testing out different damper controls and drafting the synopsis. Spending one third of project resources for planning and data gathering is, for many groups, a typical approach to limiting the risk of delays and errors later in the process. The following table includes number of issues which may confront simulation teams in the planning stage.

234

Core issue Does the client/design team have prior experience with simulation based assessments? Does the client/design team know the types of performance data and reports which can be generated? Has the client used language or provided sketches that indicate beliefs about how design will work? Simulation can test such beliefs. Has the client indicated what criteria would signal success?

Related issue Prior experience eases the educational task otherwise client expectations could be an issue. Management of reporting expectations. Identication of how interim results can be communicated. Test beliefs is as soon as they are noticed. Create focused models which can deliver information with minimal delay. What value for each criteria? What additional performance data might be captured to help calibrate the model? What magnitude/frequency of change? What are likely modes of failure? What needs to be measured to identify risk?

Actions Ensure time and resources for clear communication with the client. Brief the client on the nature of the information they will be asked to provide. Review client preferences and clarify potential misunderstandings in deliverables.

Conrm if typical data for the type of building if available. Create a test case to conrm that staff have captured the essential characteristics of the design.

Investigate whether the client criteria provide useful indicators for future what-if questions.

Has the client indicated what criteria would signal failure?

Conrm criteria are in keeping with current practice or are client-specic. Evaluate likely assessments that will test how robust the design is. Identify operational regimes or boundary conditions that would help identify risks. Conrm if staff can cope with multiple models and/or model variants. Clarify how are different models or variants to be identied.

Is the design team searching for improvement on a range of issues or a single issue?

Multiple issues might require several models or model variants.

235

Core issue Are what-if questions in the form what happens if we use a better quality low-e glass or what happens if we use product X? Do what-if questions pose parametric questions (e.g. which skylight area between 12 and 36% is the point where cooling demand escalates)?

Related issue Is the role of the simulation team in the design process to provide information for others to make decisions or is it pro-active? Resources for parametric studies must be carefully considered. Early conrmation is essential.

Actions Identify methods might to identify a better quality low-e glass. Raise the issue of wither a supplied specication is appropriate and in the clients interest. Conrm tool supports the creation of model variants. Discuss whether it will be necessary to generate scripts to automate parametric tasks. Conrm the automation works and extracted data is correct. Consider if methods are reusable. Conrm if staff have the skills to adapt existing models. Conrm the existing models documentation. Review procedures and staff resources against the current resource allocation. Consider if staff tasks need to be adjusted. Consider if additional staff required. Plan for contingencies if staff become ill. Review details of similar projects. Review criteria for deciding on whether to bid. Ensure that presentations and sample reports are available if the client needs to be briefed.

Is this project similar to previous projects? Can we adapt a past model for this new project?

What did we learn in the previous project? What were the difcult issues in past projects of this type?

Does the current state of the model reect the ideas and concepts developed during the planning stages? A potential project will be discussed with a client in a meeting tomorrow.

Is the complexity of the model consistent with the resources allocated? Have the resources used matched the initial plan? Who should take part in the meeting? What is the near-term work load? What key phrases are important to listen for? How much do we need this project?

14.5 Team manager It is critical that someone considers the broad sweep of issues within the project as well as the clients goals. Few 236

can manage the mental leaps needed to shift from the detailed focus of simulation use to a broad perspective. Ensure that simulation staff have access to someone who is paying attention to these other perspectives.

The team manager may be appointed on project basis or hold the position for a number of projects. Individuals may rotate positions - in one project they may act as the team manager, in another they may carry out simulation tasks and for another they focus on quality issues. Flexibility has several benets: It allows ad-hoc teams to be formed with the best available talent. It ensures that staff who have a broader range of skills and have opportunities to exercise those skills. It ensures distributed knowledge of the resource requirements for specic simulation tasks. It distributes strategies for solving design problems. Remember, others in the design process may know very little about the work of simulation teams and what information they can deliver. If the simulation team has sufcient condence to allow others into the process, there are signicant opportunities for both parties to discover concepts and ideas that will be of mutual benet. And one of the benets of interactive working is that it gets around the rigid structure of formal reports and the inevitable ltering of topics. Fifteen minutes of browsing performance predictions (the ESP-r results analysis tool is specically designed for interactive use) may uncover patterns that would not have been included in a report or which might have taken hours to format for a formal report. 237

Staff rotation and interactive working with others in the design process also prevents the isolation and dead-end horror stories that many simulation staff experience in some companies. Another type of exibility is in the selection of the most appropriate tool for the task. While it may be possible to coerce your preferred tool to carry out a range of tasks, the lack of choice may impose a cost. Simulation teams should review the capabilities and cost-of-use of each simulation tool and develop selection criteria. The costs associated with acquiring and supporting multiple tools should take into account whether staff are able to cope with multiple tools or if additional staff are required. Project planning should consider whether there will be a need for a mentor or one or more domain experts. Early warning of a possible request can reduce the risk of such people not being available. They may provide useful feedback to the project. Consider if an expert is needed to help with a crises, would if have been less costly to have retained them at the start of the project and perhaps have avoided the crisis? 14.6 The quality manager Just as the author of a book needs an editor to help complete the story, those who work on models nd it difcult to recognize whether the model continues to be for purpose, whether the latest performance predictions are providing a consistent story or include a new pattern which needs attention.

Good pattern matching skills and eye for detail are core competencies. A traditional approach is for quality managers review reports generated by others and request clarication from staff. And what if the quality manager did not have to wait for others? A quality manager who uses simulation to review models and generate reports about the models breaks a classic dependency. For many simulation tools the skills necessary for browsing a model and invoking a pre-dened simulation can be acquired in a few hours. Additional time is needed to become comfortable with reviewing performance predictions and generating graphs and reports. Productive quality managers will have evolved strategies for reviewing models as well as reviewing simulation predictions. They will have strategies to ensure that they can track the activities of others or track the evolution of models so as to identify points of interaction. Just as in nancial markets there is a moral hazard in expecting the quality manager to catch and solve all glitches. The quality process only works if others in the design team take steps to reduce risk as models are initially dened and evolved. Other chapters in the Cookbook were written from the perspective of reducing errors as creating models are easy for others to understand. Quality managers appreciate models that tell a clear story. One task of the quality manager is to be a champion for the exploration of 238

value added issues. This requires tracking the progress of the project and ensuring, where possible, that there is time available for speculative explorations. Efciency gains in planning and model generation should be directed at freeing up time to live with the model and explore its performance and thus better understand how it works. Typically the quality manager will have a list of classic questions and issues to explore within the model. If there is an early peak Monday demand is it possible to use an optimal start regime? Is there excess heat stored in the fabric of the building overnight? Check if a night ventilation purge or extending the running hours of the environmental control system will correct this. Are conference rooms subject to rapid overheating if the room has full occupancy? Test is massive partitions dampen temperature swings and improve comfort? Does the environmental controls short-cycle. Check if reduced capacity will correct this. Is the building over-capacity in terms of heating and cooling? Check how many additional hours over the set point occur during a season with a 5% reduction and compare this with the reduced capital and running costs. The table that follows illustrate some of the issues that confront quality managers.

Core issue Is the current project similar to a past project?

Related issue Is there valuable information in the project notes and documentation? Do staff remember useful/critical issues from that project? What might be valid approaches? Can a simple model support explorations prior to full scale implementation? Should the mentor be called in? Does the client talk about the project using phrases that could be embedded in the model? Are the essential differences in model variants communicated by the naming scheme? Does this documentation identify issues to be resolved prior to work starting? Are staff keeping a log of actions, assumptions made and information sources used? Does the actual complexity of the model match the initial plan?

Actions Discuss ndings with the team manager as well as the simulation staff. Review the past models with the team and identify critical issues to be tracked in the current project. Review criteria used to identify best approach. Find out who needs to work together to test the approach. Conrm points in the work ow where interactions with the quality manager are needed. Conrm if the simulation tool copes with the naming scheme? Consider whether manufacturers names for products are appropriate. Conrm which performance data presentation form matches client preferences. Conrm what client documentation should be incorporated in the model. Advise on who should embed this documentation. Show the model to a third party and see if they understood the essential attributes of the model. Investigate if delays in tasks could make it difcult to keep to the plan. Ensure updates to the model have been broadcast. Outline value added issues that need to be discussed.

Are there design issues in this project which are new to the simulation team?

What naming scheme will clarify the model to others in the design team? Is the client visually oriented or number oriented? What documentation has the client provided?

Does the client require a record of the tasks undertaken and the method(s) used? Does the model continue to reect the initial plan? Are there resources available for value added explorations?

239

Core issue The model predictions indicate 15% less heating capacity - is this an error or is this an opportunity? During checking it was found that occupancy in several rooms was less than specied.

Related issue What changed in the model? Who made the change to the model? Who can corroborate the difference? When did this happen? What performance data could be at risk? What design decisions might be at risk? Where are opportunities for making the design work better? What is likely to be the next issue that the client will ask us to consider?

Actions Identify other performance data which could be inuenced by this change. Investigate further changes change to the model to further improve performance. Check wither the planned occupancy density or the model details are correct. Review how predictions change when the occupancy is updated. Broadcast the changes. Revisit the assessments looking for performance improvements. Investigate modications needed to explore new topics. Employ a focused model to check if an alternative approach works better.

The project is slightly ahead of schedule what do we do now?

14.7 Simulation staff Traditional deployment of staff involves junior staff primarily working to create models, run assessments and extract performance data under the direction and guidance of senior staff. There is a place for novices in a wellformed simulation team and there are valuable tasks they can perform if they have access to a mentor and there is frequent and close supervision. Senior staff often provide oversight and mentoring. There are also times when it is cost-effective to involve senior staff in the creation and evolution of models. It is certainly the case that senior staff will notice patterns in performance predictions which will lead to value-added deliverables. And one 240

of the best ways to pass on such skills is to ensure that others in the team are able to observe this magic happening. The critical issue for successful deployment is to complement the keyboard skills of staff with domain knowledge, pattern matching skills and risk recognition skills. Inexperienced staff are unlikely to appreciate the dependencies within the simulation tool (between different entity types and between different assessment domains). They may misinterpret the jargon within the interface as well as the instructions given by senior staff. Experienced staff must continually remember that: their knowledge about thermophysical relationships that guide their decisions abut modelling and their

use of simulation tools many not be known by others their successful navigation of simulation tool facilities and interfaces relies on assumptions and relationships that others might not yet know their imagination of a time-line of tasks required to reach a particular simulation goal will probably require quite a bit of effort to translate into clear instructions which others can act on their instruction may be taken literally Pattern matching skills are mentioned as one of the up-skilling goals. Pattern matching skills can be acquired and they are useful for a range of tasks from detailed model checking to model calibration and testing of design ideas. Its part of everyones job. It is implicit in many simulation tasks and working procedures can clarity what to look for the tool interface, model contents reports (see Section 15.9) as well as in performance predictions. There is a surface labeled re-door which is made of the same construction as the laundry room door - is this possible? The operational documentation mentions a computer server but the schedule indicates considerable off hours - which one is correct? Shading patterns were calculated for all ofces on the west facade except for oor three. Did we miss something? The heating demand peak during startup is four times the value during the rest of the occupied period. Is 241

this expected? Are there alternatives we should explore? The simulation time for the last set of assessments took only half the time of the prior assessments - did something change? Risk recognition takes many forms and provides many opportunities to compromise or enhance deliverables. There are dozens of points during a simulation project where a reality check is needed and dozens of possible triggers that staff can be trained to notice. The time taken to accomplish a task is out of expected bounds. The fourth step of the standard procedure involved a system crash. This was attempted a second time and also failed. The predicted comfort (or other performance metric agreed for the project) in the meeting room has changed. The performance of the cooling (or other environmental control) is not what we expected The southwest corner ofces on the fourth and fth oors are performing very differently One of the pattern matching list examples (above) was noticed. There is a considerable overlap in pattern matching and risk recognition. Pattern matching often involves the discovery of relationships - if we see key word W in an error message then we forgot step X; if the shape of the heating demand prole looks like this then Z; if the largest heat loss path in the surface energy balance is north

facing windows then investigate Y. Experienced simulationists will recognize these patterns. They might assume that others will also notice such patterns and conclude (inappropriately) that silence from junior staff is a sign that progress is as expected. To avoid the perfect storm mentioned earlier, ensure that simulation staff are able to buy-into the goals of the project and encouraged to creatively evaluate directives and provide feedback as pattern matching and risk detection triggers are noted. The following table includes typical issues which confront simulation staff.

242

Core issue What preparation is needed for this project?

Related issue Are we clear about the clients ideas that the model should conrm? Have we done similar work in the past? Do we have test models for this building type? What running cost/control issues? What comfort/air quality issues? Are thermal bridges an issue? Which best-practice performance indices? Can a previous project act as a benchmark? What operational and climate conditions would be a good test?

Actions Meet with team manager to review client requirements. Sketch likely approaches to the model and review with the team Review past projects and identify if one can be adapted. Review past models for use in testing ideas and techniques For each domain identify what needs to be measured. Dene the level of detail required. Identify likely interactions between domains. Review standard literature and past reports. Consult working procedures for suggested tests. Identify climate pattern(s) and operational characteristics to use in tests. Embed appropriate simulation directives in the model. Review past projects with team manager. Plan a series of proof-of-concept models as a benchmark. Review with mentor. Review required tasks with staff. Ask staff for time estimates for preparation and model creation tasks and review with the team manager.

What analysis facilities are required to support the project?

What model calibration approaches are appropriate

How much time will it take to create the model?

Is there a record of resources from similar projects? Is this a crank-the-handle or exploratory model? What staff would work well in this project? What staff productivity can be assumed?

243

Core issue What model variants might be needed?

Related issue What other questions might the client pose? Is the current model at the edge of the tool facilities or staff skills? Are changes directed by new information provided or are they general parametric variations? What is the distribution of occupancy patterns? What portions of the building are sensitive to the facade? What variants of control logic might be used in different sections of the building? Is stratication an issue? Is cross-ventilation or air ow between rooms likely?

Actions Discuss what other topics might be addressed with variants of the current model. Estimate resources needed to increase or decrease the resolution of the model. Review current model complexity in each domain and discuss. Use a test model to conrm automation facilities or scripts. Report ndings to team. Using separate overlays sketch out regions for occupancy (density, schedules), control (logic, schedules), perimeter sensitivity, air ow connections, system types and control-ability. Unify the sketch overlays for initial ideas. Work out an alternative sketch of zones taking into account likely future issues. Sketch scenarios for air ow networks and revise zoning to accommodate.

What zoning pattern should be used in the model?

14.8 The mentor Different groups have different denitions of mentor: A person who has mastered the simulation software and helps staff to become comfortable with features which tend to be viewed as either magic or where dragons live. A person who has undertaken simulation projects of the scale, complexity and mix of domains which are being considered by the simulation group (to provide guidance). 244

A person who knows the physics of a design issue and who works with a team to help dene strategies and evaluation criteria (e.g. a domain expert). A person retained to carry out extended training within the simulation group, typically to assist the team to enter a new market or work with different types of clients. Mentors may be part of the team or consultants who are retained by the team via a support agreement (X hours over the next 3 months). Skill sets may be focused (e.g. they know how to

design and deploy air ow networks for large spaces) or broad (e.g. they have managed and/or delivered similar projects). Sometimes simulation teams engage a mentor to explore new topics or explore an alternative way of working within an active project (and want to limit their risks). In such cases mentors usually are given the authority to take over tasks being carried out by staff if that is what is required to guarantee deliverables. In other cases a mentor may be on-call for brief consultations because their experience allows them to quickly answer questions or demonstrate a technique. This could be done in person or via a video conference. One rapid approach to evaluating simulation methods (and tools) is to identify a recent project and explore one or two issues in the project via the use of simulation. Participants would then compare what simulation delivers with the prior ndings in terms of resources required, skills needed as well as a comparison of predictions. Recent projects are especially good if staff remember the approach they took and have access to the underlying project data. The mentor can both guide the simulation team and help them to understand the predictions from simulation. The following table includes issues from the point of view of the simulation team and from the mentors point of view.

245

Core issue Team: The project starting next week involves X. We have limited experience - how shall we proceed?

Related issue Is this a topic that the mentor deals with? Who needs to be involved in the discussion? Do we upgrade or use our standard approach? Is this in the interest of the group to improve this skill? Does the mentor handle this issue? Is this issue dealt with via a standard training course? What does the mentor need to understand about the group in order to evaluate that project? What methods could be use to test alternative approaches?

Actions Specify the issues, points of confusion, time frame and goals. Identify staff to work with the mentor and clarify their goals. Dene upgrade or discard policy. Check if this caused delays or errors. Check if new skills will free up time for other activities or help other team members. Get time/resource estimate from mentor and check for time scale and cost of the vendors course. Create a synopsis of the project for review. Review synopsis with design team and get initial feedback. Re-enact the project to identify faults Identify relevant staff. Agree a timetable for review, reenactment and work sessions.

Team: Fred is not satised with how he works with facility X.

Team: time estimates were out by 30% in the last project. Is there a different approach that would work better?

14.9 The domain expert When the primary concern is to solve a technical issue or evaluate performance simulation teams often retain the services of a domain expert. The domain expert may know little about the specics of the simulation tool but will likely have strong opinions about the information used to dene the entities associated with their specialty as well as opinions of what they expect to see in performance prediction graphs or reports. The domain expert differs from the mentor in that the goal is to solve or 246

understand a project based issue rather than adapt the teams working practices or improve staff skills. Teams may hope that the domain expert will supply a disinterested second opinion for a contentious issue within a project or help verify that current predictions are in line with expectations. The domain expert may also have an opinion that their approach and their own software are the only possible ways to deal with a specic issue. If there are several valid approaches then interactions with the expert can become complicated. They may or may not provide information in support of their approach or let others vet their

software. The other classic point of confusion comes from the imbalance in information and communication skills. The issue which lead to the expert being called is so normal and obvious to the domain expert that they may stumble in their explanations to others who do not share this knowledge. If the suggested approach is valid and the simulation tool does not support that then there are several options: check to see if the simulation tool can be adapted check if the simulation tool can approximate the approach suggested by the expert introduce another tool into the project subcontract the work to the expert if the project is dependant on this issue being resolved and it cannot be resolved within the time or resource limits of the project consider withdrawing The following table includes several scenarios related to experts:

247

Core issue The expert and the team use different terminology.

Related issue Are both we talking about the same issue? Is the terminology different because there is a difference in the underlying approach used by the expert and by the simulation tool? Is the information available? Is it in a form which can be understood? Is there an example model which demonstrates this issue?

Actions Show the expert a list of common denitions of the jargon used within the group and within the simulation tool. Arrange for a meeting to discuss underlying methods and terminology. Scan the source code for relevant blocks of code or pass the question to the software vendor. Scan the documentation for relevant sections and/or ask the software vendor if there is additional documentation. Set up a session to explore relevant models to conrm if a) the expert understands, b) the expert agrees with the facility within the software.

The expert asks to know how the simulation tool treats a specic issue.

14.10 Infrastructure Much of the productivity of simulation experts comes from a combination of quick access to information as well as clear clues as to its tness for purpose. Take away ether speed or clarity and productivity suffers. Simulation relies on access to a range of descriptive data about entities in the built environment. These are typically held in databases that the simulation tools access but which are composed of manufacturers product data, test reports, site surveys, extracts from journals and reference books. Typically, only a portion of this infrastructure comes packaged with the software. Much of the value-added for 248

simulation groups is in extending this initial store of data. There is an upfront investment to understand what is initially available followed by populating the databases with data relevant to future projects and then periodic updates and extensions. In groups where a suite of simulation tools is used the tasks associated with infrastructure management must take into consideration the degree of overlap within each tools infrastructure as well as tool specic differences (which can be subtle). Consider whether there is a business case for minimizing differences between tool infrastructures. What we choose to include in our data stores is critical. Criteria for the quality and pedigree of data under consideration for inclusion must be dened. And

how we name these new entries and the documentation we embed is also critical. The introduction of simulation into a business process or a research group thus requires initial decisions on how supporting data is acquired, evaluated, modied to t group naming and documentation standards. Procedures for how data is committed into the infrastructure and then managed on a long term basis must be agreed. Thus, one of the initial points-of-discovery for a new simulation tool is the nature and extent of its in-built datastore. Commercial software tends to be well populated with entities. And these must still be subject to evaluation, adaptation and management. Establishing quality criteria is one of the primary tasks of the Quality Manager. Every thermophysical attribute or component detail is, to some degree, subject to uncertainty. Some data sources are incomplete, for example surface solar absorption may be approximate. At a minimum, assumptions and omissions should be documented (even if this is external to the model). The Quality Manager is also the primary point of contact for staff tasked with data entry. Determining whether an entity in the data store is t for a use in a particular project may require input from senior staff and management. In extreme cases further physical tests many be required. Simulation is also relies on a computational infrastructure. And most groups assume that this is robust until it proves otherwise. The otherwise is sometimes 249

random (e.g. a disk failure) and sometimes is predictable (someone did not keep a safe copy of their work). Both have antidotes. Decide how many person-hours or person-minutes are acceptable as a loss at each stage of the design process and adapt the computational infrastructure and working practices (habits) to reect this. And the next step is to secretly back up a model or a computer and then stage a failure and notice how the group and its infrastructure recovers. One can be creative about the deployment of computational resources. Model creation tasks tend to be bound by the users speed of interaction rather than the power of the computer. A high quality monitor may be more important in model creation than computing power. A fast disk and extra memory is likely to be the critical during assessments and for data recovery tasks. 14.11 Support staff Contributions from technical and clerical staff are an integral part of the infrastructure of simulation groups and should be included in the scope of working procedures. There are a number of tasks associated with acquiring and committing data (e.g. materials and components) which support staff can make valuable contributions. Groups should consider which is likely to result in a robust infrastructure: adhoc data entry by simulation staff (who may be distracted or may have not done this task for several months) or staff trained to follow well-documented

work ow with specic QA procedures? Other simulation tasks also follow established procedures and require a specic set of skills. An example would be the production of an animated sequence of solar shading patterns on facades and specic internal spaces via a visual simulation tool such as Radiance. If done on an ad-hoc basis by simulation staff there is a risk that steps may be skipped or incorrect parameters entered. The resulting animation will not be to the expected standard and valuable time will have been lost. A well trained technician who does such work regularly may be a better choice for such tasks. Another acquired skill is the review of model contents reports in conjunction with the Quality Manager. For each simulation tool these reports tend to follow a xed format and include key words which are recognizable. It is thus a reasonable task to ask support staff to search to the inclusion or absence of specic words and phrases. For example, if a room schedule is documented with the phrase one teacher and 24 students with one laptop computer then there is a limited range of sensible and latent loads to be found in the data lines that follow. The initail task is to note the inconsistency. The follow-up task might be to suggest data which better matches the description or an alternative description which matches the numbers. Delegation of such tasks can improve the work-ow of the group. Delegating a task rst requires someone to pay close attention to and document 250

successful actions and assumptions. The word pedantic is an appropriate description. This is followed by an iterative process of testing and clarication of the procedure until it is t for deployment. Support staff will need to be trained in the procedure and given sufcient time to ne-tune their skills. A good indicator of successful deployment is when technical staff start suggesting improvements to the procedure. Delegation also implies that the group work-ow is re-designed to merge support staff contributions into the design process. Both the Project Manager and Quality Manager will be involved in this step in order to carry out reality checks and broadcast their availability. 14.12 Staff productivity Given the same simulation tool, the same computer type and the same brief, two different simulation staff can use radically different times to arrive at a completed model. What a novice can produce in a frustrating two days, seasoned staff can produce in two hours with a computer which is half as fast. Such differences in productivity are expected and should be factored into the stafng of a project. A tight timeschedule may be best supported by using more experienced staff whereas those with less experience will be more comfortable with a project with less challenging deadlines. When two staff with roughly the same capabilities take radically different times for the same work then this should trigger a closer look. Chances

are the biggest difference will be the strategies employed. Strategies can be learned. If possible, the quality manager should devise task sequences to conrm the skills level, strategies and inventive resources of staff. Simulation staff who are working at the limit of their skills are less efcient and more likely to generate errors than staff who are well within their competence level. Therefore, a well formed working procedure ensures that staff are working at a pace that is sustainable. Simulation staff should be clear about their current productivity and inform management if they are at risk. Staff who are adept at creating models are not necessarily good at noticing inconsistencies in their models. Access to another pair of eyes is essential. This may involve the Quality Manager or a review by a technician who has been trained to identify inconsistencies. It is a challenge to match resources actually used with assumptions made in initial planning. One major contribution of simulation staff to the planning process is to provide realistic estimates of time and computational resources. Keeping notes about the time actually taken for specic tasks should be included in working procedures. Frequent updates to estimates as real data becomes available can help in the management of staff resources. What about time estimates for new (to the group) tasks? One could guess and risk under or over bidding. Or the simulation team can devote some of its resources to anticipating new topics and tasks by compiling background 251

documents, creating exploratory models and undertaking mock projects. Simulation staff should be pro-active and request time (say 2-3 hours a week) for speculative explorations and keep others informed of progress. Remember, it is just as valuable to report a tool facility that is not ready for use as it is to discover an additional measurement which can be included in reports. 14.13 Tool selection The limitations of a single simulation tool have been outlined above. A simulation based group has greater exibility if there is the option to select from a suite of tools to nd the best mix of facilities for the current assessment task. Selection criteria is project specic as well as specic to the stage in the design process. Begin by carefully considering the nature of the project as well as the project goals. Answer the questions posted in Table 1.1 and sketch out (roughly) your ideas for a model. For each simulation tool judge it against the following criteria: Site resolution (the form and scale of the site). Does the tool allow you do describe the impact of adjacent buildings and topography? Are weather data and local wind pressures available? your sketch? Spacial resolution (the form and scale of the building and spaces inside). Does the tool support the complexity found in your sketch?

 Thermophysical resolution (the composition of the building and its response to changes in boundary and internal conditions). E.g. if the building has massive constructions or uses phase change materials does the solution technique support this? Environmental systems resolution (the composition of the systems and controls). Does the system(s) representation match the needs of the project? Is it possible to approximate the buildings control logic? Occupancy, lighting and small power resolution (the temporal distribution of internal gains). Is is possible to represent the interactions between occupants and the building e.g. manual controls? Computational support for the assessment domains required in the project e.g. if details of air movement is of interest is CFD available, if comfort is of interest is there a in-built model of comfort? Do the computations produce the kinds of performance data (e.g. type of data, location of data, frequency of data) to allow the design team to judge project performance? Do you have the necessary supporting information (databases of materials, constructions, optical properties, system components etc.) needed to represent the project in this simulation environment? During the life of the project what additional performance questions might arise? Does the tool support assessments for these issues and are staff skills appropriate? 252

If other simulation environments or reporting tools are being used in the project are there established communication routes for information to pass between the tool suites? Are there sufcient resources in the project to allow this simulation suite to be used? Are staff skills appropriate for this mix of project requirements and simulation tool requirements? 14.14 Summary A well formed working procedure will ensure that staff are working at a pace that does not exhaust their mental reserves. This suggests that all members of the team should be clear about their own level of competence and how much reserve capacity they have. And they should not keep this a secret and there need to be communication channels for such issues. It is a challenge to match resources used for generating and testing models with assumptions used in initial planning. With experience, simulation staff, mentors and quality managers can give close estimates of the amount of time they expect to take. Well formed working procedures will ensure that before a bid is given to the client there is an evaluation as to the tness of the suite of software tools available vis-a-vis the likely demands of the project. There will also be an evaluation of the current skills level in case preparatory work is required.

Chapter 15

MODEL QUALITY

15 Model Quality Simulation teams who are attempting to deal with real designs in real time are confronted by the need to ensure that their models are syntactically correct as well as semantically appropriate for the project. Simulation teams who thrive invest considerable passion in ensuring the quality of their models. They do so to limit risk (a traditional reason for QA and QC). The Cookbook also advocates working practices that provide early evidence of opportunities to deliver additional value to clients. Model quality involves both the facilities of the simulation tool and the skills of the simulation team. Among the most important issues are: designing models that the simulation team can understand designing models that clients recognize identifying faults in models that syntax checks fail to recognize working practices that ensure inbuilt tool checks are used regularly working practices that keep the quality manager in-the-loop working practices that ensure calibration checks understanding model contents reports 254 Semantic checking is related to the design of the model - how it includes and excludes thermophysical aspects of the design. Because it is an art as much as a science it is more difcult to establish rule sets for model design. Here the issues are: models (or tools) that are not quite t for purpose models which continue to be used after entropy has set in models which are stuck in an unusable state 15.1 How can the vendor help? The quality of models begins with the facilities offered by the software vendor e.g. QA reports, documentation, training and in-built software checks. Vendors decisions about in-built facilities have a substantial impact on the resources that simulation teams invest in model checking. Some vendors believe what you see is what you get. Unfortunately, what you see on screen is only one of many possible views of the contents of a model. Here are some examples of optical illusions: A wireframe view can look correct but have reversed surfaces or missing surfaces

 A clever interface may decide to merge adjacent surfaces together - so what is reported is not the same as the user dened. Interfaces may decide to subdivide surfaces or components so that the model includes entities that the user did not ask for. The user may dene a compact description which the tool expands into hundreds of entities which are difcult to understand and even more difcult to adapt. Some software (including ESP-r) provides both information on the screen and model contents reports. Multiple views of a model allows those with graphic interpretation skills and those with report interpretation skills to work together to spot inconsistencies. A good model contents report is a) human readable and b) reect any change to any entity within the model. Simulation tools are imperfect and thus some entities may not be reported, some reports may be opaque or include a insufcient detail. Ideally, tools should allow the user to dene the level of detail for various reported entities as well as which topics to include. As mentioned earlier, independent actions by multiple users cause clashes which are difcult to resolve. If a model is working and some action by another person causes a fault, condence can be badly affected. Of course tools may be imperfect in their implementation of this concept: Some interfaces (like ESP-r) constrain the length of entity names. Terse names are a frustration and 255

occasional source of error. Some interfaces assign names automatically and do not allow them to be changed - unique but arbitrary names can be opaque to the user. Some interfaces do not allow users to name entities within their models - this is unforgivable in terms of the resources required for model checking. Knowing that simulation tools limit our ability to create self-documenting models it is for the community of users to evolve working practices which compensate for such limitations. 15.2 Responsibilities within simulation teams Decisions made by team members as they plan and build models can inuence the resources needed by others to understand both the intent and the composition of models. Some models tell a good story and thus we can quickly use our newly acquired understanding. Other decisions result in models with impose a considerable burden on the design team. Making clients work hard is NOT a protable business strategy. When the client arrives and the model is opened up on the computer screen is there recognition, perhaps after a quick tour, and then a move to substantive issues. Or are there puzzled expressions and the meeting gets hijacked by explanations of how the image on the screen represents their design. This is not an argument for a literal translation of CAD data into a thermal model. Much that is included in CAD

drawings is simply noise in the thermal domain. A client who saw a simulation model with fty thousand surfaces would be justied in asking for the methodology behind this approach to abstraction just as if they were told a box represented the Guggenheim in Bilbao. Consider what simulation looks like from the clients perspective and choose, if possible, design the model to limit their confusion. It may save time. Second Cookbook quote of the day: Self-administered QA brings great joy to someone elses lawyer. Simulation teams of one are viable in the long term only if they outsource model checking. In a team it should be standard practice to outsource the task to another team member after initial checks are made by simulation staff. Changes in stafng can require that models be passed to others in the team for completion. Models risk become orphans if the author of the model works in isolation or uses a different style. A model that is opaque to someone in the team is likely to be even worse for a client. The task of taking another persons model and understanding it well enough to make modications to it is a classic test of working procedures. Projects go quiet for weeks at a time. If a substantial resource is given over to getting back to speed on a dormant project this could lessen the resources available for other tasks. It does not help that the design of simulation software rarely takes into account that many teams are working on several 256

projects simultaneously. Model quality issues are different for each participant in the simulation team. Team manager The team manager has in interest in ensuring that models are t-for-purpose and that staff are working within their limits (and the limits of the tool). A model which tells a good story is one which the manager can more easily browse. And managers who regularly review models can anticipate possibilities as well as notice deadlines slipping. Quality manager Just as the author of a book needs an editor to help complete the story, neither the team manager nor simulation staff are in a good position to carry out this task. The quality manager also has an interest in regular reviews of the work in progress as well as ensuring that the model continues to be t for purpose. Quality managers quickly recognize models which tell a good story from those that do not. Good working practices ensure that simulation staff get this feedback regularly. Even with good working practices errors become embedded within models. Some typographic errors that get past tool checks will evidence themselves in the predictions of performance if we are paying attention. A 10KW casual gain in a room which is supposed to have 2KW may not show up as a temperature difference if the environmental control has an oversized capacity. The review would have to

notice the reaction of the environmental control for this zone differed from other similar spaces. If the only report generated was a total for the building then this change might not be noticed. Some errors can be subtle - selecting the wrong type of glazing for one window out of a dozen windows might alter performance of the room only slightly. The logic of a control which fails for an infrequent combination of sensed conditions may be difcult to spot. Failure to check for site orientation prior to undertaking shading analysis can waste valuable time just as failure to notice that re doors may be installed with fail-safe closing mechanisms (that allow mixing between zones) can alter assumptions about ventilation in buildings. The simulation team should consider the frequency and types of error can exist without altering the patterns of performance to the point where a different design decision is made. Checks by simulation staff are likely to spot some types of errors but others only become apparent by their impact on predictions. There are benets in the quality manager being pro-active in the project and using simulation tool facilities to review models, generate model contents reports and review performance predictions. Such investigations need not be a burden in time or computing resources. The skills necessary for using the tool to carry out these tasks can be acquired in a few days. Another pro-active task is to work closely with others in the team to 257

ensure that model quality is a continuous part of the model planning and creation process. The quality manager might also devise task sequences to conrm the skills level, strategies and inventive resources of simulation staff. The denition of the quality process used in the Cookbook places emphasis on identifying opportunities as the work progresses and here a pro-active quality manager can take a primary role. The quality manager can also be a champion for reserving project resources for the exploration of value added issues. Simulation staff The traditional deployment of staff involves junior staff primarily working to create models, run assessments and extract performance data. The critical issue for model quality is self restraint. Accepting default names for entities saves a few seconds but requires that others expend effort each time they browse through the model or look at performance reports. Simulation staff are continuously making decisions and assumptions. For example - a quick decision to go with the standard concrete oor thickness in the database rather than conrming the actual thickness in the model might be valid approach at the time. It becomes problematic if it persists and the decision is forgotten. Unconstrained keyboard skills of novices can wreck havoc. Novices need active support from others who have more evolved opinions about the thermophysical nature of buildings and systems. If those with opinions take

the time to pass on ideas then novices will be better placed co-operate when they start their work. Topics that experienced users may forget that novices do not know are: Information required from the client at different phases of the work Benets and drawbacks of different tools, time and computational resources for different tools. Ideas about how design issues might be represented Ideas about zoning strategies and level of detail Ideas about past models to review Simulation staff should spend 2-3 hours a week exploring new working practices or generating scripts to automate processes. This investment may result in better procedures and better models. Domain experts and mentors The domain expert will likely have strong opinions about they see in performance prediction graphs or reports. Subtle patterns may be easy for them to recognize. The trick is to get the domain expert to also look at the model and the performance predictions with a view of further tweaks that could be made to improve performance or to conrm that the prediction is in line with expectations. Mentors can play a pivotal role in enabling staff productivity and ne tuning working practices that ensure clarity in models. Prior experience with similar projects may allow the mentor 258

to be among the rst to identify where models are providing unexpected results. Mentors engaged to explore new topics or explore an alternative way of working will likely be part of the team updating procedures and helping to adapt simulation tool facilities. Musical chairs In another section of the Cookbook it was suggested that occasional rotation of tasks within a simulation team can be useful. Rotation of quality assurance tasks has several benets: A fresh pair of eyes can notice in seconds what has been evading others for hours. Conversations needed to conrm what is this are instructive for both participants. An appreciation how different designs of models impacts model checking tasks can result in better models. 15.3 Model planning There are many steps between a simulation model that looks like a CAD model and a simulation model that is simplied beyond recognition. The thermophysical nature of a space which is reasonably represented by one hundred surfaces is not ten times better if a thousand surfaces are used. And because increasing complexity requires more than a linear increase in resources much thought is required to arrive at an appropriate model resolution. This said, a small increment in model complexity may provide sufcient

visual clues so as to reduce the effort needed to understand a model. Models that clients recognize help them to buy into the process and it often simplies reporting requirements. This might be as simple as including visual place holders for columns and desks or including a crude block representation of adjacent buildings. Other aspects of model design are covered in sections 1.4, 2.3, 3.3 and 4.1. In each of these sections the emphasis is on the planning stage and working out ideas in sketches rather than on the keyboard. Entity names A tool might be just clever enough to name the 27th surface in the zone which is vertical Wall-27. The author of the model knows the surface is the partition_to_corridor and probably knows several other attributes of the surface. The interface presents the initial guess for editing, ve seconds of typing would make this clear. Accepting the default forces everyone else to work hard to understand what Wall-27 is each time it is selected from a list or included in a report. It also slows down their use of selection lists and reduces the time delay and error if the wrong item is selected (or deleted). The Cookbook quote of the day is: Names are the rst step to understanding and essential to owning ideas. Names like hmeintrt_1 might be derived from horizontal mass element intermediate oor type instance one but almost no one else will appreciate this baggage. If a client talks about 259

room 1.12b then use that name in the model. The second Cookbook quote of the day is: attribute names rst and follow consistent patterns Recording assumptions As we create and evolve simulation models we make dozens of seemingly trivial decisions and assumptions which soon pass from our memory. If these are not recorded there can be adverse impacts. One of the driving forces for software development is to ensure that the internal data model of the simulation tool has space available to record decisions and assumptions. The existence of a dialogue for explaining the intent of an occupancy prole does not ensure that it is used. The quality manager has an interest in self-documenting models and working practices should set standards for how decisions and assumptions are recorded. Placeholders Entities in simulation models require lots of attribution and the information required may not be available when required. The use of place holders for data not yet conrmed (e.g. creation of an approximate construction in the database) is a valid way of continuing to get work done. Working procedures are needed to ensure that such pragmatic actions are followed up and the model is updated as better information becomes available.

Who does such updates, the frequency of reviews, and decisions about who needs to know that changes have been made are all items to include in a wellordered working procedure. 15.4 Complexity The evolution of software now allows simulation teams to create models which are closer approximations to the built environment and these models often involve a level of complexity which would not have been contemplated a few years ago. Our attempts to create better models is tempered by our ability to manage such models. One of the unexpected problems with software which is designed to be both user friendly and over-functional is the level of self-restraint needed to create models which match the needs of the project. Facilities intended as productivity aids can easily seduce the user into an overly complex models. Those who are unprepared for complexity multiply their workload as well as the risk that errors and omissions will go undetected. Preparation includes the evolution of working practices in projects of increasing complexity. Another investment is to allow staff to gain condence in projects of increasing complexity. Clarity in the design of models reduces the attention required for many tasks and is essential within complex models. Ensuring that the model is correct is, for many practitioners, the critical limit on the complexity of their models. Reviewing a literal representation of a hospital complex with hundreds of rooms to certify the correctness of 260

thousands of entities is, at the least, an iterative task. Each iteration focuses on a different aspect of the model and/or its performance. Spot checks are a useful step in ensuring the quality of models. Quality managers will develop techniques for scanning model contents reports as well as techniques for reviewing the model form and composition with the tool interface. A classic point of failure is to allocate time for reviewing model contents but not for commissioning assessments designed to identify semantic errors. Techniques that hi-light semantic errors tend to focus on short period assessments where patterns in the operational regime and boundary conditions should result in expected patterns of response. Finding expected patterns is usually cause for celebration. The risk is in cutting short our multi-criteria assessments because we are in a good mood rather than concluding the assessments when we have reached a holistic understanding of the design. In addition to evolving skills and working practices to cope with complexity, successful simulation teams also are able to recognize when complexity can be avoided. During model planning consider whether a design must be represented as one simulation model or whether it can be sub-divided. Subdivision can take two forms - multiple models which combine to the whole of the building and models which contain a selected portions of the building. There are cases where a fully explicit representation is required - for example in a naturally ventilated building where

air ow patterns are widely distributed. In many buildings there is considerable repetition and little to be gained by describing all rooms. The technique requires that the constrained model embody both the typical and exceptional elements of the design. Selecting what can be omitted from a model is a critical step in the planning process just as determining scaling factors is in the calibration phase. And the benets can be considerable and many simulation groups use such scaling techniques in their projects to conserve the resources needed to create, run and extract data from their models. Another technique to re-allocate resources for semantic checking is to employ scaling techniques to the assessments carried out. Limited duration assessments (e.g. typical fortnights in each season along with extreme weeks) which are carefully scaled can result in predictions that are very close to predictions of brute-force annual simulations. This technique is especially important for simulation tools such as ESP-r which are disk intensive during the simulation and data extraction phases. 15.5 Multi-criteria assessments As mentioned elsewhere in the Cookbook, time gained by good working practices can provide a reserve of time to explore model performance. The more complex the model the more multi-criteria assessments are essential for discovering unintended consequences of design decisions as well as errors and omissions within the model.

So where might one begin the process of gaining condence in a model? Well founded opinions as to what should be happening within the building (or access to such opinions) is a rst step. This may take the form of information from similar projects, tabular data in handbooks, access to a mentor or expert or to measurements in this or similar buildings. The next step is familiarity with tools and techniques for extracting performance data in forms which clarify what is happening within the virtual physics. In workshops for ESP-r, the time allocated for exploring model performance tends to be at least as long as for the model creation tasks. Both interactive investigative skills and the automation of data extraction are part of the process. The following list includes some useful indicators: the range of dry bulb temperatures in each zone and the time of the maximum and minimum AND frequency bins to conrm the number of extreme occurrences the difference between dry bulb and mean radiant temperature and if extreme do further checks for surface temperatures the range of heating and cooling demands and time of peak occurrence AND a frequency distribution of demand the number of hours heating and cooling is required AND the number of hours when zones are oating in the dead-band casual gains in each zone either as statistics and as a plot to conrm if 261

lighting is switching as expected graphs of zone temperatures and zone environmental controls to see if an optimal start or stop might be useful, if there is heat stored in the building overnight or if a modular system might be appropriate statistics and graphs of solar entering the zones to conrm that windows that look like they are facing north actually do face north when a zone catches your attention check its energy balance for the type of heat transfer associated with big gains and losses The time of occurrence is mentioned above because a peak temperature during ofce hours may be very different than a peak temperature when no one is in the building. Frequency bins are mentioned because a peak demands for a dozen hours in a season may not be a good indicator of system capacity and extreme temperatures that are rare may be amenable to demand-side management. Experts will also re-run transition season assessments without environmental controls or with reduced capacity for environmental controls. Why? Because buildings can often be comfortable with little or no mechanical intervention. The traditional focus on system capacity tends to ignore performance during the hundreds of hours of mild conditions that happen in most regions. A few moments to create a model variant to conrm this can result in signicant value to the client. Another trick of the experts is to gather statistics for the occupied period as 262

well as at all hours. Why? Because attention to after-hours performance provides clues for improving the design of the building and its operating regime. Some simulation tools such as ESP-r can be driven by scripts to automate the recovery of the data mentioned above. There are two common approaches: recording the keystrokes used during an interactive session into a scripts to automate subsequent checks dening an Integrated Performance View (IPV) for the model and using this to invoke specic assessments and recover the multi-criteria data. The use of scripts is covered in an Appendix of the Cookbook as well as in the Automation section in a subsequent page of this chapter. Setting up an IPV is a topic not yet included in the Cookbook. Working at the edge Most experts plan their work and their models to avoid the computational and complexity limits of their tools. A failure to anticipate the likely course of the project is a classic way to run short on options. ESP-r is compiled with specic limits of model complexity and it is worth checking what the current limits are during the planning stages. It may be necessary to re-compile ESP-r if you want different limits (there are alternative header les available for different model resolutions that have been tested). The Install Appendix provides information about this. Some simulation tools are written to allow models

to grow in complexity without having to re-compile, and there are still limits that knowledgeable users avoid. Models which have been extended towards the limits of the simulation tool reach a point where productivity can suffer and where dependencies within a working model can be broken and errors introduced. There are many possible vectors for this, some involve actions by the user and some can be gaps in the logic of the software. Caution and paranoia are useful attitudes. Backup the working model as a rst step. Generate a full model contents report and extract a range of performance data for use in comparisons with the revised model. Talk to others about their experiences of managing complex models and for advise on where simplications can be made before altering the model. Plan the sequence of tasks, make frequent backups, carry out calibration runs on the revised model and check these against the initial performance predictions. In addition to the overhead of working with large models there is a cost in computing time, generation of large performance data sets as well as the time needed to recover performance data. Each simulation tool and data extraction technique tends to have a point where the burden becomes noticeable. Users dependant on Excel for data presentations typically test the limits of column and rows in tables. XML documents tend to become slow to parse and graphs can become unreadable. The ESP-r is disk intensive. Data extraction gets progressively slower as 263

result les approach one Gigabyte and can be unstable after that point. A large project with a dozen design variants and ve minute time steps can take a morning if not a weekend to process. Thus, the design of the model and the design of the assessments and data recovery tasks are topics to be considered in the planning stages of the project. Some projects may require a compute server or several workstations to provide timely information to the design team. The option of larger disks and more memory can help reduce the time for data recovery tasks. To see which approach is most appropriate carry out tests on an existing model of similar complexity. Entropy is a word that begins to describe parametric studies. So much is invested in setting up a base case model that can be adjusted to reect the various design variants. If after testing and running the scripts the whole edice can be destroyed by demands to alter the base case and re-run the assessments. ESP-r has the exibility to be used for parametric work but the distributed le structure can make it difcult to make global changes to dozens of models and the potentially hundreds of les that support such models. Automation Using a simulation tool interface to apply multiple changes to a model can be frustrating. Some users hack their model les and some use scripts to perform parametric changes to models. While such actions can save time they

are also a potential source of subtle errors if dependencies are not resolved. Some practitioners make fewer errors than others when creating model variants. A critical review of the order of the tasks and the checks that were done to limit errors resulted in a create model variant facility within ESP-r. As seen in Figure X, the user who wants to create a model variant selects topics from a list and the code determines the related dependencies and manages the model les so that subsequent changes do not corrupt the initial model. ESP-r includes functions to search and replace instances of a specic construction within the model or to alter attributes of surfaces associated with a named list (also called an anchor list). There are also functions to rotate or transform the model which requires that a number of dependencies be managed. Other global changes to models may require editing of model les by a sequence of manual tasks or the use of scripts. Experts tend to test their scripts on a duplicate of the model or a portion of the model prior to use. In all cases the working procedure should insure that the altered model is scanned by the tool to see if errors are detected. It is also a good idea to generate a new model contents report and compare that with the initial model. Some parametric changes require more than a substitution of key words and names in model les. For example, removing a surface requires that many relationships within the model be reestablished. It also results in 264

calculations for shading patterns and view factors becoming obsolete. Simulation tools are designed track these dependencies and attempt to resolve them. A user generated script might have difculty duplicating all of the tasks. Consider whether the script might be re-written to invoke the tool interface to carry out these tasks. In many cases the logic within the tool can be generalized so that the same action that is carried out interactively can be driven from an alternative interaction or command line directive to the tool. Because scripts can be fragile and difcult to maintain it is worth checking with the software vendor to see if it is possible to revise the tool to support such modications. For open source tools such as ESP-r there are many options for evolving the code to accomplish standard tasks. 15.6 Semantic checks Ideally we design models to be no more and no less complex that is required to answer the current design question. If we are clever our model will also be designed to answer the next question the client will ask. A model which is overly simple may fail to represent the thermophysical nature of the design. A model which is overly complex absorbs resources which may not be sustainable. Thus we need to design tests to determine whether the model represents the essential characteristics of the design and is likely to deliver information at acceptable condence levels. One form of question follows the pattern: buildings of this type tend to XX when YY

happens - If heating stops at 10h00 on a sunny cold winter day we expect to see the little immediate change but perhaps a gradual drop in temperature until 15h00 when solar radiation levels drop. - If cooling stops at 15h00 on a hot day we expect an immediate rise of 3C and then a slow rise until about 20h00. - During a Monday morning startup after a cold weekend we expect to see full demand for 2.5 hours followed by a drop to about 40% of capacity when the set-point has been reached. - If we double occupancy in the conference room we expect the cooling system to cope for one hour and then the heat absorbed in the walls should cause comfort to degrade. - If we constrain heating capacity by 15% we expect a half hour longer to warm up and to nd eight hours below the heating set-point during the month. These questions are based on expectations of a specic circumstance. The expectations might be in the form of a pattern description, a statistic or a frequency of occurrence. Whether we are able to write down an expectation in advance or are able to construct an opinion as we look at the performance predictions or are unable to make a semantic judgement is largely a function of background and experience. This points to one of the reasons that simulation is difcult for students. They are only beginning to form their 265

ideas about how buildings and systems work and their pattern matching skills are also in development. Conversely, well designed virtual experiments can be an excellent learning tool for students. They have access to the thermophysical state of everything at each moment of time and by changing a few numbers they can undertake another experiment and look at the differences. Guidance for students is essential (and a critical weakness in the provision of simulation). It is also endishly difcult to design a good virtual experiment. The good news is that pattern matching skills can be acquired. The typical form of question involves a scenario dened in terms of a few hours or days (one exception involves a month). A graph or report covering a short period is quick to produce and its density of data is more manageable and thus it is possible to overlay other performance data to see what else is happening at the same time or just before our point of interest. Missing from the above list are questions ending with "we expect 29.5 kWhr/metre square/year heating". Why. Firstly, it implies an annual simulation. We want to delay computationally intensive checks until we have gained condence in other aspects of the model. Secondly, what is being measured is derived from the performance of dozens if not hundreds of entities and their interactions. A reported value matching our expectations does not necessarily bestow condence in the underlying entities. An unexpected value provides few clues as to the underlying cause but does

present us with a massive pile of data to sift through. Again, lets rst focus on performance indicators with fewer dependencies. The task for the simulationists is to design a virtual experiment which will allow us to see if predictions match expectations. Some of the questions require a step change to be introduced into the model and some questions imply a base case assessment and a second assessment run with some aspect of the model changed. Of course we will keep a copy of the unaltered model so that we can continue with standard assessments after the semantic checks have been run! Of course we will remember to include in our models labels that will remind us of which semantic check we are working on and to clearly identify which graph or report fragments are associated with that test! Some semantic checks can be carried out by reviewing the clients questions and considering the underlying physics involved. If, for example, the design is sensitive to the distribution of solar radiation within rooms then a review would usefully look at the pattern of surface temperatures during the day vis-a-vis the distribution of radiation. A design goal to make best use of solar energy for heating while controlling summer overheating will likely require careful attention to geometric resolution and the constructions which are used. To nd out if additional geometric resolution (e.g. subdividing walls and oors) yields better predictions then the same room can be represented by three zones at different resolutions. 266

What is learned from this exercise can be applied to the full scale model. If control of blinds was also included then switching patterns would also be checked. But in this case it may be necessary to compare against the same room without the blind control. Indeed, to clarify the impact of ideal zone controls or system component control a variant model without the control or with a simple control is often the most efcient approach and working procedures should ensure that such model variants can be quickly created or are maintained as the work progresses. The result of a semantic test might be that the model is predicting a pattern of performance for that scenario that is a good match with out expectations. Brilliant. Do other parts of the building exhibit this same pattern? Is this something to tell the client about? With each scenario is increasing condence in the model, adding to our understanding of how the design performs and if that performance is in line with the initial ideas of the design team. Because the issue is focused it is possible to convert our newly acquired understanding into a story which is easy to deciminate to others. The result of a semantic test might also be confusion. What was see is not what we expected and the task evolves into determining if our expectations were ill-founded, the model does not, in fact, support this kind of assessment, the model includes errors, or if our virtual experiment has yielded some new information and a new pattern for the design team to understand. Methods for dealing with this are covered in

Chapter X. Clearly the resource required will be some function of the complexity of the model. If a simulation team is confronted with a new kind of building or system and anticipates the need for rigorous syntactic and semantic checks then there is a business case to be made for working procedures that highlight expected or unexpected performance as early as possible and with the least resources consumed as possible. Focused initail models and focused semantic checks are one way to conserve project resources. With a general tool such as ESP-r there are usually several possible designs of the model. In the planning stage a series of constrained models of different approaches can be created to identify the most promising approach. Some simulation teams will have a range of test models available or will have procedures for setting up test models. The working practices chapter recommends that simulation groups invest in exploratory approaches and in the creation of models for testing future design process issues. An example enabling a suite of models to test sensitivity is the sequence of models in the technical features group of exemplar models distributed with ESP-r. These represent the same pair of cellular ofces and a corridor at different levels of resolution and with different simulation facilities enabled. A semantic check may also be triggered by an unexpected performance prediction. Why is this room several degrees warmer than expected? 267

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 the idea of causal chaining of energy balances in the early 1990s. It involves identifying the dependencies implied by a thermal event and working back down the dependency tree to isolate the form of energy transfer, which if corrected, will alter the initially noticed thermal event. Models which have evolved many times in response to changes in design focus may include details which are no longer relevant or at an in appropriate level of detail. A critical review may be in order to determine if a fresh start will be more productive than further revisions. Another classic point to evaluate a fresh start is when the client poses a new what-if question. The resources required to carry on with a not-quite-t-for-purpose model should be judged against the cost of designing and implementing a model for the new design question or parametric study. An example is the quality of light in rooms. Generating daylight factors to roughly assess whether the back of a room will be perceived as dark is a very different question than is there glare at the head of the conference table. Daylight factors are much less sensitive to the geometry of the facade than the requirements of a glare assessment. One is essentially independent of time and the other is both position and time dependant.

Hardware and human gremlins Think of simulation models as prisoners of war which have a duty to escape (or at least ruin your weekend). There are countless ways for models to be rendered unusable because of corruption, inconsistencies or lost les. Phrases like - I was going to backup this evening compete with I was only trying to make the model work better and there was a power spike become part of the folk history of every simulation group. The intensity and duration of the disruption which follows is determined by the robustness of our working practices. Making backups is not rocket science. It is amazing how a delayed holiday brought on by a disk crash can change work habits to the point where the loss of a half hours work is considered a failure within the group. For every type of computer and operating system that ESP-r runs on there are utility applications available to create archives of model folders. In Unix/Linux/OS X systems commands like tar cf broxburgh_18_apr_contol_a.tar broxburgh will put all the les and

sub-folders of broxburgh into an archive le. On Windows it is usually a matter of a right click on the model folder to create a zip le. Each simulation group will have its own naming scheme for such les as well as rules as to where these les are stored. The frequency of backup depends partly on the imagined hassle of repeating a particular set of actions as well as the state of the model. The following 268

are classic trigger points for making backups: when a zone becomes fully attributed prior to making a model variant prior to a search and replace operation 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 building And backups can be focused on one or two les which are related to an issue being tested. A quick test of reducing the cooling capacity in one zone of the building would start with making a backup of the current control, altering a few values in the control denition, running a test and then recovering the initial state of the control. Different groups adopt different styles of le naming conventions and the logs of the actions taken and reverted. One issue which is much debated is whether model archives should include results les. Some groups include these, some compress such les prior to archiving and some groups include in the archive scripts and directives needed to re-generate results les. ESP-r models can include pre-dened simulation parameter sets and many groups build their working procedures around such facilities. 15.7 Team Checklists The following table includes some of the issues to notice when working with

simulation models. Roughly, the order begins at the start of the work. Clearly there are scores of topics which could be added to this table. The form of the table is to pose a general issue in the left column and provide a list of associated topics or questions in the middle column and related actions in the right column. The Cookbook uses terse phrases and only includes a sub-set of related actions within these tables. Consider this as a starting point and create verbose versions of the tables in this chapter and extend the topics as new situations arise and as working procedures for speculative future work is contemplated.

269

Question What is interesting about the site?

Related issues What do we know about the site? Does the client realize the importance of the site? Is the north arrow on the site plan? How might site issues constrain the design? How might site layout be used to improve the design?

Actions Check the site plan and area maps. Find out which way is north. Review photographs or visit the site. Check site solar and wind obstructions. Check principal wind direction and whether vernacular architecture takes this into account. Collect local opinions of the site. Discuss with design team options for adjusting the building on the site. If orientations may vary ensure naming regime avoids confusion (e.g. avoid north_entrance). Review climate data to establish seasons, typical periods and extreme periods. Review climate data for useful building failure test sequences. Review climate data for duration of extremes as well as the frequency of moderate weather patterns. Discuss with design team the results from initial review of weather. Review drawings or CAD les and gather comments from simulation staff and quality manager. Check that the drawing scale is reasonable and if details might inuence the design of the model. Discuss the level of detail required within the team. Arrange a meeting with the design team and present sketches of planned model and likely approaches.

What weather data is appropriate for the site?

What climate data is available near the site? What patterns of weather will impact the building design? How have other buildings adapted to the local weather? What are the design teams ideas about the inuence of weather? What drawings or sketches can we access? Are there plans, sections and elevations available to review? Are the drawings likely to change? What is the design team debating now and what are likely future topics?

Is the design evolving or static?

270

Question What is the composition of the building? Are the goals of the project consistent with these constructions?

Related issues Are construction details known? What what-if questions relate to constructions? Are these typical for this building type? Do we have sources for missing data? What criteria for rejection of constructions? Does the client have an well-formed opinion about the building use? Is building occupancy an issue for futureproong? Is there seasonal diversity as well as daily diversity? What performance issues are related to the big idea(s)? What analysis domains and metrics of performance will conrm this? Can beliefs held by the design team be conrmed?

Actions Review standard databases for matching constructions and/or SIMILAR constructions. Create place holder constructions and document. Review sections and discuss with design team. Discuss support for selecting appropriate constructions.

How is the building used? Is the building for a known tenant or is it speculative? How are rooms likely to be occupied at different times and seasons? What is the clients big idea? What kind of model would conrm this idea? What are others in the design team interested in?

Check the assumptions made by the client. Quantify likely scenarios. Consider diversity, holidays and peak use occurrences. Check past models for similar patterns.

Listen to the language used and review sketches to identify beliefs behind the big idea(s). Identify issues and determine if they can be assessed. Review available tools to check for matches in numerical capabilities and reporting facilities. Brief the design team on the approach to be taken and the likely information to be derived from the assessments.

In-built Tool checklists The internal checks which simulation tool interfaces support typically include issues such as is this polygon at and does the construction attribute point to a correct entity in the database and does the boiler have a non-negative capacity. 271

Tool checks are not likely to ag a surface named door which is composed of 150mm of concrete or which is horizontal. It is unlikely that doors are horizontal or have a concrete construction attribute. Unlikely can happen and users are in the best position to notice this. In addition to checks in the interface, further scanning of the model may be done by the simulation engine. If the

simulation engine scan passes then it becomes possible to move from syntax checks to semantic checks based on predicted performance (see sections 15.6 and 15.8). Criteria for frequency of syntax checks should be included in the working procedures. Typically these would happen during the evolution of the model as well as after simulations have been run. There are techniques for reducing the time taken for checks. Incremental checks are well supported by looking at the differences against an earlier report and software for hi-lighting the differences between two les or between two folders is readily available. The use of pattern search tools (i.e. grep) can identify key words in model contents reports. The table that follows illustrate some of the issues. Use this as a starting point for generating your own responses to issues as they arise and for planning future tasks.

272

Core question What changed since version 1.3?

Related issue Who is working on the model? What tasks are they involved in? Does this match the work plan? Which parts of the model are affected? Is information available on the new roof? What performance issues might change? What tasks are required and which staff should be involved? Is this a model variant or an edit of the existing model? Is there a missing surface? Are there edges which do not follow the rules used in the tool? Is there one or more reversed surface? Under what operating regimes and weather conditions is this happening? What are the primary gains within the ceiling void? Is it possible to remove heat from the ceiling void?

Actions Consult the work log or the log of actions generated by the tool. Generate a model contents report and see how this differs from the previous report. Check with the quality manager and simulation staff about current status. Update the constructions database if required. Generate a model contents report, archive the current model and performance predictions. Create model variant if required. Apply changes, generate model contents report, check against previous report, re-run calibration assessments and review. Archive the revised model and brief the client. Look at the wire-frame for missing surface labels. Use the check vertex topology option for a report. Turn on surface normal arrows to review orientation of surfaces. Check for vertices linked to only one surface. Carry out checks under different weather patterns. Review the energy balance in the ceiling void. Review how boundary conditions are represented and the state of adjacent zones. Test different operating regimes to determine sensitivity. Force a brief purge of heat from the ceiling void and check the whether (and how long) it takes the condition to re-establish.

The client wants to test a different roof type

The interface says problem edges in conference zone.

The ceiling void is warm and retaining sufcient heat to cause a morning cooling issue.

273

15.8 Simulation outputs In simulation the time when the fat lady sings is most often after the simulation has been run and the team is exploring the performance predictions looking for the story to tell the rest of the design team. Some simulation groups generate the same report irregardless of the project. Such poor value for money is largely the fault of the client for not making their needs clear or not having sufcient experience to know the variety of deliverables that a simulation team can provide. It is only natural that simulation staff have their preferences for the graphs and tables that are included in reports. However, the goals of many projects are multi-criteria and working patterns need to be established to ensure that a range of performance issues are tested and taken into account in reports to the client. Gremlins enjoy watching us nd patterns we expect, declaring success and then having someone else discover the chaos. The risk of unintended consequences can be reduced by multi-criteria assessments and by different people with different agendas attempting to understand the predictions. This is not a new issue. ESP-r has long included the concept of an Integrated Performance View (IPV) where a number of performance issues are identied at the planning stage and recorded in the model so that recovery of multi-criteria assessments can be automated. A typical range of metrics would be 274

comfort, system capacity, energy use over time, emissions of carbon dioxide, distribution of light in rooms and the number of hours of system use. As implemented, the IPV is imperfect and further work is required to allow risk to the better managed and opportunities identied. In other simulation tools this could be implemented by the inclusion of performance meters for a range of issues. The critical step is taking the time early in the design process to identify issues which may arise as design options are tested. Running well-designed calibration assessments should usually only take a few moments each so they will focus on typical weeks rather than whole seasons. For performance metrics which are not yet part of an IPV there are still options to automate assessments and data recovery. A library of standard scripts for extracting performance data on a range of topics is a useful complement to interactive explorations. The table that follows is a sample of issues and questions and actions for staff attempting to understand performance predictions. Use this as a starting point for your own working practices.

Core issue Is the model still calibrated?

Related issue Have calibration assessments been run? Were there enough measurements to understand performance? Does the data recovery script include these issues? Do we have trigger values for failure? What other data views will complement standard reports and graphs? Who can conrm the additional reports? What products would be likely candidates? Do we have thermophysical and optical data? What criteria would signal better performance? Is performance sensitive to the facade orientation?

Actions Review the criteria for calibration assessments. Identify measurements which match expectations. Identify unexpected measurements and investigate further. Explore performance interactively, including a few tangent issues. Get a second interactive review. Follow up issues by looking at dependant or related issues. Run test script to conrm data recovery logic and reporting format is ok. Do spot checks. Run the full script. Do spot checks and get someone else to conrm. Establish what is available and the claimed benets. Review data sources or generate data Identify glazing-related improvements Decide where alternative glazing could be applied. Implement design variants. Archive model, establish base case performance, test substitution and data extraction procedures. Implement one change at a time and compare against the base case. Rank the design variants and identify performance changes. Get a second opinion.

Is performance tracking planning stage expectations? What issues were mentioned in recent meetings? What value added issues are under consideration?

What if we altered the vision glass?

275

15.9 The model contents report This section is a review of the ESP-r model contents report. What should you be looking for? What are key words to scan for? How much detail is available? Where is is information held? The reports generated by other tools will differ in detail but they will cover many of the same issues. Those of you who are constrained to screen captures of the tool interface can also create rules for interpreting entities shown in the interface. The following listings are portions of the model contents report for the doctors ofce used in the initial chapters of the Cookbook. Prior to each section is a discussion of the contents of the report. After the report fragment is a discussion of key words and phrases to look for. The user has the option to selected which topics are included in the report as well as the level of detail included for each topic. The example below used the verbose level for most topics. As mentioned elsewhere, many quality managers will create a hard-copy of such reports and use them in conjunction with the interface when reviewing models. One common pattern is for simulation staff to generate the report and then insert additional notes and assumptions or highlight blocks of text that require further discussion and pass this to the quality manager along with the location of the model. The header The header of the model report focuses on site and high level project related information. Some of the text is based 276

on user supplied phrases and other parts are generated from model data and le names. The key words for this section are the date that the report was printed and the name of the model log le (which may contain useful additions by the user). The rst two lines of the report also are the place to identify what is different about this model. These phrases are used in many places in the interface and in reports. The year mentioned in the summary will have been initially set to match that of the climate le. One reason to alter the year is to shift the day of the week - for example, in 2001 the rst of January is a Monday.

Synopsis This is a synopsis of the model for training session on Thursday defined in office_for_doctor.cfg generated on Fri Jul 30 11:13:01 2010. Notes associated with the model are in office_for_doctor.log The model is located at latitude 55.90 with a longitude difference of -4.10 from the local time meridian. The year used in simulations is 2007 and weekends occur on Saturday and Sunday. The site exposure is typical city centre and the ground reflectance is 0.20. Simulationist Simulationist Simulationist Simulationist Simulationist name: not yet defined telephone: not yet defined address: not yet defined city: not yet defined postcode: not yet defined

The climate is: ESP test climate and is held in: /usr/esru/esp-r/climate/clm67 with hour centred solar data.

you like to nd in order to come back to speed on this project? What to look for in header The summary of the site location and the climate should be checked to see if they match the project. Default values here may be indicative of a lack of attention. In the report below the lines identifying the building, the building owner and the simulation team have not yet been lled out. If the project requires model variants then its is really important to consider naming schemes and titles - users in a hurry can easily select the wrong model! If you create a model variant check that the tiles and documentation have been updated to reect this. The log le for the model is a text document which is initially lled in by the interface when the model is created. Some groups use this le as a place to document progress on the model. Imagine reviewing a model after several months. What kind of notes would 277 The databases The next section of the report focuses on databases associated with the model. Some of these are standard databases - the path (/usr/esru) is one clue or the report indicates that it is a standard database. Databases can also be model specic - a path ../dbs. And databases might be located in a nonstandard location with a full path give /home/fred/databases. Databases in the standard esp-r/databases folder are initially supplied with the software. The exemplar and validation models may reference these databases as will many user created models. Thus is it important that these databases are secure and are only altered with due care and attention. Other databases can be added to the standard databases folder as required or added to a non-standard location if that is more convenient.

It is up to the group to manage and document the databases. Databases items should be reviewed and the contents should be of a know quality and kept up to date by the quality manager. The le read and write permissions on Unix and Linux and OSX computers can be used to ensure that these socalled corporate databases are protected from corruption or casual modications. Groups working within a Windows infrastructure will have to implement their own procedures because it is difcult to prevent corruption or casual modication by users. Databases associated with the model may or may not be derived from the standard database. Typically they will include items specic to the model. Such entities may eventually migrate to a standard database (a task for the quality manager). ESP-r has limitations on the internal documentation of database entities. It falls to the simulation team to supplement the information held in the model data les and databases so that they conform to group policies. Each database differs slightly in implementation. Currently the constructions database contents are the core of the report. The constructions make reference to items in the materials database and if the construction is transparent to the associated optical properties. The layout of the report is similar to that used in the interface. The constructions part of the report is a combination of numbers and short labels. It follows an older format which lacks clarity for some users. For example, name of the construction is restricted to twelve characters and 278

there are no categories. Until the data structure is revised it is up the user to compensate for the limitations in the tool (other tools will have different limitations to compensate for).

Databases associated with the model: standard pressure distr: pressc.db1 materials : ../dbs/office_for_doctor.materiald constructions : ../dbs/office_for_doctor.constrdb standard plant comp : plantc.db1 standard event profiles: profiles.db2.a standard optical prop : optics.db2 . . . sections skipped . . . Multi-layer constructions used: Details of opaque construction: extern_wall

Layer|Matr|Thick|Conduc-|Density|Specif|IR |Solr|Diffu| R |Descr |db |(mm) |tivity | |heat |emis|abs |resis|m2K/W Ext 6 100.0 0.960 2000. 650. 0.90 0.70 25. 0.10 lt brown brick : Light brown b 2 291 150.0 0.040 12. 1000. 0.90 0.70 30. 3.75 Min wool quilt : Insulation (M 3 0 50.0 0.000 0. 0. 0.99 0.99 1. 0.17 air 0.17 0.17 0.17 Int 2 100.0 0.440 1500. 650. 0.90 0.65 15. 0.23 breeze block : Breeze block ISO 6946 U values (horiz/upward/downward heat flow)= 0.226 0.228 0.224 (partition) 0.222 Total area of extern_wall is 78.45 Details of opaque construction: int_doors Layer|Matr|Thick|Conduc-|Density|Specif|IR |Solr|Diffu| R |Descr |db |(mm) |tivity | |heat |emis|abs |resis|m2K/W 1 69 25.0 0.190 700. 2390. 0.90 0.65 12. 0.13 oak : Oak (radial cut) ISO 6946 U values (horiz/upward/downward heat flow)= 3.316 3.682 2.928 (ptn) 2.554 Total area of int_doors is 4.20 . . . Details of transparent construction: dbl_glz with DCF7671_06nb optics.

Layer|Matr|Thick|Conduc-|Density|Specif|IR |Solr|Diffu| R |Descr |db |(mm) |tivity | |heat |emis|abs |resis|m2K/W Ext 242 6.0 0.760 2710. 837. 0.83 0.05 19200. 0.01 plate glass : Plate glass 2 0 12.0 0.000 0. 0. 0.99 0.99 1. 0.17 air 0.17 0.17 0.17 Int 242 6.0 0.760 2710. 837. 0.83 0.05 19200. 0.01 plate glass : Plate glass ISO 6946 U values (horiz/upward/downward heat flow)= 2.811 3.069 2.527 (ptn) 2.243 Clear float 76/71, 6mm, no blind: with id of: DCF7671_06nb with 3 layers [including air gaps] and visible trn: 0.76 Direct transmission @ 0, 40, 55, 70, 80 deg 0.611 0.583 0.534 0.384 0.170 Layer| absorption @ 0, 40, 55, 70, 80 deg 1 0.157 0.172 0.185 0.201 0.202 2 0.001 0.002 0.003 0.004 0.005 3 0.117 0.124 0.127 0.112 0.077 Total area of dbl_glz is 11.55

What to look for in databases When reading the report remember the layers go from other-side to room side. Make a point of comparing the 279

reported U values with other data sources to ensure that the construction is properly dened. In the case of ESPr, a U value is a derived value and not part of the calculation process. It is also up to the user to correctly account

for the changes in heat transfer between the centre of glazing and sections near the frame. There are several approaches such as using averaged values and using separate surfaces for the centre and edge of glass but little consensus in the community. Constructions which are transparent have additional entries in the report for optical properties. This part of the report includes jargon and a not particularly human readable format. The data used by ESP-r is more detailed that that provided by some manufacturers. And it does not include some data generated by optical analysis tools such as Window 5.2 and WIS. ESP-r is not unique in simplifying some aspects of diffusing glass and advanced light re-directing glazing products. Other potential errors might include reference to the wrong database or confusion about the contents of the database. Several of the exemplar models include local copies of a standard database and maintain the same name as the standard database. Updates to the standard database will not be reected in these derived databases. Conversely if new entities have been added to a local database care and attention are required when incorporating this into the standard databases to avoid name clashes. Updates to standard database also require care and attention. For example, an ISO standard recommended that foundation constructions include at least 500mm of earth. Two standard constructions in the databases were identied for upgrading but it was also necessary to scan for references to 280

these constructions in the exemplar and validation models distributed with ESP-r. For one of the constructions a dozen models required updating and the update needed to include not only refreshing the zone construction les but also remembering to update the model contents reports. A similar procedure would apply to simulation groups and their own archives of models. Another relationship to check in the constructions database is between the construction and optical property. A three layer double glazed windows construction can only be matched to a three layer optical property set. For a window with a low-e coating the improved performance is represented as an increased resistance in the air gap in the construction denition. An internal (between the glass) blind is often represented by glass air metal air glass in the construction with optical property sets that allow some radiation to pass through the metal layer. Thus the metal layer mass is used in the construction denition and the optical property tells the simulator what portion of the solar radiation passing through the construction is absorbed at the metal layer. An operable blind is usually implemented by altering only the optical properties (the mass does not move). The thickness of a layer in a construction is often the same as the physical entity. And there are instances where this in not appropriate and where a given construction may need to be represented in different ways. For example, a sandstone wall in a castle is

700mm thick and ESP-r will complain about this as it stresses the underlying numerical method and limits our knowledge of the temperatures within the wall. A better representation would be four layers e.g. 150mm 200mm 200mm and 150mm (assuming the 400mm in the centre are rubble and the outer 150mm is faced stone). A similar approach would apply to insulation products. Layers of insulation of 100mm are preferred. The idea that constructions are composed of layers is thermophysically defensible for homogeneous constructions but requires adaptation for nonhomogeneous constructions. A given layer (parallel with the face of the construction) may be composed of one or two repeating materials perpendicular to the face of the construction e.g. insulation and structure. In this case the properties of the parallel layer is derived from the weighted contributions of the insulation and structure. If such composite materials are to be included in a database then it must be clear what materials were used and the percentages of each. Zone controls The next section of the model report is extracted from the controls dened for zones and/or ow or system networks. The documentation phrases are provided by the user. Next there is a short synopsis of what is being sensed and what is actuated. This is followed by an automatically generated synopsis for each period in the control schedule. The control section of the report is a compromise. The space available for 281

translating the parameters of each periods control law is limited and abbreviations are necessary. Some controls include jargon used by control engineers. There are a few controls which have almost no translation of the control parameters. Some controls which have parameters which include auxiliary sensor denitions can be confusing because the standard report of sensor and actuator locations does not know that it has been superseded. Invest time in understanding to how ESP-r represents and reports on controls so you can spot errors and omissions before you run assessments. The reports may also provide clues if you nd the model is not working as expected. The control portion of the QA report below indicates that the model is probably at an early stage. There is, for example, no mention of why 2KW capacity was specied for heating and cooling during ofce hours and 1KW during the setback periods. Documentation is important for ideal controls because the sensor actuator control law pattern used by ESP-r can approximate any number of physical devices. It may be that a later version of the model shifts from ideal representations to component based representations of environmental controls and initial statements can assist this transition.

The model includes ideal controls as follows: Control description: to work with reception occupant 80W with diversity during the day max to 400W. Lighting at 150 W during occupied period. 60W equipment during occupied period Zones control includes 1 functions. 1kW heating overnight during setback, 2kW office hours to reach 20C set-point during office hours. Weekend setback to 10C. The sensor for function 1 senses the temperature of the current zone. The actuator for function 1 is air point of the current zone The function day types are Weekdays, Saturdays & Sundays Weekday control is valid Mon-01-Jan to Mon-31-Dec, 2007 with 6 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 10.0 24.0 0.0 basic control: max heating capacity 1000.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 10.00C cooling set-point 24.00C. 2 7.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 20.0 24.0 0.0 basic control: max heating capacity 1000.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 20.00C cooling set-point 24.00C. 3 8.00 db temp > flux basic control 2000.0 0.0 1000.0 0.0 21.0 24.0 0.0 basic control: max heating capacity 2000.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 21.00C cooling set-point 24.00C. 4 9.00 db temp > flux basic control 2000.0 0.0 1000.0 0.0 21.0 24.0 0.0 basic control: max heating capacity 2000.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 21.00C cooling set-point 24.00C. 5 17.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 20.0 24.0 0.0 basic control: max heating capacity 1000.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 20.00C cooling set-point 24.00C. 6 21.00 db temp > flux free floating Saturday control is valid Mon-01-Jan to Mon-31-Dec, 2007 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux free floating 2 8.00 db temp > flux basic control 1000.0 0.0 1000.0 0.0 10.0 24.0 0.0 basic control: max heating capacity 1000.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 10.00C cooling set-point 24.00C. 3 19.00 db temp > flux free floating Sunday control is valid Mon-01-Jan to Mon-31-Dec, 2007 with 3 periods. Per|Start|Sensing |Actuating | Control law | Data 1 0.00 db temp > flux free floating 2 8.00 db temp > flux basic control 500.0 0.0 1000.0 0.0 10.0 24.0 0.0 basic control: max heating capacity 500.0W min heating capacity 0.0W max cooling capacity 1000.0W min cooling capacity 0.0W. Heating set-point 10.00C cooling set-point 24.00C. 3 19.00 db temp > flux free floating Zone to contol loop linkages: zone ( 1) reception << control zone ( 2) examination << control 1 1

What to look for in controls Words and numbers must be backed up with a clear description and an initial check should evaluate whether the 282

description given is a good synopsis for the controls that have been implemented. The software does not force you to update the description when you are working with control loops so nd a way to make this a habit! ESP-r allows control loops to be dened which are not yet referenced in the model. Users are also responsible for assigning links between control loops and thermal zones. Thus is it possible that this association is not correct. It is possible that an incorrect link will result the the appearance that the zone is controlled and so it is necessary to be pedantic in inspections of the control listing to ensure that the correct control is used. Control logic is separated into different periods in the day. This allows for considerable exibility in environmental controls and it also complicates the process of proving that controls are working as intended. Control logic may also differ on different day types one typical error is to update controls for one day type and not check further. Dead-bands and heating and cooling set-points can be used to ne tune control logic to match the response of physical devices. There are caveats ESP-r is implementing ideal controls so the time-lags in physical devices is absent. We might think we know what is happening in a room thermostat but most of the time we are guessing. ESP-r does not support auto-sizing so it is up to the user to dene heating and cooling capacity. Sometimes we have this information but many users just stick in a big number. Imagine what a big number represents to a numerical 283

engine - a small room with a hundred thousand Watts of heat dumped into it not something that we would do in reality so it is probably best not to go there in a virtual world either. Some controls in real life are unstable if not properly tuned and an un-tuned PI or PID controller in ESP-r will exhibit the same patterns. Reserve time for virtual tuning and be aware that the same controller may not perform well in different seasons without re-tuning. Minimal capacity is a concept embedded in a number of ideal controls. The idea is that some wet central heating systems tend to have poorly lagged pipes that are exposed in the room and even if a valve turns off the radiator there is still some heat released from the piping. Zone composition The next section of the model report provides both summary and detailed reports of zone composition. If the attribution in a zone is incomplete the summary will reect this. The report for each zone reects the verbosity selected before the report was generated. Much of the report is based on information derived from scanning the form and composition of the zone. If the zone is fully attributed then U-values and UA values are reported for a quick reality check. Note that the derived values may be a bit confusing if the zone shape is complex - for example if portions of the facade are horizontal and facing up then they will be included in the roof area. Transparent surface that are not vertical may be reported as skylights.

ID Zone Volume| Name m3 | 1 reception 120.0 2 examination 60.0 all 180.

Surface No. Opaque Transp 12 165.5 4.5 11 86.0 7.0 23 252. 12.

Floor 40.0 reception has one staff and up to 4 visitors 25.9 examination for one doctor and one visitor 66.

Zone reception ( 1) is composed of 12 surfaces and 26 vertices. It encloses a volume of 120.m3 of space, with a total surface area of 170.m2 & approx floor area of 40.0m2 reception has one staff and up to 4 visitors There is 94.000m2 of exposed surface area, 54.000m2 of which is vertical. Outside walls are 123.75 % of floor area & avg U of 0.226 & UA of 11.195 Flat roof is 100.00 % of floor area & avg U of 0.924 & UA of 36.965 Glazing 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 | m2 |deg |deg | name |optical|locat| use | name |other side 1 12.0 180. 0. partn_a OPAQUE VERT mass_part ||< partn_a:examination 2 9.90 270. 0. partn_b OPAQUE VERT mass_part ||< partn_b:examination 3 9.75 180. 0. south_wall OPAQUE VERT WALL extern_wall ||< external 4 21.0 90. 0. east_wall OPAQUE VERT WALL extern_wall ||< external 5 9.75 0. 0. north_wall OPAQUE VERT WALL extern_wall ||< external 6 12.0 0. 0. partn_c OPAQUE VERT mass_part ||< identical environment 7 9.00 270. 0. west_wall OPAQUE VERT WALL extern_wall ||< external 8 40.0 0. 90. ceiling OPAQUE CEIL ROOF roof_1 ||< external 9 40.0 0. -90. floor OPAQUE FLOR grnd_floor ||< ground profile 1 10 2.25 180. 0. south_glz DCF7671_ VERT C-WIN dbl_glz ||< external 11 2.25 0. 0. north_glz DCF7671_ VERT C-WIN dbl_glz ||< external 12 2.10 270. 0. door OPAQUE VERT int_doors ||< door:examination An hourly solar radiation distribution is used for this zone. Insolation sources (all applicable): south_glz north_glz Explicit viewfactors have been derived for this zone. Shading patterns have been calculated for this zone.

The list of surface attributes is probably best viewed in conjunction with a wire-frame image of the zone. This is one of the places where a well designed naming regime will allow inconsistencies to be identied quickly. After the surfaces attributes have been listed there may be additional lines which identify optional attributes of the zone. In the example above is a notice that shading patterns have been precalculated for the zone as well as radiation viewfactors calculated. 284

Details of the polygons which make up the surfaces of the zone are not included. Users interested in this level of detail will either have to look at the interface (where co-ordinates and edge lists are found) or look at the model descriptive les. What to look for in zone reports Quality managers will scan this report for UNKNOWN attributes. One might expect some UNKNOWN early in the model composition. Some users tend to address attributes one at a time - for example, they might make a

pass through the model assigning construction attributes, and then make a second pass attributing the ground connection details for foundation surfaces. Frequent re-freshes of the model contents report will clearly show where such progress has been made. Another check that is part of many groups work ows is to look for names that do not match the entity. For example, a wall named south_wall might actually be facing West. Is this because the zone was rotated after the surfaces were named? If so a better naming scheme might be front, back, left, right. Differences in names and wire-frame views might also indicate that a surface has been inverted. In this case one would look at the numerical value of the azimuth and elevation reported as well as the wire-frame view of the zone and turn on the draw surface normal option. In the column of surface names look for duplicate names - this can cause havoc with some functions in ESP-r. Check also that the surface names are following the general rules for naming agreed by the group. The column of optical tags will either include the key words OPAQUE or TRAN or the initial part of the optical property name. If ESP-r becomes confused or the user is forgetful then surfaces which you intended to be transparent might show up with an OPAQUE tag. To correct this go to the menu for the attributes of this surface and re-select the construction and also, if necessary set the optical property toggle. If the problem persists then it might be that the entry in the 285

constructions database does not have the correct optical property. The column of location tags are based on the orientation of each polygon and are used by some methods within ESPr. For example, a polygon which is approximately vertical uses a specic heat transfer regime so it is useful to pre-calculate this attribute of the surface. The tag also can be useful tag for quick visual scans of the model. The column of surface uses supports building code compliance rules which need to identify specic types of facade entities. As a form of documentation surface use tags are also useful. In the future these tags may help automate the creation of ow networks. Currently surface use attributes are optional so you will often nd this column lled with - entries. The column of construction names should be read in the context of the optical property name as well as the surface name. Some users also check the location tag. In a well designed and well composed model these attributes should reinforce each other and a key pattern matching skill is to learn to quickly recognize discontinuities in these attributes. The right-most column described boundary conditions. For partitions this report is more specic than the ANOTHER tag that occurs in the geometry le or the higher level menus. Be aware that there are space limitations and longer zone and surface names may have been truncated. After the columns of surface attributes the report (if generated in verbose mode) should tell you about extensions

to the zone denitions. In the example above there is a note that explicit viewfactors have been calculated. The report does not include the actual viewfactors and it is not clear from the report whether or not the view-factors are up to date. To get more information one must go to the interface for viewfactors. Zone schedules The next section of the report focuses on the schedules of air ow and casual gains dened for the zone. First there is the user supplied documentation and then the data for each of the schedule types. The format of the report is similar to that supplied in the interface and thus it is somewhat terse. In the example below there is no control imposed on the air ow schedule and so no information on the control logic is included. The current version of ESP-r supports a minimum period of one hour so there can be up to 24 periods in a day. Periods should be in sequence and include the whole of each day type. Working procedures that minimize errors typically enforce matching documentation and data. Numbers may be correct without being clear as to what they represent. The user documentation includes a brief note about the casual gains. There is some diversity included in the casual gains for occupants. Lights are a xed wattage as are small power loads. The documentation says computer all the time but the data is only on during ofce hours. Which is correct? A quality manager would notice that the 286

radiant and convective split is 50 50 for occupants and lights and ask for clarication.

Air schedule notes: one air change all day. reception - up to 3 people, one computer all the time Control: no control of air flow Number of air change periods for daytype weekdays : Period Infiltration Ventilation From Source id Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp. 1 0 - 24 1.00 0.0333 0.00 0.0000 0 0.00 Number of air change periods for daytype saturday : Period Infiltration Ventilation From Source id Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp. 1 0 - 24 1.00 0.0333 0.00 0.0000 0 0.00 Number of air change periods for daytype sunday : Period Infiltration Ventilation From Source id Hours Rate ac/h m3/s Rate ac/h m3/s Zone Temp. 1 0 - 24 1.00 0.0333 0.00 0.0000 0 0.00 Notes: reception - up to 3 people, one computer all the time Number of weekdays casual gains= 14 Day Gain Type Period Sensible Latent Radiant No. label Hours Magn.(W) Magn. (W) Frac weekd 1 OccuptW 0- 7 0.0 0.0 0.50 weekd 2 OccuptW 7- 8 80.0 40.0 0.50 weekd 3 OccuptW 8- 9 240.0 120.0 0.50 weekd 4 OccuptW 9-12 400.0 200.0 0.50 weekd 5 OccuptW 12-14 240.0 120.0 0.50 weekd 6 OccuptW 14-17 400.0 200.0 0.50 weekd 7 OccuptW 17-21 40.0 20.0 0.50 weekd 8 OccuptW 21-24 0.0 0.0 0.50 weekd 9 LightsW 0- 8 0.0 0.0 0.50 weekd 10 LightsW 8-19 150.0 0.0 0.50 weekd 11 LightsW 19-24 0.0 0.0 0.50 weekd 12 EquiptW 0- 8 0.0 0.0 0.40 weekd 13 EquiptW 8-19 60.0 0.0 0.40 weekd 14 EquiptW 19-24 0.0 0.0 0.40 Number of saturday casual gains= 3 Day Gain Type Period Sensible Latent Radiant No. label Hours Magn.(W) Magn. (W) Frac satur 1 OccuptW 0-24 0.0 0.0 0.50 satur 2 LightsW 0-24 0.0 0.0 0.50 satur 3 EquiptW 0-24 0.0 0.0 0.40 Number of sunday casual gains= 3 Day Gain Type Period Sensible Latent Radiant No. label Hours Magn.(W) Magn. (W) Frac sunda 1 OccuptW 0-24 0.0 0.0 0.50 sunda 2 LightsW 0-24 0.0 0.0 0.50 sunda 3 EquiptW 0-24 0.0 0.0 0.40 1

Convec Frac 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.60 0.60 0.60 Convec Frac 0.50 0.50 0.60 Convec Frac 0.50 0.50 0.60

What to look for in zone schedules As with controls the documentation of zone schedules should match the values and an update to the schedule should (by habit) include a revision to the documentation. A review of the 287

model contents report should ensure that the documentation is both clear and consistent. The section on inltration and ventilation provides both air changes per hour and m3/second values. The latter is derived from the volume of the zone and thus should change if the room

volume changes. Another thing to look for in the ventilation section is that the volume given for ventilation between rooms is in terms of the current zone, not the supply zone. It is the users responsibility to derive the correct volume for ventilation. The example above indicates eight periods for occupants on weekdays and it is implied that the changes in values are to introduce some diversity into the schedule. The 400W periods are clearly the peak and the peak lasts three or four hours. There is also a ramp-up and ramp-down at the start and end of ofce hours. It is assumed that this is used to represent brief occupancy of cleaning staff but it is not explicitly stated in the documentation. Another pattern to observe is the radiant and convective split. It is likely that default values have been used and it may be worthwhile to ne tune these values. Note that ESP-r uses xed representations of sensible and latent values for occupants but in reality they are sensitive to the temperature of the room and the metabolic rate. Those doing analysis in temperate climates without air conditioning should adapt values accordingly. There is also a summary section in the QA report which provides a range of derived data which have proved to be of use to practitioners. For example there are UA values for different portions of the building fabric which provide a quick reality check.

288

Project floor area is 65.900m2, wall area is 78.450m2, window area is 11.550m2. Sloped roof area is 17.088m2, flat roof area is 40.000m2, skylight area is 0.00m2. There is 147.09m2 of outside surface area, 90.000m2 of which is vertical. Outside walls are 119.04 % of floor area & avg U of 0.226 & UA of 17.743 Sloped roof is 25.930 % of floor area & avg U of 0.924 & UA of 15.791 Flat roof is 60.698 % of floor area & avg U of 0.924 & UA of 36.965 Glazing is 17.527 % of floor & 12.833 % facade with avg U of 2.811 & UA of 32.463

What to look for in the project summary The reported oor area is based on the list of surfaces associated with the base of each zone. Occasionally errors occur in this if surfaces have been added or removed or the oor is sloped. Check the values in each zone report. The summary report makes assumptions when allocating surfaces to particular categories. It is possible that complex zones may not be accurately reported. An example is a facade which includes horizontal elements. The reported UA values are based on standard assumptions and might also be mis-allocated if their location is mis-interpreted. The intent is to provide a guide for practitioners who also work with software that uses UA based calculations or include quick UA evaluations as part of their model quality checks. 15.10 Summary Well-formed working procedures will ensure that models tell a clear story to the design team and that performance predictions have been reviewed to ensure that predictions are within normal expectations and options for better 289

than expected performance are delivered to the design team. It is a challenge to ensure resources used for generating and testing models is within the project budget and that sufcient time and attention is available for exploring value-added issues. A pro-active quality manager is needed to champion such issues. The quality of models is a result of decisions made during the planning stage, the design of the model, actions by members of the simulation team and the facilities included within the simulation tool. The increasing complexity of models is partly driven by new questions from design teams and by productivity features in simulation tools but is constrained by our ability to conrm that models are both syntactically and semantically correct. The discussions and tables included in this chapter are intended to be a starting point for simulation teams to generate robust working procedures and provide ideas for skills which may be useful to acquire.

Chapter 16

INSTALL APPENDIX

14 Install Appendix ESP-r is available on a number of computing platforms and this section provides information on how to acquire ESP-r pre-compiled distributions or to checkout one of the current ESP-r distributions from the Subversion repository. comma, tab or space is a separator between data. There is also a restriction that names of entities use an ASCII character set rather than extended character set. These dependencies are related to the underlying Fortran source code read and write statements. ESP-r has been observed to have problems with some, but not all Asian keyboards and locales. Solaris supports an F90/C/C++ compiling environment as well as the GNU compiler collection. The former is particularly useful for development work as Sun supports IEEE oating point exceptions (e.g. divide by zero) and array bounds checking (e.g. asking for the 12th value of an array of size 10). Linux supports the GNU compiler collection. Note that recent Linux distributions tend to have version 4.2 of the GNU compilers and ESP-r currently works better with the older 3.4 version of the compilers. There is also a general issue with 64 bit computers - there are slight differences in predictions and a risk of some graphical tasks causing program crashes. ESP-r is currently more robust when running on 32 bit computers.

ESP-r was initially a suite of tools running on Sun workstations and then with the advent of Linux running on lower cost personal computers the code was adapted to also run on Linux. There are a few lines of code which required adaptation for Solaris and Linux platforms and there are almost no differences in user interactions and in administrative tasks. ESP-r implicitly assumes a range of operating system services and protections. For example, that corporate databases and example models are held in folders where normal users can read but not overwrite such les. On other computing platforms such protections are either enforced in a different way or absent. Note that ESP-r assumes the computer environment is using a USA or UK locale and that real numbers use a period as a decimal point and that a 291

With the advent of OSX, Apple

computers offer many of the same compilers and low level operating system services as Linux and so it has been possible to port ESP-r to Apple computers. There are a few minor differences in operating system services (le name case sensitivity is incomplete and users folders are found in /Users rather than /home. In terms of use the interface is the same as is offered on Linux. Because it does not follow the full OSX look and feel rules, some users nd this confusing. OSX supports the GNU compiler collection as well as X11 libraries and source code conventions. For development work it is necessary to install the so-called nk facilities as well as X11 support. A full list of requirements can be found in the ESRU web pages. The pre-compiled distribution is made on a PPC rather than Intel Apple computer. It has been reported to run on Intel based Apple computers.

Again there few code differences required for development and use of ESP-r on Cygwin. In terms of user experience, ESP-r thinks it is running on a Linux box and the same user interactions apply. Cygwin supports the usual GNU compiler collection and X11 graphics libraries and the development tasks are essentially the same as on Linux. File permissions are less strict than Linux and thus care should be exercised to avoid overwriting les that ESP-r assumes have strict permissions.

Because of the differences in compilers and operating system services it took some time to realize a version of ESP-r that runs natively on Windows computers. The initial approach to ESP-r running on Windows computers was to use an emulation environment called Cygwin. Cygwin provides the compilation environment required by ESP-r as well as translating many operating system requests and providing a similar command line interpreter (shell scripting) as one would nd on a Linux machine. 292

The native Windows version of ESP-r is an almost complete port of the facilities available on other computer platforms. This version works on Windows 2000 and Windows XP computers. There has been little or no testing on Windows Vista or on 64-bit versions of Windows. The underlying graphic libraries currently restrict some functions (this is work-in-progress). The major differences are found in the facilities provided by the operating system and in the layout and conventions of the le system. ESP-r currently has a limited ability to cope with spaces in le names and it also has limits on the length of le names. These limit where ESP-r can be installed as well as how deeply nested model folders can be before le names become truncated. For this reason, precompiled versions of ESP-r are designed to be in C:\Esru\esp-r

rather than in C:\Program Files\Esru. ESP-r models work better in C:\Esru\Models rather than
C:\Documents and Settings\Fred\Current Models\

Development for Native Windows currently requires the MSYS collection of tools in addition to MinGW, a port of the GNU compiler collection. Environment variables and les When ESP-r is initially compiled several types of information are embedded in the executables (e.g. where ESP-r is installed) and other types of information (e.g. where to nd example models and what databases to initially load) is scanned in from text les. One of these text les is called esprc and the standard version is assumed to be in the installation sub-folder esp-r. Its contents are listed in Figure X and the meaning of the tokens is presented below. The le is in tag - data, data format. Typically the rst token is a label and the second token is either an executable to be invoked or the name of a le to be used. To alter this initial specication use a text editor and change the relevant token as required. Look in the preferences menu of the Project Manager to access the details of this le. The initially created version of the esprc le is held in the ESP-r installation folder. If a user wants a custom version of this le to use they should copy it to their home folder with the name .esprc. *ESPRC - this is the le type tag. It must be the rst line 293

*gprn - commands associate with capturing a rectangular section of the screen. The 2nd token import is the executable which captures a section of the screen. In this case the esprc le was created with a Linux computer and the executable name would be different for a different computer operating system. *tprn - commands associated with dumping the current text feedback buffer to le will write to the le identied in the second token. *gxwd - a variant of *gprn but which captures the whole screen. *cad - instructions for a CAD tool to invoke. The second token is the executable and the third token is a key word describing the type of le it creates. *image_display - commands related to the display of model-associated images. The second token is a key word identifying the format of the le and the third token is the name of the executable to invoke to display that type of image. There can be several *image_display lines in the esprc le. *journal - turns on a time-stamp facility which logs user actions and the key words are ON and OFF. *editor - which ASCII text editor to invoke if an external application is required. *report_gen - not used *exemplars - the name of the le to read which includes a list of models which can be accessed and where they are stored. The initial contents of the exemplars le is for use in

ESP-r workshops but the contents can be edited to include other models. *validation_stds - the name of a le to read with information needed to commission standard tests *db_defaults - the name of a default le which holds a list of initial databases. If you want to use an alternative list of initial databases edit this le or include a reference to an alternative list of databases. *db_climates - the name of a climatelist le which holds a list of climate data sets and their location. If you want to use an alternative list edit the le or provide the name of an alternative le. Default le assumptions The second le which is commonly scanned when ESP-r modules start is the default le. The name of this le is included in the esprc le. The le is a tag - data format and is typically found in the installation folder. An example of this le is listed in Figure 10.2. Note that the path /Users/jon/esru_prj_dev points to an installation made for testing purposes and this path was generated as the test version of ESP-r was compiled based on the directives given at the time. As with the previous les the name of the le is associated with a specic topic and/or dialogue within the user interface. These dialogues associated with specic types of model les require a default name and the default le names are scanned in via the default le rather than being hardcoded into the interface. The name of 294

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 ESPr has been installed based on the specic commands given during the installation process *cfg - this is a default le name for a model conguration le (useful for demonstration purposes) *ctl - this is a default le name for control loop denitions *mfn - this is a default le name for an air ow network *dfd - this is a default le name for a CFD domain description *res - this is a default le name for a zone predictions (results) le. This le should be created during the install process so that it is easy to demonstrate ESP-r. *mfr - this is a default le name for mass ow predictions *clm - this is a default le name for climate data. This climate le should be created during the install process. *prs *prm *mlc *opt *evn *pdb these are default le names of databases (in case the user request a default database. Many users will change the name of the database les to suite the needs of their work. This le can be accessed via the preferences menu of the Project Manger.

*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/s tds_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_start Location is 52.0N and 0.0E. The solar radiation is Direct Normal. Month Minimum Time Maximum Time Mean

295

Jan -6.4 @20h00 Sun 8 12.7 @14h00 Sun 29 3.8 Feb -1.9 @ 5h00 Tue 14 12.2 @13h00 Thu 2 5.2 Mar -0.8 @24h00 Fri 31 16.1 @15h00 Tue 21 6.8 Apr -1.9 @ 2h00 Sat 1 19.4 @15h00 Mon 17 7.1 May 0.0 @ 3h00 Wed 3 22.7 @14h00 Thu 11 10.4 Jun 5.0 @ 2h00 Fri 9 21.1 @15h00 Tue 6 13.6 Jul 9.4 @ 3h00 Mon 3 27.7 @12h00 Mon 17 18.0 Aug 7.7 @ 4h00 Sat 5 24.4 @12h00 Tue 1 15.6 Sep 5.0 @ 6h00 Thu 21 22.2 @12h00 Tue 26 13.5 Oct 2.2 @ 5h00 Mon 30 19.4 @13h00 Sat 7 10.8 Nov -0.8 @ 5h00 Mon 27 14.4 @14h00 Sat 11 5.2 Dec -4.2 @ 1h00 Sat 9 12.7 @ 9h00 Sat 23 3.8 All -6.4 @20h00 Sun 8 Jan 27.7 @12h00 Mon 17 Jul 9.5 Typical 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. a display name for the climate data (as seen the the interface list) The list of available climate les a brief documentation about the climate data The last ASCII le which is used by ESP-r modules on a regular basis is the its location on the computer so-called climatelist le. This le is the start and end dates of each of ve referenced by the esprc le (see above seasons (winter from 1 Jan, spring, discussion) and includes a list of the summer, autumn, winter ending 31 climate data sets that were installed on Dec). These dates typically were the computer. When the interface of supplied by a person who knows the one of the ESP-r modules presents a climate of the region and the social list of available climate data it scans customs of the region. this le. the start and end dates of a typical Each time you want to add climate data week in each season. There is an to your computer you should edit this facility in the clm module which le with a text editor so that the listing searches for typical weeks based on will include the new le. There is a heating and cooling degree days and detailed discussion of how to use clm solar radiation patterns. to add new climate les in Chapter 6. a block of text up to 60 lines which A portion of this le is shown in Figure provides a summary of the climate. 16.3. This block is auto-generated within The climatelist le includes the followclm and you can edit it and extend it ing types of information: if required. 296

297

Chapter 17

VERSION APPENDIX

17 Version Appendix In addition to its multi-platform capabilities, ESP-r has three possible styles of interaction on most computing platforms: text-mode interactions, a legacy X11 graphic interface and a newer GTK graphic interface. In most cases the command menu selections are the same. Differences are found in the layout of some types of dialogue, in the le browser facilities, in sensitivity to mouse clicks and keyboard input shortcuts. First a brief review of the interaction styles. Text mode operation is the most geeky on offer. It is primarily used by experts who are commissioning a series of standard assessments. The interface is driven either by user supplied keystrokes or commands included in a script. This mode is also useful for working on a remote compute-server or when only a slow internet connection is available. The X11 interface has separate regions for graphic feedback, text feedback, menu selections and user dialogues for editing entities and selecting les. Menus items are selected via mouse clicks or by keystroke. This interface is available for all operating systems except for Native Windows. User interactions are uniform across all machine types and each of the ESP-r modules follows the same layout although some 299 take up more room on the screen. The GTK+ based interface was selected as a replacement for the X11 interface because it can be deployed across a range of operating systems, including Windows. It also has a richer application programming interface and a larger number of in-built features that previously had to be written from scratch in X11. 17.1 Text mode Text mode operation is available as a command line option for users working on Solaris, Linux, Cygwin and OSX. To use text mode on Native Windows ESP-r must be compiled without graphics. As it is difcult to have two versions of ESP-r on a Windows computer this usually necessitates the use of a second (or virtual) Windows computer in order to have access to wireframe views of models and graphs in the results module. In Figure 17.1, the project manager has been invoked from a command window (the same command syntax applies in Linux, Solaris, OSX and Cygwin). The list of user options is shown in a double column (options which start with a character or number are activated by typing that character). The prompt is seen at the bottom of the gure.

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

#!/bin/csh -fb set CONFIG=$1 bps -file $CONFIG -mode text <<XXX c $CONFIG.wc_res 9 1 15 1 3 1 s y ESRU Standard test: $CONFIG y y XXX

Production work often requires a specic sequence of tasks be carried out. To reinforce this practitioners will often create a script to drive ESP-r. For example, during testing a standard set of assessments need to be run and then a standard report should be extracted for each assessment. Below is a portion of a script called SIMULATE.wc is used to run a standard assessment (with ideal controls active). The script invokes an ESP-r module (bps) with a suitable set of command line parameters and then passes a sequence of keystrokes to the module to control it. 300

Having run the assessment, a second script in the source code validation/benchmark/QA/model/cfg folder named ANALYSE_4 is invoked to start up the results analysis module and cause a sequence of reports to be

generated.
#!/bin/csh -fb set RESFILE=$1 res -file $RESFILE -mode text<<XXX d # enquire about > $RESFILE.data $RESFILE results a # summary statistics h # sensible a # heating h b # cooling b # temperatures a # zone db b e # zone resultant b d # zone control pt d # enquire a # summary statistics f # zone flux a # infiltration f b # ventilation m a # real power m b # reactive power j b # convective casual gains j c # radiant casual gains d # solar processes a # entering from outside d c # solar absorbed i # zone rh j # casual gains a # all j b # convective portion j c # radiant portion j e # total occupant gain j i # total lighting gain j m # total small power c # timestep reports

g # j # e # j i # j m # ! # d f # g # h # b b i # b b * # * # * # l # a b # b # a # y > XXX

perf metrics casual total occupant total lighting total small power list data

energy delivered casual gains distrib zone energy balance surface energy balance all surfaces in reception all surfaces in office all surrace in roof monthly frequency of temperatures zone db

Seasoned users of ESP-r often use the Perl language to compose a sequence of assessments and data recovery tasks. Indeed, it is possible to use a script to modify the shape and or composition of a model. Anything that can be done via an interactive session in text model can be included in a script.

301

17.2 Legacy X11 graphics

Figure 17.2 Specifying a le name.

Figure 17.3 Pop-up help for a dialog.

Figure 17.4 X11 real number dialog.

Figure 17.5 X11 radio button dialog. This style of interaction supports the most complete graphics input functionality. It is also dated in appearance and has limited le browsing facilities. The current plan is to depreciate and eventually remove X11 graphic dependencies as and when the newer GTK 302

library code (see below) are in place.

X11 equivalent of a radio button (only one item can be selected). Figure 17.6 shows the X11 control of a wire-frame view and Figure 17.9 is for the GTK interface. In this case a menu dialogue has been used to approximate a proforma. Selection lists where you are able to select more than one entity e.g. Figure 17.7 shows a list of surfaces in a zone that have been selected and the selected items have a * in the right column. There is an * All items option which will select the whole list. If you want to remove and item from the selection then select it and the * will be removed.

Figure 17.6 X11 wire-frame control menu. Figure 17.2 is an example of a text dialogue (asking for a le name). The layout is similar to all X11 dialogues there is a prompt above and/or to the left of the editing box. On the right is an ok box, a ? box and a default box. Clicking on the ? produces a pop-up dialogue (see Figure 17.3). If there are more than about 20 lines of text then up and down arrows will be included to support scrolling. Figure 17.4 is a dialog requesting a real number. Such dialogues usually have range checking included and you might be asked to respecify the number. Figure 17.5 is the 303

Figure 17.7 X11 entity selection(s) list.

17.3 GTK+ graphics

Figure 17.8 GTK le browsing dialog.

Figure 17.9: GTK wire frame control dialogue. work around the limitations. The current plan is to continue coding until the full X11 functionality is in place. The development community will then review how the layout of ESP-r might 304

This style of interaction is more in keeping with what the user community expects. The port is incomplete, however, many users nd that they can

evolve to take advantage of the functionality in the GTK graphics API. The following Figures are the GTK equivalents to the le specication dialogue, pop-up help message, real number dialogue and a radio button dialogue. It generally takes fewer lines of code to implement a dialogue in GTK than it does in raw X11.

Figure 17.12 GTK radio button dialogue. ESP-r dialogues normally use English, however GTK does support locale specic text in buttons that are used in some dialogues. Once the X11 code is depreciated it should be possible to consider revising the code structure to support multiple languages if resources could be found. << more text here >>

Figure 17.10 GTK popup help.

The table below provides a summary of differences. This is followed by specic examples where you might encounter differences. The chapter is work in progress. More text to be added here.

Figure 17.11 GTK real number dialogue.

305

Chapter 18

CAPABILITIES

18 Capabilities This Chapter is a review of the capabilities of ESP-r for representing the virtual physics of buildings and systems as well as what can be measured and reported. Some of the information is similar to the publication Contrasting the Capabilities of Building Energy Performance Simulation Programs by Crawley, Hand, Kummert and Grifth of July 2005. In that publication the summary of ESP-r is: ESP-r is a general purpose, multidomain (building thermal, interzone air ow, intra-zone air movement, HVAC systems and electrical power ow) simulation environment which has been under development for more than 25 years. It follows the pattern of simulation follows description where additional technical domain solvers are invoked as the building and systems description evolves. Users have options to increase the geometric, environmental control and operational complexity of models to match the requirements of particular projects. It supports an explicit energy balance in each zone and at each surface and uses message passing between the solvers to support inter-domain interactions. It works with third 307 party tools such as Radiance to support higher resolution assessments as well as interacting with supply and demand matching tools. ESP-r is distributed as a suite of tools. A project manager controls the development of models and requests computational services from other modules in the suite as well as 3rd party tools. Support modules include: climate display and analysis, an integrated (all domain) simulation engines, environmental impacts assessment, 2D-3D conduction grid denitions, shading/insolation calculations, view-factor calculations, short- time-step data denitions, mycotoxin analysis, model conversion (e.g. between CAD and ESP-r) and an interface to the visual simulation suite Radiance. ESP-r is distributed under a GPL license through a web site which also includes an extensive publications list, example models, cross-referenced source code, tutorials and resources for developers. It runs on almost all computing platforms and under most operating systems. Although ESP-r has a strong research heritage (e.g. it supports simultaneous building

fabric/network mass ow and CFD domains), it is being used as a consulting tool by architects, engineers, and multi-discipline practices and as the engine for other simulation environments. 18.1 General modelling features This section provides an overview of how ESP-r approaches the solution of the buildings and systems described in a users model, the frequency of the solution, the geometric elements which zones can be composed and exchange supported with other CAD and simulations tools. ESP-r employs a partitioned solution approach. Simultaneous loads, network air ow, CFD domain, electrical power and system component solution is via custom domain solvers. Interactions between domains are handled with message passing between the solvers at each time-step. The building solution is based on matrix partitioning and Gaussian elimination. Partitioning is by thermal zone and zone coupling is handled by message passing at each time-step. This approach conserves memory in the case of large models, but requires resources for message passing. Entities in ESP-r are represented as control-volume heat-balance nodes (nite volumes). Such nodes are distributed throughout the fabric and air volumes of the building and within system components. An explicit energy balance is maintained at each zone air volume, at each face of each 308

surface and at each nite volume of used in system components. System components support temperature, two component (moist air and steam) ow, heat injection/extraction and electrical characteristics at each component node. Electrical power solution supports mixtures of DC as well as three phase power with real and reactive power. The electrical network can link to casual gains in zones and surfaces which include electrical characteristics as well as system components. The mass ow solution works with mixed air and water ow networks of nodes (at zones, system components and at boundary locations) as well as a range of ow components. Control logic can be applied to ow components to approximate mechanical or user interventions. The solver is highly optimized and can solve networks of hundreds of nodes with minimal computational overhead. It typically runs at the same frequency as the zone solver with the option to iterate (useful for models with large openings). Iteration supported in system component and network ow solution domains. Zone solver can be adjusted from fully implicit to fully explicit but defaults a Crank-Nicolson formulation. Conduction defaults to 1D and models can include 2D and 3D conduction (if additional data is supplied). Domain interactions supported e.g. mass ow solution feeds system component and zone solution at each

time-step. Zones can be assessed with a mixture of environmental controls, including free oat and user undersized controls as well as supporting radiant gains and injection of heat into layers of a construction. Simulation frequency is one minute to one hour for zone and air ow domains. System and electrical components solved from one second to one hour. Time-step controller with support for rewind to start of day for exploring optimal start regimes. Zone geometry is based on 3D polygons of arbitrary complexity (including explicit representation of internal mass). Shading devices are block shapes. There are a number of geometric rules: a) zones must be fully bounded, b) surfaces must be at, c) edge ordering denes outward face of surface, d) unbounded edges detected, e) internal mass requires back-to-back surfaces, f) zones can be embedded within other zones. All zone surfaces take part in the zone energy balance. Glazing is a surface with optical property attributes which supports solar transmission and absorption at each layer in addition to the convective, conductive and radiant exchanges of opaque surfaces. Optical properties can be subject to control action. Frames can be represented explicitly or via adapting the properties of the surface representing glazing. Surfaces can have attributes for phase change materials, temperature dependant conductivity, electrical 309

characteristics (e.g. integrated PV), moisture adsorption, contaminate emission properties. Facility to import DXF les (V12) which conrm to specic standards of layer naming and use of 3D entities. Facility to export DXF les (V12), EnergyPlus (geometry, constructions, casual gains), VRML worlds, Radiance visual simulation models. Measured data (one minute to one hour frequency) of temperatures, setpoints, weather data, casual gains can be associated with a model. Ideal environmental control systems can be dened (in addition to component based system descriptions).

18.2 Zone Loads This section provides an overview of ESP-rs support for solving the thermophysical state of rooms: the heat balance underlying the calculations, how conduction and convection within rooms is solved, and how thermal comfort is assessed. An explicit energy balance is maintained at each zone air volume and at each face of each surface. The default treatment is to use three nite volumes for each layer of each construction. Typically, materials over about 200mm thick are subdivided into multiple layers to increase the efciency of the solution as well as providing additional points for recording temperature. The minimum size of a zone is 1cm3. Rooms with dimensions greater than 100m probably should

be subdivided. Minimal surface dimensions are 1mm and there is no specic maximum size. Surfaces can include 24 edges but complex surfaces or surfaces with large dimensions may not be well represented by 1D conduction. Minimum thickness of a construction layer is 0.2mm although care should be taken when thin and thick layers are adjacent. A number of boundary condition types are supported in ESP-r: a) exterior, b) other side has similar temperature and radiation, c) other side has xed temperature and radiation, d) other side is a surface in this or another zone, e) standard or user dened monthly ground temperature prole or a 3D ground model, f) adiabatic (no ux crosses), g) other side is part of a BASESIMP foundation description, h) CEN 13791 partition. Air gaps are typically treated a resistance layers which are sensitive to surface orientation. Glazing using alternative gasses or with coatings must be approximated by altering the air gap resistance. Air gaps can be explicitly represented as thermal zones and optionally included in an air ow network (such explicit treatments do not scale well but do support explicit treatments of radiation and convection across air gaps). There are 20 internal convection regimes and 25 external convection correlations in addition to user dened heat transfer coefcients. Conditions at inside and outside face are evaluated at each time-step. Some outside regimes are sensitive to the angle of incidence of the wind 310

as well as whether the surface is on the windward or leeward side. Heat transfer coefcients derived via a CFD solution can be applied at the next time-step. Internal mass can be explicitly represented and these surfaces take part in the full energy balance as well as solar insolation patterns and long wave radiant exchanges. Radiation view factors can be calculated for zones of arbitrary complexity and shape, including internal mass. Fanger thermal comfort as well as MRT and resultant temperature reported. If sensor bodies are dened then radiant asymmetry is also reported. 18.3 Building envelope and daylighting This sections is an overview of the treatment of solar radiation outside a building as well as its distribution within and between zones. Outside surface conduction is also discussed. The default treatment is to assume no shading and that the distribution of insolation is diffusely distributed within a room. If there are external sources of shading these are represented as opaque non-reective block shapes. Shading calculations (direct and diffuse) are done for each hour on a typical day of each month. Diffuse shading can be based on isotropic or anisotropic sky conditions. Insolation distribution (including radiation falling on internal mass surfaces) can also be predicted at

each hour on a typical day of each month. Beam solar radiation is tracked to rst absorption and then diffusely distributed. Solar radiation passing into adjacent zones is treated as a diffuse source. Solar radiation passing out through a facade is assessed. Optical data on transmission and absorption at ve angles is typically used and can be imported from Window 5.1 or 5.2. Data from WIS requires additional editing. Bidirectional optical properties and control is supported for those with experimental data. Seasonal adaptation of shading devices requires separate models, each pointing to obstruction descriptions for that season. Optical properties can be switched based on a range of criteria (the number of layers is required to be constant). There is a facility to substitute an alternative construction as well as alternative optical properties. The requirement for a constant number of layers poses a challenge for the representation of movable blinds and shutters. Day-lighting control can be based on split-ux method, user dened daylight factors or time-step use of the Radiance visual simulation suite to compute lux on a sensor. Multiple circuits can be treated in each thermal zone. Some users choose to explicitly represent opaque blinds as sets of surfaces. In the case of blinds between glass this is often approached by 311

treating the blind as a layer with the construction which has optical properties approximating the transmission through the slats and openings. If the optical properties of this layer are switched then the absorption characteristics of the blind layer change (as does the thermal state of the construction). Conduction is typically represented in 1D but can be switched to 2D and 3D (the input data requirements increase considerably). 18.4 Inltration ventilation and multi-zone air ow This section provides an overview of how air movement, either from the outside or between rooms or in conjunction with environmental systems is treated. The simple approach to air movement in ESP-r is to create schedules of inltration (air movement from the outside either natural or forced) and ventilation (air movement between zones). Control can be applied to these scheduled ows based on a range of criteria e.g. increase inltration to 2ach if room goes over 24 degrees C. The intermediate approach to air movement is to create a network of ow nodes and components and solve the leakage distribution at each time-step based on the current boundary driving forces as well as stack and pressure distributions inside. Most of the underlying component representation are derived from the literature. In common with most other mass ow solution

approaches there are some gaps in the provision of component types. Control can be applied to mass ow components to approximate occupant interactions or mechanical ow controls. Combinations of controls in sequence and in parallel are used to create complex regimes. The highest resolution approach is to dene a computation uid dynamics domain with one zone of the model (optionally in addition to a ow network). The CFD domain is in a rectangular co-ordinate system with optional blockages. Solution is typically transient 2D or 3D. There are a range of wall functions available as well as equation types. The CFD solution supports one way and two way conation. The latter takes its boundary conditions from the zone solution and returns heat transfer coefcients. There is an adaptive controller which re-forms the CFD domain at each time-step based on changes in boundary conditions and the ow patterns predicted from an initial course CFD assessment. The CFD solution can also use ow boundary conditions from an associated mass ow network. This allows wind pressures and ows with other zones to be assessed at each timestep. Iteration is used to negotiate between the mass ow and CFD domain solvers. The CFD solution can include cells which are heat and contaminate sources. The former can be associated with zone casual gain schedules so that there is a temporal aspect to 312

such gains. Zone air volumes are assumed to be well mixed at one temperature. Stratication requires either the use of a CFD domain or subdivision of physical spaces into multiple thermal zones with a mass ow network used to assess air exchange. A mass ow network can include elements associated with natural ventilation and buoyancy driven ow as well as components within a mechanical system. Thus it is possible to create an air based solar collector from a collection of explicit zones and a ow network (as an alternative to a component based approach). For models of high resolution there is a post-processor which determines if specic species of mycotoxin will grow on surfaces of a model. Architectural elements such as Trombe-Michelle walls and double skin facades are usually composed of multiple zones with a mass ow network to support air movement assessments. ESP-r includes a database of wind pressure coefcients (at 22.5 degree intervals) which can be associated with wind pressure boundary nodes in a ow network. Some users populate this database with data from wind tunnel tests or CFD runs.

18.5 Renewable energy systems and electrical systems This section is an overview of options for representing renewable energy systems either as components within an

ESP-r model or via 3rd party tools. Including an electrical power network in a model allows a number of issues related to renewable energy systems to be addressed. Some system components represent components of renewable energy systems such as generators, fuel cells and batteries. These can be tested independent of or switched into the power grid. Mixtures of 1/2/3 phase AC and DC can be described. The electrical solvers works at the same time-step as the system components and yields real and reactive power ows, power losses, current magnitudes and phase, voltage magnitudes and phase, phase loadings. ESP-r data can be exported for use with supply and demand matching tools such as MERIT (also available from ESRU). 18.6 Ideal environmental controls This section is an overview of ESP-rs approach to ideal (from a control engineers perspective) zone controls. For early stage design issues ESP-r users tend to use ideal zone controls to represent environmental controls as loops of sensors and actuators with a range of control laws. Ideal zone controls can be combined with control of mass ow components to increase the resolution of models. Mass ow components can be used to represent some aspects of duct work in mechanical systems (ESP-r has not been designed to be used as a duct design tool). 313

Sensors in ESP-r can be located at a number of positions within the building (the zone air volume, at or within a surface, at a ow node or outside of the building for use with climate variables). Actuators in ESPr can be located at the air node, at or within a surface, at a ow component etc. Zone control loops include a schedule of control laws are applied as required to approximate many environmental control regimes. The zone controls include: basic ideal control with maximum and minimum heating and cooling capacity, heating set-point, cooling set-point and moisture injection. free oating control xed injection/extraction with heating injection, cooling extraction, heating set-point and cooling setpoint. basic proportional control with maximum and minimum heating injection, maximum and minimum cooling extraction, heating set-point, cooling set-point. There is a throttling range and optional integral action time and/or derivative action time. A multi-stage controller with hysteresis. There are three stages of heating and three stages of cooling. There are heating off and cooling off set-points as well as dead bands for heating and cooling and heating and cooling set-points. Variable supply controller with or without available cooling. It includes a maximum supply temperature,

minimum supply temperature, air ow rate room heating and cooling set-points. Separate ON/OFF controller which includes heating and cooling capacity, heating on below, heating off above, cooling on above and cooling off below set-points. Ideal match temperature controller which is given a maximum heating and cooling capacity and a list of sensors and their weightings as well as scaling factors. A typical use is to control a boundary zone to a measured temperature or to match the temperature in another zone. There is also an ON/OFF controller which can be used to match measurements or other zone temperatures. Time proportioning control which includes heating and cooing capacity, heat on and off set-points, cooling on and off set-points, minimum on times and off times. Useful for equipment that has a slow cycle time. Optimal start logic with heating capacity, desired set-point, desired time of arrival, minimum time difference with optional start time. There is also an optimal stop controller. Slave capacity controller points to a common sensor and forces the zone actuator to act as the master actuator but with a user dened heating and cooling capacity. VAV approximation controller which includes a reheat capacity, supply temperature, room set-point, maximum and minimum ow rate 314

18.7 Component based systems This section is an overview of ESP-rs component-based approach to describing environmental systems. There are a number of component types (some are listed below) which can be linked together to form a range of environmental control systems. Some devices are represented by several components - for example there is a single node radiator as well as an eight node radiator - so the user has a choice of component resolution. As with zone controls, system components can be included in system control loops. There are a number of control laws available depending on whether ux or ow is to be controlled. Air conditioning steam/spray humidier, water/steam ow multiplier, water/steam ow converger and diverger Air conditioning cooling coils with ux control, a counterow cooling coil with water mass ow rate control, a counterow cooling coil fed by WCH system, a two node cooling coil with specic n and tube details. Air conditioning heating coils with ux control, a counterow heating coil with water mass ow rate control, a counterow heating coil fed by WCH system Plate heat exchanger, air/air exchanger, heat exchanger segment, duct, duct damper Cooling tower Centrifugal fan

 Wet central heating boilers: non-condensing boiler, with on/off control, with aquastat control, calorier, modulating boiler, TRNSYS type 6 WCH 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-leg junction, converging multi-leg junction, heat transfer tube, heat transfer tube with transport delay, insulated pipe with transport delay, ow control valve WCH basic chiller or heat pump, water cooler, compressed gas cylinder WCH generic liquid/liquid heat exchanger and gas/liquid heat exchanger and water/air heat rejector Oil lled electric panel radiator CHP engine components: one node and three node representations. Hydrogen appliance (generic generator supplied by hydrogen source) 18.8 Environmental emissions The emissions associated with the energy use of buildings can be tracked via user supplied conversion factors for heating and cooling and small power loads as well as loads which are not attributable to a particular zone. There is a rarely used facility that allows users to dene environmental impacts associated with the assembly and transport and disposal of building components. 315

18.9 Climate data This section gives a summary of how ESP-r uses climate data and how users access and manipulate this data. ESP-r holds the following climate data in both ASCII and binary le format. Solar data can be in two forms. The normal le formats support hourly data. 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 longitude difference from the local time meridian. There is a conversion utility which is able to read EnergyPlus EPW weather data and extract the required data elds. ESP-r also works with subhourly weather data via a so-called temporal le. There is an facility that scans a climate data set to determine best t weeks in each season based on heating and cooling degree days and radiation levels. It also reports initial scaling factors that can be used to convert from short period assessments to seasonal performance data.

18.10 Results reporting This section is an overview of how building and systems performance data is accessed in ESP-r. The standard approach differs from many other simulation suites in that one or more custom binary databases are created depending on the number of domain solvers used in a particular model. The zone solver writes out a number of items at each time step which related to temperatures of the zone air and surfaces as well as uxes associated with a zone air energy balance and surface energy balances. The plant component solver writes out the temperature, 1st phase and 2nd phase ows at each node of each component. The mass ow solver records the pressure and temperature at each node, pressure difference across each network connection as well as stack pressure and mass ows along each connection. The electrical power solver writes out the real and reactive power, power loss, current magnitude and phase, voltage magnitude and phase, phase loading for each node in the electrical network. ESP-r includes a results analysis module which is able to read these binary results les and, for any of the stored variables report on the data in various formats and undertake statistical analysis. Graphs of time vs variable with option of multiple vertical axis and support for combinations of data. 316

Graphs of variable vs variable to look for trends and correlations between data types Statistics with maximum value and time of occurrence, minimal value and time of occurrence, mean and standard deviation Statistics with number of hours over and under a specied value Time step listings in multiple columns with various separators as required by third party applications Frequency bins and cumulative frequency bins in tables and graphs. Zone and surface energy balances as well as individual reporting of all contributor variables in the energy balances. Energy demand over time including hours of use. Comfort in terms of PMV, PPD, radiant asymmetry, resultant temperature, MRT. Monthly gains and losses for a number of variables in each zone. There is an facility which generates XML les based on a description of variables to save during a simulation. The list of items to capture is typically generated by editing a separate specication le. There is a facility which allows users to include a range of performance metrics for a model called an Integrated Performance View. This description is used by the results analysis module to generate a report based on information in one or more simulation les.

18.11 Validation Testing of software has been an ongoing activity for the ESP-r development community and takes several forms: assuring the quality of the code in ESPr, testing that the underlying computations are correct and detecting differences with the predictions of other tools. ESP-r has been involved in the following projects: IEA Annex 1 (1977-1980). Interprogram comparison of 19 different tools IEA Annex 4 (1979-1982). Interprogram comparison of a commercial ofce building with nine tools over four years. IEA Annex 10 (1984-1986). Interprogram comparison of HVAC systems. IEA Annex 21 (1988-1993). Interprogram and analytical comparison commonly known as BESTEST. SERC validation project (1988). Inter-program comparison undertaken by several Universities and research groups in the UK with extensive analytical tests. UK Energy Technology Support Unit Applicability study was carried out over seven years and focused on passive solar houses. EC PASSYS project (1986-1993) combined outdoor test facilities (in 14 locations) with model predictions. British Research Establishment/ Electricity de France empirical validation study of a BRE ofce building and a BRE house. 317

BESTEST, RADTEST, Home Energy Rating System BESTEST were carried out at various times and by various teams and focused on radiant heating systems (RADTEST) and air conditioning systems and furnace models (HERS). CEN 13791 standard required a number of extensions to ESP-r to accommodate the unusual physics assumed in the standard.