Workflows

Planning

ESP-r gives the user a lot of freedom in the composition of models and the level of detail within each domain. This places the burden of careful planning on the user. Some questions you might ask yourself when commencing a simulation study:

What specifically do you want to find out about the performance of a design? E.g., is the building comfortable in summer?

Which physical quantity do you have to measure to judge this performance? E.g., what is the temperature and humidity in the main occupied areas?

What level of detail is appropriate for these performance questions (and measurements)? E.g., maybe only the south-facing offices need to be checked.

What boundary conditions would form a useful test of the design idea and simulation goals? E.g., simulate only peak summer conditions.

What follow-up questions might arise from this exercise? In other words, future proof the design of the simulation model as far as possible. E.g., ...

One successful workflow which reflects this is:

Review the materials and constructions used in the project and check whether these are available in the corporate ESP-r databases or whether model specific databases need to be setup. Create placeholder materials and constructions if necessary.

Review the types and diversity of activities in the building(s) and plan the master calendar of day types (adding day types is tedious!).

Consider options for environmental controls but delay investing time in entering details until the initial free floating assessments indicate the patterns of demands.

Consider air flow paths within the building and whether an air flow network or CFD domains are required.

Decide on a zoning strategy and the level of detail in each zone. Then make a note of critical dimensions from the plans, sections, and elevations for subsequent reality checks.

Plan the sequence of zone creation and interface facilities and the naming scheme to apply to zones, surfaces, casual gains, etc.

Decide who in the team is best equipped to implement different aspects of the planned model, who does the reality checks, what computational resources are required as the model evolves.

Model creation

In ESP-r the Project Manger (prj) is the core application for managing databases, defining the form and composition of zones, defining what is happening within zones as well as setting up the parameters of assessments to be run. It will invoke other tools required to increase the resolution of the model (e.g. pre-calculate shading and view factors) as well as invoke the simulator bps and recovery of predictions res.

Zones begin either as simple shapes which are then evolved, as extrusions from floor plan coordinates or as explicit lists of user supplied vertices and polygons. A typical sequence is shown below:

Another approach is to digitise from image(s) of floor plan(s). In this case a sequence of zones (decided in the planning stage) can be input in a single session, optionally inserting doors, windows and furniture origins during the session). The zones can then be adapted and attributed as required.

Model evolution

The Project Manager manages the evolution of models. It knows the dependencies in the model data structures and within the suite of applications. Changes are detected and either resolved, a suggested action is provided or the relevant facility is invoked to resolve the dependency. In some cases you can delay dependency resolution until you have completed a set of changes.

ESP-r uses a distributed file regime for models. Different parts of the model data structure are written to different files. For example, controls are held in a different file from air flow networks. Changes in a subset of the data model are applied to the relevant files. ESP-r provides few facilities to undo changes which have been written to file - users are in charge of their own backup regimes.

Model variants

ESP-r provides facilities to manage the creation of model variants. For example, if a version with heavy weight partitions is required then renamed copies of the relevant files will be created. The user can then use search-and-replace facilities to substitute constructions without touching the original model files.

Model quality control

ESP-r includes a facility to generate a model contents report. There are options to include or change the level of verbosity on a topic-by-topic basis. The contents report is designed as a complement to the user interface with the goal of ensuring full coverage of the underlying data as well as derived information and user documentation. Chapter 13 of the user manual discusses the contents report and explains its syntax. The updated February 2018 version can be found at: download.

Model contents reports are also snapshots of the model and many users create contents reports as the model evolves and then use visual differencing tools to check for specific changes. The image below shows a side-by-side comparison between two different environmental control variants:

And the image below shows differences after the explicit mass of a desk has been added to a zone:

Defining assessments to be run

The ESP-r model configuration file can incude definitions of the assessments to be run e.g. a typical winter week, the warmest summer month, the year as five seasonal assessments. Each simulation parameter set is named and includes definitions of the period of the assessment, the number of startup days, the timesteps for each domain and the names of the results files to be created. These are typically defined to reflect the project goals. The name of the simulation parameter set can be passed to the simulator to ensure repeatability of assessments and to automate assessments.

Extracting performance data

ESP-r has several options for extracting performance data. The default mode is to use the res module interactively. It is also possible to drive any ESP-r module via keystroke sequences (each menu item has a key character) that have been recorded into a file. This is usually accomplished via invoking res in text mode and in a separate editor recording the keystrokes used. Data extracted can be directed to a file. An example of such a script which is passed the name of a results file and issues keystrokes until the marker XXX is found. This is shown below:

#!/bin/csh
# take current model and extract monthly report as well as
# hours over for 24 25 26C unfiltered and filtered for occup.
set RESFILE=$1
res -mode text -file $RESFILE< # redirect output
$RESFILE.data
$RESFILE results
f # energy delivered
a # stats
h # heating cooling
g # all sensible and latent
-
l # monthly stats
b # nearest 100wh
c # hours above
b # temperatures
e # resultant
24.0
b
a
24.0
+ # filter
b # occupants
b
e
24.0
b
a
24.0
> # switch back to screen
-
-
-
XXX

Modelling the unusual

ESP-r is a general purpose simulation tool that allows opinionated practitioners to design and create models of unusual designs. In the figure below existing entities and facilities have been combined to explore an earth-tube air tempering design. The earth tube is explicitly defined from a series of thermal zones with a (controlled) flow network used to transport air. The tube wall construction on the top, sides and base include 1-2 metres of earth and are bounded by suitable earth temperature profiles. Heat transfer coefficients suitable for the velocity in the tubes are imposed and the temperature evolution along the length of the tubes over the year follow expected patterns. In reality the tubes would not be so close together and would probably be round rather than rectangular in section.