Thermal simulation outputs: exploring the concept of patterns in design decision-making

Abstract

This paper describes the ongoing development of a building performance simulation (BPS) knowledge management scheme for design decision-making. This knowledge management scheme is developed with reference to the patterns of Christopher Alexander and colleagues, which describe commonly recurring abstract problems in architectural design together with successful abstract solutions. As such they form a ‘repository of knowledge’ on architectural design. Patterns have been used in other fields such as software engineering where they also aim at capturing expert knowledge, and their potential to do the same for BPS is explored here. Decision support using simulation is introduced and the concept of patterns described. A pattern structure is developed and some examples given. Interviews with architectural practices investigated whether patterns could support design processes, and the further development of the concept is discussed.

Keywords:

• building performance simulation
• building design
• decision support
• simulation outputs
• patterns

1. Introduction

This paper aims to describe the development of a building performance simulation (BPS) knowledge management scheme to aid design decision-making. The main features of this scheme were developed as part of a framework intended to guide the production of thermal simulation post-processed information meaningful to building design decision-making (Bleil de Souza and Tucker 2013, 2014). The scheme is also partly based on some features of the design patterns proposed by Alexander et al. (1977) and Alexander (1979) which describe abstract solutions to commonly recurring abstract problems that occur in architectural design and the built environment. This paper outlines how the knowledge management scheme may potentially be developed into design patterns, which would act as an open-access repository of knowledge for applying simulation to the design of low-energy buildings. Such patterns are supposed to capture knowledge so far owned largely by simulation experts, and to make it more accessible to potential groups of simulation end users including building designers. The authors have not intended at this stage to capture or reproduce the full sophistication and qualities of patterns and pattern languages.

Researchers have noted the need for better uptake of simulation tools in practice to provide design-related information (Hand 1998; Mahdavi 1999; Augenbroe 2001; Clarke 2001; Bleil de Souza 2009). This problem is often attributed to a lack of integration of simulation tools into the ‘design process’ (Mahdavi and Suter 1998) and/or the difficulties involved in the construction of virtual models (Mahdavi 2004). In addition to these problems, little theory or knowledge is easily accessible by potential simulation users on how thermal simulation is done, what its aims are, and how its results can be used to support the design of low-energy buildings. There is also a lack of defined procedures, processes and protocols that enable building energy modelling to be carried out consistently and effectively (Franconi 2011). This is a problem particularly when the potential users are building designers with perhaps little interest in the simulation tools themselves or lack the time to gain the required expertise in BPS and the underlying building science.

Much of the available advice on BPS is linked to particular simulation software in the form of ‘cookbooks’ (e.g. Hand 2011), or is available as generic advice perhaps illustrated by case studies (CIBSE 1998) or is expected to be gained through training. There are also comprehensive technical descriptions of BPS (Hensen and Lamberts 2011). These sources are suitable when the designer has some commitment to or interest in simulation as a method of supporting design, but probably not in other cases. Knowledge on using simulation tools to inform design decision-making seems to be tacitly acquired by simulation experts through ‘learning by doing’ when involved in consultancy projects with building designers.

A number of initiatives have attempted to address these problems. These include efforts to create simplified and task-focussed tools that map better onto what are assumed to be ‘design workflows’, construction of new platforms that enable simulation experts and their skills to be better integrated into design processes, and data interoperability initiatives for better integration between simulation tools. However, despite this activity there is little explicit and formal knowledge on what a user could or should do with a simulation tool; for example, how to make a suitable model, determine the simulation settings, which analytical methods to use, and how to understand the limitations and uncertainties associated with the results. This is perhaps a result of the development of simulation which has generally been led by building engineers, building physicists, and software engineers, and generally taught as an art or a craft albeit one with a strong scientific basis. Defining and representing procedures and protocols that represent expert knowledge in using BPS to inform design decisions could be seen as potentially enabling ‘knowledge transfer’ between the experts who formulate the simulation procedures and the user who can then make use of that knowledge. This paper begins to explore the idea that this knowledge can be structured into patterns.

The patterns and pattern language of Alexander are potentially relevant as they form a system that attempts to capture and represent knowledge on how buildings, parts of buildings and the wider built environment can be designed. While this knowledge is more concerned with qualitative and physical abstract solutions for abstract building design problems than with procedures and protocols, patterns have subsequently been found useful in the field of software engineering where they are used to store procedures (i.e. code) such that they can be reused where appropriate (Gamma et al. 1995). Patterns have also been used successfully in the fields of interaction design (Rogers, Sharp, and Preece 2011) and human–computer interaction (Tidwell 2011) which are concerned with enabling human users to interact productively with computers and with other digital artefacts. They have also been used in teaching (Bergin 2000). In each of these fields, patterns are used to record successful generic and abstract solutions to common problems such that the knowledge on how to solve similar problems can be transmitted, and are intended to describe good practice in fields that are inherently complex. These precedents gave the motivation for exploring whether patterns could support building designers in their productive use of BPS. The idea of using patterns in this way was first reported in Tucker and Bleil de Souza (2013).

2. Background

2.1. Support for building design decision-making using thermal simulation

With increasing emphasis on low-energy and low-carbon performance, the outputs of BPS are of potential interest to different actors in the processes of building design and construction, including building designers, clients, practice managers, researchers and consultants. There have been many suggestions for ways of making BPS and its potential for analysis available to the building designer. These include the following:

• Development of ‘user friendly’ interfaces to BPS engines (e.g. DesignBuilder, Open Studio).

• Design advice systems, where BPS can be used to provide performance information (Papamichael 1999; Soebarto and Williamson 1999).

• Generation of design alternatives, or generation of ‘design space’ to act within (Mahdavi and Gurtekin 2001; Marsh and Haghperast 2004).

• Systems that support dialogue between expert simulation users and the design team (Clarke et al. 1995; Augenbroe et al. 2004).

• Systems that focus on supporting design processes and/or data management in order to provide better integration of existing tools into design processes (Papamichael, LaPorta, and Chauvet 1997; Mahdavi 1999; Mahdavi, Bachinger, and Suter 2005).

These initiatives and others are described throughout the literature with summaries provided by Augenbroe (2001) and Bleil de Souza (2009), amongst others. A number of critiques have been made of existing initiatives and tools. De Wilde and van de Voorden (2004) conclude that many of the attempts (at integration) have failed because of their focus on development of one specific tool only. Augenbroe et al. (2004) point out that many efforts assume fixed interaction modes and dialogues for the required design analysis which therefore fail to account for the spontaneity and even idiosyncratic way that design teams organize themselves and proceed with design projects. Bleil de Souza (2012) points to problems in producing data outputs that have meaning to designers in terms of their ‘way of thinking’ or modus operandi.

The approach explored here is to enable the use of BPS by the building designer by transfer of expert knowledge in the form of patterns. This approach is intended to support individual and disparate design processes, and is a general or abstract method not based on any one tool. The approach is also based on understanding simulation outputs for decision-making as a designed product that must be useful to have validity. Simulation outputs should be designed with the user in mind. If they are not, then they may be too difficult to work with and so fail to be useful. Interaction designers point out that users do not need to know every technical detail of how a product or system works, but only how to use it effectively (Cooper, Reimann, and Cronin 2007). Therefore, the views of building designers have been sought as to what they feel they need in practice, and whether the use of patterns in the ways proposed by them and by the researchers would suit their everyday activities.

2.2. Protocols and procedures for general use of simulation

There are few explicit examples of formal protocols and procedures for using simulation in the context of design, and those that are available exist in the form of software or proposals for software. The intelligent front-end (IFE) system (Clarke and MacRandal 1993; Clarke et al. 1995) was developed within the COMBINE project (Augenbroe 1992) and addressed the ‘over engineered’ nature of simulation programmes by proposing a knowledge-based interface sensitive to the needs of designers which would map well to the flows of information of the design process. This ‘intelligent, integrated building design system’ could contain procedural routines such as automatic determination of climate patterns which could then be used to test a building model for overheating, with automatic identification of the spaces where the worst overheating occurred and presentation of appropriate information on this to the user.¹ Therefore, modelling decisions that were implicit in the majority of simulation-based studies were made explicit in the IFE. The system was designed partly to provide feedback and guidance to the user and parts were implemented in ESP-r code. However, this initiative focussed on provision of a system and not necessarily on what designers need such a system to provide, although it did show that simulation knowledge can be explicitly expressed.

Performance assessment methods (PAM) (Clarke et al. 1996) were intended to define simulation procedures to determine the multivariate performance of a building model, and linked simulation actions (e.g. calibrate, simulate, identify problem areas, analyse results, postulate remedies and iterate) to knowledge (e.g. of reliable techniques, suitable criteria, appropriate design options and justifiable level of resolution). Instances of knowledge were attributes of a PAM and could be varied according to user and programme capability. PAM's are therefore a generic proposal for controlling simulation processes.

An empirical example of simulation knowledge being made available to simulation users is the ‘parametric module’ of EnergyPlus which can be selected to automatically run the analytical technique of assessing the effect on performance of varying a building parameter.² Similarly, in the Design Analysis Interface (DAI) Initiative (Augenbroe et al. 2004) ‘analysis functions’ identify and define a virtual experiment to be carried out on the model in addition to defining a data model and aggregating output data. The DAI used the analysis functions as part of a system that would enable expression of requests for analysis, and corresponding expert generated answers to those requests. The Integrated Performance View module of ESP-r also provides the capability of defining the required assessments and extracting specified performance metrics from the results (Clarke et al. 1996; Morbitzer 2003; Prazeres 2006).

The patterns explored in this paper have similar aims to the examples above in that they should define and make available analytical methods and meaningful simulation outputs, but are part of a system explicitly intended to make expert knowledge available to non-expert users (e.g. building designers) based on their needs. These needs therefore must be defined and used to inform which knowledge exactly should be transferred, rather than assuming that this is already known by simulation experts.

3. The concept of patterns

3.1. Patterns in the work of Christopher Alexander

Patterns are descriptions of recurring abstract problems in place making, together with instructions for abstract solutions, illustrated with practical examples and explanatory diagrams. The instructions are abstract and generic and designed to be modified depending on context, such that no two concrete solutions would be exactly the same but that each would successfully solve the problem described, because each is based on an analysis of how that problem has been solved before, throughout the history of human building and creation of settlements.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. (Alexander et al. 1977, x)

A total of 253 patterns are described that together address different aspects of the built environment, focussing equally on social and psychological aspects of space and culture, and on physical and material qualities.³ The scale of patterns ranges from cities and regions down to the individual parts of a building, and are arranged in a hierarchy of levels. They are intended to be used together and to link to one another. For example, a pattern for ‘Night Life’ (pattern 33) responds to the need to provide for the nightlife of a city, and the problem here is that most activities of a town or city close at night. The solution is to group together the small number of shops and services that are open in order to form a well-lit lively area. This pattern supports other patterns including ‘magic of the city’ (pattern 10) and ‘community of 7000’ (12), both of which need a measure of nightlife to work well. It also supports the pattern for ‘promenade’ (31) which should be a public and lively length of street. The ‘nightlife’ pattern is supported itself by patterns such as ‘carnival’ (58), ‘street café’ (88), ‘local town hall’ (44) and several others.⁴

As a greater number of patterns are successfully applied to solving problems in any one place, the greater is the quality of the place where they coincide and overlap. Use of one pattern can lead to use of further patterns at lower levels which support the first pattern, which itself can support patterns at higher levels. When the patterns are used together in a coherent way they become part of a pattern language and the places developed become ‘living structures’ in the world. Alexander is concerned with the qualitative aspects of design of ‘timeless’ human habitations, and proposes that by using patterns these qualities can be successfully reproduced in new designs. The patterns concept has been subsequently developed further partly through recognizing some limitations of effectiveness of patterns in practice (Alexander 1999) and there is more emphasis given to the processes of developing deeper structures underlying the patterns. The authors decided however to explore the original concept as it has since found uses in other fields.

3.2. Use of patterns in software engineering and other fields

The concept of patterns was subsequently adopted by the field of software engineering particularly with respect to object-oriented programming (Gamma et al. 1995; Buschmann et al. 1996; Fowler 1997). One of the main aims of using patterns in software engineering is to encourage the reuse of useful (and successful) methods and routines, such that a new code does not have to be written each time an identical problem or task is encountered, with the corresponding risk of errors being introduced and the cost in time required for testing and debugging. In principle, the reuse of tried and tested patterns can lead to an increase in stability and more efficient solutions, and it is proposed that the use of patterns by novice computer programmers can teach them expert knowledge, through learning by example (Stevens and Pooley 2000). Financial considerations, reduced development time and reduced ‘time to market’ are further reasons given. Component-based, modular systems and styles are also said to be easier to maintain over time (Stevens and Pooley 2000).

Educators have proposed the use of pedagogical patterns within the context of teaching (Goldblatt Anthony 1995; Bergin 2000; Laurillard 2012). Patterns can, for example, describe proven techniques for teaching complex concepts in the classroom, or how Information Technology is best used to support learning.

Borchers (2001) and others have proposed patterns for use within the field of interaction design, and Tidwell (1999, 2011) has outlined the need for a pattern language in human-computer interaction (HCI). Interaction design involves ‘designing interactive products to support the way people communicate and interact in their everyday and working lives’ (Rogers, Sharp, and Preece 2011). Examples of patterns are commonly used features of web pages such as web search tools, or the format of a web page and tools for its navigation. Patterns are seen as useful in these contexts because similar problems continually recur and can be resolved using a similar approach each time (e.g. the use of a search tool to enable searches through documents or web pages). Patterns in interaction design need to address not only the organization and structure of elements of an interface, but also how these change in time in response to user interaction (Cooper, Reimann, and Cronin 2007). Patterns can be seen as helping the user to make sense of complex and changing systems, and would seem to be useful where procedures and functions that solve regularly occurring problems can be modularized for re-use perhaps with small modifications.

Although patterns are used in these fields and in others, there is less evidence that corresponding pattern languages have been developed, and patterns generally tend to be used one at a time to address particular problems (Alexander 1999; Qian 2009). The work reported here looks mainly at the potential structure and use of individual patterns, and only briefly at how they might be used together.

3.3. Use of patterns to support building design decision-making based on simulation outputs

Given the on-going need for methods to support the use of simulation tools in building design, the precedents described above suggest that patterns might have a use in this field. Some problems recur and in particular the following:

• Problems of presenting relevant and useful information to the user who may have little experience with BPS or the time to become familiar with it. These problems involve the correct and productive operation of simulation and include questions of what type of analysis to carry out, what exactly to model, which results to display and how to learn to use BPS.

• Problems of how to improve building performance through the design of the building (e.g. how to reduce overheating, how to minimize heating energy use or how to achieve comfort conditions while operating in a passive mode).

Similarly to the case in architectural design where no two problems are ever exactly the same, no two problems in the design of low-energy buildings are exactly the same, due to differences, for example, in the climate, site and brief and how simulation is used. The question is rather whether any two situations or problems are similar enough such that they can be solved using a similar approach.

4. Methodology

To explore the concept further, the structure of the patterns was developed such that they could:

• Describe a generic abstract solution to an abstract recurrent problem in a similar way to Alexander's design patterns.

• Act as a means to enable communication and knowledge transfer between building designers and simulation developers and experts.

These aims led to development proceeding in two stages. The idea of linking abstract solutions to abstract problems within the context of BPS was adopted while formulating a wider framework (Bleil de Souza and Tucker 2013, 2014). This framework provides a system by which a range of information and data representations and analytical processes can be collected and assessed as to their suitability for use in informing design decision-making using thermal simulation tools from which user-centred simulation outputs can be produced. The framework relates descriptions of design aims and actions, modelling and analysis processes, metrics, interaction with data and types of data display system. Related instances of these elements of the framework form the underlying structure of the proposed patterns and we currently refer to these related elements as outline patterns.

The second strand of development explored some other features and qualities of Alexander's design patterns. A previously completed consultancy/research project was used to generate a number of outline patterns, which were then developed into patterns with greater similarity to Alexander's design patterns. The aim was to examine how patterns could best capture and transfer knowledge of building simulation for design decision-making. During this phase further questions emerged, many of which are not yet answered but which can foster further discussions and future work in this area.

Building designers were then interviewed to identify any recurring problems that these professionals faced and to ascertain whether patterns might have any practical use in their work. The results of the interviews were used to identify areas for further development.

5. Underlying structure of outline patterns

5.1. Design information

Outline patterns focus on connecting design aims with simulation outputs that are tailored to respond to these aims. Design actions are seen as actions of making changes to the forms, materials and components of the building and its operation.

There are two directions of inference between design and information:

• From the design of a building to a performance prediction.

• From a performance measure or criteria towards information on how to meet those criteria (Mahdavi 2004).

Therefore two different types of information are needed by a designer:

• A report on the consequences on performance of a design action(s).

• Advice for the designer on what design actions to take in order to achieve an aim.

The decision on which of these to use and/or how they might be combined can be inferred from identifying the aims of designers when using BPS. Satisfying these aims will in general imply the construction of a model(s) and running of simulations, together with the structuring of analysis processes that when applied to these models will allow meaningful outputs to be retrieved. This sequence of elements and events is described by an outline pattern (Figure 1).

Figure 1. Elements of an outline pattern.

Previous papers (Bleil de Souza and Tucker 2013, 2014; Tucker and Bleil de Souza 2013) have referred to these elements but they are briefly described here for clarity, followed by an account of how they are linked together through the expression of questions. The questions represent the designer's aims and determine the model settings and the type of analysis required to provide answers to the questions. They also specify the most suitable outputs for presenting information which enable design decisions to be taken in support of the aims.

5.2. Designer's aims

Building designers have in general five different design aims⁵ when using BPS, either directly or through consultants, to inform design decisions:

• Exploring a specific design strategy for its effect on performance.

• Understanding a specific performance result (why it happens).

• Meeting a performance target.

• Assessing the performance of a specific product.

• Optimizing performance and/or building parameters.

A system that supports the designer in achieving these aims is seen by the authors as key to productively use thermal simulation to assess and/or inform design decisions.

5.3. Model settings and analytical processes

An outline pattern specifies the details of the required models, the simulations to be run, analytical processes and any post processing of results. Model settings include details of model parameters that may need to be varied, climate files, time periods for the simulations and levels of modelling resolution required. Analytical processes are the different types of analysis that can be undertaken to address the designer's goals and include:

• Description of the results of a single simulation run.

• Comparison of the effects on performance of two or more design actions or design alternatives.

• Sensitivity tests: assessing the sensitivity of specified design parameters on an aspect of performance. Parameters can be varied either singly or in combination (Macdonald 2002).

• Elimination parametrics: the effect of each of a specified number of parameters is eliminated one at a time to assess the parameter's relative effect on an aspect of performance (Ternoey et al. 1985).

• Optimization routines: optimization of a specific performance metric(s) through variation of a specific building parameter(s).⁶

Other analytical techniques (e.g. uncertainty analysis) can be added to this list as required. There are implications on the choice of the analytical method on processing time and on the modelling required that are not addressed here.

5.4. Simulation outputs

Also specified are the metrics and representation systems that will be used to display simulation outputs. They provide information on:

• performance metrics,

• different types of suitable display systems,

• analytical processes used to generate the requested information and

• different types of data interaction afforded by the represented system.

Interaction with the data is structured as proposed by Shneiderman (1996):

• Overview: Gives the user a broader picture of a phenomenon.

• Zoom/filter: Allows the user to focus on an area of specific interest.

• Details on demand: Requires the user to actively ask for a specific type of detailed information.

• History: Allows the user to retrace steps.

• Relate: Enables the user to compare information.

Each specific aim can be connected to a specific type of analysis process, set of metrics and number of displays. A full description and exploration of these relationships is provided in a separate forthcoming paper.

5.5. Linking the elements of an outline pattern

The designer's aims are represented by questions from which model settings and analytical processes can be specified to produce information to allow the aims to be met. Each question has two parts;

• A standard part which refers directly to the aim and which allows an analytical process needed to meet the aim to be specified.

• A custom part where the user defines which design actions or changes associated with a design parameter are to be investigated.

For example, a designer might want to determine the effect on overheating of adding a specific shading device to a window. This aim can be represented by the generic question: ‘What is the effect on performance when a single parameter is changed?’ This question implies the use of an analytical process of comparison of performance before and after the parameter change. Therefore, the aim of determining the effect on performance can be explicitly linked to an analytical process. Similarly, the question ‘in respect to overheating, how sensitive is this building to the parameters of shade depth, width and height above the window?’ implies that a sensitivity test will follow.

The aims were used to generate a list of generic questions (Table 1) along with specification of the analysis process that could be used to answer the questions.⁷ The questions fall into two categories based on what type of information is produced:

• Questions asking for information on building performance following a design change.

• Questions asking for advice on how to proceed with development of the design, in line with the aims of the designer.

Table 1. Generic questions related to design aims in using BPS (from Bleil de Souza and Tucker 2014).

Index	Questions related to aims	Type of question	Analysis process
Exploring a specific design strategy
E1	How does this building perform?	Performance query	Descriptive
E2	How do these buildings perform in relation to each other?	Performance query	Comparison of two or more models
E3	What is the effect on performance when a single parameter is changed?	Performance query	Comparison with previous model
E4	What is the effect on performance when several parameters are changed simultaneously?	Performance query	Comparison with previous model
Understanding specific performance results
U1	What is causing the performance of this building?	Advice	Elimination parametric
U2	How sensitive is this building to design parameter X?	Advice	Sensitivity test
U3a	How sensitive is this building to user defined parameters X, Y, Z, … n ?	Advice	Sensitivity test
U3b	How sensitive is this building to automatically pre-defined parameters X, Y, Z, … n ?	Advice	Sensitivity test
Meeting a target
T1	How does this building perform in relation to target(s)?	Performance query	Comparison with target
T2	What is causing the performance of this building not to meet the target(s)?	Advice	Elimination parametric
T3a	How sensitive is this building to user defined parameters X, Y, Z, … n in relation to target(s)?	Advice	Sensitivity test
T3b	How sensitive is this building to automatically pre-defined parameters X, Y, Z, … n in relation to target(s)?	Advice	Sensitivity test
T4a	What are optimum values of user defined parameters X, Y, Z, … n to meet target(s)?	Advice	Optimisation
T4b	What are optimum values of automatically defined parameters X, Y, Z, … n to meet target(s)?	Advice	Optimisation
Assessing a specific product
AP1	How does this building perform with this product?	Performance query	Descriptive
AP2	What is causing the performance of this building with this product?	Advice	Elimination parametric
AP3	How sensitive is this building to parameters X, Y, Z, … n of the specific product?	Advice	Sensitivity test
AP4	What are optimum values of parameters X, Y, Z, … n of the specific product?	Advice	Optimization
Optimizing
O1a	What are optimum values of user defined parameters X, Y, Z, … n for best performance?	Advice	Optimization
O1b	What are optimum values of automatically defined parameters X, Y, Z, … I for best performance?	Advice	Optimization

The distinction between the two categories of the question clarifies which analytical process should be used, the information to be displayed and the information to be highlighted. The questions are generic in that they do not specify a particular aspect of performance, but simply represent a means of linking user aims to specific analytical processes and information outputs. When the questions are made more specific by explicitly stating which performance measure and building parameters are to be considered, it becomes clear what metric and output will be appropriate. Questions and aims explored in this work are supposed to address building designer's needs. However, the structure of linking question to analytical processes can be extended to include further user groups such as HVAC engineers, control engineers, etc., with their own aims in using simulation.

The authors find it interesting that apparently just a small number of generic questions can represent many, if not all, of the questions that a building designer might ask about the effects of design changes or potential design changes on aspects of building performance. Clearly, there are other questions (or variations on those in Table 1) that an expert researcher might ask, but for building designers the uses of thermal simulation can perhaps be seen as limited although nevertheless important.

The aim is represented by a question, which implies specific model settings and simulation processes. The outputs to be presented as an overview are specified, and also the level of interaction with the outputs that is to be provided (Figure 2). The overview is seen as the minimum amount of information needed to provide an answer to the original question, such that the building designer can make a decision.

Figure 2. Information required in an outline pattern.

In summary, outline patterns represent abstract problems and abstract solutions, in a similar way to Alexander's design patterns. The abstract problem can be stated as ‘What simulation output is required that will help the building designer to make design decisions?’ The abstract solution to this problem is ‘an output that provides the answer to the question posed by the building designer’. The abstract problems and solutions are made specific by stating which aspects of building performance are to be examined, and which building parameters (if any) are involved. In the following section, we examine how these outline patterns might transfer knowledge, and how other aspects of Alexander's design patterns and pattern language can inform the development of patterns more closely resembling design patterns. We will now refer to these patterns under development simply as patterns. However, the outline patterns remain as the underlying structure of the proposed patterns for design decision-making and are returned to at a later stage.

6. Development of Patterns

6.1. Knowledge transfer

Patterns can be constructed consistently using the elements described, and related examples already exist such as the parametric module in EnergyPlus, or the automatic generation of compliance forms (IES 2014). To test their capacity to carry knowledge, a report from a research consultancy project (Tucker 2012) was used. This study had investigated implications of future climate change for the design of a school building in the UK (Figure 3).

Figure 3. Computer model (Integrated Environmental Solutions) of Ellingham School designed by ECD Architects, London.

An approach to modelling using probabilistic climate files and for testing the performance of the building under future climate scenarios had been developed. This project was chosen because it produced information intended for use in making design decisions when combined with other information on project management, costs, etc. Two of the groups of experiments are outlined in Table 2. Each one represents ‘simulation knowledge’ that was developed over the course of the project represented in the form of a simulation pattern.

Table 2. Examples of patterns.

	Goal/question	Model settings	Simulation/analysis/ post-processing	Outputs (overview)	Interaction with outputs
1	Will the building meet BB101 overheating targets in 2020, 2050, 2080? What would the energy use be?^a	1. Base case: As per drawings/ specifications. Settings follow recommendations.^b	Descriptive analysis.	Text: BB101 PASS or FAIL.	Zoom: Location and time (produces Bar chart: Heat and cool energy).^e
		1a. Free-running.	Weather files:^c	Table of BB101 figures.	Bar chart: Heat and cool energy
		1b. With heat/cool system.	2020/H/90/DSY	Bar chart: Annual heat and cool energy.^d
			2020/H/50/DSY
			2050/H/90/DSY
			2050/H/50/DSY
			2080/H/90/DSY
			2080/H/50/DSY
2	Will the fixed shading as designed be sufficient until 2050, or should it be made adjustable or extendable?^f	1. Base case.	Comparative analysis.	Text: BB101 PASS or FAIL.	Zoom: Location and time (produces Bar chart: Heat and cool energy)
		2. No shading.	Weather files:	Table of BB101 figures.	Bar chart: Heat and cool energy^e
		3.100% efficient shading.^g	2050/H/90/DSY	Bar chart: Annual heat and cool energy.
		Each model simulated with:	2050/H/50/DSY
		3 * ventilation values (1, 3, 5 ac/h).
		2 * internal gains values (low and standard).

^a BB101 specifies the recommended overheating limits for UK schools.

^b All settings for ventilation, internal gains, etc. follow appropriate recommendations (e.g. from the Chartered Institute of Building Services Engineers). Simulations include free-running and for heating & cooling loads.

^c Probabilistic weather files are represented as ‘year/emissions scenario/percentile/file type’.

^d The outputs shown are thought to be the minimum required for answering the question.

^e Zoom into user selected time range and location (e.g. classroom).

^f The second part of this question is addressed by reframing it as ‘does the building need any shading at all?’

^g The ‘100% efficient shading’ model gives a result that indicates whether any shading solution will work. The range of values for ventilation and internal gains represent different scenarios.

The knowledge embedded in example 1 (Table 2) is that of asking relevant questions concerning building performance, and which model settings, weather files to choose, etc. A specific decision made was to use weather files representing a Design Summer Year, high carbon emissions scenario, at 90% and 50% percentiles. The 90% percentile represented a ‘worst-case scenario’, while 50% represented an ‘average’ probability of such a scenario occurring. These files were used to investigate the likelihood of passive measures working well under future climate scenarios. Answering these two questions requires a base case model to be simulated in a full free running and in a hybrid condition (i.e. HVAC running when necessary), with six weather files to represent future climate scenarios, and output information on whether the overheating criteria specified in Building Bulletin 101 (BB101 2006) have been met. The knowledge embedded in example 2 is related to the benefit of using shading devices under future climate scenarios. Therefore, it compares the base case (shading as designed) with models incorporating ‘no shading’ and ‘100% efficient shading’ (obtained by eliminating solar gains entering through the glazing in question). This comparison allows a decision to be made on the significance of the shading on building performance.

These patterns appear to carry some ‘knowledge’ of BPS that can inform design decision-making. The examples are not claimed to represent the best currently available knowledge, which instead might be arrived at by testing, by reference to accepted research findings and by consensus. The patterns however say little or nothing about how, why or when BPS should or could be used, and might be somewhat meaningless to a beginning BPS user. There is also no information on the significance of results, or how results might change given different model settings. It would be valid to conclude therefore that they might have some use for experienced BPS users such as consultants or instructors but not really for non-experts. However the how, why and when might be provided by instructions of some sort, and so a number of further aspects of Alexander's design patterns were briefly considered.

6.2. Communication of knowledge

A key strength or quality of a pattern as presented in ‘A Pattern Language’ is it's communicative power, employing a narrative style which ‘talks’ the user through the pattern and explains how it may be employed to its full effect within the wider environmental and design contexts. A template is used to record and communicate each design pattern and to give it structure. Two draft templates for patterns have been developed following those of Alexander et al. (1977), Gamma et al. (1995) and others. The user facing template (Figure 4) follows the layout and style of Alexander's pattern template, modified slightly to suit the audience who are assumed to be conversant (as users) with relatively complex software and have a broad knowledge of buildings and their systems.

Figure 4. User facing pattern template.

Figure 5 attempts to capture this communicative quality in a draft pattern for testing for overheating and BB101 compliance in a school. This simple pattern resolves the ‘problem’ of testing a model for overheating, and serves to illustrate how a pattern can communicate. This draft has a level of abstraction in that it contains no indication as to whether such a pattern would appear to the user as text or whether it would inform the design of an interactive interface system, or both. It ‘talks’ the user through the process of simulation, imparting information and knowledge on building physics and BPS. It employs a non-technical vocabulary which may suit beginning BPS users and represents a prototype that could be tested on such users. Pattern descriptions could be modified to suit different levels of user, enabling progression of skills. Computer-based, web and/or local links could lead to supporting information on regulations, performance criteria, information on model settings, etc. ‘Linking patterns’ are marked ‘#’ and are discussed below.

Figure 5. Draft template (user facing) of a pattern for testing room temperatures and comfort levels.

The details shown in Figure 5 will differ depending on whether the pattern is linked to the building model in such a way as to automatically set building operating parameters such as ventilation rates. A developer facing pattern template contains the technical information and follows the same format as the user facing template but with additional sections for the pattern elements and developer's comments (Figure 6). Patterns are intended to be modified to suit an individual BPS system and/or modelling software and the example shown here would be expanded accordingly to include such information.

Figure 6. Draft template (developer facing) of a pattern for testing reduction of overheating through shading.

6.3. Types of pattern

A quality of Alexander's design patterns is that the solution it proposes should resolve conflicts between opposing or misaligned ‘forces’ and should solve real problems (Alexander 1979). Section 3.3 identified two types of problem: those concerning the use of BPS and those concerning low-energy design per se. Patterns addressing problems of low-energy design may be proposed by observing commonly used and successful solutions to performance conflicts (e.g. conflicts involving heat flows or costs, etc.). Examples of solutions and ‘balancing of forces’ could include;

• Shading, as a solution to the problem of providing sufficient daylight and/or views together with the prevention of overheating through solar gains.

• Sufficient thermal mass with sufficient external insulation, as a solution to the problem of reducing summer overheating together with preventing the mass from getting too cold in winter.

A comprehensive range of such solutions to performance problems would need to be formulated such that the building designer would always have available the appropriate generic solutions to generic problems in order to further develop the design. Each ‘solution + problem’ (i.e. pattern) would then be developed as a virtual experiment(s), using the format of the outline pattern to make the full completed pattern.

Similarly, BPS-related patterns identify solutions to conflicts in the process of carrying out BPS experiments, such as reducing the level of complexity of a model to a more manageable but adequate level when simulation running time needs to be reduced. Several further types of pattern relevant to BPS have been identified including those that describe how models can be easily manipulated, controlled, copied, modified, etc. and may be analogous to patterns in object-oriented programming (Gamma et al. 1995) and in parametric design (Qian 2009). ‘Visualization patterns’ might be drawn from existing patterns on information visualization (Granlund, Lafreniere, and Carr 2001) and/or the HCI patterns of Tidwell (1999).

We propose that the low-energy design patterns can therefore contain BPS, modelling and visualization-related patterns and possibly others. These contained types of pattern can be used within the outline pattern (Figures 1 and 2) to create larger patterns addressing low-energy design. For example, a pattern that solves a modelling problem might be specified as part of the model settings required by the larger pattern. The larger pattern may be described using the templates and when tested and proven can be considered to be a design pattern with some of the qualities of Alexander's design patterns. The authors are currently developing and recording a range of such patterns.

6.4. Links between patterns forming networks

The linking patterns (marked ‘#’ in Figure 5) suggest a network of patterns. It is by linking patterns coherently that pattern languages can start to be formed (Alexander 1979). Although there seem to be doubts that working design pattern languages are viable, most pattern designers aim to build a language and believe that patterns cannot survive independently but need to be linked in some way, even if only informally (Qian 2009).

While future work might focus on the formal structures of such networks, it is largely outside the scope of the current paper. It is useful however to speculate on what such linking patterns might achieve and in terms of knowledge transfer the linking patterns might point the user toward:

• Further patterns that should or could be used, based on results produced by the current pattern and triggered by conditional rules acting on the results.

• Patterns which do not directly address an aim, but which contain useful guiding information as to what further actions, analyses and strategies to consider based on the results.

For example, a pattern that talked the user through an experiment to determine whether the building is likely to overheat could, if the building does overheat to a degree defined in the pattern, trigger access to patterns on different passive cooling strategies such as ventilation, thermal mass with night cooling, shading, etc. Quality assurance (QA) advice could be brought to the user's attention, for example, information on how to check results through further simulations. If this can be done then it is arguable that the how, why and when of using BPS can be communicated.

6.5. Hierarchies of patterns

Alexander's design patterns are described individually but, as the potential elements of a design language, are arranged in levels and are linked to other specified patterns with those at a lower level supporting those in the levels above. Design patterns are arranged in the three groups of global structures of towns and communities, individual buildings and the spaces and relationships between them, and building construction and detailing (Alexander et al. 1977). This hierarchy might be borrowed to generate ideas for patterns (Table 3). The levels correspond generally to the advice given in design guides on low-energy buildings (moving from a broad overview to detailed design) and therefore seem suitable to guide the formulation of individual patterns.

Table 3. Proposed hierarchy of patterns.

Level	Type/purpose	Modelling details/notes
High-level, planning related	Site analysis, guidance on climatic strategies, passive and low-energy strategies and renewable energy systems potential	Simple models (from a library) could be used to test concepts (e.g. heavy – lightweight, insulation levels, glazing for solar gains) and explore site and overarching design strategy
Mid-level, building related	Exploring building form, glazing ratios, insulation of building elements, preliminary calculations on renewable energy systems integration and site specific ‘rules-of-thumb’	Models (user generated) tend to have many defaults ascribed
Low-level, detailed modelling	Effect on performance of building parameters, plant efficiencies and effect of occupants	User-detailed model is constructed to carry out detailed building performance experiments

Higher level patterns might use a library of example building models or no model at all. For example, a pattern to report on climate and likely thermal strategies would focus on choosing the information to be presented to the user following analysis of a weather file. Another very simple example would be a pattern which requires the user to place a building volume on a site with surroundings modelled, and to note the times that sunlight falls on each part of the building. This is a well-established ‘solution’ to the problem of gathering information on how a building and its interior and exterior spaces will receive sunlight throughout the day and the year. It could be argued that there is no need for this to be considered a pattern, but the authors would claim that by making it a pattern it becomes conceptually linked to the patterns that solve more complex BPS problems, and therefore helps to ‘join-up’ the processes of thinking and experimentation needed to create low-energy buildings.

Mid-level patterns might explore the effects on performance of building form at an early stage of design, and would probably use a large number of default settings, contain routines that altered those defaults and made further simulations, and perhaps highlight the most performance critical building parameters. As such these patterns might have similarities with ‘rules of thumb’, but based on the use of BPS, with a modelled site and surroundings, and therefore potentially more specific.

Detailed level patterns might focus on the effect of specific building parameters (particularly those that building designers are concerned with) on performance. These patterns would rely on precisely defining the model settings, the post processing algorithms to be used and what information to highlight.

6.6. Structured and unstructured use of patterns

Patterns could be used ‘standalone’, but would gain significance and usefulness from being used alongside others, just as a simulationist carries out a series of BPS experiments, each one contributing towards a full appreciation of the problems and solutions. The capability of being able to repeatedly use appropriate patterns while investigating and refining performance is analogous to the overlaid and inter-related ‘dense use of patterns’ that Alexander advocates when designing environments of quality. We refer to these two types of use as:

• Unstructured use: any pattern can be started at any time, depending on the aims of the designer at that time. This type of use is intended to support the spontaneity and idiosyncrasies (Augenbroe et al. 2004) of multiple and disparate design processes.

• Structured use: patterns are linked together to support a particular design strategy.

Allowing the unstructured use of patterns is considered important as building designers must take into consideration many criteria other than performance related, and therefore do not want to be tied into fixed design procedures. The structure of patterns allows them to be used one at a time, at any time and in any order. The requirement that patterns can be used like this reflects how designers often approach the design of buildings as described by Schon (1988, 1991) (for a full discussion see Bleil de Souza 2012; Bleil de Souza and Tucker 2014). A structured use of patterns would attempt to follow more closely Alexander's proposal, in which patterns are used sequentially, one leading to the next, and where the patterns chosen for informing a design comprise a language.

While implementation of patterns is not addressed here, the process of selecting a pattern on a computer system might broadly follow Table 4. Users should be able to choose unstructured or structured use at any time.

Table 4. Outline of pattern selection procedure

Step	Description
1	Identify question(s) by selecting and modifying from a list (as in Table 1) or drop down menus, or through use of a natural language user interface (see e.g. Androutsopoulos, Ritchie, and Thanisch 1995)
2	Information retrieval method recovers/constructs/modifies appropriate patterns
3	User selects required pattern
4	Pattern produces any required input dialogue
5	Pattern runs simulations and produces outputs, options for interaction with results and links to appropriate further patterns

7. Patterns in practice: results of interviews

7.1. Introduction and methodology

Formulation of patterns may potentially be achieved through studies on how professional BPS users (e.g. consultants) contribute to the building design, to establish what analyses are made and when, and whether these are done consistently for specific design problems. Another approach is to ask whether building designers tend to use patterns or similar in their work, and if so, could the concept of patterns as outlined above be useful?

Interviews were held with five architectural design practices to gather their views on the concept of and potential uses of patterns. The practices varied in size from 2 to 35 personnel,⁸ and worked on a range of projects from small domestic work to large office developments and schools. The interviews sought to identify whether patterns or procedures of any sort were used in each practice, and whether there were recurring problems that might plausibly be solved using a system of BPS-related patterns. Preceding each interview, a short presentation was made that outlined the theory and structure of the proposed patterns. The semi-structured interviews (Bryman 2012) were based around questions on design management, communication and/or performance assessment. Follow-up questions were used where appropriate. Interviews were recorded, and the main points are summarized below.

7.2. Current use of modelling and simulation

Every practice used consultants (or internal groups acting as consultants) for energy modelling. Most practices carried out their own daylighting and solar studies. Some practices were unsure of what tools were used by the consultants, and some practices required only simplified modelling methods to be undertaken. No practice used BPS in-house, and some were unaware if it was used by their consultants. Modelling was generally used when required by planning to meet performance and renewable energy targets, although one practice use it for every project.

7.3. Management processes and procedures for modelling and simulation

A case-by-case approach towards energy performance modelling projects is used by all the practices. They do not use specific procedures or protocols for running projects, but do have consistent ways of approaching each job. Often the brief and/or contract type will determine the direction of the design process. The Royal Institute of British Architects ‘design stages’ also influence when work is done and reported on. As an example of consistency in approach one practice stated that theirs was ‘a common sense approach to design, good solar orientation, a fabric first approach, design of a good ventilation system … ’.

7.4. Recurring problems in practice

The interviews brought to light a number of specific problems that occurred repeatedly in practice and are summarized in Table 5.

Table 5. Problems identified in interviews.

Problems of communication: Communication problems occurred in relation to consultants, clients, planners and others and include:

Delays in getting feedback from consultants on building performance

Being unable through lack of knowledge and information to be able to discuss the recommendations of the consultant in terms of implications on the design (as opposed to simply having to accept them)

Feedback from consultants does not include information on how to change the design to improve it or why it is unsatisfactory (i.e. relative effect of parameters on performance)

Dissatisfaction with ‘separation’ of consultant from design process and development and the effects of this on the final design

Dissatisfaction with simplified methods used by consultants that result (in the opinion of the designers) in a ‘sub-optimal’ design

Problems of effectively displaying information to clients on relationships between design decisions, performance and cost

Use of one tool in the practice (e.g. daylighting assessment) but not the others required for the project (e.g. thermal)

Being unable to effectively share knowledge (e.g. on performance benchmarks for specific building typologies)

Problems accessing performance information: These types of problem typically occur at early design stages and include:

A need for sensitivity testing of building elements that designers are interested in manipulating

The need to guarantee to planners at an early stage a performance level, without understanding fully the implications that this will have on the design and strategy

Lack of procedures for testing proposed strategies throughout the design process

Problems involving costs: Costs were related to the building and its operation, and time spent on design-related work

Increased performance modelling costs at early design stages

Difficulties in relating capital, in-use and life cycle costs

The majority of problems therefore involved communication and access to building performance information (quantitative information and the meaning and significance of the information). Four examples from the interviews illustrate how communication and performance information can be bound together:

• One practice were able to satisfactorily carry out in-house daylighting studies within a building information management (BIM) environment, but depended on consultants to give advice on the thermal implications of design decisions. They did not want to do without the consultant but felt unable to productively discuss the design recommendations of the consultant, because of lack of information on how building parameters related to the thermal performance. Therefore, they had to ‘accept’ the recommendations, whereas ideally they would have wanted to discuss alternatives such that the best choices could be made.

• Another practice often needed to carry out a specific study to determine the ‘best’ ratio of glazed/opaque wall area for a specific building type (offices), but for each iteration the design had to wait for results to be returned from the consultants. These results did not give information on how the ratio could be improved to meet the performance targets or whether varying other building parameters could meet the targets given a particular ratio.

• There was a need to explore thermal performance much earlier in the design process than previously was the case because planning permission is often dependent on achieving specific performance levels. This was combined with the need to ‘freeze the design’ at an early stage because of the requirement for definitive drawings on which to base planning permission. This means having to make more final decisions about building parameters at early design stages, and information on the effect of building parameters on performance was very difficult to get.

• One practice had developed a shading system for offices with a different form and geometry for different orientations, acting also as a light shelf in some orientations. This solution was found to work very well and it was used where appropriate. Clients however usually queried the effectiveness of the solution in relation to its cost and thermal/lighting performance and much time was spent in trying to convince the client of the benefits.

Each of these examples seems to show that there is a continuing need for designers to have straightforward access to information on the relationship between building parameters and building performance. Every practice wanted a way of understanding the effect on performance of the building parameters in which they were interested in manipulating. The examples highlight the challenge of creating patterns that allow for virtual experiments (albeit constrained to certain geometric and material variables) and extracting informative and robust results that can be related to wider issues such as capital and life cycle costs. All examples are concerned with the management of information within the design process, and having information available at the right time.

7.5. Information needed by designers

The interviews produced many examples of what designers felt they needed in terms of building performance information, and how such information would facilitate their design processes (Table 6).

Table 6. Initial responses to patterns concept from building designers.

Communication and design management

Patterns could

facilitate informed conversations with engineers and consultants

allow designers to check on the results and recommendations of consultants and be able to query their advice

provide more information and insight into the results: information on which design parameters could be changed and by how much to improve performance

facilitate demonstration to clients of the advantages of a proposal

deliver reports in a user preferred format

assist in the timing of decision-making

hold benchmarks for energy, lighting and local benchmarks related to building control

hold ‘internal benchmarks’ (i.e. benchmarks chosen by the practice)

support ‘integrated design’ (i.e. integrating all aspects of design into the building)

Performance-related information

Patterns could

provide identification of potential performance problems with respect to building regulations at the start of a project

provide instant feedback on the effect of design actions

facilitate early exploration of design strategies

facilitate understanding of cause and effect (i.e. a building parameter's effect on performance)

be of use in developing modular or prototype rooms or buildings

facilitate life cycle costing and performance studies

Suggestions for related patterns

integrate lighting and thermal studies and show the results in a consistent ‘client-friendly’ format

test for overheating risks

sensitivity tests on specified parameters to identify alternative designs

determine window sizing

exploring ratio of opaque/glazed areas for office buildings

exploring effect of shading on daylighting and overheating/space heating energy within a context of costs

explore relationships between ventilation, CO2 levels and overheating in schools

refurbishment modelling (in the context of uncertainty of existing building element compositions)

rights to light modelling

7.6. Further comments

Some interesting comments were made about the patterns concept in general. One practice stated that providing ‘accreditation’ was the single most important function for a pattern. These designers wanted methods whose results have some ‘legal’ validity and could be recognized as professionally authoritative (e.g. to show compliance with regulations or to size a heating system). This type of requirement seems particularly true for small practices that need to employ external consultants but cannot afford to have them heavily involved in the design development throughout. This comment also raised questions of how quality could be assured through the use of patterns (if at all), and of who might provide such accreditation.

Other points made by the interviewees included:

• The patterns concept seems to offer a non-procedural approach: this approach would be supported by many designers as often they do not want to follow procedures.

• Integration of any new tools or system into BIM and other existing CAD tools is extremely important.

• The issue of risks and professional insurance must be addressed.

• Patterns must be fast to use and save time over existing practice.

• A combination of information is needed on why to solve problems and where to solve problems … not just one of these.

• All practices liked the 2D and 3D representations, and all were happy with a variety of representation systems.

The results of the interviews point towards the advantages of dialogue between researchers, software developers and building designers in order to uncover the structure of practice-based recurring problems, and to develop solutions.

8. Discussion

8.1. General comments

Overall, the designers interviewed tended to want methods that gave them broad and quick indications of how building variables and parameters contributed to performance results. They also wanted information to enable more productive dialogue with consulting engineers, and that was reliable and quality assured. All interviewees identified the potential usefulness of the patterns concept in communication with clients, consultants and internally within the practice. All practices had ‘recurring problems’ in these areas and expressed support for the idea of making simulation tools available to designers if possible.

8.2. ‘Custom patterns’

Each interview produced several examples of individual patterns that would be useful to the individual practice. The generic structure of the patterns proposed in this study can be made specific to a particular problem and solution in practice. Issues around implementation of patterns into software systems are not addressed here, but such work might explore the idea of ‘user-defined patterns’ in which the user could record and save patterns, perhaps by modifying a template pattern, or by being able to add links to supporting documentation and/or to other patterns. An individual pattern might have similarities with a simulation engine ‘constrained interface’, which is constructed to allow the user to alter only parameters relevant to a particular design issue (Clarke et al. 2012).

8.3. Automatic routines in patterns

Routines to automatically produce models, quality assure models or to make variations to model parameters can be included in patterns. These types of operations are already available in interface programmes and simulation codes (e.g. OpenStudio, ESP-r, DesignBuilder). The analytical processes (see Table 1) could in theory be automated and some already are.

Much of the practice of simulation is concerned with pattern recognition within the simulation results, and this may be a suitable process for automation. Because the intention of the patterns is to transfer knowledge of simulation experts to non-expert users, it is likely that extensive use would be made of automatic routines. Examples could include:

• Use of stochastic models of activity and operation of the building to determine robustness of building and systems performance to changes in use and operation.

• Use of rules to trigger scripts that lead automatically into the use of related patterns or present to the user a list of relevant patterns from which to select, so as to let the user customise the decision-making process.

8.4. Potential users of patterns

In addition to building designers other groups may find uses for patterns including:

• Educators: for transmission of knowledge and practices related to building typology, thermal physics, environmental design and the use of BPS.

• Continual professional development providers: for example, for experienced design professionals who wish to quickly reference information about unfamiliar building typologies and regulations and benchmarks applying to them.

• Other stakeholders in building design: for example, clients, funders, future occupants or any group with an interest in the performance of the building and where relevant information from simulation would help them to make a decision or become better informed.

8.5. Quality assurance

To use BPS effectively implies that the user (or system) must have some type of QA measures available. Patterns should therefore be quality controlled not only in their functional operation but in how and when they are used. QA in the use of patterns might be addressed by:

• Provision of sufficient user support in the BPS pattern itself through feedback as indicated in the user facing template (Section 6.2).

• Provision of PAM features within the pattern. Existing BPS software contains routines for checking, for example, for missing surfaces and for expected results falling outside expected bounds (IES 2014).

• Automatic ‘disabling’ of a pattern when the model settings or other simulation conditions are not as required.

• Giving control of pattern dissemination to BPS software providers and/or consultants who provide the QA.

• Requiring that users are in some way qualified or even liable for the use of patterns, if they are to be used without expert supervision.

8.6. Further development

Alexander and other pattern authors state that development is a collaborative process, with patterns being circulated for critique and modification, and for rejection if they do not work well enough. Further development of this concept would therefore benefit from input of software developers, building designers and researchers. Alexander and colleagues took 10 years to produce and publish 243 patterns, but with the imperatives on reducing the environmental impact of buildings the development of patterns could be shared with the BPS community.

The focus of this paper has been largely on ‘stand-alone’ patterns that can be used at any time and in any order or sequence to support individual design processes. In contrast, a ‘pattern language’ has only been selectively and partially addressed here, but should be explored further in any development of this concept in relation to BPS. We have also focused only on some of the obvious features of patterns rather than how they might support learning and inspire designers to create their own solutions. We have however noted their communicative qualities and envisage patterns as facilitating conversations between experts and beginners. Therefore, further work will address related topics in educational pedagogy and learning technologies and systems. Since formulating the concept, Alexander has proposed deeper structures underlying patterns and also discussed how computers and code can potentially influence the making of an ‘alive, humane, ecologically profound’ built dimension of the world (Alexander 1999) and these aspects will also be explored.

The patterns concept in general has been criticized on several grounds (often philosophical – see Bhatt 2010) including their potential to over-complicate what might be straightforward problems and solutions. Such criticisms should be carefully examined in relation to the potential use of patterns, although few would agree that getting BPS widely accepted and used in building design is a straightforward problem.

Further work will observe more closely the day-to-day practices of building designers in order to identify specific patterns useful to that practice and to determine the technical possibilities and implications of implementing them. Implementation of patterns has not been addressed here but should be in any further work, particularly because the method of implementation would influence the formulation of the patterns themselves. It is also intended to study the use of patterns for training building designers, where it appears that they hold great potential for transmitting ideas and knowledge in environmental design and BPS, just as the patterns of Alexander have been proven over time to transmit ideas and knowledge in architectural design.

9. Conclusions

This paper has made an initial exploration on the use of patterns as proposed in the work of Christopher Alexander and colleagues, to inform the construction of a BPS knowledge management scheme to aid design decision-makings in the support design of low-energy buildings. The design of low-energy buildings using BPS is seen here as consisting of solving problems of:

• Presentation of relevant and appropriate information to support the building designer in making design decisions.

• Building design and its relation to low-energy performance.

The recurrence of these problems has a parallel in the recurrence of design problems in the fields of architectural design, software engineering, interaction design and education. That patterns have found uses in these fields suggests that they may be of use in the structuring of simulation processes and outputs to support decision-making for low-energy building design.

The potential uses of patterns identified here are to:

• Provide support for design decisions by linking questions about the performance of a building to analytical procedures and outputs tailored to provide answers to these questions.

• Give non-expert users such as building designers access to the potential uses of BPS in design decision-making.

• Increase and enable dialogue between building designers, consultants, clients and other stakeholders through the use of patterns that represent expert knowledge and through which knowledge can be transferred.

• Support automatic routines for QA and sophisticated analytical processes such as optimization and parametric tests.

• Provide a repository of knowledge and an educational resource on many aspects of low-energy building design and on productive use of BPS.

To make simulation outputs available and useful to building designers suggests that knowledge on simulation could be organized into a system designed specifically for delivery to these users. The patterns proposed by Alexander may point towards a way of achieving this and to make it possible for all members of a design team to gain a level of control over the simulation process and its outputs, to support the design of low-energy buildings.

The authors acknowledge that they have just begun to explore the concept of a pattern language and only referred in outline to a number of the features and qualities of patterns. One conclusion is that it would be premature to describe a full range of patterns at this stage, or indeed any ‘finished’ patterns as these will of necessity be generated and refined collaboratively through further research in educational and practice contexts. It will also be necessary to consider to a greater degree the form (e.g. print, embedded in software) in which these patterns could be expressed.

The concept of patterns was considered by the designers interviewed to be worth pursuing further. The authors consider that the environmental challenges facing the built environment professions coupled with the potential of the patterns concept to address such challenges justifies further work on this topic. However, the paper is primarily intended at this stage to contribute to current debate and ideas on making BPS more accessible to a wider range of users.

Further work will address:

• Identification of potential classifications or ontology's of pattern under a number of different scenarios and themes.

• Detailed development of several types of pattern in practice and educational/training contexts.

• A deeper consideration of the potential and possible structure of a pattern language for BPS of low-energy buildings.

• A study of the use of patterns and pattern language in other fields to determine where and why they have been used, by whom and with what success.

Acknowledgments

The useful discussions and suggestions of the following are gratefully acknowledged: Dr. Paul Strachan, Dr. Jon Hand and Prof. Joe Clarke (Energy Systems Research Unit, Strathclyde University), Dr Ian Knight (Cardiff University), Alan Gillard and Carlos Nicolini (Gillard Associates), Neil Macomish (Scott Brownrigg Ltd), Toby Adam and his team (Gaunt Francis), Chris Loyn (Loyn & Co) and Katja Timmermann and Adrian Jones (Capita Symonds). The comments and suggestions of the reviewers of previous drafts are also gratefully acknowledged. The reported work was funded by the Engineering and Physical Science Research Council, UK.

Notes

1. See also Hand (1998) for a description of an ‘integrated building design system’.

2. See EnergyPlus Manual. This feature is also made use of in DesignBuilder.

3. The full range of patterns are listed at https://www.patternlanguage.com/

4. The high level or global ‘NightLife’ pattern has a social focus, but many of the patterns particularly at the mid- and low levels concern buildings and parts of buildings such as walls, roofs, windows, etc.

5. This list is open ended and subject to modification in the light of further research. It can also be modified if a different user is being considered. It does however seem uncontroversial as the goals stated correspond to those commonly found in practice.

6. It is assumed that suitable optimization techniques already exist or can be further developed, for example, to provide sufficient ‘robustness’ of the result.

7. These aims and questions have been observed by the authors as recurrent in practice and in educational contexts.

8. A total of 12 designers were interviewed (2 practices with 1 participant, 2 with 2 and 1 with 6).