Welcome to umi Online Documentation

The Urban Modeling Interface (umi) is a multi-year effort, led by the Sustainable Design Lab at MIT, to develop an urban modeling platform to evaluate the environmental performance of neighborhoods and cities with respect to operational and embodied energy use, neighborhood walkability, access to daylighting, urban food production and district-level energy supply analysis. umi is a design environment for Rhinoceros 3d (Rhino) and includes an application programming interface (API) for researchers and consultants interested in adding additional performance modules and metrics. Focus users are urban designers and planners, municipalities, utilities, sustainability consultants and other urban stakeholders. umi files can be generated form scratch in Rhino or via the UBEM.io web app. UBEM.io also supports the results comparison of multiple umi files.

Requirements

UMI is a plugin for Rhinoceros 3D NURBS modeler. To use UMI, you need the following software and hardware:

Hardware

A computer running the Windows operating system. UMI does not currently run on the Mac operating system.

Software

The latest version of Rhino 7. (UMI does not work with Rhino 6.) A free, fully functional 90 day trial is available from the McNeel web site.

Installation

Download & Install

To download UMI, go to the project web site, downoad the installer and run it. This video tutorial walks you through the process of downloading UMI and starting your first project.

Learn UMI

To get started learning UMI, it is recommended that you follow the video tutorials on the Sustainable Design YouTube channel. You can download the UMI project files used in the tutorials below.

Tutorial 01 | Installation

Tutorial 02 | Model and FAR

Tutorial 03 | Operational Energy

Tutorial 04 | Embodied Energy

Tutorial 05 | Mobility

Tutorial 06 | Results Viewer

What is an UMI bundle?

UMI stores all project information in a single file called an UMI bundle. The file has the extension FILE.UMI and has the format of a Microsoft Windows ZIP archive file. When you open an UMI bundle, the project content is extracted into a temporary directory on your computer. While you are working in UMI, files in that directory get updated and/or created. When an UMI project is saved, the directory content is saved back into the UMI bundle.

To access the content of an UMI bundle, rename the file extension to FILE.ZIP and open the file. A typical bundle content is shown below.

The main directory contains the Rhino geometry file (.3dm), the climate file (.epw) and the template librabry (.json)> Under sdl-common other, project-specific files may be stored that belong to individual modules.

Starting a project

To start a new project, open Rhino and either type “UMI” on the command prompt or left-click on the UMI icon in the UMI toolbar.

The umi toolbar

To run UMI properly, it is key that the working units of your Rhino file are in meters. To change them, in Rhino, go to > File — Properties — Units — Model Units : Change to “meters”.

Opening/Creating a project

When working with UMI projects, it is important to use the umi functions and NOT the Rhino commands for “Opening” and “Saving” a project. Umi creates it’s own file system (*.umi) which is a package containing all relevant files and data needed for a project.

To create a new project, simply click on the UMI button and select “open project” or “new project” and browse to the folder location of your choice. Once a project has been opened.

The umi menu

Configuring Site Parameters

To configuring your project’s parameters, click the “Project” button in the umi toolbar:

The umi panel opens, with the “Project” tab active:

Note that new projects use the Boston Logan Airport weather file, a default template library, and the default amenities profile. Within umi, blue text indicates default values.

To select a new weather file, click the “Import” button:

Navigate to and choose your desired EnergyPlus weather (.epw) file. Notice how the location text is not blue after a new file has been chosen.

To customize your building templates, click the “Edit” button:

The template library editor will open. Make any changes you desire, and remember to save! Notice how the template library text is not blue after changes are made. Whole template libraries can also imported into and exported from umi projects. Watch out - existing changes will be overwritten when this happens!

The third setting allows you to provide a custom “amenities profile” for mobility calculations. The default profile is usually sufficient, but to learn about providing a custom profile, see Design Accessibility.

Saving a Project

All umi project geometry, settings, and simulation results are stored in a single .umi file called an umi bundle. The location of the bundle is specified when you create a new project, and whenever you save your Rhino document, this bundle is re-exported automatically in the background. The bundle includes the project’s Rhino scene file, the epw weather file, building modeling templates as well as all simulation results in an SQLite data base, so you don’t need to include those separately if you transfer the bundle to a different computer.

Note

Please note that an .umi file is just a compressed Windows.zip file, meaning that you can access all data related to your project directly. The purpose of the bundle is to streamline your workflow and to share and archive project data.

If you wish to change the location of the current umi bundle, use the UmiBundleSaveAs Rhino command. There is no toolbar button to invoke this command - you have to type it manually into the Rhino command window.

To export a copy of the current umi bundle without making it the “working” copy, use the UmiBundleSaveCopy Rhino command. Like the UmiBundleSaveAs command, there is no toolbar button for this command, and you will have to type it in yourself.

To export a project’s building template library, use the “Export” button of the umi site settings tab:

To export a project’s geometry, use the standard Rhino SaveAs command (this is the command invoked by selecting File > Save As… from the Rhino menubar). The project’s working Rhino document will change, and standard geometry saves will now modify this new version.

Model Setup - Buildings

Buildings are one of the key elements of an UMI project, used by most modules. In UMI, buildings are represented as building massings, i.e. outer envelopes including facades, roofs and external floors. In Rhino, a building is represented by a single volume modeled as a “boundary representation” or “brep”. A brep in Rhino can be generated by a variety of means, such as the extrusion of polylines and curves, or the repeated application of Boolean operations (such as union or intersection). If a building contains multiple occupied volumes, these should all be part of a single brep. However, additional exterior components (like shading devices) should not be modeled as part of the building - these objects should be placed on separate context layers. For a brep to be an acceptable building massing, it has to fulfill the following conditions:

• The brep needs to be “airtight”.
• The brep’s surfaces must all be planar.

As long as the above conditions are fulfilled, the brep’s facade surfaces can have any orientation. “North” is always the direction of the y-axis.

Step 1: Building the brep geometry

One of your first tasks when starting a new umi model will probably be constructing its buildings. In this example, a nontrivial building with two volumes is generated by creating each volume independently and then “joining” them into a single brep.

Steps to create a building volume

Step 2: Adding the building to the “Buildings” layer

When umi starts a new project for you, it creates an “umi” Rhino layer, with sublayers corresponding to various objects that umi uses. One of these sublayers is the “Buildings” layer, and this is the layer on which all building breps must be placed in order for umi to “see” them as building objects.

Some of the layers created when an umi project is started

You can create any sublayer structure within the Buildings layer that you want - umi will “see” buildings on any sublayers that are visible when you run a simulation. This is an essential way to keep large projects organized.

When you assign building settings to an object (see next section), umi will automatically move it to the Buildings layer for you if you forgot, but it’s best to do it yourself so you don’t lose track of any buildings.

Step 3: Assigning a name and a template in the “Settings” panel

After creating a building’s geometry and adding it to the Buildings layer, its properties must be specified. This is done using the Building Settings Panel, which can be opened by clicking on the “Building Settings” button of the umi toolbar or through the command “UmiOpenBuildingSettings”.

The umi panel will open with the “Building” tab active.

The “Building name” field contains the user-specified name for the umi building. This is the same as the Rhino object name; changing one will change the other. Umi offers an “UmiMultiname” Rhino command that can be used to automatically assign numbered names to a collection of buildings all at once.

The “Building template” field allows you to select the simulation template to apply to this building. The options are drawn from the currently-loaded building template library, which can be modified in the “Project” tab of the umi panel. (See “Configuring site parameters” in the User Guide.)

You can assign a template to multiple buildings at once by simply selecting all of them before making your selection from the combobox.

Step 4: Assigning other simulation properties

Once a template is assigned to a particular building, additional settings are configurable.

The building’s window-to-wall ratio (WWR) represents the percentage of the building’s façade area that is glazed. Umi allows the specification of a different WWR value for each façade orientation. (If your building is not perfectly compass-aligned, umi will use the closest compass direction for each façade surface.)

The building’s floor-to-floor height is the height between each story’s floor and the floor of the story above it (umi assumes uniform story height). If the building’s height is not evenly divisible by the provided value, various simulation modules will perform differently; refer to the individual documentation for each simulation module to learn what will happen.

Note

The advanced settings section includes a series of modeling parameters intended for advanced and experimental use of the energy module. Parameters are detailed in section Shoebox Model. The default values for these fields are sufficient for general use.

Model Setup - Template Editor

The Template Library Editor is an independent application provided with umi for the creation, management and edition of XML Template Library Files (TLF). TLF files are the open format used by umi to exchange and store information about materials, constructions, schedules, thermal loads, spaces and buildings. This section explains the basic characteristics of the TLF and the basic controls of the editor.

The XML Template Library File

The Template Library File (TLF) is an XML type file with a specific structure in which all building and space properties, both thermal and environmental, are stored for multiple building types. It includes both a library of building definitions, and libraries of all their data dependencies.

Within the file, these categories are listed as XML objects, grouped by the previously named types, and can be created and edited both through the use of the template editor, and directly in any text edition software (See Figure below for a diagram of the data structure). To know more about the TLF file format and its importance in building performance simulation in design you can access the academic paper “Towards standardized building properties template files for early design energy model generation”, accessible in the following link.

The template library file structure

Opening a TLF file and navigating contents

You can open the Template Library Editor, from the “Project” umi panel by clicking the “Edit” button. The application will pop up in a separate window, and immediately open the TLF file currently loaded in your umi file. If you did not change the original file, you will see the default library file opened.

Template Editor Main Window

Additional file management commands are accessible from the “File” menu at the top left. You can open a different TLF by clicking “Open”, and finding the file in the browser window. You can as well save the file with a different name through “Save as”. Finally you can “Save” the file under its current name. Note that all changes you make on the library will be lost if you do not save the file before closing the editor. If the file you modify is the same one you have loaded in umi, changes will be immediately applied to your file, but if you rename the file remember to load it in umi.

Adding and modifying components in a TLF file

Todo

this section needs to be drafted

Basic content modification

Each component data type in a library file has different data fields accessible within the Template Editor, used in different modules of umi. This section provides general directions about how to manipulate these fields. However, in order to know more about the specific meaning and interpretation of the fields, you can visit the “Embodied Energy” and “Operational Energy” sections of this user guide.

You can add a new component to the table by clicking the “Add Component” button

Model Setup - Context

In addition to the Rhino layer for buildings, a new umi project has a variety of other context layers for other objects relevant to various aspects of urban simulation. Each of these is a sublayer of the “Context” layer, which is in turn a sublayer of the “umi” layer, and is explained below.

Streets

The umi mobility analysis module relies upon the existance of a suitable street network for the site. This network should exist on the Rhino “Streets” layer. For details on setting it up, refer to the relevant section of the user guide.

Site boundary

The “Site boundary” layer contains closed polylines that mark the boundaries of the site. The total area enclosed by these polylines is used to calculate the site Floor Area Ratio (FAR). Please note that the site area should not includes streets and public sidewalks. See the Site Analysis Module for details.

Parks

Objects on the “Parks” layer can be used in mobility calculations. For details, see the relevant User Guide section.

Shading

Objects on these layers are used for operational energy and daylight simulations. Objects on the “Shading” layer are used to calculate shadows cast on simulated buildings. This is used for shading objects that do not touch the buildings to be analyzed.

Boundary Objects

Boundary objects are similar to the shading objects. They are used for contextual shading. However, on these objects an adjacency test is performed in order to detect adjacencies and adiabatic surfaces. Boundary objects have to be closed breps.

Water bodies

This layer consists of surfaces that correspond to outdoor bodies of water such as rivers and swimming pools. This layer is currently only used by an experimental water use module.

Irrigated land

This layer consists of surfaces that correspond to land surfaces on site that are actively irrigated. This layer is currently only used by an experimental water use module.

Site Analysis Module

Umi can calculate a site’s Floor Area Ratio (FAR), which is simply the ratio of the total gross floor area of each building on the site to the area the site itself occupies.

In order to perform an FAR calculation, two criteria must be satisfied. First, a floor-to-floor height for every building on the Buildings layer must be set, which requires that each has a building template assigned, as well. See Model Setup - Buildings for details. Second, a ground surface must exist on the “Ground” layer. This must be a flat, closed surface. Multiple ground surfaces can be defined; their area will simply be added together.

The FAR calculation can be executed from with the umi panel’s Simulate tab. It is located on the first simulation sub-panel. The “Recalculate” button will perform the calculation and display the result. The button simply executes the “UmiCalculateFAR” Rhino command, which can also be directly invoked.

FAR results are never saved within the umi bundle, and must be recalculated (if desired) every time a project is reloaded.

Energy Module Overview

Input Geometry

Insolation Analysis Mesh
[high(red) low(blue)]

Clustering

low - insolation - high

Shoebox clusters

The operational energy model simulation uses your umi buildings and building template settings as well as the shading geometry on the umi shading layers. A small input geometry example is shown in Fig. 8.

First your building envelope is subdivided into floor volumes according to your floor to floor height settings in the building template. Along the facades of each floor volume a solar insolation analysis is performed using Radiance / GenCumulativeSky. Internally your geometry is meshed and then handed over to radiance. Fig. 9 shows a typical result of this insolation simulation.

This radiation data as well as the basic facade surface orientation are then used to cluster facade regions of each building by solar micro climate similarity - see Fig. 10 for an example. Each color represents a cluster. The number of clusters is a user setting and can be specified for each orientation (a typical cluster count per facade is two).

The Shoeboxer then assigns an area weight to each cluster centroid. This centroid is then also the location for a shoebox model that then represent the cluster. See Fig. 11. Each Shoebox or Cluster is written out as IDF file and is simulated with EnergyPlus. The final simulation step is to gather all shoebox data and aggregate the building result. For further details regarding the method please refer to the reference paper.

Shoebox Model

The Shoebox model is based on the EnergyPlus “ZoneHVAC:IdealLoadsAirSystem” component. It models a core zone and a perimeter zone. Mechanical Ventilation and Natural Ventilation are modelled using the “DesignSpecification:OutdoorAir” and the “ZoneVentilation:WindandStackOpenArea” components.

Advanced settings under the Building tab

These settings adjust the parameters for the shoebox model used for the energy simulations.

Variable	Default Value	Explanation
Core depth (m)	3	The depth of the shoebox core zone.
Room width (m)	3	The width of the shoebox.
Perimeter offset (m)	3	The depth of the shoebox perimeter zone.
envr	0.1	The external sensor spacing for the annual solar radiation incidence analysis that determines shoebox location.
fdist	0.01	The internal sensor spacing for the annual solar radiation incidence analysis that determines shoebox location.

Larger values of envr and fdist reduce accuracy but speed up simulations, especially with large numbers of buildings. Radiation sensor generation and anlaysis tends to be the biggest bottleneck in running large models. However, modifying fdist and envr is not reccomended.

End uses

End uses are reported using EnergyPlus Meters for each shoebox and multiplied by a weighting factor. A mapping of the EnergyPlus meters to (=>) the UMI Results name are shown in the following table.

EnergyPlus Variable	UMI Output
Zone Lights Electric Energy	SDL/Lighting
Zone Electric Equipment Electric Energy	SDL/Equipment
Zone Ideal Loads Supply Air Total Heating Energy	SDL/Heating
Zone Ideal Loads Supply Air Total Cooling Energy	SDL/Cooling
Water Use Equipment Heating Energy	SDL/Domestic Hot Water
Zone Windows Total Transmitted Solar Radiation Energy	SDL/Window Radiation

Accessing the Shoebox IDFs

If you want to access the idfs created for each shoebox, go to c/umi/temp/energy after simulation. Under two filename subdirectories, open the eplus folder. From there you will find “group#” folders, with as many groups as there are templates. Each group has a number of sample folders under it. The samples are based on the number of shoeboxes required by the radiation mapping. You can navigate to an individual sample and open up the .idf file from there and simulate in the standard EP-launch. If you want to process the resulting data, you can use the command “UmiExportShoeboxWeights” in the Rhino command line. This command creates a .json file that maps each shoebox file back to the original model. The weights can be used to extrapolate the individual idf results out to the full model results if repeated across all samples and groups.

Life Cycle Impact

Umi 3.0 introduces the first version of its Life Cycle (LC) module, which currently allows for the calculation of basic embodied environmental impacts associated with construction materials, such as Embodied Energy and Embodied Carbon. The purpose of this introductory section is to identify the available metrics and calculations in the current version.

Purpose and metrics

Given the contribution of the built environment to GHG emissions and fossil fuel consumption, the search for sustainability in its design mostly focus on the energy impacts of buildings happening due to their operation. However a holistic look to the energy and emissions impacts of buildings and cities needs to take into account those impacts happening in other phases of the life cycle of buildings such as, production, transport, maintenance and disposal of construction materials. These impacts also caused by the production of the urban built environment, although typically smaller than those coming from operation fuel consumption in the building lifetime, become more relevant in the design of high efficiency or net zero urban developments.

Typically these fuel and emission impacts associated with materials are added up in each life cycle phase through Life Cycle Assessment (LCA) methodologies to generate so called “embodied environmental impacts” of a building lifetime. In the current version of umi two embodied metrics are available:

• Embodied Energy (EE): It represents all fuel consumption (Typically from non-renewable sources) which happened through the lifetime of a product (or building), expressed as primary energy (kWh or MJ). The equivalent impact category in an impact assessment method such as TRACI (US EPA) would be Fossil Fuel Depletion. In umi, building results are expressed as kWh of primary energy.
• Embodied Carbon (EC): In a parallel manner to EE, it represents the GHG emissions through the lifetime of the product (or building). The term “embodied carbon” sometimes is used referring exclusively to CO2 emissions and measured in kgCO2, ignoring the effect of other greenhouse gases. In other cases it is used to referring to CO2 emissions equivalent and measured in kgCO2eq, being then an equivalent to the impact category of Global Warming Potential (GWP) in a method such as TRACI. In umi, building results are expressed as kgCO2 only. However the results units depend only on the units of the properties introduced in the Template File Editor. If you prefer to use kgCO2eq introduce such values when defining materials and constructions.

Life Cycle calculation in umi

The Life Cycle module in umi takes as inputs EE/EC data about materials and building massing, and performs a simplified Life Cycle Inventory calculation providing yearly results for both metrics, for the selected lifetime of the building. Note that it is not a complete LCA tool, such as other commercial more complex software suits focused on LCA modeling for products and materials, and it does not include a validated dataset for environmental properties of building components. The umi Life Cycle module focuses on the accounting of materials and geometrical components in a building, generating an approximate “Bill of materials” and allowing for the calculation and visualization of multiple buildings at a time. To know more about the methodology you can find here the conference paper from Building Simulation 2013 in which it was presented.

Depending of the boundaries considered in an LCA, EE and EC can be expressed as Cradle-to-Gate (Only considering production and manufacturing processes), Cradle-to-Site (Also including transportation to the site of use) and as Cradle-to-Grave (Including also use and disposal phases). In umi the three approaches are possible through the use of the following template data inputs:

• Production EE/EC by kg of material
• Transport EE/EC and average distances by kg of material
• Assembly EE/EC by m²; of construction
• Replacement/maintenance rate and yearly schedule
• Disassembly EE/EC by m² of construction

In the calculation umi will use the amount of surfaces for each envelope assembly and estimate amount of interior elements such as floors, structure and partitions to generate results only for the lifecycle of materials. In future versions the Life Cycle module will allow for the automatic inclusion of operational primary energy and carbon in the use phase into the calculations. If you want to do a complete life cycle impacts calculation using the current version, you will have to take yearly results in energy consumption from the Operational Energy module and add them by year to the embodied impacts results. Note that in that case the energy load results generated by the Operational Energy module will have to be converted into primary energy or carbon emissions using the appropriate conversion factors for each fuel type.

Life Cycle - Data Inputs

Embodied energy and carbon calculations in umi are based on a set of environmental parameters defined in the Template Library File (TLF). The TLF does not only include life cycle data inputs, but many others used in different modules within umi. This user guide only focuses on describing in detail those data inputs required for the Life Cycle module, within Material, Construction, Structure and Building definitions. To know more about the TLF and its management through the Template File Editor you can go to the Model Setup - Template Editor section of this user guide. In order to learn about the definition of thermal properties you can go to the Energy Module Overview section of the user guide.

Life Cycle data in Opaque/Glazing Materials

All life cycle related inputs within Material components are located in the “Environmental” section. They characterize, for each opaque or glazing entry, the Production, Transport and Maintenance life cycle impacts in terms of Embodied Energy and Carbon.

The first section (1) has two fields: “Embodied Carbon” and “Embodied Energy”. These refer to the impacts in production and manufacture of a kg of the material in question, measured in a Cradle-to-Gate manner. The units selected are the most typical ones in existing databases: MJ/kg for primary energy and kgCO2/kg for carbon. A common and validated reference for these values is the Inventory of Carbon and Energy (ICE) developed by the university of Bath.

The second section (2) has also two fields and is used to define replacement rates for materials during the lifespan of the building. “Substitution Step” is defined as the duration in years of a period of replacement (e.g. There will be interventions in this material type every 10 years). “Substitution Rate” is a ratio from 0 to 1 which defines the amount of the material replaced at the end of each period of replacement (e.g. Every 10 years this cladding will be completely replaced with ratio 1). Notice that you can define different replacement ratios for different consecutive periods, introducing them separated by commas. For example, if you introduce the series “0.1 , 0.1 , 1” after the first 10 years a 10% will be replaced, then after 20 years another 10%, then after 30 years a 100%, and finally the series would start again in year 40.

The third section (3) is used to define the transport impacts through three inputs. “Transport Distance” refers to the average distance in km from the manufacturing site to the building construction site. “Embodied Energy/Carbon” refer the impacts associated with the transport by km of distance and ton of material. These values are typically defined by vehicle (Truck, Train, Boat, etc.) and size and can be found in fuel efficiency publications.

Life Cycle data in Structure Constructions

The “Structure” component under constructions is an special type of construction not associated to any particular geometry component in a building, but the complete structural material system defined by m² of floor area. It is exclusively used in life cycle calculations and is defined in three main sections: “Typology information”, “Materials” and “Environmental”. The first (1) includes data only to be used for structures classification matters in this version and has no implication in calculations.

The second (2) allows for the definition of the different materials within the structure type (e.g. Concrete and Steel in a reinforced concrete structure). You can add a new material by clicking in the first empty Material cell and selecting form the list. Then define the amount of that material per m² typically present in that type of structure (Normal Ratio). In future versions of umi you will be able to define high load ratio for structures exposed to seismic actions or high winds.

Finally the “Environmental” section has equivalent fields to those in other construction components and can be filled following the directions given in the previous point.

Life Cycle data in the Building Template

The building template component includes two types of inputs used by the life cycle calculations in umi, but in some cases also shared by other simulation modules. The first is the Lifespan parameter, defined as an integer number that represents the number of years a building is supposed to last, and the maximum number of year the module will produce results for. The second one is the “Partition Ratio” parameter, as an additional input exclusively used by the life cycle module, which refers to the number of lineal meters of partitions (Floor to ceiling) presenting in average in the building floor plans by m².

The other area of inputs is used to select the constructions to be assigned to all components of the building (Core, pertimeter and structure), which can be set be clicking in the grey boxes and choosing from the list of available components.

Life Cycle - Simulation and Visualization

Once all modeled buildings have templates assigned, Life Cycle simulation for Embodied Energy and Carbon are launched and visualized through the “Simulate” tab in the umi panel, which can be opened by clicking on the “Simulate” button of the umi toolbar, or the command “UmiOpenSimulatePanel”.

The umi panel will open with the “Simulate” tab open. In order to access the Life Cycle module controls you can click its logo in the side tabs:

1. Running a calculation

The Life Cycle umi module offers two modes for running calculations: Either running all possible models in the Buildings layer or only running those specifically selected. You can run a calculation by clicking the “Run” button located in the first section of the panel. When no building objects are selected in the Rhino viewport the button will show the text “Run all” and will trigger the first mode. You can run only specific buildings by selecting them in Rhino. In that case the button will change its text into “Run selected” triggering the second mode. The progress bar in the panel will show the evolution of the calculation which will take from seconds in the case of 1 building to minutes in the case of more than 100.

2. Visualizing results

Once one or more buildings have been calculated, umi allows for the visualization of results directly on the model by false coloring their volumes according to their performance, through second half of the “Simulate” panel. In visualization mode umi will duplicate brep geometry into the “Results” layer. Again, the module offers two modes of visualization (All buildings or selected buildings) controlled through the “False color” button in the second section of the panel. Note that in order for the visualization to work the “Buildings” layer will have to be active.

The type of results visualized can be modified through the controls in the umi panel, in order to change the metric, the component, the normalization and the year of the building lifetime. You can choose between Embodied Energy or Embodied Carbon results by clicking in the corresponding logo in the top of the “Results” section (1).

You can modify the result type (Between results for the complete building or only envelope), the normalization (Total results or normalized by floor area) and the year to visualize (Results are given as a cumulative value taking into account replacement cycles). To do so, choose the desired type using the dropdown and text boxes in the control (2). Whenever you make a change, the false color will automatically re-render.

The umi “Simulate” panel also incorporates a color scale which will automatically show the min and max of the visualization (3) as well as an info text (4) that will show the specific value associated with selected buildings. The color bar limits can be modified to suit the color range to the needs of the user just by typing in new limits. In order to keep the new limits fixed for a new false color you can block them by clicking the “Lock” icons located besides. The info text located on top of the color bar will show one value if one building is selected, and the addition of all selected if it is a multiple selection.

3. Exporting results into CSV

Within the results visualization controls in the “Simulate” panel in umi it is possible to directly export results in a comma separated value (CSV) format which can later be easily manipulated as a spreadsheet in Excel or similar software. To do so you can click the ‘Export” button in the bottom of the panel which again offers “AllBuildings” and “SelectedBuildings” modes. Then a new file called “Results” will be created in your desktop. This file will only contain results for the metric, unit, normalization, etc. currently selected in the controls.

Modeling Low Carbon Energy Systems

Authorship

The district energy plugin enables the simulation of city-scale energy demand at the plant level. It is developed by Samuel Letellier-Duchesne (Polytechnique Montréal) and Shreshth Nagpal (MIT). The following sections present an overview of the modelling assumptions and mathematical description of each energy sub-module.

The Big Picture

A district level thermal energy plant comprises several equipment that serve the distribution network for a project’s hot water, chilled water and electricity requirements by converting grid purchased utilities into usable thermal and electrical energy. The plant inputs, usually a combination of grid electricity and natural gas, can vary considerably based on the selection, capacity and efficiency of various plant equipment. The thermal plant should be configured carefully after considering the load balance between project electricity and thermal energy requirements, and the relative emissions and costs associated with grid electricity and natural gas.

The model is defined as a cascade of different components (energy modules) that try to meet the demand (either hot water, chilled water or electricity) for all 8760 hours of the year. A module will supply energy up to its given capacity. If the demand is higher than a module’s capacity, the remaining demand will be met by the subsequent modules in the chain. The chain of energy supplies is defined here and illustrated in Fig. 12.

Schematic arrangement of various thermal plant equipment that are incorporated in this tool

The input to the tool includes hourly load profiles for hot water, chilled water, and electricity, as simulated by the Operational Energy Module and, in a future version of this plugin, the dynamic distribution network module. As each equipment is individually enabled or disabled by the user, and its performance characteristics are modified, the thermal plant planning tool calculates the hourly consumption of purchased grid electricity and natural gas.

Input Profiles

Model component / Input parameter	Default Value
Hourly chilled water load profile (kWh)	From distribution network
Hourly hot water load profile (kWh)
Hourly electricity load profile (kWh)
Hourly location solar radiation data (kWh/m2)	From selected weather file
Hourly location wind speed data (m/s)

Note

In this version of the plugin, the model assumes there is no heat loss due to the distribution network.

Energy Supply Modules

The following section presents a mathematical description of each energy modules.

Absorption chillers

The model assumes that the absorption chillers meet the base load. It is the first module that will be used to meet the demand up to the chillers capacity. The annual hot water required to generate project chilled water, \(hw_{abs}\), is added to the projects hot water demand and can be expressed as:

()\[hw_{abs}=\sum_{n=1}^{8760}\left [ \frac{\min \left ( chw_n, cap_{abs} \right )}{ccop_{abs}} \right ]\]

where:

\(chw_n\) is the chilled water load from the distribution network at a particular timestep

\(cap_{abs}\) is the cooling capacity of absorption chillers

\(ccop_{abs}\) is the Cooling Coefficient Of Performance

The chilled water demand met by the absorption chiller, \(chw_{abs}\), is given by:

()\[chw_{abs}= \min \left ( chw_n, cap_{abs} \right )\]

Input Parameters

Model component / Input parameter	Description	Default Value
Capacity as percent of peak cooling load (%)	Ratio of cooling delivered by absorption chillers to total load at peak conditions	0
Cooling coefficient of performance	Average annual ratio of useful cooling delivered to natural gas consumed	0.90

Typical Values

Table Table 1 summarizes typical chiller efficiency ranges for different chiller technologies.

Typical chiller efficiency ranges with different prime drivers

Chiller type	Typical efficiency	Capacity (KW)
Steam driven centrifugal HW absorption chiller (single effect)	COP 0.55–0.70	<200 to >11500
Steam absorption chiller (single effect)	COP 0.60–0.8	<200 to >11500
Direct fired (double effect) absorption chiller	COP 0.85–1.30	<350 to >11500

Electric chillers

If the absorption chillers can’t supply all the chilled water demand, then the electric chillers will cover the remaining. This module has a infinite capacity. It’s electricity demand [kWh] is defined as:

()\[\begin{split}elec_{ech} = \begin{cases} \sum_{n=1}^{8760}\frac{chw_n-cap_{abs}}{ccop_{ech}}, & \text{if } chw_n > cap_{abs}\\ 0, & \text{otherwise} \end{cases}\end{split}\]

and the chilled water produced [kWh] is defined as:

()\[\begin{split}chw_{ech} = \begin{cases} \sum_{n=1}^{8760}chw_n-cap_{abs}, & \text{if } chw_n > cap_{abs}\\ 0, & \text{otherwise} \end{cases}\end{split}\]

Input Parameters

Model component / Input parameter	Description	Default Value
Cooling coefficient of performance	Average annual ratio of useful cooling delivered to electricity consumed	4.40

Typical Values

Table Table 2 summarizes typical chiller efficiency ranges for different chiller technologies.

Typical chiller efficiency ranges with different prime drivers [1]

Chiller type	Typical efficiency	Capacity (KW)
Electric centrifugal (standard single compressor)	COP 4.7–6.75	1750 to > 5275
Electric centrifugal (standard dual compressor)	COP 4.7–6.75	5275 to >14000
Electric centrifugal (single compressor industrial – field erected)	COP 4.7–6.75	8800 to > 20000

Solar thermal collectors

Similarly to chilled water, the hourly hot water load profile (\(hw_n\)), is an input to the model from the distribution network. This module calculates hot water generation potential per unit collector area based on user defined values of collector efficiency (\(eff_{shw}\)), an area utilization factor to account for collector frames and other infrastructural requirements (\(util_{shw}\)), and miscellaneous losses (\(loss_{shw}\)). In addition to these performance parameters, users input an offset target as a percentage of total annual hot water demand (\(off_{shw}\)). In combination with the hourly solar radiation data available from the weather file (\(rad_n\)), the model calculates the overall area needed for solar collectors (\(area_{shw}\)), and the annual total solar hot water generation to meet building loads (\(hw_{shw}\)), which can be expressed as:

()\[area_{shw} = \sum_{n=1}^{8760}\frac{hw_n*off_{shw}}{rad_n eff_{shw} \left(1 - loss_{shw} \right ) util_{shw}}\]

where:

\(hw_n\) is the hot water load profile at a particular timestep

\(off_{shw}\) is the user-defined amount of energy the module should produce (or offset)

\(rad_n\) is the solar energy falling on a horizontal surface during the timestep

\(eff_{shw}\) is the collector efficiency

\(loss_{shw}\) is the collector

\(util_{shw}\) is the area utilization factor

()\[hw_{shw} = \sum_{n=1}^{8760}\min \left ( rad_n area_{shw} eff_{shw} util_{shw} \left( 1 - loss_{shw} \right), hw_n + hw_{abs} \right )\]

Note

This module cannot model the solar radiation on an inclined surface. It will therefore assume solar collectors are laid horizontally. This simplification is fine considering the level of detail of an early design analysis.

Model component / Input parameter	Description	Default Value
Target offset as percent of annual energy (%)	Ratio of heating delivered by solar collectors to total annual heating requirement	0
Collector efficiency (%)	Average annual ratio of the heat output from collectors divided by received solar radiation	45
Area utilization factor (%)	Accounts for collector frames and other infrastructural requirements	75
Miscellaneous losses (%)	Accounts for other losses including leakage, distribution, or context shading	15

Hot Water Storage Tanks

Any solar generation that is surplus to the project loads for each hour is assumed to charge a hot water tank. Based on a user defined tank capacity (\(cap_{hwt}\)), the previous hour’s charge (\(chg_{n-1}\)) and current balance (surplus - deficits), the model calculates the tank charge for each hour (\(chg_n\)). First, the solar hot water balance is defined as:

()\[bal_{shw} = rad_n area_{shw} eff_{shw} util_{shw} \left( 1 - loss_{shw} \right) - hw_n - hw_{abs}\]

It represents the energy that goes into or comes out of the storage system. If \(bal_{shw}\) is negative, it means that we are discharging the tank during this timestep. If it is positive, then we are charging the tank. Tank charging and discharging is limited by the charging and discharging rates, which are calculated based on the size of the storage.

Note

Charging and Discharging Rates

The module assumes the storage system can be fully charged during \(n\) days of autonomy, assuming only 12 hours per day can supply solar energy to the tank. For example, if a storage tank has an autonomy of 3 days, it’s charging rate will be \(rate = \frac{cap_{hwt}}{nb_{days} * \text{12 hours/day}} \text{[kWh/h]}\), where \(cap_{hwt}\) is the capacity of the tank [kWh] and \(nb_{days}\) is the number of days of autonomy specified by the user.

Input Parameters

Model component / Input parameter	Description	Default Value
Capacity as the number of days of autonomy (#)	Number of average annual days that tanks can meet demand once fully charged	0
Miscellaneous losses (%)	Accounts for other losses including leakage and distribution	15

Electric Heat Pumps

The model assumes that these loads are first met by renewables along with thermal storage, and only demand in surplus of their user defined capacity is sent over to the remaining equipment. The electricity consumption (\(elec_{ehp}\)), required to generate hot water from heat pumps is based on their capacity (\(cap_{ehp}\)), and heating coefficient of performance (\(hcop_{ehp}\)), and can be expressed as:

()\[elec_{ehp} = \sum_{n=1}^{8760}\frac{\min \left ( hw_n, cap_{ehp} \right )}{hcop_{ehp}}\]

The hot water produced is then defined as:

()\[hw_{ehp} = \text{SmallestNonNegative} \left ( hw_n + hw_{abs} - hw_{shw} - hw_{hwt} - hw{chp}, cap_{ehp} \right )\]

where:

\(hw_n\) is the hot water load profile at a particular timestep

\(hw_{abs}\) is the additional load from the Absorption chillers

\(hw_{shw}\) is the load covered by the Solar thermal collectors array

\(hw_{hwt}\) is the load covered by the Hot Water Storage Tanks

\(hw_{chp}\) is the load covered by the Combined Heat & Power plant

Input Parameters

Model component / Input parameter	Description	Default Value
Capacity as percent of peak heating load (%)	Ratio of heating delivered by heat pumps to total load at peak conditions	0
Heating coefficient of performance	Average annual ratio of useful heating delivered to electricity consumed	3.20

Natural gas boilers

The Natural Gas Boilers acts as the last module that can produce hot water. Its priority is lower than the Combined Heat & Power plant, which means that the hot water produced by the boilers supplements any remaining energy that could not be produced by the Solar thermal collectors, the Hot Water Storage Tanks or the Combined Heat & Power plant.

With a user defined heating efficiency (\(eff_{ngb}\)), the hot water produced by the Natural Gas Boilers (\(hw_{ngb}\)) is defined as:

()\[hw_{ngb} = \max \left (hw_n - hw{ehp} + hw{abs} - hw{shw} - hw_{hwt} - hw_{chp}, 0 \right);\]

The natural gas consumption of the boilers is then defined as:

()\[ngas_{ngb} = \max \left (hw_n + hw_{abs} - hw_{ehp} - hw_{shw} - hw_{hwt} - hw_{chp}, 0 \right )\]

Where:

\(hw_n\) is the hot water load profile at a particular timestep

\(hw_{abs}\) is the additional load from the Absorption chillers

\(hw_{hwp}\) is the load covered by the Electric heat pumps

\(hw_{shw}\) is the load covered by the Solar thermal collectors array

\(hw_{hwt}\) is the load covered by the Hot Water Storage Tanks

\(hw_{chp}\) is the load covered by the Combined Heat & Power plant

Input Parameters

Model component / Input parameter	Description	Default Value
Heating efficiency (%)	Average annual ratio of useful heating delivered to fuel consumed	70

Photovoltaic Array

The photovoltaic calculation is based on user defined values for panel efficiency (\(eff_{pv}\)), an area utilization factor to account for panel frames and other infrastructural requirements (\(util_{pv}\)), and miscellaneous losses (\(loss_{pv}\)). In addition to these performance parameters, users input an offset target as a percentage of total electricity demand. In combination with the hourly solar radiation data available from the weather file (\(rad_n\)), The model calculates the overall area needed for the photovoltaic array (\(area_pv\)), and the total electricity generation (\(elec_pv\)), which can be expressed as:

\[elec_{pv} = \sum_{n=0}^{8760} rad_n area_{pv} eff_{pv} util_{pv} (1-loss_{pv})\]

Note

This module cannot model the solar radiation on an incline surface. It will therefore assume solar collectors are laid horizontally.

Model component / Input parameter	Description	Default Value
Target offset as percent of annual energy (%)	Ratio of electricity delivered by PV Array to total annual electricity requirement	0
Cell efficiency (%)	Average annual ratio of electricity output from array divided by received solar radiation	15
Area utilization factor (%)	Accounts for module frames and other infrastructural requirements	75
Miscellaneous losses (%)	Accounts for other losses including line losses and balance of system	15

Wind Turbines

The wind turbine calculation is based on user defined values for turbine coefficient of performance (\(C_p\)), the rotor area per turbine (\(A\)), and miscellaneous losses (\(loss_{wnd}\)). In addition to these performance parameters, users input an offset target as a percentage of total electricity demand (\(off_{wnd}\)). In combination with the hourly wind velocity data available from the weather file (\(V\)), the model calculates the number of turbines needed and the annual electricity generation based on equation (12) and equation (13).

()\[num_{wnd} = \frac{\sum_{n=1}^{8760}elec_n off_{wnd}}{\sum_{n=1}^{8760}pow_{n}\left ( 1 - loss_{wnd} \right )}\]

Where:

\(elec_n\) is the electricity demand at timestep \(n\).

\(off_{wnd}\) is the target offset as percent of annual energy.

\(pow_{n}\) is the power output in kilowatts for one turbine (calculated from equation (14))

\(loss_{wnd}\) is the miscellaneous losses.

()\[elec_{wnd} = power \left ( 1 - loss_{wnd} \right ) num_{wnd}\]

Where:

\(elec_n\) is the electricity demand at timestep \(n\).

\(off_{wnd}\) is the target offset as percent of annual energy.

()\[\begin{split}pow_n = \begin{cases} \frac{C_p \rho A V_n^3}{2 \cdot 1000}, & \text{if } cut_{in} < V_n< cut_{out}\\ 0, & \text{otherwise} \end{cases}\end{split}\]

Where:

\(pow_n\) is the turbine’s power output [kW] at a particular timestep.

\(C_p\) is the maximum power coefficient, ranging from 0.25 to 0.45. It is dimensionless (theoretical maximum = 0.59).

\(\rho\) is the air density [kg/m³]. Taken constant as 1.2753.

\(A\) is the rotor swept area [m²].

\(V_n\) is the Wind Speed [m/s] at a particular timestep.

Equation (14) is taken from windpowerengineering.com.

Input Parameters

Model component / Input parameter	Description	Default Value
Target offset as percent of annual energy (%)	Ratio of electricity delivered by wind turbines to total annual electricity requirement	0
Turbine coefficient of performance	Average annual ratio of power captured by turbine to total power available in the wind	0.3
Cut-in speed (m/s)	Minimum wind speed at which the turbine blades overcome friction and begin to rotate	5
Cut-out speed (m/s)	Speed at which the turbine blades are brought to rest to avoid damage from high winds	25
Rotor area per turbine (m2)	The swept area is the plane of wind intersected by the turbine	15
Miscellaneous losses (%)	Accounts for other losses	15

Battery Bank

Any renewable energy generation that is surplus of the project loads for each hour is assumed to charge a Battery Bank. Based on a user defined battery capacity (\(cap_{bat}\)), the previous hour’s charge (\(chg_{n-1}\)) and current balance (surplus - deficits), the model calculates the battery charge for each hour (\(chg_n\)). Similarly to the Hot water tank, charging and discharging of the battery is limited by its charging and discharging rates. The rates are assumed to follow the same principles as the hot water tank charging and discharging rates.

The electricity balance is defined as the balance of generated electricity and electricity consumption at a particular timestep :

()\[bal_{elec} = elec_{pv} + elec_{wnd} - elec_n - elec_{ech} - elec_{ehp}\]

It represents the energy that goes into or comes out of the storage system. If \(bal_{bal}\) is negative, it means that we are discharging the battery during this timestep. If it is positive, then we are charging the battery. Furthermore, the battery sees a certain loss (\(loss_{bat}\)) whenever charging and discharging occurs and thus the battery charge is defined as:

()\[\begin{split}bat_{chg,n} = \begin{cases} \max \left[ bat_{chg,n-1} + bal_{elec} \left(1-loss_{bat} \right), \\ \max \left( bat_{chg,n-1} - dchg_{bat}, 0 \right) \right ], & \text{if } bal_{elec} < 0\\ \text{SmallestNonNegative} \left [ bat_{chg,n-1} + bal_{elec} \left(1-loss_{bat} \right) , \\ \text{SmallestNonNegative} \left( bat_{chg,n-1} + chrg_{bat}, cap_{bat} \right) \right], & \text{if } bal_{elec} \geq 0\\ \end{cases}\end{split}\]

Model component / Input parameter	Description	Default Value
Capacity as number of days of autonomy (#)	Number of average annual days that batteries can meet demand once fully charged	0
Miscellaneous losses (%)	Accounts for other losses including line losses and balance of system	15

Combined Heat & Power

By default, the combined heat and power component tracks and serves the remaining project hot water demand up to its maximum heating capacity. The heating capacity is calculated by the model based on user defined electrical capacity (\(cap_{chp}\)), electricity generation efficiency (\(eff_{chp}\)), and heat recovery effectiveness (\(hrec_{chp}\)). The annual heating energy recovered from the combined heat and power plant and supplied to the project (\(hw_{chp}\)), can be expressed as:

()\[\begin{split}hw_{chp} = \begin{cases} \min \left [ \frac{cap_{chp}}{eff_{chp}} hrec_{chp}, hw_n + hw_{abs} - hw_{shw} - hw_{hwt} - hw_{ehp} \right] & \text{for thermal tracking}\\ ngas_{chp} hrec_{chp} & \text{for electrical tracking}\\ \end{cases}\end{split}\]

The module can also be assigned to track electricity instead of the thermal load. In this case, the combined heat and power component tracks and serves the project electrical load up to its capacity that remains after subtracting the renewable system (\(elec_{ren}\)) and battery bank (\(elec_{bat}\)) supply from overall demand (\(elec_n\)).

Model component / Input parameter	Description	Default Value
Tracking mode	Control the generator to prioritize meeting the hot water or electricity demand	Thermal
Capacity as percent of peak electric load (%)	Ratio of electricity delivered by generator to total demand at peak conditions	0
Electrical efficiency (%)	Average annual ratio of electricity delivered by generator to fuel consumed	22
Waste heat recovery effectiveness (%)	Average annual ratio of usable heat recovered from generator to fuel consumed	29

References

[1]

Tredinnick and G. Phetteplace, 8 - District cooling, current status and future trends, In Woodhead Publishing Series in Energy, edited by Robin Wiltshire,, Woodhead Publishing, Oxford, 2016, Pages 167-188, Advanced District Heating and Cooling (DHC) Systems, ISBN 9781782423744, https://doi.org/10.1016/B978-1-78242-374-4.00008-2. (https://www.sciencedirect.com/science/article/pii/B9781782423744000082)

HARVEST

Authorship

HARVEST – the urban food production simulation plugin – estimates food yields of indoor farms and their associated operational building energy use, water use and carbon emissions, as well as their economic performance through metrics such as operational costs and job creation. It is developed by Khadija Benis (MIT). The following sections present an overview of the inputs, structure and outputs of the module.

Background

Controlled-Environment Agriculture

Controlled-Environment Agriculture (CEA) is an umbrella term for a large set of cultivation systems where the environment is controlled in order to extend crop growth period. Whereas the scope of the designation is broad enough to include very low-tech systems such as cloches set on field-grown crops, this first version of HARVEST only considers indoor conditioned farms – also called Plant Factories – using soilless cultivation techniques and artificial lighting. These indoor farms include container farms, an emerging trend that consists of growing crops in retrofitted shipping containers equipped with hydroponic systems. Controllable environment variables in CEA include CO2, humidity, light, nutrients, pests, temperature, ventilation and water.

HARVEST estimates food yields of indoor farms and their associated operational building energy use, as well as water use and carbon emissions. It also provide insights on the economic performance of the farms through metrics such as operational costs and jobs created locally. Additionally, it compares simulation outputs to existing urban supply chains and provides a carbon balance as well as a site premium. The following sections describe the simulation inputs, the structure of the tool and its underlying models, and the simulation outputs.

Fig. 1: Key performance metrics provided by HARVEST

Modelling crop growth

Photosynthesis is fundamental to plant growth and has been shown to be affected by environmental factors such as light and temperature (Kozai et al., 2016). Crop growth models consist of mathematical equations that represent these reactions occurring between plants and their environment, predicting the growth rate and final state of total biomass and harvestable yield (Jame and Cutforth, 1996). HARVEST food production calculations use the gathered data on optimal growth conditions of crops and apply these models as described in the sections below.

Thermo-classification of vegetables was one of the earliest attempts to group plants and remains widely used today (Welbaum, 2015). Based on their light and temperature requirements for optimal growth, HARVEST clusters crops into four groups – red, orange, light green, and dark green crops (see Fig. 2). Red and orange are warm season crops. Red crops prefer temperatures above 21 oC, whereas orange crops are adapted to temperatures ranging from 18.3 to 29.4 oC. Light green and dark green are cool-season crops. Light green crops are adapted to temperatures ranging from 12.8 to 23.9 oC, whereas dark green crops prefer average monthly temperatures of 15.6 to 18.3 oC.

Fig. 2: Classification of crops based on light and temperature requirements

Simulation inputs

CEA Farm templates

Simulating indoor crop growth requires the definition of specific templates for the “farm” building type, which are based on the optimal indoor conditions required by the plants. A default crop template library is embedded in HARVEST. In order to build these templates, a database of optimal growth conditions for a set of crops was developed through a literature review of scientific articles describing the settings and outcomes of controlled-environment cultivation experiments conducted in growth chambers equipped with hydroponic systems. The UMI Template Editor can be used to edit and/or add templates.

Zone information

The building envelope can be customized by the user according to the specific needs of a given project, as indoor farms can be implemented in any building. For instance, to model a shipping container growing unit, the user can set the envelope and adjust its dimensions according to the envelope properties and dimensions of standard shipping containers.

Occupancy, equipment and lighting loads are defined according to farms’ operation requirements. For occupancy, a density of farmers (ppl/m2) and a farm occupancy schedule were set, documented by existing practices in commercial hydroponic farms. Similarly, based on equipment specificities and schedules of hydroponic farms, equipment power density (W/m2) and equipment schedule were set. Light power density (W/m2) is defined according to the specificities of the lighting fixtures and to the number of vertically stacked growing racks for a given crop. A lighting schedule is allocated based on the photoperiod requirements of the crop, and an illuminance target (lux) is set according to the PPFD. Finally, heating and cooling set points are defined according to the thermal requirements of each crop, documented in the literature.

Zone information	Settings
Constructions	Customized by the user
Loads	From crop requirements
Ventilation	From crop requirements
Domestic hot water	From crop requirements
Windows	All WWR automatically set to 0% when selecting the CEA Farm Simulator

Schedules

Depending on the distribution of labor that is assumed for the farms, daily occupancy can be allocated in different ways. As for lighting, testing different schedules can have great impacts on simulation results. In fact, under a given optimal temperature range, plant growth is further affected by light intensity and it has been established that under a controlled environment, the response of crop growth to increase in PPFD is virtually linear (e.g., Cockshull et al., 1992). This linear response of plant growth over target daily Photosynthetically Active Radiation PAR24 – also called Daily Light Integral (DLI) – and the reciprocity between the effects of PPFD and photoperiod at the same DLI can be used in lighting design when choosing the fixtures’ PPFD and deciding photoperiod needed to achieve target DLI (Kozai et al., 2016). For instance, the target DLI of 11 mol/m2/day that is required for strawberry can either be achieved by 255 μmol/m2/s through a photoperiod of 12 hours or by 170 μmol/m2/s through a photoperiod of 18 hours. The reduction of PPFD reduces the number of lighting fixtures and thereby capital costs, while reducing and changing photoperiod distribution can take advantage of the off-peak hours of utility charges and contribute to a better energy demand management.

Schedules	Settings
Occupancy	Farmers occupancy
Equipment	Farm equipment
Lighting	From crop optimal photoperiod
Heating	From crop optimal temperature range
Cooling	From crop optimal temperature range
Domestic hot water	Farm hot water use

Urban Food Profiles (Urban foodprints)

A fundamental preliminary step in the sustainability assessment of urban food production consists of collecting and integrating data on the existing supply chain for the crops to be assessed. The Urban Foodprints method consists of getting snapshots of the existing food system for a given urban area, using metrics related to food demand, resource use intensity of production, and food miles, to estimate the overall environmental impacts caused by the supply of a given produce to the city (Benis et al., 2018). In addition to this environmental sustainability component, HARVEST integrates a cost analysis component. A site-specific input file is therefore needed to run simulations: the Urban Food Profile (UFP), which contains crop-specific data related to the existing supply chain for the assessed crops. Specifically, the UFP file is a JSON file containing the list of simulated vegetables for which the following data inputs must be provided:

Input name	Type	Unit	Description
Name	(string)	n/a	Crop name
Color	(string)	n/a	Color code of the crop group
TemplateGroupCode	(string)	n/a	R = Red; O = Orange; LG = Light Green; DG = Dark Green
PerCapitaSupply	(double)	kg/cap/year	Yearly per capita food supplied to the population
FoodMiles	(double)	km	Average distance traveled by the crop to reach the city
PerKgEnergyUse	(double)	kWh/kg	Embedded energy use per unit weight of imported produce
EFEnergyOrigin	(double)	kgCO2eq/kWh	Emission factor of energy at origin of produce
WaterUseImported	(double)	L/kg	Embedded water use per unit weight of imported produce
EFWaterOrigin	(double)	kgCO2eq/L	Emission factor of water at origin of produce
FoodWaste	(double)	n/a	Share of conventional agricultural output that is wasted
AverageRetailPrice	(double)	$/kg	Yearly average selling price of the produce
LightUseEfficiency	(double)	kg/mol/m2	Ratio of gross yield to the absorbed Photosynthetically Active Radiation (PAR)
WaterUseEfficiency	(double)	kg/L	Ratio of biomass produced to the rate of transpiration
OccupancyCoefficient	(double)	n/a	Ratio of area occupied by the plants to the total floor area of the farm
RootDepth	(double)	m	Maximum depth of the roots
ShootHeight	(double)	m	Maximum height of the plant before harvest
TrayInterval	(double)	n/a	Interval to keep plant canopies at optimal distance from lighting fixtures
HarvestIndex	(double)	n/a	Ratio of harvested edible yield to total gross yield
CropLosses	(double)	n/a	Share of yield lost at farm gate
EFWater	(double)	kgCO2eq/m3	Emission factor of water
WaterRate	(double)	$/m3	Water rate in the city

CEA Farm Simulator

Marketable yield

HARVEST provides the yearly Marketable Yield Y_M (kg/m2/year), expressed as follows:

()\[Y_{M} = Y_{G} × n_{T} × c_{A} × HI × (1-L)\]

where:

\(Y_{G}\) is the yearly Gross Yield (kg/m2/year);

\(n_{T}\) is the number of growing trays that are vertically stacked in the farm (see Fig. 3);

\(c_{A}\) is the coefficient of occupancy of the growing area in the farms (see Fig. 4);

\(HI\) is the Harvest Index;

\(L\) are crop losses.

Gross yields have been defined as the total amount of CO2 fixed by the plants per unit time through photosynthesis into organic matter (Gough, 2011), and modeled as the product of canopy light interception and Light Use Efficiency (LUE):

()\[Y_{G} = PAR_{365} × LUE\]

where:

\(PAR_{365}\) is the Photosynthetically Active Radiation available per year (mol/m2/year);

\(LUE\) is the Light Use Efficiency of the crop (kg/mol/m2).

where:

PAR_{365} is the Photosynthetically Active Radiation available per year (mol/m2/year);

LUE is the Light Use Efficiency of the crop (kg/mol/m2).

Photosynthetically Active Radiation (PAR) – the amount of light available for photosynthesis – derives from the Photosynthetic Photon Flux Density (PPFD) and the optimal photoperiod found in the literature for each crop:

()\[ PAR_{365} = (PPFD × Ph × 3600) / 10^6\]

where:

\(PPFD\) is the Photosynthetic Photon Flux Density (µmol/m2/s);

\(Ph\) is the Light Use Efficiency of the crop (kg/mol/m2).

In the templates, both the PPFD and the photoperiod can be altered by the user by changing the illuminance target for the former, and the lighting schedules for the latter.

In fully artificially-lit farms, crops are stacked vertically in order to maximize yields within the volume of the enclosure (see Fig. 3). The number of growing trays nT is calculated by HARVEST, based on the floor-to-floor height that was set by the user for the farm and on the spatial needs that were reported in the literature for each crop, as follows:

()\[n_{T}= FFH / (( H_{shoot} + D_{root} ) × i\]

where:

\(FFH\) is the Floor-to-Floor Height (m);

\(H_{shoot}\) is the height of the shoot (m);

\(D_{root}\) is the depth of the root (m);

\(i\) is the interval, a coefficient that was applied in order to take into account the extra space that is necessary so that plants do not reach the lighting fixtures above them. It was set to 1.5.

Fig. 3: Vertical stacking of crops in plant factories

The cA coefficient represents the ratio of the area occupied by the plants to the total floor area of the farm. Architectural drawings of existing indoor farms were reviewed. In plant factories, the culture room occupies 60% of total floor area, the remaining area being used for circulation, sanitary installations, technical rooms and administrative office space (see Fig. 4). In the culture room, the growing area represents around 70% of the floor area.

Fig. 4: Rough floor plan and outdoor view of a plant factory (“Mirai” in Chiba, Japan). Source: Kozai et al. (2016)

The Harvest Index HI represents the ratio of harvested edible yield to total dry matter produced. It was collected from the literature for each crop of the database, and varies from 0.20 for cucumber to 0.80 for cabbage.

Finally, crop losses L were set to 5%, based on the literature (Vanthoor et al., 2012) and on existing practices in commercial hydroponics farms (Benis et al., 2017).

Water Use

The yearly water use per unit floor area WA (m3/m2/year) is estimated as follows:

()\[W_{A}= (Y_{G}) / WUE × n_{T} × c_{A} × 0.001\]

where:

\(Y_{G}\) is the yearly Gross Yield (kg/m2/year);

\(WUE\) is the Water Use Efficiency of the crop (kg/L);

\(n_{T}\) is the number of growing trays that are vertically stacked in the farm;

\(c_{A}\) is the coefficient of occupancy of the growing area in the farms.

Energy Use

When the CEA Farm Simulator is selected for a building, UMI generates multizone EnergyPlus™ models for the farm (one zone per floor), to which construction properties, loads, conditioning settings and schedules are associated based on the allocated farm template. All Window-to-Wall Ratios (WWR) are automatically set to 0% (see Fig. 5). Energy Use Intensity (EUI) of the farms is displayed in the UMI energy module.

Fig. 5: From input geometry to multizone farm

Carbon Balance

Based on the UFP inputs and on the operational resource use of the simulated urban farms (water and energy), HARVEST displays the carbon balance, i.e., the difference between the existing supply chain and the local food production scenario, showing potential Greenhouse Gas (GHG) emissions mitigation:

()\[GHG_{BALANCE} = GHG_{BASE} - GHG_{CEA}\]

Crop-embedded GHG emissions (kgCO2eq) under the existing supply chain (GHGBASE) include emissions related to resource use during the cultivation process (water and energy) as well as emissions related to food miles and food waste from farm to retail:

()\[GHG_{BASE}= GHG_{BASE}^E+ GHG_{BASE}^W + GHG_{BASE}^{FM} + GHG_{BASE}^{FW}\]

where:

\(GHG_{BASE}^E\), \(GHG_{BASE}^W\), \(GHG_{BASE}^{FM}\) and \(GHG_{BASE}^{FW}\) are the respective baseline embedded emissions of energy, water, food miles and food waste.

Embedded GHG emissions of on-site food production in controlled-environment urban farms GHGCEA (kgCO2eq) include the GHG emissions related to the operation of the farms – namely of water and energy use:

()\[GHG_{CEA} = GHG_{CEA}^E + GHG_{CEA}^W\]

where:

\(GHG_{CEA}^{E}\) and \(GHG_{CEA}^{W}\) are the respective baseline embedded emissions of energy use and water use (kgCO2eq).

Jobs

The jobs calculation uses the occupancy of the farms that was set in the templates, which was documented by existing practices in commercial hydroponic greenhouses and vertical farms, and the floor area of the simulated urban farms.

Site premium

Based on the inputs of the UFP and on the outputs of the CEA Farm Simulator, HARVEST not only displays costs of on-site food production, but also the difference between the baseline (i.e., the consumers’ food expenditure under the existing supply chain) and the simulated local food production scenario, showing the site premium for each crop type.

Simulation outputs

Site metrics

Site metrics provide an overview on (1) local food consumption; (2) food expenditure; and (3) farming area needed for 100% self-sufficiency.

Metric	Unit	Description
Food consumption	t/year	Total site yearly consumption of vegetables (excl. food waste across the supply chain)
Food expenditure	k$/year	Yearly expenditure of the residents to purchase vegetables
Estimated growing area needed for 100% self-sufficiency	m2	Estimated farming area needed to fully satisfy the local demand with on-site hydroponic farming

Key performance metrics

Metric	Unit	Description
Local food production	t/year	Ratio of total site production in CEA farms to total site yearly demand for vegetables
Jobs created	workers	Number of jobs created by on-site CEA farms
Water use	m3/year	Total on-site water use in CEA farms
Site premium	k$/year	Total operational costs of CEA farms (incl. energy, water and labor)
Carbon balance	tCO2eq/year	Difference between baseline embodied GHG emissions of imported vegetables (incl. energy, water, food miles and food waste) and on-site GHG emissions resulting from the operation of CEA farms (incl. energy and water)

References

1. Benis, K., Reinhart, C., Ferrão, P., 2017. Development of a simulation-based decision support workflow for the implementation of Building-Integrated Agriculture (BIA) in urban contexts. J. Clean. Prod. 147, 589–602, https://doi.org/10.1016/j.jclepro.2017.01.130.
2. Benis, K., Gashgari, R., Alsaati, A., Reinhart, C., 2018. Urban Foodprints ( UF ) – Establishing baseline scenarios for the sustainability assessment of high-yield urban agriculture. Int. J. Des. Nat. Ecodynamics 13, 349–360, https://doi.org/10.2495/DNE-V13-N4-349-360.
3. Cockshull, K.E., Graves, C.J., Cave, C.R.J., 1992. The influence of shading on yield of glasshouse tomatoes. J. Hortic. Sci. 67, 11–24, https://doi.org/10.1080/00221589.1992.11516215.
4. Gough, C.M., 2011. Terrestrial Primary Production: Fuel for Life. Nat. Educ. Knowl. 3, 28, retrieved from https://www.nature.com/scitable/knowledge/library/terrestrial-primary-production-fuel-for-life-17567411.
5. Jame, Y.W., Cutforth, H.W., 1996. Crop growth models for decision support systems. Can. J. Plant Sci. 76, 9–19, https://doi.org/10.4141/cjps96-003.
6. Kozai, T., Niu, G., Takagaki, M., 2016. Plant Factory: An Indoor Vertical Farming System for Efficient Quality Food Production. Elsevier. https://doi.org/10.1016/C2014-0-01039-8.
7. Vanthoor, B.H.E., Gázquez, J.C., Magán, J.J., Ruijs, M.N.A., Baeza, E., Stanghellini, C., van Henten, E.J., de Visser, P.H.B., 2012. A methodology for model-based greenhouse design: Part 4, economic evaluation of different greenhouse designs: A Spanish case. Biosyst. Eng. 111, 336–349. https://doi.org/10.1016/j.biosystemseng.2011.12.008.
8. Welbaum, G.E., 2015. Vegetable Production and Practices.

Design Accessibility

Motivation

The utilization of high density and diversity in land-use is an effective strategy that decreases automobile dependency and contributes to more sustainable modes of transportation (namely walking and biking), as a short proximity between amenities encourages human powered transportation (HPT).To quantify the impact of applying such principles, the integration of simulation tools that evaluate cities’ “walking friendless” in the design process is becoming significant. Assessment of neighborhood walkability has long been considered a function of quarter mile to one and a half mile walking distances from housing units to vital amenities. This idea has been adapted by many walkability evaluation schemes in different forms, and has been proven to be a good indicator of “walking environments.” Popular indices such as the “Walkscore” have been validated in terms of estimating neighborhood walkability and health as well as real estate prices.

How it Works

Walkscore measures the ease of residing in a certain area without depending on your car. We adapted this web-based tool to be used within the design environment of Rhino as a comprehensive modeling approach. The algorithm tests points of interest for proximity to nine North-American oriented amenities (Schools, Restaurants, Coffee, Shopping, Entertainment, Parks, Banks, Grocery and Books). Each amenity receives a different weight based on importance. Egress points for addresses are then rewarded based on distances to amenities, and a polynomial distance decay function is used to calculate scores. Within a distance of quarter mile, a full score is received, and at one mile, amenities receive about 12% of the score as a penalty. After one mile, scores slowly decrease with greater distance, until it reaches zero at 1.5 miles. There are other reward scores received by examined points based on street intersection densities and average block length. Scores range from 0 to 100.

Scoring is implemented by constructing a pedestrian travel network and performing a series of shortest-path calculations using Dijkstra’s algorithm.

Setting Up a Rhino Model

Important

When creating a new Rhinoceros model for Umi, always use Meters as the unit system.

Step 1: Starting a new umi project

Create a new umi project or start from an existing one. To create a new project, follow the steps detailed in setup_model.

There is no need to set site information or set building information at this point. Click on “Simulate” to setup layers specific to mobility and then on the “Mobility” icon on the left. Click on “Create amenity layers” to generate layers appropriate for mobility simulation.

Step 2: Modeling Streets, Buildings and Amenities

Streets

On the Streets layer, streets can be drawn as any lines, curves or line-like curves.

Buildings

Building massing can take the form of any Brep, and are placed exclusively on the “Buildings” layer. This should be done by drawing geometry and then setting it up in the settings button. Choose the Brep and click on “Settings” to give the building a name. That is enough for mobility simulation.

Draw buildings as Breps.

Important

Each Brep has to be connected to the streets network by a path that touches the massing. This is because the algorithm that generates a starting “egress” point for each building searches the start and end points of each curve in the model, and the nearest point becomes a door for the Walkscore simulation. If it is not connected, simulation will run by projecting an egress point to the nearest street, even if not connected.

Amenities

Amenities are modeled as points on the streets network. They have to be placed precisely on a street curve, However, if they are not they will be projected to the nearest street line. A good tip is to use “Osnap” to snap to the nearest curve on the streets layer.

Important

place amenity points on the streets network, but not on the end of the curve that touches the building massing. This will make the algorithm consider that “start” and “end” points the same, and Walkscore will fail.

Amenities are drawn as points and parks as surfaces

The “Parks” amenity is the only amenity modeled as surfaces, and it has to be surrounded with street curves on all sides (regardless of the geometry). If a park is placed as a surface, it is recommended to model it by tracing an empty space between street curves.

Typically a Walkscore simulation will include streets, massings connected to the streets, amenity points and park surfaces.

Step 3: Running a Simulation

After selecting the “Simulate” button, choose the “Mobility” tab. You can run both the Walkability simulation and the Bikeability Simulation by pressing “Run All.” The next section explains how both algorithms work.

Step 4: Results Visualization

After a simulation runs, a new layer is created with simulation results. This will take the form of false colored buildings.

Example

This file is for you to test if you are modeling for a Walkscore simulation correctly. After downloading the file, you have to set the location and set the building information for at least one Brep on the “Buildings” layer. Follow the Setting Up a Rhino Model steps, and you will find that walkscore and bikescore run correctly.

Walkscore_Example.3dm

Template Library Editor

This section provide details on the template files

Materials Tab

This section provide details on the template files

Opaque material description

Conductivity

Todo

Section to be written

Cost

Todo

Section to be written

Density

Todo

Section to be written

Embodied Carbon

Todo

Section to be written

Embodied Energy

Todo

Section to be written

Substitution Rate Pattern

Todo

Section to be written

Substitution Timestep

Todo

Section to be written

Transportation Carbon

Todo

Section to be written

Transportation Distance

Todo

Section to be written

Transportation Energy

Todo

Section to be written

Moisture Diffusion Resistance

Todo

Section to be written

Roughness

Todo

Section to be written

Solar Absorptance

Todo

Section to be written

Specific Heat

Todo

Section to be written

Thermal Emittance

Todo

Section to be written

Visible Absorptance

Todo

Section to be written

Glazing material description

Conductivity

Todo

Section to be written

Cost

Todo

Section to be written

Density

Todo

Section to be written

Embodied Carbon

Todo

Section to be written

Embodied Energy

Todo

Section to be written

Substitution Rate Pattern

Todo

Section to be written

Substitution Timestep

Todo

Section to be written

Transportation Carbon

Todo

Section to be written

Transportation Distance

Todo

Section to be written

Transportation Energy

Todo

Section to be written

Dirt Factor

Todo

Section to be written

Back-side IR Emissivity

Todo

Section to be written

Front-side IR Emissivity

Todo

Section to be written

IR Transmittance

Todo

Section to be written

Back-side Solar Reflectance

Todo

Section to be written

Front-side Solar Reflectance

Todo

Section to be written

Solar Transmittance

Todo

Section to be written

Back-side Visible Reflectance

Todo

Section to be written

Front-side Visible Reflectance

Todo

Section to be written

Visible Transmittance

Todo

Section to be written

Opaque

Setting	Short Description
Conductivity
Cost
Density
Embodied Carbon
Embodied Energy
Substitution Rate Pattern
Substitution Timestep
Transportation Carbon
Transportation Distance
Transportation Energy
Moisture Diffusion Resistance
Roughness
Solar Absorptance
Specific Heat
Thermal Emittance
Visible Absorptance

Glazing

Setting	Short Description
Conductivity
Cost
Density
Embodied Carbon
Embodied Energy
Substitution Rate Pattern
Substitution Timestep
Transportation Carbon
Transportation Distance
Transportation Energy
Dirt Factor
Back-side IR Emissivity
Front-side IR Emissivity
IR Transmittance
Back-side Solar Reflectance
Front-side Solar Reflectance
Solar Transmittance
Back-side Visible Reflectance
Front-side Visible Reflectance
Visible Transmittance

Constructions Tab

This section provide details on the template files

Opaque Construction Description

Opaque assembly

Todo

This section should explain how a Construction element is created from multiple material layers

Important

All material layers must have a thickness. Massless layers are not supported at the moment.

Window assembly

Todo

This section should explain how a Window element is created from multiple material layers

Important

All material layers must have a thickness. Massless layers are not supported at the moment.

Structure assembly

Todo

This section should explain how a Structure element is created from multiple material layers

Important

All material layers must have a thickness. Massless layers are not supported at the moment.

Schedules Tab

This section provide details on the template files

Schedules

Day | Week | Year

Todo

Section to be written

Zone Information Tab

This section provide details on the Zone Information tab

Zones tab parameters

Setting	Description	Unit	Default Value
Constructions	Description
Loads	Description
Conditioning	Description
Ventilation	Description
Domestic Hot Water	Description
Dayligth Mesh Resolution	Description
Dayligth Workplane Height	Sensor Node Height		0.8 m
Internal Mass Construction	Description
Internal Mass Exposed Floor Area	Description

Loads tab parameters

Setting	Description	Unit	Default Value
People
Occupancy density	Description
Occupancy schedule	Description
Equipment	Description
Equipment power density	Description
Equipment availability schedule	Description
Lighting	Description
Lighting power density	Description
Lighting availability schedule	Description
Dimming type	Description
Illuminance target	Description

Constructions tab parameters

Setting	Description
Facade
Ground
Partition
Roof
Slab
Facade is adiabatic
Ground is adiabatic
Partition is adiabatic
Roof is adiabatic
Slab is adiabatic

Conditioning tab parameters

Setting	Description	Units	Default Value
Heating
Heating setpoint
Heating schedule
Heating limit type
Max heating capacity
Max heating capacity
Max heat flow
Heating CoP
Cooling setpoint
Cooling schedule
Cooling limit type
Max cooling capacity
Max cool flow
Cooling CoP
Mechanical ventilation
Mechanical ventilation schedule
Min fresh air per area		m3/s-m2	0.0003
Min fresh air per person		m3/s-person	0.0025
Economizer type			NoEconomizer
Heat recovery type			None
Heat recovery efficiency (latent)			0.65
Heat recovery efficiency (sensible)			0.70

Ventilation tab parameters

Setting	Description	Unit	Default Value
Infiltration	Description
Infiltration rate	Description
Natural ventilation	Description
Natural ventilation minimum outdoor air temperature	Description
Natural ventilation maximum outdoor air temperature	Description
Natural ventilation maximum relative humidity	Description
Natural ventilation schedule	Description
Natural ventilation zone temperature setpoint	Description
Scheduled ventilation	Description
Scheduled ventilation ACH	Description
Scheduled ventilation schedule	Description
Scheduled ventilation setpoint	Description
Buoyancy	Description
Wind	Description
Afn	Description

Domestic Hot Water tab parameters

Setting	Description	Unit	Default Value
Enabled	Description
Scheduled	Description
Supply Temperature	Description
Inlet Temperature	Description
Flow rate	Description

Windows tab parameters

Setting	Description	Unit	Default Value
Type	Description
Construction	Description
Operable area	Description
Shading is used	Description
Shading system availability schedule	Description
Shading system setpoint	Description
Shading system transmittance	Description
Shading system type	Description
Zone mixing	Description
Zone mixing availability schedule	Description
Zone mixing delta temperature	Description
Zone mixing flow rate	Description
Virtual partition	Description
Airflow network discharge coefficient	Description
Airflow network temperature setpoint	Description
Airflow network window availability	Description

Zones

Setting	Description	Unit	Default Value
Constructions	Description
Loads	Description
Conditioning	Description
Ventilation	Description
Domestic Hot Water	Description
Dayligth Mesh Resolution	Description
Dayligth Workplane Height	Sensor Node Height		0.8 m
Internal Mass Construction	Description
Internal Mass Exposed Floor Area	Description

Constructions

Assigns one of the Constructions objects to the selected zone.

Loads

Assigns one of the Loads objects to the selected zone.

Conditioning

Assigns one of the Conditioning created in the Conditioning Tab.

Ventilation

Assigns one of the Ventilation objects created in the Ventilation Tab.

Domestic Hot Water

Assigns one of the Domestic Hot Water objects created in the DHW Tab.

Dayligth Mesh Resolution

Defines the Dayligth Mesh Resolution. To use a finer mesh resolution when running any a daylighting simulation, adjust the “Geometric Density” option. Values are in meters. A fine mesh resolution will show a spacial distribution of daylighting better than a coarse one, but will take longer to calculate.

Dayligth Workplane Height

The distance of sampling nodes off of analysis surfaces. A value of 0.8 m will put the sensor nodes roughly at desk height.

Internal Mass Construction

Todo

Section to be written

Internal Mass Exposed Floor Area

Todo

Section to be written

Loads

Setting	Description	Unit	Default Value
People
Occupancy density	Description
Occupancy schedule	Description
Equipment	Description
Equipment power density	Description
Equipment availability schedule	Description
Lighting	Description
Lighting power density	Description
Lighting availability schedule	Description
Dimming type	Description
Illuminance target	Description

People

Occupancy density

Occupancy schedule

Equipment

Equipment power density

Equipment availability schedule

Lighting

Lighting power density

Lighting availability schedule

Dimming type

Illuminance target

Constructions

Setting	Description
Facade
Ground
Partition
Roof
Slab
Facade is adiabatic
Ground is adiabatic
Partition is adiabatic
Roof is adiabatic
Slab is adiabatic

Facade

Ground

Partition

Roof

Slab

Facade is adiabatic

When enabled, the facade will see no heat transfer to the surroundings.

Ground is adiabatic

When enabled, the ground plane will see no heat transfer to the surroundings.

Partition is adiabatic

When enabled, the partition will see no heat transfer to the surroundings.

Roof is adiabatic

When enabled, the roof will see no heat transfer to the surroundings.

Slab is adiabatic

When enabled, the slab will see no heat transfer to the surroundings.

Conditioning

Setting	Description	Units	Default Value
Heating
Heating setpoint
Heating schedule
Heating limit type
Max heating capacity
Max heating capacity
Max heat flow
Heating CoP
Cooling setpoint
Cooling schedule
Cooling limit type
Max cooling capacity
Max cool flow
Cooling CoP
Mechanical ventilation
Mechanical ventilation schedule
Min fresh air per area		m3/s-m2	0.0003
Min fresh air per person		m3/s-person	0.0025
Economizer type			NoEconomizer
Heat recovery type			None
Heat recovery efficiency (latent)			0.65
Heat recovery efficiency (sensible)			0.70

Heating

This checkbox field defines whether or not this component is available to operate. If this field is unchecked, the Heating schedule field will be forced to the generic schedule name Off.

Heating setpoint

The temperature below which zone heating is turned on. Umi controls the temperature in the zone using a ThermostatSetpoint:DualSetpoint object. This would be for heating and cooling thermostat where both a heating and cooling setpoint can be scheduled for any given time period. The setpoint can be scheduled and varied throughout the simulation for both heating and cooling.

Note

In this version of umi, the heating setpoint can only be scheduled as a constant.

Heating schedule

The name of a schedule (ref: Schedule) that denotes whether heating is available. A schedule value greater than 0 (usually 1 is used) indicates that heating and humidification are available. A value less than or equal to 0 (usually 0 is used) denotes that heating and humidification are not available. If blank, heating and humidification are always available.

Note

Schedule for when the heating system is available. Winter only enables the heating system when the outdoor temperature is less than 5 °C.

Heating limit type

The input must be either LimitFlowRate, LimitCapacity, LimitFlowRateAndCapacity or NoLimit. LimitFlowRate means that the heating supply air flow rate will be limited to the value specified in the input field Max heat flow. LimitCapacity means that the sensible heating capacity will be limited to the value specified in the Max heating capacity field. LimitFlowRateAndCapacity means that both flow rate and capacity will be limited. NoLimit (the default) means that there will not be any limit on the heating supply air flow rate or capacity and the subsequent two fields will be ignored.

Max heating capacity

The maximum allowed sensible heating capacity in Watts if Heating Limit is set to LimitCapacity or LimitFlowRateAndCapacity. If blank, there is no limit. If Heating Limit is set to NoLimit or LimitFlowRate, this field is ignored.

Max heat flow

The maximum heating supply air flow rate in cubic meters per second if heating limit is set to LimitFlowRate or LimitFlowRateAndCapacity. This field is ignored if heating limit is set to NoLimit or LimitCapacity. If blank, there is no limit.

Heating CoP

Efficiency of heating system. This value is used in deriving total heating energy use by dividing the heating load by the heating efficiency.

Cooling

This checkbox field defines whether or not this component is available to operate. If this field is unchecked, the Cooling schedule field will be forced to the generic schedule name Off.

Cooling setpoint

The temperature above which zone heating is turned on. Umi controls the temperature in the zone using a ThermostatSetpoint:DualSetpoint object. This would be for heating and cooling thermostat where both a heating and cooling setpoint can be scheduled for any given time period.

Note

In this version of umi, the heating setpoint can only be scheduled as a constant.

Cooling schedule

The name of a schedule (ref: Schedule) that denotes whether cooling is available. A schedule value greater than 0 (usually 1 is used) indicates that cooling and dehumidification are available. A value less than or equal to 0 (usually 0 is used) denotes that cooling and dehumidification is not available. If blank, cooling and dehumidification are always available.

Note

Schedule for when the cooling system is available. Summer only enables the cooling system when the outdoor temperature is greater than 8 °C below the cooling setpoint.

Todo

to confirm

Cooling limit type

The input must be either LimitFlowRate, LimitCapacity, LimitFlowRateAndCapacity or NoLimit. LimitFlowrate means that the cooling supply air flow rate will be limited to the value specified Max cool flow field. LimitCapacity means that the total cooling capacity will be limited to the value specified in the Max cooling capacity field. LimitFlowRateAndCapacity means that both flow rate and capacity will be limited. NoLimit (the default) means that there will not be any limit on the cooling supply air flow rate or capacity and the subsequent two fields will be ignored.

Max cooling capacity

The maximum allowed total (sensible plus latent) cooling capacity in Watts per square meter if Cooling Limit is set to LimitCapacity or LimitFlowRateAndCapacity. If Cooling limit type is set to NoLimit or LimitFlowRate, this field is ignored.

Max cool flow

The maximum cooling supply air flow rate in cubic meters per second if Cooling Limit is set to LimitFlowRate or LimitFlowRateAndCapacity. This field is ignored if cooling limit is set to NoLimit or LimitCapacity. If blank, there is no limit. If Cooling Limit is set to NoLimit, this field is ignored. This field is required if Outdoor Air Control Type is TemperatureEconomizer in order to establish an upper limit on outdoor air flow when the economizer is active.

Cooling CoP

Performance factor of cooling system. This value is used in deriving the total cooling energy use by dividing the cooling load by the COP.

Mechanical ventilation

Mechanical Ventilation affects building energy consumption by forcing Fresh Air into the zones, air that needs to be treated. If on, an outdoor air quantity for use by the model will be calculated.

Mechanical ventilation schedule

This field is the reference to the schedule that defines how outdoor air requirements change over time. The schedule values are multiplied by the outdoor air flow rate defined by the next two fields. The schedule values must be between 0 and 1, inclusive. For example, if users specify the same schedule as the OccupancySchedule, this means that the current occupancy level will be used when computing the minimum outdoor air flow rate based on the next two fields.

Min fresh air per area

The design outdoor air volume flow rate per square meter of floor area (units are m3/s-m2). This input is used if Outdoor Air Method is Flow/Area, Sum or Maximum. The default value for this field is 0.

Note

Umi uses by default the Sum method which means that the flows calculated from the fields Min fresh air per person, Min fresh air per area, Outdoor Air Flow per Zone, and Air Changes per Hour (using the associated conversions to m3/s for each field) will be added to obtain the zone outdoor air flow rate.

Min fresh air per person

The design outdoor air volume flow rate per person for this zone in cubic meters per second per person. The default is 0.00944 (20 cfm per person). An outdoor air flow rate is calculated based on the total number of people for all People statements assigned to the zone. Occupancy schedule values are not applied during sizing calculations and are applied during the remainder of the simulation. This input is used if Outdoor Air Method is one of Outdoor Air Flow per Person, Sum, or Maximum.

Economizer type

This field specifies if there is an outdoor air economizer. The choices are: NoEconomizer, DifferentialDryBulb, or DifferentialEnthalpy. The default is NoEconomizer. DifferentialDryBulb and DifferentialEnthalpy mean that the economizer will increase the outdoor air flow rate above the minimum outdoor air flow (see fields Design Specification Outdoor Air Object Name and Demand Controlled Ventilation Type) when there is a cooling load and the outdoor air temperature or enthalpy is below the zone exhaust air temperature or enthalpy. The DifferentialDryBulb and DifferentialEnthalpy options require that the Max cool flow be specified which will be used as the limit for maximum outdoor air flow rate.

Heat recovery type

Select from None, Sensible, or Enthalpy. None means that there is no heat recovery. Sensible means that there is sensible heat recovery whenever the zone exhaust air temperature is more favorable than the outdoor air temperature. Enthalpy means that there is latent and sensible heat recovery whenever the zone exhaust air enthalpy is more favorable than the outdoor air enthalpy. The default is None.

Heat recovery efficiency (latent)

The latent heat recovery effectiveness, where effectiveness is defined as the change in supply humidity ratio divided by the difference in entering supply and relief air humidity ratios. The default is 0.65.

Heat recovery efficiency (sensible)

The sensible heat recovery effectiveness, where effectiveness is defined as the change in supply temperature divided by the difference in entering supply and relief air temperatures. The default is 0.70.

Ventilation

Setting	Description	Unit	Default Value
Infiltration	Description
Infiltration rate	Description
Natural ventilation	Description
Natural ventilation minimum outdoor air temperature	Description
Natural ventilation maximum outdoor air temperature	Description
Natural ventilation maximum relative humidity	Description
Natural ventilation schedule	Description
Natural ventilation zone temperature setpoint	Description
Scheduled ventilation	Description
Scheduled ventilation ACH	Description
Scheduled ventilation schedule	Description
Scheduled ventilation setpoint	Description
Buoyancy	Description
Wind	Description
Afn	Description

Infiltration

This field is the name of the schedule that modifies the maximum design volume flow rate (see Design Flow Rate Calculation Method field and related subsequent fields). This fraction between 0.0 and 1.0 is noted as in the above equation.

Infiltration rate

Natural ventilation

Natural ventilation is assumed to be air movement/exchange as a result of openings in the building façade and will not consume any fan energy. For this model, the ventilation air flow rate is a function of wind speed and thermal stack effect, along with the area of the opening being modeled. This object can be used alone or in combination with Scheduled ventilation. This model is intended for simplified ventilation calculations as opposed to the more detailed ventilation investigations that can be performed with Energy+’s AirflowNetwork model. Using the “Wind and Stack with Open Area” model, the natural ventilation flow rate can be controlled by a multiplier fraction schedule applied to the user-defined Operable area and through the specification of minimum, maximum and delta temperatures. The temperatures are taken as single constant values for the entire simulation.

Note

Note that if Natural ventilation is used in combination with Scheduled ventilation, the resulting ventilation rate for the zone will simply be the summation of the flow rates specified by the ventilation objects.

Natural ventilation minimum outdoor air temperature

This is the outdoor temperature (in Celsius) below which ventilation is shut off. The minimum value for this field is -100.0°C and the maximum value is 100.0°C. The default value is -100.0°C if the field is left blank. This lower temperature limit is intended to avoid overcooling a space, which could result in a heating load.

Natural ventilation maximum outdoor air temperature

This is the outdoor temperature (in Celsius) above which ventilation is shut off. The minimum value for this field is -100.0°C and the maximum value is 100.0°C. The default value is 100.0°C if the field is left blank. This upper temperature limit is intended to avoid overheating a space, which could result in a cooling load.

Natural ventilation maximum relative humidity

Defines the dehumidifying relative humidity setpoint, expressed as a percentage (0-100), for each timestep of the simulation.

Note

The default value for the Minimum Relative Humidity is 20C.

Natural ventilation schedule

This field is the name of the schedule (Day | Week | Year) which ultimately modifies the Opening Area value (see previous field). In its current implementation, any value greater than 0 will consider, value above The schedule values must be any positive number between 0 and 1 as a fraction.

Natural ventilation zone temperature setpoint

Scheduled ventilation

Ventilation is the purposeful flow of air from the outdoor environment directly into a thermal zone in order to provide some amount of non-mechanical cooling. Scheduled Ventilation is intended to model “simple” ventilation as opposed to the more detailed ventilation investigations that can be performed with the AirflowNetwork model or with air systems that have outdoor air mixers. Zone ventilation can be controlled by a Scheduled ventilation schedule and through the specification of Scheduled ventilation setpoint, maximum and delta temperatures as described below. Note that maximum and delta temperatures are not supported yet in the Template Editor.

Note

Natural ventilation is assumed as a result of openings in the building façade and will not consume any fan energy. Values for fan pressure and efficiency for natural ventilation are ignored. The conditions of the air entering the space are assumed to be equivalent to outside air conditions.

Scheduled ventilation ACH

This factor, along with the Zone Volume, will be used to determine the Design Flow Rate.

Scheduled ventilation schedule

This field is the name of the schedule (Schedules Tab) that modifies the maximum design volume flow rate. This fraction is between 0.0 and 1.0.

Scheduled ventilation setpoint

This is the indoor temperature (in Celsius) below which ventilation is shutoff. The minimum value for this field is -100.0°C and the maximum value is 100.0°C. The default value is -100.0°C if the field is left blank. This lower temperature limit is intended to avoid overcooling a space and thus result in a heating load. For example, if the user specifies a minimum temperature of 20°C, ventilation is assumed to be available if the zone air temperature is above 20°C. If the zone air temperature drops below 20°C, then ventilation is automatically turned off.

Note

Since the Template Editor does not support changing the values of the Maximum Indoor Temperature, the value will be left blank meaning that the default value is 100.0°C.

Buoyancy

Wind

Afn

Domestic Hot Water

Setting	Description	Unit	Default Value
Enabled	Description
Scheduled	Description
Supply Temperature	Description
Inlet Temperature	Description
Flow rate	Description

Enabled

Scheduled

Supply Temperature

Inlet Temperature

Flow rate

Windows

Setting	Description	Unit	Default Value
Type	Description
Construction	Description
Operable area	Description
Shading is used	Description
Shading system availability schedule	Description
Shading system setpoint	Description
Shading system transmittance	Description
Shading system type	Description
Zone mixing	Description
Zone mixing availability schedule	Description
Zone mixing delta temperature	Description
Zone mixing flow rate	Description
Virtual partition	Description
Airflow network discharge coefficient	Description
Airflow network temperature setpoint	Description
Airflow network window availability	Description

Type

Construction

Operable area

Shading is used

Shading system availability schedule

Shading system setpoint

Shading system transmittance

Shading system type

Zone mixing

ZoneMixing is intended to allow simplified treatment of air exchange between zones. Note that this statement only affects the energy balance of the “receiving” zone and that this statement will not produce any effect on the “source” zone. More advanced mixing calculations are possible using the AirflowNetwork model for multi-zone airflow with or without HVAC system operation.

Zone mixing availability schedule

This field is the name of the schedule (Schedules Tab) that modifies the maximum design volume flow rate parameter (see next field). This fraction between 0.0 and 1.0 modifies the design level parameter.

Zone mixing delta temperature

This number controls when mixing air from the source zone is sent to the receiving zone. This parameter is a temperature and is expressed in units of Celsius. If this field is positive, the temperature of the zone from which the air is being drawn (source zone) must be “Delta Temperature” warmer than the receiving zone air or else no mixing occurs. If this field is negative, the temperature of the source zone must be “Delta Temperature” cooler than the receiving zone air or else no mixing occurs. If this parameter is zero, mixing occurs regardless of the relative zone temperatures.

Zone mixing flow rate

This factor (m3/s-m2) is used, along with the Zone Area to determine the maximum Design Volume Flow Rate as described in the Design Volume Flow Rate field.

Virtual partition

Airflow network discharge coefficient

Airflow network temperature setpoint

Airflow network window availability

Building Templates Tab

This section provide details on the Building Templates Tab

Building Template components description

Core Zone Type

Todo

Section to be written

Perimeter Zone Type

Todo

Section to be written

Structure

Todo

Section to be written

Partition ratio

Todo

Section to be written

Lifespan

Todo

Section to be written

Windows

Todo

Section to be written

Setting	Description
Core Zone Type
Perimeter Zone Type
Structure
Partition ratio
Lifespan
Windows

Indices and tables

• Index
• Module Index
• Search Page