Gains data model Option

Gains data

There are three levels of gains model detail:

Lumped - all internal gains including occupancy, computer, office equipment, miscellaneous, catering process and lighting gains are lumped together into a single value. Solar gains are still calculated in the usual way.Note that with Lumped gains you cannot generate Temperature distribution and Comfort simulation output data.

Note: When using the Lumped Gains model option, Comfort data is not generated because in EnergyPlus the request for comfort calculations is made in the People statement and this is not generated by DesignBuilder when Lumped gains is set.

Early - gains can be defined separately under various categories. This is the default and is normally the preferred option for design and energy assessment work.
Detailed - gains are specified by defining each individual item of equipment in each zone on the Equipment tab. If you select this option then DesignBuilder will automatically set the Timing model option to Schedules . Note that this option was developed for creating very detailed models of existing buildings based on survey data. Entering this data for a large building is very time-consuming and in most cases you will be better served by the Early gains option above.

Important Note: The Detailed gains option is included for legacy models only and may be discontinued in future versions of the software.

Occupancy method

This model option allows the way that occupancy is defined to be customised based on the following options:

1-People/area - the default option where occupancy is defined as occupancy density (in people / m2 or people / ft2).
2-Area per person - is sometimes preferred as an inverse occupancy density. Note that when switching between this option and occupancy density the definitions on the Activity tab zone level are translated accordingly. This is not the case when the number of people option below is selected.
3-Number of people - entering the number of people in each zone can be useful when modelling existing buildings to avoid the need to calculate a value normalised by area. In this case note that the value entered at block and building level does not inherit so well as for the other options, especially in buildings with zones of very different floor areas. In this case enter the number of people for the most common type of zone at building level. Unless you need to enter specific numbers of people in each zone this option is best avoided as it increases the amount of work involved due to the inheritance mechanism not working effectively for gains that are not normalised by floor area.

Occupancy latent gains

There are 2 ways for the sensible-latent split of occupancy gains to be defined:

1-Dynamic calculation - where the latent fraction of occupancy gains is calculated within EnergyPlus at runtime based on internal temperatures and metabolic rate. In this case the ratio of sensible to total occupancy gain will reduce as the internal temperature in the zone increases and at temperatures much above 30°C all of the occupancy gain will be latent (occupants sweating).
2-Fixed fraction - where the latent fraction of occupancy gains is constant regardless of internal conditions and defined on the Activity tab under the Occupancy header.

Note: The total occupancy gain (sensible + latent) is not affected by this option, only the split of sensible vs latent gain.

Lighting gain units

There are 2 ways to define General lighting gains in DesignBuilder:

1-Watts per m2 - this used to be the default value in versions pre v2.1, where the General lighting gains are defined as W/m2 independent of the required illuminance level. This method has the advantage that the level of gains can clearly be understood by looking at W/m2 values and floor area. However it can cause problems when loading data from lighting templates (where lighting gains are defined in W/m2/100lux) in that if the activity is changed subsequently with a different illuminance requirement, the lighting W/m2 value is not updated. This led to the introduction of the second option.
2-Watts per m2 per 100lux - the default option in v2.1 and later. Although the units W/m2/100lux may seem quite obscure, this method of defining lighting gains has advantages over using W/m2. Namely that the actual lighting level is associated with the lighting system type without the need to refer to the activity and hence illuminance requirement. So if a particular lighting system type is installed throughout a building but the building has a range of activities, it will usually be possible to enter the lighting W/m2/100lux value once only at building level, set the activity for each zone and still get realistic lighting gains. See General lighting gains for details on the calculation of lighting gains from W/m2/100lux, floor area and illuminance requirements.
3-Design lighting level - where the lighting gains are defined as W without reference to the zone floor area. This option can be useful when the actual absolute lighting gains levels are known in W. Unless you need to enter lighting equipment gains in each zone this option is best avoided as it increases the amount of work involved due to the inheritance mechanism not working effectively for lighting gains that are not normalised by floor area.

Note: When using the 3-Design lighting level option, where gains are entered in W, the lighting gains data must be entered explicitly in each zone as data will not be loaded from the Lighting template and values inherited from building and block levels will typically not be correct.