Model data hierarchy & data inheritance

See also the Model data hierarchy and inheritance tutorial

DesignBuilder models are organised in a simple hierarchy:

Default data is inherited from the level above in the hierarchy, so block data is inherited from building level, zone data is inherited from block data and surface data from zone data. This arrangement allows you to make settings at building level which can becomes active throughout the whole building; or make settings at block level to change data for all zones/surfaces in the block. So for example, if the External wall construction is set to 'Wall 1' at building level, then this will be the default External wall for all blocks in the building. It is possible to change the inherited defaults in any of these blocks by making an explicit selection (say 'Wall 2'). All the zones in the block whose external wall construction was set to 'Wall 2' have that default External wall construction.

The construction and opening defaults are inherited down to surface level where the data is actually used in the calculations. For example it is the External wall construction model data at the surface level that defines the actual construction used for that external wall. The External wall model data set at zone, block and building level has no effect on the model (other than by providing the default data for the level below in the hierarchy).

To assist in identifying where data is inherited from DesignBuilder uses a colour code. Data set at building level or user defined data ‘hard set’ at any level below will appear in red. All data inherited at levels below will be in blue (see below).

The simplest way of determining where data is inherited from is to start at the lowest level, a surface or opening, and go up through the levels until the data turns red. This then is the level from which the data has been inherited.

The DesignBuilder hierarchy mechanism is a fast way of setting data globally in a building model, but you must take care to enter the minimum amount of data to get the most from the inheritance system. For example if all zones in a particular block have the same activity called say 'Office work', you should set the activity at block level and not multiple times at zone level. Equally if all the blocks in the building have the same activity, you should set the data at the building level and allow the blocks to inherit the data from the building. By keeping the amount of user data to a minimum, you will find it quicker to make changes at a later date. Clearly it is much faster to change a few Model data items at building and block level than it is to make multiple changes at zone or surface levels.

When entering construction data, you could set the construction for each surface in the model but in practice this would be an extremely inefficient process. It is faster and less error-prone to set the construction as high up in the hierarchy as possible, possibly at building level (if all external walls in the building have that external wall construction), or at block level if all walls in that block have the construction (and other blocks don't).

Most data at the building level is 'user data' as buildings do not inherit their data from the site level.

Site data holds location and regional settings as well as a list of buildings.

To undo user defined ‘hard set’ data run the Edit > Clear to default menu command and select All data’ or Custom openings and specify level (block, zone or surface) down to which the data is to be cleared.

Defaults

In short the rules are:

Construction and Openings data is used at the surface level, i.e. all construction and opening data at building, block and zone level is default data and only data at surface level is actually used to define the model.
Activity, Lighting, HVAC, Equipment data is used at the zone level, i.e. all Activity, Lighting, HVAC, Equipment data at building and block level is default data.

A common question is "Why do I see Pitched roof constructions at building/block/zone level on the Constructions tab when my building/block/zone doesn't have a pitched roof"?

The answer is that the Pitched roof construction setting at building, block and zone levels should be thought of as the default setting for any pitched roofs that may (or may not) exist in the model further down in the hierarchy. If there are no pitched roofs in the model then the data is simply not used.

Custom openings

When custom (user-drawn) openings have been created at surface level these override any openings that would otherwise have been generated through the facade layout Model data for the surface.

Component blocks

Component blocks inherit their data from building level.

Partition data inheritance

There are 2 types of partition surface:

Partitions separating zones within a single block. These partitions within a block inherit their data from the block level. Why? They can't inherit from zone level because there are 2 zones adjacent to the partition so they inherit from the next level up in the hierarchy - blocks.
Inter-block partitions which separate zones in 2 different blocks have 2 parent blocks and so it is not possible for the data to inherit from block level for these surfaces so data inherits directly from building level.