Steps in Performing Analysis

 

The following workflow is recommended for preparing and performing a <VE> Compliance analysis for Part L2 (2006). The plan need not be followed slavishly. Variations can be made in the ordering of the tasks and experienced users may wish to take alternative approaches to some of the stages. The purpose of the plan is to guide you through the basic process.

The process usually begins with the entry of building geometry in ModelIT.

The building location is specified in the APLocate utility. The L2 regulations currently cover locations in England and Wales.

Weather data for simulation-based Part L2 (2006) assessments is provided by CIBSE and consists of two weather files – a Test Reference Year (TRY) used for Criterion 1 and a Design Summer Year (DSY) which is used in one of the methods for showing compliance with Criterion 3. TRY and DSY files are provided for 14 UK locations. You will need the TRY and DSY files corresponding to the nearest of these locations to the building location. A licence to use this data must be obtained from CIBSE. IES acts as an agent for CIBSE and the licence to use the data may be purchased online using an option on the IES Online menu. If you use this option, copies of the files in the IES .fwt format will automatically added to your installation.

Constructions for building elements such as walls, roofs and glazing are created in the Constructions Database (CDB) utility accessible via Apache View or <VE> Compliance. They should satisfy the U value requirements of Criterion 2. The construction definition should include allowance for non-repeating thermal bridging, using an area-based thermal bridging coefficient. Constructions may be assigned to building elements in either Apache View or <VE> Compliance.

At this stage you may wish to go to <VE> Compliance and set up some of the high-level data required for the compliance analysis.

First check that the Regulatory framework selector is set to ‘Part L2 (2006) – ApacheSim’.

In the ‘Building settings’ box near the bottom of the screen select a building type from the list. This indicates the type of building for Part L2 purposes and determines what room activities can be specified in the building. It also automatically sets the Building Category, which determines glazing areas in the notional building.

For a building with multiple use, the various parts can be analysed by including NCM activities from other NCM building types. This is a new feature in version 5.6.

Not all zones may need to be included in a compliance run for example separate buildings may exist within the same model. The part(s) of the building included in a particular analysis is defined by the settings of the check boxes ‘Include room in Building Regs analysis?’ for each room on the Space Data Building Regulations tab.

An efficient way to assign Space Data is by means of Room Templates. A Room Template contains a collection of settings that define the internal conditions applying in a room of a given kind. By defining these conditions centrally you can assign them quickly to large numbers of rooms and transfer them readily to other models via the Import Template mechanism.

Room Templates contain data arranged on tabs under the headings Building Regulations, Room Conditions, Systems, Internal Gains and Air Exchanges. Not all this data is used in <VE> Compliance assessments, some being overridden by standard settings. It is therefore important to understand where and how the various components of Room Template data are used. In particular, if you do not intend to use the analysis options available in Apache View (which analyses the real building) you do not need to set Room Template data on the Room Conditions and Internal Gains tabs, or create air exchanges of the Auxiliary Ventilation type.

One of the attributes that can usefully be set in the Room Template is the NCM Activity, which is always partnered with an NCM Building Type. If these attributes are set in the Room Template, rooms assigned the template will automatically have the NCM Activity (and all the Space Data associated with it) set in <VE> Compliance.

If you adopt a policy of including NCM Activity settings in your Room Templates you will save a lot of time and effort assigning NCM Activities to individual rooms and groups of rooms in <VE> Compliance.

The next section provides guidance on the Room Template settings.

When creating Room Templates it is important to understand which Room Template settings will be used in <VE> Compliance and which are overridden by standard activity-based settings.

 

Building Regulations (taken from Room Template or specified room by room)

This tab contains data used exclusively by <VE> Compliance. Some of the fields can be set in the Room Template. Others appear only in the <VE> Compliance Space Data and must be set on a room-by-room basis.

The check box ‘Include room in Building Regs analysis?’ allows you to restrict the Part L analysis to part of the building only.

The ‘Type of room’ attribute is normally set to ‘Heated room’, but the following alternative settings are provided to cover various types of unheated space:

Unheated roof – use this type for an unheated roof space lying outside the insulated building envelope (ie where the insulation is at ceiling level).

Glazing cavity (required only rarely) – use this type for a glazing cavity that has been modelled as a separate room for simulation purposes.

Unheated buffer space – use this type for other types of unheated space attached to the building but lying outside the insulated building envelope. Examples are car parks and lean-to outbuildings.

Internal void or warm roof – use this type for floor and ceiling voids, and for roof spaces that lie inside the insulated building envelope (ie with insulation at rafter level).

In the case of the first three types listed above – all representing types of unheated buffer space – an external ventilation rate must also be entered for the purpose of calculating U values for Criterion 2. All the above types of room are excluded from the floor area summation upon which the emission ratings are based.

The settings NCM Building type and NCM Activity together specify the activity assigned to the room for the compliance analysis, which in turn (via the NCM Template) sets the standard conditions applied for occupancy and plant operation. While these attributes are optional in the Room Template, it is a good idea to set them there to save effort in <VE> Compliance.

 

Room conditions (taken entirely from NCM template)

The data set on this tab in the Room Template will be ignored in <VE> Compliance (but it will be used for assessments of the real building in Apache View).

In <VE> Compliance, the data on this tab can be viewed but not edited. It is taken from the NCM Template as part of the specification of standard occupancy and plant operation conditions.

 

System (taken from Room Template)

The data set on this tab in the Room Template will be used in both <VE> Compliance and Apache View.

In either of these views, data on this tab is initially taken entirely from the Room Template (but as usual you have the option to override this data in individual rooms).

For compliance assessments, the important parameters on the System tab are the following.

In the Systems box:

HVAC system – this indicates the Apache System serving the room’s space conditioning needs

DHW system – this indicates the Apache System serving the room’s hot water needs including any solar energy system

In the System outside air supply box:

Free cooling flow capacity – this indicates the maximum intake of outside air that is available for free cooling. In the case of a naturally ventilated room, a value of 5 ach would be typical to model ventilation by window opening. In the case of an air conditioned room, where the outside air is brought in via the system, it would be usual to express the value in l/(s·m²) and a value of 0.5 in l/(s·m²) would be typical. Note that this figure represents the additional outside air intake over and above the minimum ventilation level. Free cooling is covered further in the User Guide.

Parameters on the System tab that can be ignored are:

Auxiliary ventilation system – this is not applicable because under the NCM conventions there is no conditioning of ventilation air.

Sizeable parameters (shown in blue) – sizing plays no part in <VE> Compliance.

Humidity limits – these are disabled for <VE> Compliance assessments in line with the conventions applying in the NCM systems approach.

Flow rate and profile for System outside air supply – in <VE> Compliance this type of air supply is replaced by standard ventilation patterns handled by Auxiliary Ventilation air exchanges.

The setting of data on the System tab is closely linked with the setting of data in Apache Systems, which is dealt with below.

 

Internal gains (taken from NCM Template – lighting editing permitted)

In the <VE> Compliance Space Data, this data is taken from the NCM Template as part of the specification of standard occupancy and plant operation conditions. It can be viewed but, with the exception of the lighting data, should not normally be edited.

An exception to this rule can occasionally be appropriate where rooms have been subdivided with horizontal partitions for modelling purposes. In such cases it is permissible to distribute the gains as appropriate among the sub-spaces. However, it is your responsibility to ensure that the total gains for the room are as specified in the NCM template.

The lighting data in <VE> Compliance has a special status. Whilst it is initially set from the NCM Template (activity) it may be edited in order to model improvements to lighting system efficiency over that assumed in the notional building. The types of edit permitted are a) changes to the gains and associated power consumptions of the lights and b) changes to the profiles applied to the lighting.

The lighting levels laid down for the different NCM room activities are specified in terms of a lighting illuminance (lux). The rules for the notional building translate this to a power consumption (and corresponding room gain) expressed in W/m² using an installed power density factor (W/m² per 100 lux). The power density factor assumed in the notional building is 3.75 W/m² per 100 lux for offices and similar rooms such as classrooms, seminar rooms and conference rooms, and 5.20 W/m² per 100 lux for rooms of other types. In an office, for example, an illuminance level of 500 lux lighting level would require a power input of 18.75 W/m². The same power density factors form the basis for the lighting gain and consumption data (expressed in W/m²) contained in the NCM templates used in both the notional building and the actual building. This means that if the lighting system in the actual building achieves a 20% reduction in power density factor over the value assumed in the template (for example from 3.75 to 3.0 W/m² per 100 lux), this should be accounted for by reducing the lighting gain by the same factor (for example from 18.75 to 15.0 W/m²). Note that both the gain (which affects cooling loads and summer temperatures) and the power consumption (which directly affects carbon emissions) should be reduced.

Daylight compensation controls can also be included in the compliance assessment. The recommended way to do this is with dimming profile which is applied in combination with the variation profile and can be used to reduce the lighting gains in the rooms in response to available daylight. Contact support@iesve.com for further guidance on this approach.

It is important to emphasize that where changes are made to the lighting data, this must be done in the rooms, not in the NCM Template (which is uneditable). Data for a group of rooms may be edited together by means of the ‘Edit group attributes’ toolbar icon.

The data appearing on this tab in the Room Template will be ignored in <VE> Compliance (but will be used for assessments of the real building in Apache View).

 

Air exchanges (auxiliary vent from NCM Template, other vent from Room Template)

Some of the data on the Room Template’s Air Exchange tab is used in <VE> Compliance, and some is overridden. The rules are as follows.

The activity (NCM Template) for a room specifies a rate and a schedule for minimum ventilation supplied to the room. This ventilation appears in the NCM template as an air exchange of type Auxiliary Ventilation, which replaces any other Auxiliary Ventilation air exchanges that might be assigned to that room by means of the Room Template or manual additions. By contrast, other types of air exchange (those of type Infiltration or Natural Ventilation) assigned to the room by the template or otherwise are retained in <VE> Compliance.

One further rule is that any settings for ‘System outside air supply’ on the System tab are, like Auxiliary Ventilation air exchanges, ignored in <VE> Compliance.

The straightforward way to ensure that ventilation is correctly modelled in <VE> Compliance is to follow the scheme set out below:

1. Specify infiltration based on air leakage characteristics.

2. If you are not concerned with the real building (as used for Apache View analyses) ignore Auxiliary Ventilation air exchanges and System outside air supply settings in the Room Template.

3. If you are modelling the real building, set up its minimum ventilation rates as either Auxiliary Ventilation air exchanges or System outside air supply settings, keeping this component of ventilation separate from ventilation of other kinds.

4. Where additional ventilation – that is, ventilation over and above the minimum levels – is required, use either Natural ventilation or Free cooling (the latter being the recommended first choice).

This will ensure that those ventilation components that are subject to standard settings for compliance purposes are identifiable and correctly substituted without omissions or double counting.

Under normal circumstances auxiliary ventilation should not be edited, as this data forms part of the NCM activity specification. There is one exception to this rule: if ventilation is provided by an ApacheHVAC system (at the rate set in the NCM template), it would be appropriate to turn off the auxiliary ventilation.

More guidance on ventilation in compliance assessments is provided in Appendix A of this User Guide.

It is recommended that HVAC and DHW systems characteristics for <VE> Compliance analysis are specified within the framework of Apache Systems. Apache Systems provide a robust and uncomplicated system model that has been harmonised with that provided in iSBEM with the aim of providing a point of reference and common ground between these alternative compliance methods.

Systems are one of the aspects of building design where substantial carbon emissions improvements can be introduced. The system data is therefore under your control, and it is shared between the real building (as displayed in Apache View) and the actual building (as displayed in <VE> Compliance).

The Apache System HVAC model has three key parameters, which can be defined in summary as follows:

SCoP – the efficiency of the heating system

SSEER – the efficiency of the cooling system (if present)

Auxiliary Energy Value – energy required for fans, pumps and controls

These are the most important parameters featuring in the calculation of the energy consumed by the space heating and cooling systems. Taken together with the fuels specified for heating and cooling, they encapsulate most of the important data about system performance in relation to carbon emissions.

On the Apache System dialogue there are other parameters that are linked with the heating and cooling system efficiencies and do not represent independently editable settings. For example, the heating system’s Generator seasonal efficiency and Heating delivery efficiency are linked to the SCoP by the relation

SCoP = (Generator seasonal efficiency) × (Heating delivery efficiency)

so that in terms of carbon emissions they can be viewed as secondary to the SCoP.

On the cooling side an analogous relationship exists between SSEER and the following parameters:

EER – the cooling system generator energy efficiency ratio or COP

CDE – the cooling delivery efficiency, and

HRP – the heat rejection pump and fan power fraction

namely

SSEER = EER * CDE / (1 + (EER + 1)*HRP)

In terms of carbon emissions EER, CDE and HRP can thus be viewed as secondary to the SSEER.

These ‘secondary’ parameters are important for certain design tasks in Apache View – for example the calculation of boiler and chiller loads. But for <VE> Compliance, SCoP and SSEER are the key efficiency measures.

Auxiliary energy value is a concept that has been developed in connection with the NCM methodology. This parameter indicates the power consumption of fans, pumps and controls associated with the space heating and cooling systems. It is expressed in terms of Watts per square metre of floor area served, and is incurred when the heating, cooling or ventilation systems are running.

Parameter values can be entered directly into the Apache System dialogue. But it will usually be appropriate to make use of the UK NCM System Data Wizard to assist this task.

The UK NCM System Data Wizard has been developed as a replica of the analogous facility in iSBEM. Its purpose is to guide you through the process of describing the system properties and to generate values for the three key parameters.

In addition to the key parameters mentioned so far, there are other system parameters of importance such as heating and cooling system fuels and ventilation heat recovery effectiveness. These are also generated automatically from data entered in the wizard.

More information on using the wizard is provided in the <VE> Compliance User Guide.

New nomenclature for heating, cooling efficiencies has recently been introduced that aligns <VE Compliance> with the NCM. Definitions of these can be found in the DCLG document ‘Non-Domestic Heating, Cooling and Ventilation Compliance Guide’. This is freely downloadable from the DCLG website:

http://www.odpm.gov.uk/index.asp?id=1130726

SCoP and SEER values for commonly available plant can be found at:

www.eurovent-certification.com

The Apache System approach to DHW systems is slightly different from that adopted in iSBEM, but allows essentially the same flexibility. By default DHW is assumed to be the supplied by the same Apache System as the space heating system. If the building has a separate DHW system this can be created as an Apache System and connected to the rooms it supplies by means of the DHW System selector on the Space Data System tab. The efficiency of the DHW system must be expressed in terms of a generator (eg boiler) efficiency and a DHW delivery efficiency, the overall efficiency of the system being the produce of these two efficiencies.

The DHW system wizard enables the definition of the delivery efficiency, storage and the secondary circulation efficiencies and pumping power. The DHW heating demand can be derived from a solar water heating system. This system will use solar power, when available, to pre-heat the water for the DHW system. A storage system can be defined for the solar water heating system.

While the real (Apache View) and actual (<VE> Compliance) systems are in most respects identical, one difference is enforced in <VE> Compliance because of the way minimum ventilation is specified in NCM. For the real building there are controls on the Space Data System tab allowing you to specify air supplied to the room in the form of a ‘System air supply’. In <VE> Compliance all such air supplies are handled by Auxiliary Ventilation air exchanges, and for this reason the System air supply is disabled in this View. Following on from this the settings in Apache Systems dealing with setting the condition of the System air supply do not play a part in <VE> Compliance. In <VE> Compliance, ventilation is always supplied to rooms (or their terminal HVAC units) at outside air temperature.

Four renewable systems are available for use within the actual building; CHP, Wind, PVs and Solar water heating. CHP should be sized to provide the base load of heating for the building and the power generated will be used to offset the electrical energy usage in the building. Wind and PV systems will, when the prevailing weather conditions permit, provide electrical energy that will offset electrical energy usage in the building.

The carbon emission factors to be used in L2 (2006) compliance assessments are stipulated in the NCM methodology for a range of fuels. The Fuels Data facility in Apache View and <VE> Compliance allows fuel carbon emission factors to be edited. The default values are those which conform with NCM. For compliance runs, any departure from these values, or use of fuels not on the NCM list, would need to be carefully justified in supporting documentation.

We now return to the Building & System Data dialogue to prepare for the compliance simulations. If the ‘Set Building & System Data’ button is not visible at the bottom of the screen, move the cursor into an empty space on the model workspace graphic and click once.

Building & System Data is distributed over three tabs.

First, on the General tab, fill in the address and contact details.

Then move to the Building & System Performance tab. This contains data required by the BRUKL compliance checker that collates the simulation results and generates the compliance report.

Building air permeability at 50 Pa – BRUKL requires confirmation of this air-tightness parameter, which must have a value of 10 m³/( m²·h) or less. Note that setting this parameter must be set in addition to the infiltration rates used in simulations.

Is solar gain acceptable in occupied zones without mechanical cooling (L2A paragraphs 59 & 60)? -  If the building contains any occupied spaces without mechanical cooling (air conditioning), you are required to make a statement that the solar gain in those rooms has been shown to be acceptable (Criterion 3).

Method used to show compliance with L2A paragraph 60 (supply supporting documentation) - If the previous box displays ‘Yes’, the method used to demonstrate that Criterion 3 is satisfied must be indicated here. The recommended setting for <VE> Compliance methodology is Method b (temperature simulation).

Heat, cool source and DHW efficiency - BRUKL requires the overall system heat source efficiency as an input. You may type a value or tick the box labelled ‘Derive from Apache System?’ to get the software to calculate an area-weighted average heat source efficiency for all Apache Systems used in the building. In addition BRUKL requires confirmation of the stage of analysis either as designed; or as built and the overall building specific fan power.

The remaining parameters appear in the box labelled ‘Adjustment for management features’. These settings allow credit to be taken in the BER calculation for management features applied to electrical power and lighting:

Electric power factor

Lighting systems have provision for metering?

Lighting systems metering warns of ‘out-of-range’ values?

Finally, click on the Simulations settings tab, which displays the ApacheSim simulation settings that will be used in the Compliance simulations and test runs. Note that where appropriate these are shared between the Notional and Actual building, and between compliance and summer temperature check simulations. The following are the important settings:

Results file – the name you enter here (prefixed by ‘a_’ for the actual building and ‘n_’ for the notional building) will be used to store the results of the simulations, which can be viewed in Vista.

SunCast link? – tick this box if you wish to use SunCast shading data in the simulation of the actual building.

Preconditioning period – make sure (using test runs if necessary) that this is sufficient to establish a realistic starting condition for the simulations.

Other settings which you may also need to use are:

Natural ventilation air exchange? – tick this box if you have specified any ventilation by means of natural ventilation air exchanges

Use previous results for notional building? – tick this box to save simulation time if you are repeating a compliance test with changes that do not affect the notional building, for example changes to system efficiencies.

You may also change the time step, reporting interval and output options to generate more detailed results data for Vista.

Note that the weather file is forced to the appropriate TRY dataset for compliance simulations. If this file is not present compliance simulations will not be enabled.

Select ‘Notional’ from the Current model selector at the top right of the screen. You can then inspect the notional building. Note the changes to glazing (and in some cases doors), constructions, Apache Systems and Space Data. You may if you wish perform test simulations on the notional building to check its performance over periods of a few days up to a year.

Under the NCM rules, the notional building is generated automatically from the actual building and is in almost every respect uneditable. The only attribute of the notional building that may in some instances be edited is the heating system fuel in the appropriate Apache System(s). If natural gas is not available at the site, this fuel may be switched to oil. This can be done in the Apache System utility, accessed from any suitable View.

Before committing to a full compliance analysis it is generally advisable to check the model settings by performing one or two test runs on the actual building. This is done using the button ‘CO2 emissions: test run (actual building)’. Test runs may also be performed on the notional building.

Simulate the building for a few days in winter and a few days in summer. View the results in Vista and check that the model is behaving as designed. In particular, check room temperature control, the operation of mechanical and free cooling and take a look at system loads and energy consumptions. This feedback provides a check on the overall design and helps eliminate model input errors.

When you are satisfied that the actual building model is performing as intended, click on the button ‘CO2 Emissions: Part L compliance’. The software will immediately begin the analysis for compliance with Criterion 1.

The first stage of the analysis is a check on building element U values as required by Criterion 2. Any failures will result in a screen message and the analysis will halt.

The next step is the simulation of the actual building. Progress is indicated on the screen.

This is followed by simulation of the notional building.

Results from both buildings, together with data provided on the Building & System Data dialogue, is then fed into the BRUKL compliance calculator. The calculations performed there to produce the Building CO₂ Emission Rate (BER) and Target CO₂ Emission Rate (TER) are set out in Appendix B

When the process is complete a summary of the result of the Part L2 analysis will be displayed on the Results tab, and you can click on a button to display the compliance document generated by BRUKL.

If the result is a pass for Criterion 1 you may move on to the next stage.

Otherwise you will need to improve the design and try again.

For buildings including rooms that are not served by comfort cooling, a check against Criterion 3 is required.

The recommended procedure is to use method b, which is based on operative temperature statistics in these rooms.

Click on the button labelled ‘Summer temperature check (actual building)’. This displays an interface for performing summer temperature simulations. You will need to assign or check the settings, including the following:

Results file – the name you enter here (prefixed by ‘s_=’) will be used to store the results of the simulation, which can be viewed in Vista.

SunCast link?

Note that the settings appearing here are shared, where appropriate, with other <VE> Compliance simulations. However, you will need to set the simulation period. A whole year’s simulation is normally appropriate, but there is some flexibility in the rules.

Document L2A should be consulted for the requirements governing summer temperature performance.

At the end of the simulation a report is generated on the incidence of high temperatures in the rooms without comfort cooling, which can form part of your Part L2 submission.

Assuming a successful outcome, the Part L2 (2006) compliance process is now complete in relation to those aspects that can be tested before construction. The reports generated, together with appropriate supporting evidence, can now be submitted to Building Control.

The content of Part L submissions should be agreed in advance with the local Building Control officer as there may be differing interpretations during the early stages of implementation of the new regulations. These are likely to be resolved over time as a sufficient number of Competent Persons are trained and accredited. It may be necessary, for instance, to agree how compliance with Criterion 4 will be met post construction as part of the pre-Construction report.