Coincidental Loads

Understanding Load Calculations in Building Simulation: Coincidental Loads vs. Steady-State Loads

In the world of building design and simulation, accurately calculating loads is essential for ensuring optimal performance and energy efficiency. As buildings evolve to meet the demands of modern life, understanding the nuances of different load types becomes increasingly critical. Among these, coincidental loads and steady-state loads play pivotal roles in how we design systems that can adapt to varying conditions.

In Tas, loads can be calculated using Heating & Cooling Design Days via the Design Day Wizard, or directly from the Dynamic Simulation Results. In this blog post, we will explore the difference between the two methods and how this relates to coincidental and steady state loads. 

Steady-State vs Dynamic Loads

Before we discuss what coincidental loads are, we need to discuss the difference between steady-state and dynamic loads

Steady-state loads are characterised by their predictability and consistency over time. For instance, the Chartered Institution of Building Services Engineers (CIBSE) employs steady-state heating design day calculations to establish the heating requirements of a building. 

These calculations assume constant conditions for each hour of the design day, including factors such as indoor temperature, occupancy, and weather patterns. A fixed external dry bulb temperature is selected, usually -4°C in the UK, and solar , occupancy and equipment gains are removed. As the hourly conditions do not change from hour to hour, they are considered to be steady and therefore simulating this day over and over should eventually cause the results to converge. 

 

For Heating Design Days, a fixed external dry bulb temperature of -4°C is typically used for sizing in the UK. Other internal gains are removed, such as solar gain and occupancy/equipment gains.

The Design Day Wizard simplifies this process, allowing you to set up these calculations efficiently.

Similarly, the Design Day Wizard can also be utilised for cyclic cooling design day calculations, which differ slightly in that the same day of weather is simulated repeatedly but the weather does typically vary throughout the day:

 

Typically, a hot day of weather is picked for a cooling design day and this day is simulated repeatedly. Other heat gains are usually included, such as occupancy and equipment gains.

Advantages of Steady-State Loads:

  • Simplicity: Steady-state calculations are relatively straightforward and easy to implement, making them accessible for designers.
  • Consistency: They provide reliable estimates for typical operating conditions, allowing for easier compliance with regulations and standards.
  • Time Efficiency: The use of tools like the Design Day Wizard streamlines the process.

Disadvantages of Steady-State Loads:

  • Oversizing Risk: These calculations often lead to oversizing of systems since they focus on worst-case scenarios or peak demands that may not occur simultaneously. As a result, systems may be designed to handle maximum loads that are infrequent or unlikely.
  • Lack of Flexibility: Steady-state calculations do not account for fluctuations in usage or environmental conditions, which can lead to inefficiencies and higher operational costs.
  • Limited Realism: By neglecting the dynamic nature of actual building usage, steady-state calculations may not accurately reflect how systems will perform under varying conditions, potentially resulting in increased energy consumption.

In contrast, dynamic loads fluctuate in response to varying conditions and usage patterns, leading to the concept of coincidental loads. 

What are Coincidental Loads?

Imagine you are simulating a building with 5 zones. These zones are called Zone A, Zone B, Zone C etc. You simulate the entire year, and have results for every hour of the year for these zones…

One way of determining the Peak Load for these zones would be to find the maximum value in each column and sum them:

Office Zone Individual Peak Heating Load (W) Peak Occurrence Time
Zone A 10,000 Day 1, 9:00 AM
Zone B 8,000 Day 5, 9:00 AM
Zone C 12,000 Day 5, 10:00 AM
Zone D 6,000 Day 12, 11:00 AM
Zone E 5,000 Day 11, 2:00 PM
Total Individual Peak 41,000

The total individual peak loads for each office zone represent the maximum heating demand that each zone can reach. However, these peaks may not occur simultaneously; they could happen on different days and at different times.

As a result, the peak load that an HVAC system needs to accommodate when conditioning these spaces is not simply the sum of the individual peak loads. Instead, the actual peak load for the HVAC system corresponds to the specific day and hour when the combined loads of all zones are at their highest.

This is known as a coincidental load, which represents the maximum demand that the HVAC system must be prepared to meet when all zones reach their peak demand at the same time. 

Hour Zone A Heating Load (W) Zone B Heating Load (W) Zone C Heating Load (W) Zone D Heating Load (W) Zone E Heating Load (W) Total Heating Load (W)
2, 9 1,313.97 1,285.20 477.41 461.18 1,297.07 4,834.83
2, 10 730.20 665.77 245.61 212.91 715.16 2,578.65
2, 11 624.66 545.94 204.76 159.28 582.48 2,116.12
2, 12 548.08 475.79 167.82 125.19 457.60 1,774.48
2, 13 492.02 437.21 152.27 110.80 402.73 1,595.03
2, 14 427.83 406.52 144.88 114.07 384.29 1,477.59
2, 15 465.37 427.63 164.17 134.41 435.21 1,826.99

So, to be clear, the coincidental load is found by summing the rows and finding the maximum value in the Total Heating Load column throughout the year. 

In Tas, this is easily achieved in the results viewer by using the Tabular Sum table:

Coincidental Loads & Design Days

Heating Design Days produce a steady state result; the result converges, so the simulation results are the same for each hour:

As the results are the same for every hour, the coincidental peak is the same as the sum of the individual peaks due to the nature of the calculation.

With cyclic cooling design days, the results may vary hour to hour so it is possible that the coincidental load may be different to the sum of the individual peaks:

Hour Zone A (W) Zone B (W) Zone C (W) Zone D (W) Zone E (W) Coincidental (W)
193, 1 0 0 0 0 0 0
193, 2 0 0 0 0 0 0
193, 3 0 0 0 0 0 0
193, 4 0 0 0 0 0 0
193, 5 0 0 0 0 0 0
193, 6 0 0 0 0 0 0
193, 7 0 0 0 0 0 0
193, 8 0 0 0 0 0 0
193, 9 0 0 0 0 32.42 32.42
193, 10 744.19 806.96 329.64 366.47 804.12 3051.38
193, 11 817.84 877.64 359.59 395.19 896.80 3347.06
193, 12 878.05 936.04 385.12 420.38 971.08 3590.67
193, 13 917.72 976.72 403.29 440.83 1,005.45 3744.01
193, 14 975.07 1,011.81 430.39 452.72 1,047.70 3917.69
193, 15 1,026.89 1,032.86 458.94 458.89 1,083.71 4061.29
193, 16 1,067.16 1,039.12 486.24 459.08 1,107.94 4159.54
193, 17 1,099.06 1,043.97 501.24 456.24 1,128.63 4229.14
193, 18 1,020.67 995.22 434.54 423.60 1,044.74 3918.77
193, 19 0 0 0 0 0 0
193, 20 0 0 0 0 0 0
193, 21 0 0 0 0 0 0
193, 22 0 0 0 0 0 0
193, 23 0 0 0 0 0 0
193, 24 0 0 0 0 0 0

In this case, the sum of the individual peaks (4231.98W) is slightly larger than the coincidental peak (4,229.14W).  If the peak for zone D occurred at hour 17 as with the other zones, the coincidental peak would be equal to the sum of the individual peaks. 

Finding Coincidental Peaks in Tas

The method you use to obtain coincidental loads from Tas depends if you are using design days or the dynamic simulation. 

Design Days

If your design day is steady state, i.e. the results are not varying hour by hour, the coincidental load is equal to the peak load so the results from the design day wizard and the peak zone loads report can be used directly. They will be equal. 

If your design day is cyclic as is often the case with cooling design days, you can obtain the coincidental peak by looking at the tabular sum results in the TSD file and finding the maximum value.

Dynamic Simulation

If you are obtaining loads from the dynamic simulation, the Peak Loads report will report the coincidental peak in addition to the individual peaks, for the zones included in the report. 

You can also obtain the coincidental peak from the dynamic simulation by looking at the tabular sum in the TSD results and finding the peak. 

Part L 2021 Building Use Types

Part L 2021 Building Use Types

Sometimes it’s not always clear which NCM internal conditions correspond to each of the Building Use Types listed in the BRUKL document. This table lists them all out, clearly. 

 

These categories are the categories assigned by the BRUKL generator version 6.1.4.0, in conjunction with the 6.1.b internal conditions. 

Retail/Financial and Professional Services

  • A1A2_CarPark
  • A1A2_Circulation
  • A1A2_DepStoreSales
  • A1A2_DepStoreSalesChill
  • A1A2_DepStoreSalesElectric
  • A1A2_Display
  • A1A2_EatDrink
  • A1A2_FoodPrep
  • A1A2_Laund
  • A1A2_Office
  • A1A2_Plant
  • A1A2_RetWareSales
  • A1A2_RetWareSalesChill
  • A1A2_RetWareSalesElectric
  • A1A2_Sales
  • A1A2_SalesChill
  • A1A2_SalesElectric
  • A1A2_Store
  • A1A2_Toilet

Restaurants and Cafes/Drinking Establishments/Takeaways

  • A345_Circulation
  • A345_EatDrink
  • A345_FoodPrep
  • A345_Office
  • A345_Plant
  • A345_Stage
  • A345_Store
  • A345_Toilet

Offices and Workshop Businesses

  • B1_CarPark
  • B1_Changing
  • B1_Circulation
  • B1_EatDrink
  • B1_FoodPrep
  • B1_Gym
  • B1_Office
  • B1_Plant
  • B1_Reception
  • B1_Store
  • B1_Toilet
  • B1_WkshpSS

Hotels

  • C1_Bath
  • C1_Bedroom
  • C1_Changing
  • C1_Circulation
  • C1_DrySptHall
  • C1_EatDrink
  • C1_EnsuiteBedroom
  • C1_FitGym
  • C1_FoodPrep
  • C1_Laund
  • C1_Office
  • C1_Plant
  • C1_Reception
  • C1_Store
  • C1_Toilet

Residential Institutions: Residential Schools

  • C2_Schools_Bath
  • C2_Schools_Bedroom
  • C2_Schools_Changing
  • C2_Schools_Circulation
  • C2_Schools_CommunalArea
  • C2_Schools_DrySptHall
  • C2_Schools_EatDrink
  • C2_Schools_FoodPrep
  • C2_Schools_HighDensIT
  • C2_Schools_Lab
  • C2_Schools_Laund
  • C2_Schools_Lecture
  • C2_Schools_Office
  • C2_Schools_Plant
  • C2_Schools_Reception
  • C2_Schools_Store
  • C2_Schools_Teaching
  • C2_Schools_Toilet
  • C2_Schools_WkshpSS

Residential Institutions: Universities and Colleges

  • C2_Uni_Bath
  • C2_Uni_Bed
  • C2_Uni_Changing
  • C2_Uni_Circulation
  • C2_Uni_CommunalArea
  • C2_Uni_DrySptHall
  • C2_Uni_EatDrink
  • C2_Uni_FitGym
  • C2_Uni_FoodPrep
  • C2_Uni_HighDensIT
  • C2_Uni_Lab
  • C2_Uni_Laund
  • C2_Uni_Lecture
  • C2_Uni_Office
  • C2_Uni_Plant
  • C2_Uni_Reception
  • C2_Uni_Store
  • C2_Uni_Tea
  • C2_Uni_Toilet
  • C2_Uni_WkshpSS

Others: Car Parks 24 hrs

  • CarPark_CarPark
  • CarPark_Circulation
  • CarPark_Office
  • CarPark_Plant
  • CarPark_Toilet

Non-residential Institutions: Crown and County Courts

  • Court_Cell
  • Court_Circulation
  • Court_EatDrink
  • Court_FoodPrep
  • Court_Lecture
  • Court_Office
  • Court_Plant
  • Court_Reception
  • Court_Store
  • Court_Toilet

Non-residential Institutions: Education

  • D1_Edu_Changing
  • D1_Edu_Circulation
  • D1_Edu_DrySptHall
  • D1_Edu_EatDrink
  • D1_Edu_FoodPrep
  • D1_Edu_HighDensIT
  • D1_Edu_Lab
  • D1_Edu_Lecture
  • D1_Edu_Office
  • D1_Edu_Plant
  • D1_Edu_Reception
  • D1_Edu_Store
  • D1_Edu_Teaching
  • D1_Edu_Toilet
  • D1_Edu_WkshpSS

General Assembly and Leisure, Night Clubs, and Theatres

  • D2_Auditoria
  • D2_Changing_High
  • D2_Changing_Low
  • D2_Changing_Medium
  • D2_Circulation
  • D2_CirculationPub
  • D2_DrySptHall
  • D2_EatDrink
  • D2_FitGym
  • D2_FitStud
  • D2_IceRink
  • D2_Laund
  • D2_Lecture
  • D2_Office
  • D2_Plant
  • D2_Reception
  • D2_Sales
  • D2_Stage
  • D2_Store
  • D2_Toilet
  • D2_WkshpSS

Non-residential Institutions: Community/Day Centre

  • DayCtr_Changing
  • DayCtr_Circulation
  • DayCtr_DrySptHall
  • DayCtr_EatDrink
  • DayCtr_FoodPrep
  • DayCtr_Lecture
  • DayCtr_Office
  • DayCtr_Plant
  • DayCtr_Reception
  • DayCtr_Store
  • DayCtr_Toilet
  • DayCtr_WkshpSS

Residential Spaces

  • Dwell_DomBath
  • Dwell_DomCirculation
  • Dwell_DomCommonAreas
  • Dwell_DomDining
  • Dwell_DomKitchen
  • Dwell_DomLounge
  • Dwell_DomToilet

Others: Emergency Services

  • EmgcySvc_Bath
  • EmgcySvc_Bed
  • EmgcySvc_Cell
  • EmgcySvc_Circulation
  • EmgcySvc_DrySptHall
  • EmgcySvc_EatDrink
  • EmgcySvc_FitGym
  • EmgcySvc_FoodPrep
  • EmgcySvc_Office
  • EmgcySvc_Plant
  • EmgcySvc_Reception
  • EmgcySvc_Store
  • EmgcySvc_Toilet

Residential Institutions: Hospitals and Care Homes

  • Hosp_AECons
  • Hosp_Bath
  • Hosp_Bed
  • Hosp_Bed_24x7
  • Hosp_Changing
  • Hosp_Circulation
  • Hosp_CirculationPub
  • Hosp_ClassRm
  • Hosp_Diagnostic
  • Hosp_EatDrink
  • Hosp_FoodPrep
  • Hosp_IndProcess
  • Hosp_Lab
  • Hosp_Laund
  • Hosp_Lecture
  • Hosp_Office
  • Hosp_OpTheatre
  • Hosp_Physiotherapy
  • Hosp_Plant
  • Hosp_PostMortem
  • Hosp_Reception
  • Hosp_Store
  • Hosp_Toilet
  • Hosp_Wards

General Industrial and Special Industrial Groups

  • Indust_Circulation
  • Indust_EatDrink
  • Indust_FoodPrep
  • Indust_IndProcess
  • Indust_Lab
  • Indust_Office
  • Indust_Plant
  • Indust_Reception
  • Indust_Store
  • Indust_Toilet
  • Indust_WareStore

Non-residential Institutions: Libraries, Museums, and Galleries

  • LibMusGall_Circulation
  • LibMusGall_DisplayPublic
  • LibMusGall_EatDrink
  • LibMusGall_FoodPrep
  • LibMusGall_Lab
  • LibMusGall_Lecture
  • LibMusGall_Office
  • LibMusGall_Plant
  • LibMusGall_Reception
  • LibMusGall_Store
  • LibMusGall_Toilet
  • LibMusGall_WkshpSS

Others: Miscellaneous 24hr Activities

  • Misc24Hr_DataCentre
  • Misc24Hr_HeavyPlant
  • Misc24Hr_ServerRoom
  • Misc_24x7Office
  • Misc_24x7Toilet

Secure Residential Institutions

  • Prison_Bath
  • Prison_Cell
  • Prison_Changing
  • Prison_Circulation
  • Prison_ClassRm
  • Prison_DrySptHall
  • Prison_EatDrink
  • Prison_FitGym
  • Prison_FoodPrep
  • Prison_Laund
  • Prison_Lecture
  • Prison_Office
  • Prison_Plant
  • Prison_Reception
  • Prison_Store
  • Prison_Toilet
  • Prison_WkshpSS

Non-residential Institutions: Primary Health Care Building

  • PrmHlthCare_Circulation
  • PrmHlthCare_Office
  • PrmHlthCare_Plant
  • PrmHlthCare_Reception
  • PrmHlthCare_Store
  • PrmHlthCare_Toilet

Others: Stand Alone Utility Block

  • Stand_Changing_High
  • Stand_Changing_Low
  • Stand_Changing_Medium

Others: Passenger Terminals

  • Terminals_Checkin
  • Terminals_Office
  • Terminal_Circulation
  • Terminal_EatDrink
  • Terminal_FoodPrep
  • Terminal_Lounges
  • Terminal_Plant
  • Terminal_Reception
  • Terminal_Store
  • Terminal_Toilet
  • Terminal_WaitRm

Storage or Distribution

  • Ware_24x7Office
  • Ware_24x7WareStore
  • Ware_Changing
  • Ware_Circulation
  • Ware_EatDrink
  • Ware_FoodPrep
  • Ware_Office
  • Ware_Plant
  • Ware_Reception
  • Ware_Store
  • Ware_Toilet
  • Ware_WareStore

Modelling Primary and Secondary Pump Loops in TPD

We will often have to edit the water-side systems created by the wizard. One common reason is to replace a basic setup with a system which has a primary pump loop for the plant equipment, and one or more secondary pump loops distributing water around the building.

Before attempting the setups shown in this guide, you should be familiar with the topic of splitting and recombining plant flows, covered here.

Let’s begin by taking one of the setups from the previous blog post; there are three heating collections and two boilers in parallel.

The flow rates are specified rather than sized, and the correct splitting of flows is ensured by the design flow rate entered into the valves.

There is a single pump which is controlled to run when any of the collections has a load.

For this starting case, we are not using variable flow capacity on the heating collections.

We can very quickly turn this into a primary-secondary setup by replacing the valves with pumps, and adding another pipe (highlighted).

Note that the secondary pumps are connected to the controller of their respective collection. Now each secondary pump will run when its respective collection has a load. The primary pump will run whenever any collection has a load (note the MAX controller).

On hours when only one or two collections have a load, any excess flow from the primary pump will be recirculated in the primary loop.

On hours when all the collections have a load, there is no excess flow to recirculate; all of the flow from the primary pump is sent to a collection.

Note that it is possible for the sum of the secondary pump flow rates to exceed the flow rate of the primary pump; to some extent the rules established in the previous blog post do not apply for primary-secondary setups. This is potential pitfall, however, as there is no error message to warn us that the flow rates are unbalanced and we may have water flowing in an unwanted direction, leading to unwanted temperatures. In this image the flow rate of every pump is 0.9 l/s and the water temperature supplied to the collections has fallen below the target of 71 C.

If we return the pump flow rates to the correct values and delete the wires connecting the secondary pumps to their controllers, we can use the variable flow capacity option on the collections.

Let’s change how the boilers are used now. Let’s only use both boilers if the required heating load is over 50% of the maximum value.

There are a few ways we could detect this switching point; for the sake of this example we are going to test the return water temperature in the primary loop.

We have a setpoint of 71 C and a delta T of 11 C, so for a 50% load we might expect a return temperature of about 65.5 C. Let’s put a controller on the valve of one of the boilers and switch the control signal around this temperature.

We can soon see the impact on the results, compared to the case where the flow is always split evenly between the boilers.

Of course, we could just use a multiboiler component to achieve a similar result instead of two separately controlled boilers. But there may be instances where we prefer to model two separate boilers in this fashion, for example to use a wide control band as in the example above, or in a case where there are further components which we need to take into account (if, for example, one of the boilers was preceded by an exchanger to a different plant loop). There may also be a difference in pump load which needs to be taken into account; on that note, if the boilers and valves are replaced by a multiboiler we should ensure that its pressure drop matches the sum of the pressure drops of the components we have replaced (e.g. 25 kPa for the valve and 25 kPa for the boiler becomes 50 kPa for the multiboiler).

We can try to simplify the setup further; as we are using variable flow capacity on the collections we could experiment with replacing these three collections with a single one and allow the varying flow capacity to provide the flow we need (assuming we don’t need to see the heating load split between the three collections in our results). In this example the difference made to pumping power was around 0.1%, so no major error was introduced; in fact, as simpler systems generally simulate more smoothly and with fewer simulation events, in most situations we are more likely to remove a source of error by simplifying the model.

It’s not necessary with such a simple example, but it can sometimes be expedient to separate loops with a 100% efficient exchanger. This is a convenient way to stop pressure and flows from one loop affecting what’s happening in a connected loop, while still conveying 100% of the heat energy as if the water flows were uninterrupted. This is a particularly useful strategy in cases where pressure-related errors are occurring, or errors relating to negative flow through components.

Using this exchanger technique we can make a variation on an earlier setup; two boilers,
this time in series rather than parallel, with the second controlled only to be used for loads over 50% of the peak.

The first boiler in the loop is controlled to be used whenever there is a load at the collection (or rather, its pump is controlled like this, but remember the boiler will only run whenever there is flow through it).

The second boiler is controlled to be used when the water temperature leaving the first boiler is below the setpoint of 71 C, but only on hours when there is a load (note the MIN controller).

If each boiler is sized for 50% of the total load, and the exchanger efficiency is 100%, then this setup will work just fine. This could be a useful setup if we had a pump associated with each boiler and wanted to see this fact reflected in the results.

We can take this latest example and change it into a very simple-looking setup.

We have used the ancillary load property to remove the boiler pumps from the schematic and, in effect, absorb them into the multiboiler component.

We set the profile modifiers so that ancillary load 1 is used when the heating load is positive, and ancillary load 2 is used when the heating load is over 50%.

If the collection is using variable flow capacity then we don’t even require a controller for the pump.

It is often better to use an elegant solution that gives the correct results, rather than create a complicated setup which matches a schematic drawing. Whether simplification is suitable will depend on the information available and the results detail required, but there are normally several ways to reach similar or even identical results.

Splitting TPD Plant Room Flows

We will often want to create plant room layouts which are more complex than the ones created by the systems wizard, and split and combine flows to use components on separate branching pipes. There are different ways to achieve this, but also a few potential pitfalls; this guide aims to shed some light on the subject.

In the image above we have used the wizard to create three heating circuits because we wish to view the results for each collection separately. But what if we want to have the three heating collections on the same heating loop, served by the same heating source? We might decide wouldn’t be appropriate to put the collections in series as the water temperatures into the second and third collections would be too low. 

In order to put the collections in parallel we will need to use junctions to split and combine the water flow.

Each collection has a controller checking to see if the load is above zero, and the pump has a “max” controller so that it will run if any signal is greater than zero.

If we’re not careful, however, soon we could start running into problems. Here is one message we might well encounter.

Why has this happened?
Why do we have an inconsistent design flow rate?
Let’s look at the parameters which will affect flow sizing:

If we calculated the sized flow rates for the boiler and collections from their maximum loads and delta T, for this model we would find:

Boiler: 0.68 l/s
Heating A: 0.16 l/s
Heating B: 0.32 l/s
Heating C: 0.41 l/s

The 0.68 l/s of the boiler does not match the 0.89 l/s total required by the heating collections. This is the inconsistency referred to in the error message. In other words,

0.16 + 0.32 + 0.41 =/= 0.68.

How can it be fixed? We can either balance the equation or we can remove the boiler from the flow sizing altogether. If we set the boiler delta T to “none” then it won’t be used in the pump sizing and it will just accept whatever flow is required by the collections. Alternatively, we could, for example, change the delta T to 11 for the collections currently using 8; when the components have the same sizing parameters the equation will balance:

0.16 l/s + 0.23 l/s + 0.29 l/s = 0.68 l/s

This setup will still work if we want to incorporate varying flow rates; we can assign variable flow capacity to the collections and the flow rate will decrease for lower heating loads.

When we’re using the variable flow capacity on all the collections there is no more need for the controllers on the pump; the collections’ capacity will increase or decrease to allow the hot water to flow as and when it is needed, and only where it is needed, for example on this hour when only collection C has a heating load:

If we wanted to, we could take our earlier example and replace the multi-boiler with two boiler components, each with a sizing factor of 0.5, and put them in parallel; as long as the boilers are sized using the same delta T the pump sizing will succeed.

What if we didn’t want to size these flows, and instead we wanted to dictate the pump maximum flow rate and the maximum flow rate which will travel down each pipe? Let’s enter a set value for the pump flow rate and add some valves to the system.

Now we might run into an inconsistent design flow rate issue again. The error says that it might relate to the collection “Heating C”, but we shouldn’t take this too literally; this tells us that the heating system has the problem but we will have to check the whole system.

Let’s look at the design flow rate values we’ve entered into our components…

The total flow rate for the valves associated with the collections is 0.3 + 0.3 + 0.3 = 0.9, the same as the pump flow rate. So the problem probably isn’t related to the heating collections after all.

Let’s check the boilers: 0.75 + 0.75 = 1.5 l/s, which is inconsistent with the 0.9 l/s pump flow rate.

Consider what would happen where the boiler flows join before entering the pump; how could 1.5 l/s become 0.9 l/s? It cannot, so the simulation fails. On the other hand, on the other side of the pump there is no problem splitting 0.9 l/s into 0.3 + 0.3 + 0.3.

0.9 = 0.3 + 0.3 + 0.3
0.9 =/= 0.75 + 0.75

We could fix this easily by changing the boiler valve flow rates to 0.45 l/s each.

0.9 = 0.3 + 0.3 + 0.3
0.9 = 0.45 + 0.45

What if we encounter a message about an error calculating capacities?

We’ve already ensured that the flow rates are inconsistent. We now need to check either the component capacities, or pressure drops (note that only one or the other of these parameters will be specified at any time for a given component).

In this system we have specified a pressure drop for each component (and for the pump, a peak pressure value). As before, we should check the whole circuit and not just the component mentioned in the message.

Whereas with the flow rates we needed to ensure that the total flow rates on either side of a junction are equal (e.g., 0.45 and 0.45 combining into 0.9), with the pressure drops we instead need to ensure that when flows split and join the pressure drops on the branching pipes are equal to one another. Let’s break this down further:

Here we have two branches. The flow returning from the heating collections (yellow pipe) reaches a junction and is split between the two boilers. Their flows then recombine and enter the red pipe.

The pressure drop on the top branch is 25 + 50 = 75 kPa. The pressure drop on the bottom branch is 25 + 25 = 50 kPa. 50 and 75 are not equal, so we need to edit the components to balance the equation (e.g., by changing the pressure drop of the top-most valve to 25 kPa).

Meanwhile for the collections the flow from the pump (red) is split into three branches which recombine (yellow).

From top to bottom, the total pressure drop of the branches is:

25 + 25 = 50 kPa
25 + 25 = 50 kPa
50 + 25 = 75 kPa

50 and 75 are not equal. Again, we can change the pressure drop of the bottom-most valve to 25 kPa to remedy this.

We would also receive an error message like this if the peak pressure of the pump was insufficient.

In this example, if every valve, boiler, and collection had a pressure drop of 25 kPa, we could draw the diagram below:

On a complete circuit the water loses 100 kPa of pressure and the pump has to overcome this; the pump peak pressure must be 100 kPa or more.

Now the design flow rates and pressure drops are in balance, and the pump is strong enough to move the water.

The schematic is rather messy. Is there a more elegant solution?

As the error messages above have hinted, the point of the design flow rates and design pressure drops is to get a flow “capacity” value for the components. You can choose to just type this in directly.

Note that this value is not really appropriate for this component, but it is convenient; more on this later.

This approach makes it very easy to split flows equally between branching pipes.

The valves have all been deleted and a capacity of 1 has been entered into each boiler and collection.

Note that we can now adjust the ratio of flow rates between branches very easily; for example, if the capacity of the boilers is in the ratio 5:1 then the flows will take on the same ratio.

Note that this approach of using capacities will also work if we wanted to size the pump flow rate rather than specify it, as long as we set a delta T value to our collections and/or boilers.

One major downside of using capacities like this is it can be hard to get the correct pump load, which is related closely to pressure drop. By using such large capacity values, we have a negligible pressure drop and pump load. We can work around this by adding a valve in series with the pump which has a pressure drop representing the drop around the whole system, and whose flow is sized in the same way as the pump, either “Auto” (sized) or a fixed value:

As before, if it is appropriate for our design, we can turn on the variable capacity option for the collections and do away with the controllers.

In the next blog post on this topic we will look at modelling primary and secondary loops.

Drawing Dormer Windows

Windows which project from a pitched roof can be drawn without difficulty in the Tas 3D modeller. This short guide shows how to achieve this on five example models, using a methodical approach and knowledge of the “intersect planes” tool.

It is recommended that users should be familiar with different techniques for drawing roofs before following this guide. See here for more details.

Example 1

This is the easiest example, a flat-roofed wall dormer. The face of the dormer is coplanar with the external wall and there is no roof void to worry about.

Firstly, create the planes which will define the pitched roof. (On the “drawing utilities” tab, under “3D planes”, use the tool “by points”). Do not apply any planes at this stage.

Now create a plane where all points are equal to the height of the flat roof over the dormer. The reason will become clear in the next step.

Select the space. On the “drawing utilities” tab, under “3D planes”, find the tool “intersect planes”. Select the pitched roof plane and the horizontal plane which you have just created.

This will create a null wall across the space where the pitched roof and flat roof will intersect. From this line, draw null walls to the external wall (on a real project, refer to your drawings for the dormer side wall positions).

Place the window.

Recommended but optional: Clean up null lines.

Now apply the 3D planes. Note that for the flat roof over the dormer you can either use the horizontal plane created earlier or just enter a value for the space height.

Apply zones. Create the 3D analysis model.

In the list of building elements, change the null-exposed element to represent an external wall. Be sure to assign an appropriate construction to this building element in the TBD.

Finished!

In the following examples you can see how these techniques can be used to model window types that could seem challenging at first glance.

Example 2

Here we have a gable-fronted wall dormer. The face of the dormer is coplanar with the external wall and there is no roof void to worry about. But we do have to deal with two pitched roofs over the dormer – this is not a major obstacle as long as we remember how to use the intersect planes tool.

As in the previous example, begin by creating the planes which will define the main pitched roof.

Draw null lines marking the middle and limits of the dormer (on a real project, follow your drawings).

Create the planes which will define the pitched roof over the dormer. Note that it doesn’t matter if the points selected are not within the limits of the dormer’s location according to your drawings – as long as the points are on the correct line, the planes will intersect correctly with the main roof plane to define the dormer limits.

Select one of these spaces and intersect the corresponding dormer roof plane and the main roof plane. Do the same for the other space.

Place the window. Clean up null lines. Apply 3D planes.

Apply zones. Create the 3D analysis model. In the list of building elements, change the null-exposed element to represent an external wall.

Finished!

Example 3

This is similar to example 2 but we have the added complication of a roof void in some parts of the space. Thankfully, the use of 3D planes means the voids will not make our task any more difficult.

Firstly, create the planes which will define the main pitched roof. Draw null lines marking the middle and limits of the dormer (on a real project, follow your drawings).

Create the planes which will define the pitched roof over the dormer.

Select one of these spaces and intersect the corresponding dormer roof plane and the main roof plane. Do the same for the other space.

Draw the internal walls which separate the occupied space and the roof void (on a real project, follow your drawings). Also change the sides of the dormer to internal walls so that a solid wall separates the occupied space from the roof void.

Place the window. Clean up null lines. Apply 3D planes. Note that you can select multiple spaces and assign the same plane to them at the same time.

Apply zones. Create the 3D analysis model.

In the list of building elements, change the internal wall-exposed element (and if necessary, null-exposed element) to represent an external wall. Be sure to assign an appropriate construction to this building element in the TBD.

Finished!

Example 4

By now you can probably see how these techniques can be easily applied to a situation where a dormer window is set back from the external wall. Here we have another gable-roofed dormer and roof void situation, but the window is not coplanar with the external wall.

Firstly, create the planes which will define the main pitched roof. Draw null lines marking the middle and side limits of the dormer (on a real project, follow your drawings).

Create the planes which will define the pitched roof over the dormer. Note that it doesn’t matter if the points selected are not within the limits of the dormer’s location according to the plans – as long as the points are on the correct line, the planes will intersect correctly to define the dormer limits.

Select one of these spaces and intersect the corresponding dormer roof plane and the main roof plane. Do the same for the other space.

Draw the internal walls which separate the occupied space and the roof void (on a real project, follow your drawings). Change the sides of the dormer to internal walls. Draw an internal wall (not external) at the face of the dormer (on a real project, follow your drawings).

Place the window. Clean up null lines. Apply 3D planes.

Apply zones. Create the 3D analysis model. In the list of building elements, change the internal wall-exposed element (and if necessary, null-exposed element) to represent an external wall.

Finished!

Note how the different treatment of “internal wall” and “internal wall-exposed” allows us to have one building element separating the occupied space from the void space, and a different building element separating the occupied space from the outside air.

Example 5

Here we have a hip roof dormer set back from the wall, with a roof void. This is the most complicated example but by now you probably see clearly how to model it. Essentially this is the same as the previous example but with an additional step for the additional plane.

Firstly, create the planes which will define the main pitched roof. Draw null lines marking the middle and side limits of the dormer (on a real project, follow your drawings). Create the planes which will define the pitched roof over the dormer.

Draw an internal wall (not external) at the face of the dormer (on a real project, follow your drawings).

Draw a null line which intersects the dormer centre-line at the apex of the pitched roof over the front of your dormer (on a real project, follow your drawings).

Create the plane which will define the pitched roof over the front of the dormer.

Intersect planes twice. Intersect the front dormer plane with the first dormer side plane. Intersect the front dormer plane with the second dormer side plane.

Clean up null lines. This ensures nothing will interfere with intersecting the main roof plane and the dormer side planes.

Intersect the dormer side roof planes and the main roof planes.

Draw the internal walls which separate the occupied space and the roof void (on a real project, follow your drawings). Change the sides of the dormer to internal walls.

Place the window. Clean up null lines. Apply 3D planes.

Apply zones. Create the 3D analysis model. In the list of building elements, change the internal wall-exposed element (and if necessary, null-exposed element) to represent an external wall.

Finished!

Applying the techniques demonstrated in these examples will allow you to model any dormer window type you are likely to encounter.

Rhino to Tas: How to with Honeybee

Creating Tas models with Rhino & Honeybee

Rhinoceros, otherwise known as Rhino3D, is a freeform surface modeller that is gaining popularity amongst energy modellers and architects for its ease of use in creating complex geometries. Not only that, but Rhino has a diverse range of plugins which make it possible to perform building energy analysis using interoperability with simulation engines such as Tas. In this blog post, we’ll walk through using the Honeybee plugin by Ladybug tools to link Rhino and Tas. 

What are Grasshopper, Ladybug Tools & Honeybee?

Ladybug tools is a collection of applications that support environmental design founded in 2012. These applications are opensource, and are free to use. 

One of these tools is called Honeybee, and this tool is a plugin for Grasshopper, a parametric modelling tool which is part of Rhino. 

Honeybee can be used to perform daylight simulations using Radiance, and simulate energy models using OpenStudio and EnergyPlus. Honeybee can also be used to produce IDF and gbXML files, both of which provide a route into Tas. 

gbXML? IDF? What's the difference?

Both gbXML and IDF are industry standard formats that are designed to allow building design software to share and communicate data. Whilst most building design packages can export gbXML, very few produce gbXML files that contain more than just geometry.

Fortunately, IDF files often contain both geometry and the data required to perform a full building simulation. IDF files produced using Honeybee contain geometry, internal conditions, construction information, design conditions and more, so we recommend using IDF files unless you’re only interested in importing Rhino geometry into Tas. 

How do I get started?

In order to get started with Rhino and Honeybee, you’ll first need to download and install Rhino. At the time of writing, you can get an 90 day trial if you do not have a license. 

Next, you’ll need to download and install Ladybug tools from Food4Rhino. This is a zip file, so unzip it and start Rhino. Then launch Grasshopper, and open the installer.gh file within Grasshopper:

 

After running the installation script and restarting Rhino, you should see the Ladybug tools appear in Grasshopper.

Note that you will also need to install OpenStudio if you want to generate IDF files. 

Creating Rhino Geometry

Now we’re ready to create some simple geometry in Rhino, to get ready for export. Let’s start by drawing a two zone model with a couple of windows – this way we can check that our adiabatic links are created correctly, and we’ll be able to see the principles behind marking surfaces as windows. Note that there are several ways to achieve the same outcome in Rhino, so feel free to experiment!

In the video below, I demonstrate how to:

  • Set the Rhino units
  • Draw two connected cuboids
  • Draw surfaces where the windows will be

It is important to remember that two touching faces must have the same dimensions in order to form an adiabatic link when using Honeybee. 

Setting up Honeybee in Grasshopper

Now that we’ve installed Honeybee and created some geometry in Rhino, we can start setting up our Grasshopper document. In the below video, I demonstrate how to produce a gbXML and an IDF file. I also demonstrate how to modify one of the Honeybee components to produce the IDF file without simulating the OpenStudio project..which saves a lot of time!

To skip running the open studio project and copy the IDF file to a directory of our choice, we can find the line containing run_idf and comment it out using a # at the start of the line. 

				
					import shutil
        elif run_ in (1, 3):  # run the resulting idf throught EnergyPlus
            shutil.copyfile(idf,_idfPathOut)
            #sql, zsz, rdd, html, err = run_idf(idf, _epw_file, silent=silent)

    # parse the error log and report any warnings
#    if run_ in (1, 3) and err is not None:
#        err_obj = Err(err)
#        print(err_obj.file_contents)
#        for warn in err_obj.severe_errors:
#            give_warning(ghenv.Component, warn)
#        for error in err_obj.fatal_errors:
#            raise Exception(error)

				
			

We have also used shutil.copyfile to copy the IDF file to the path of our choosing using the _idfPathOut parameter we added to the ModelToOSM component. For full details, see the video above.

Commenting out the end of the script stops any error messages appearing when we attempt to run the component. 

Importing the IDF into Tas

Once we’ve created our IDF file, we can import it into Tas using the IDF tool. We can optionally create a Tas3D model for shading calculations, import constructions & geometry and even specify the weather we want to use to simulate. In other words, the model is ready to go!

Rhino to Tas Workflow Summary

Below is a labelled Grasshopper diagram showing the key steps in creating gbXML and IDF files from Rhino. Remember, this is just one way to do it! Some of the components can be linked together in a different order, and some can be omitted. If you wanted to model % glazing, for example, you could add the apertures straight to the HoneyBee model and skip specifying and combining them. 

As the Rhino files are saved separately to the Grasshopper files, you can save the Grasshopper files and re-use them on future projects just by updating the geometry components each time. 

What else is Possible with Tas & Rhino?

As Grasshopper provides a visual programming interface to Rhino and Tas has a programming interface, the two can be linked to achieve endless outcomes – from parametric runs to performing full energy simulations and visualising the results in Rhino. 

You can create your own Tas Grasshopper code modules via python scripts:

				
					import win32com.client

#open the building simulator and then open a file
tbdDoc = win32com.client.Dispatch("TBD.Document")
tbdDoc.openReadOnly("C:\\Users\\hilmya\\Desktop\\tas house.tbd")

i = 0
while(tbdDoc.Building.getZone(i) is not None):
    #print each zone name to console
    print(tbdDoc.Building.getZone(i).name)
    i = i+1
				
			

Better yet, you can create C# modules in Grasshopper which have the advantage of code completion:

In order to use the Tas automation interface with a c# script component in Grasshopper, right click on the component and click Manage Assemblies. Then reference the appropriate dll, for example, for TBD you would reference Interop.TBD.dll from the Tas installation directory. 

You can do the same with the Visual basic (VB script) component. 

Ben Abel shares how Hilson Moran use the Tas API

Ben Abel shares how Hilson Moran use the Tas API

Ben Abel is a Director and Head of Research and Development at Hilson Moran, and we recently spoke to him to learn how Hilson Moran use the Tas Application Programming Interface to be one of the most advanced cutting edge designers of the built environment.

Hilson Moran have been using Tas for 25 years

HM has been a long-time user (25 years) of advanced computer modelling techniques in the built environment. EDSL TAS has been the preferred dynamic thermal modelling (DTM) tool of choice over that period and has been used on many iconic and significant projects in the business from 30 St. Mary Axe (The Gherkin) in London, to three of the stadia for the Qatar 2022 World Cup and many others in-between.

Noticing Trends: Coding

The recent upturn and interest in coding by users to create custom interfaces has become increasingly important to improve productivity and allow the outputs to meet the end user/client requirements.

TAS was an early adopter of allowing access to the underlying functions in the software through the Application Programming Interface (API). HM has used this feature extensively to create a range of tools to improve both functionality and productivity.

The types of tools range from bespoke interfaces, for areas such as thermal comfort, HVAC plant modelling and dynamic façade control, and interoperability in using the software through applications such as Grasshopper to allow the DTM information to interact with other outputs from a variety of software.

TM59 Parametric Tool & the CIBSE Building Simulation Group Awards

The HM creation of a TM59 parametric tool, using the TAS API, resulted in the tool being a CIBSE Building Simulation Group Awards finalist at the event at Build2Perform in November 2022.

The tool was used to test and inform the values which were used in the simplified method of the new Building Regulation Part O. The tool allowed hundreds of models to be tested against the overheating criteria to ensure the glazed and ventilations areas presented in the simplified method were in line with the full dynamic methodology.

This task would have been excessively time consuming to achieve manually and at risk of human error.

HM will continue to explore and develop the use of TAS through the API as the benefits it brings are immense due to the efficiencies of automation and the wider sharing and integration of data.

Drawing Roofs

There are many options for drawing roofs in the Tas3D modeller. This short guide explains when each option may be the best choice and clears up some common questions.

Option 1: Set Wall Height
Pros: A very quick solution for simple sloped roofs with a level ridge.
Cons: Unsuitable for any other type of roof.

Option 2: Set Space Height
Pros: A very quick solution for stepped flat roofs.
Cons: Unsuitable for sloped roofs.

Option 3: Set Point Height (Select Join)
Pros: Allows quick modelling of curved roofs and intersecting slopes.
Cons: Can be time-consuming with roofs that cannot be triangulated easily. Not suitable when there is an abrupt change in roof level.

Option 4: Use 3D Planes
Pros: Can be applied to any sloping roof situation. Plane can be used for multiple roof areas at once. Intersection line between two planes can be calculated automatically. Reduces risk of errors arising from incorrect wall and point heights.
Cons: Creating the planes can be more time-consuming than the other methods.

Examples

How would three different roofs be modelled most effectively on this simple building?

With this roof there is a sudden change in roof level, and the “Set Point Height” option cannot be used. We can see why if we consider one of the points used by both sloping roofs (highlighted in lower image) which would need to have two different roof heights at the same time; in this example it would need to be 4.5m for the left-hand roof and 5.5m for the right-hand roof.

We need to use 3D Planes here.

With this example we have a sudden change in roof level, meaning that once again we have points which would need to have two different heights at once; we cannot use the “Set Point Height” option.

In this case we would need to use 3D Planes for the left-hand roof. For the right-hand roof we can simply use the “Set Space Height” option.

This roof rises to a single point and there is no step or sudden change in roof level. The roof can be achieved easily by using the “Set Point Height” option.

What about a situation where the roof itself is very simple, but there are several internal walls underneath it?

The answer depends on whether or not the roof is on a separate storey. In the case where the internal walls extend upwards to meet the underside of the sloping roof, the best option is to use 3D Planes. But if there is a separate roof space and the internal walls only extend to the underside of a flat ceiling, we should model the roof on a separate storey and the “Set Point Height Option” can be used.

What about “gaps” in the roof where internal walls or null lines are exposed?

When you create the analysis model, Tas3D creates a new building element for the exposed parts of internal walls, null walls, etc. These new elements, which will have a name ending in “-exposed” can be changed by the user to represent external walls (or, depending on your building, you may want to set these up to represent, e.g., glazing). When you refresh the analysis model you will see that your roof “gaps” have been filled. Be sure to assign an appropriate construction to these building elements in the TBD.

Overview of a 90.1 Appendix G Project in Tas

This blog post gives a brief overview of the methods recommended in Tas to carry out an ASHRAE 90.1 Appendix G analysis. Please note that the emphasis here is on the Tas methods, rather than interpretation of the regulations; as Tas files allow editing, a wide range of different interpretations can be allowed for. Moreover, the exact requirements for results or methods can vary from project to project. The steps explained here are designed to make carrying out a 90.1 project as quick and accurate as possible.

First step: Create the Proposed Tas3D file

When zoning the model, consider space use and conditioning so that each area can receive the correct internal condition and HVAC. Also consider perimeter zoning rules for the version of 90.1 you are using.

Create the Proposed TBD file

The Proposed TBD file represents the building fabric and space use of the designed building (with some important exceptions), and is used as the basis for the Baseline buildings.
Depending on the requirements of your project, may have to consider the following:
Blinds or shades that are controlled automatically or which are permanent features may be included in the Proposed building. Manually controlled blinds or shades cannot be included in the Proposed building.
The building is required to be mechanically ventilated for the purposes of the 90.1 project, so apertures for naturally ventilated areas should be removed even if they are part of the design.
The solar reflectance of roof constructions should be set as 0.30.
Automatic lighting controls may be included, but manual lighting controls may not.
If the lighting system has been designed then you should use these values. If not then the Proposed building should be set based on the building area method for the appropriate building type (more on this later).
EDSL recommend that the fresh air ventilation rate is set correctly in the internal conditions (or at least close to the correct rate) in order to ensure accurate results in TPD.

Add Proposed files to the NPO Studio

The 90.1 Studio allows organisation of the files associated with the project, and has built-in tools to speed up the project work.

Create the Baseline buildings

The 90.1 Studio creates the geometry for the four Baseline buildings; this includes rotating the building and applying new constructions in line with 90.1 versions 2007, 2010, 2013, and 2016. Constructions will be applied to the Baseline according to the surface type which the user assigns to the building elements from the proposed TBD file, according to the space use types (also assigned by the user), and according to the climate zone.

Adjust Baseline lighting

The 90.1 Studio adjusts the lighting level in the Baseline TBD files to comply with 90.1 2007, 2010, 2013, or 2016. If the Proposed building uses the building area method (because the lighting system has not been fully designed) then so should the Baseline building. In other cases, use the space-by-space method to assign the lighting gains to the Baseline building.
Lighting controls are not allowed in the Baseline building, and are automatically removed by the lighting wizard.

Simulate the TBD files

The TSD files created by these simulations will be automatically stored within the 90.1 project structure.

Create the Proposed systems file

In the Proposed building, if an area of the building has a fully designed mechanical ventilation system which provides both heating and cooling, then you should model the designed system. In all other cases (for example if the area is intended only to be heated, or it is intended to have heating and cooling but the system has not been designed) you must use the appropriate Baseline system.
When modelling the designed system, you should try to replicate the design as closely as possible. In most cases a close equivalent can be found in the wizard and edited later if necessary. Baseline systems can be created in the wizard.
See the Tas documentation for more information on Tas Systems:
https://docs.edsl.net/tpd/
If Baseline systems are used, the user should follow the guidelines below, and ensure that they run the 90.1 airside and plant efficiency tools in the Proposed TPD:
https://docs.edsl.net/NPOTPDx/
When the Proposed TPD is complete, save and add it to the 90.1 Studio.

Complete a sizing run for the Proposed TPD

This is needed so that the zone fresh air rates can be sized (if applicable) and copied to the Baseline TPD files. Save the Proposed TPD after the sizing run.

Create the Baseline 000 TPD file

We only need to create systems for one Baseline building. The TPD files for the three remaining orientations will be generated from this file.
See the guide “Tas Systems Project Wizard and 90.1 Baseline Systems” for details of Baseline system selection and setup:
https://docs.edsl.net/NPOTPDx/
Tas can generate Baseline systems for 90.1 versions 2007, 2010, 2013, 2016, or 2019.
When the Baseline TPD is complete, save and add it to the 90.1 Studio.

Create the other Baseline TPD files

Select the Baseline 000 TPD file. Select the “Use for Baseline Systems” option.

Copy fresh air rate values

Located in the 90.1 Studio under Tools -> Copy Fresh Air Rate Values.

Simulate TPD files

Final Step: Re-runs and reports

The “Generate Documentation” button in the 90.1 Studio creates several reports, including a summary of unmet hours in the Proposed and Baseline buildings. Depending on the 90.1 version and the requirements of your project, a large number of unmet hours may require you to make changes to your system sizing.

A large number of unmet hours could mean zones have been grouped together incorrectly, e.g. zones with very different schedules or gains. It could also indicate airside schedule issues, for example a radiator which is turned off during unoccupied hours and cannot provide out-of-hours heating.

Many 90.1 project submissions are assisted by providing supporting documentation to explain the project inputs. A great deal of this information can be extracted from the systems files, using the “Create Report” button in TPD and by copying data from the 90.1 efficiency tools.

Approved Document O

Overheating: Approved Document O

Approved Document O, commonly referred to as “Part O”,  relates to assessing overheating in domestic properties and came into force on the 15th June 2022.

Its purpose is to reduce the occurence of high indoor temperatures to protect the health and welfare of occupants.

TM59 vs Approved Document O?

When it comes to dynamic thermal modelling, the methodology is based on TM59 – the main differences relate to openings. The following opening controls should be familiar:

  • During the day (8am to 11pm), openings should start to open at 22°C and be fully open at 26°C
  • The openings should start to close when the temperature falls below 26°C and be fully closed at 22°C
In addition to the above, Approved Document O states that, at night (11pm to 8am), inaccessible openings should:
  • Be fully open if the internal temperature exceeds 23°C at 11pm and stay open until 8am

This does not apply to ground floor windows or openings which pose a security risk.

Demonstrating Complaince in Tas

In Tas version 9.5.4 we have introduced a new aperture function specifically for Approved Document O.

Simply set up your models as you would for TM59 and apply the above aperture function to openings which are safe to open at night.

The day operation of the function will reflect the input settings, and at night the apertures will automatically stay open if the temperature exceeds 23°C at 11pm.

Then run through the TM59 wizard as normal.

Part O Aperture Function in Tas.

What else is new?

In addition to the new aperture function for part O, Tas v9.5.4 also allows you to model the effect of ceiling fans and other means of reliably generating air movement:

TM59 wizard screenshot showing wind speed column

Increased air movement can help reduce the temperature a person experiences when there are warm radiant surfaces present.

This functionality has also been added to our TM52 Adaptive Overheating report.

Where can I find more information about TM59 and Approved Document O?

In addition to the official TM59 document and the offical Approved Document O document, please see our TM59 documentation for more information about Approved Document O and TM59 in Tas.