From Heatweb Wiki
Jump to: navigation, search

Diversity is how one works out the peak instantaneous hot water load on a heat network, based on the number of properties. As the number increases, the possibility of every system running at peak load reduces, and peak design load also reduces.

Diversity will vary depending on application, however we are concerned primarily in this article with domestic properties.

Danish DS439


Coincidence Factor for DS439

This represents the peak load on a network as a percentage of the sum total of individual peak loads (Number x 37.6kW).


DS439 is unavailable in English, despite being referred to in UK guidance, however the above graph is derived from DS439 based on a peak property load of 37.6kW.

For larger HIUs (see below) coincidence factors are commonly applied to peak HIU output (incorrectly in the opinion of many, including ourselves).


Real World Date At 1s Resolution

Overlapped Diversity

Scaling Diversity for Larger Properties

A larger property may have an HIU sized for higher peak flow rate, so how does this affect diversity?

Scaling on Coincidence

With the Danish diversity at 37.6kW for a standard property, if we use a 75.4kW HIU, it is a common practice is to base diversity on doubling the calculation.

So for example, Danish for 10 properties is 89kW. It would be wrong to say if these properties had 80kW HIUs that the peak load will be 178kW.

178kW would, by Danish standard, deliver enough power for around 37 properties.

If one were to say a property with a 38kW HIU had 2-3 people, say 2.5, and a larger 76 kW unit had 4-6 people, then...

10 larger 76kW HIU properties, potential for 760kW, with 50 people = 178 kW

20 standard 38kW HIU properties, potential for 760kW, with 50 people = 126 kW

Why the disparity?

One reason given is that in a single larger property, rather than than two smaller properties, occupants are more likely to get up at the same time. However, patterns of hot water use depend on age and occupation, and it may be there is more diversity within a large family home, than in smaller properties.

The actual reason coincidence calculations provide inaccurate results is because it scales output without scaling the number of users.

Where it would be valid, were if a larger HIU was fitted to enable the use of a high flow rate shower, or to fill a larger bath. There would be the same number of occupants, and the same frequency of use, but the peak load would be higher. Note that kitchen taps and hand washing would be unaffected.

As such, coincidence diversity would be used for luxury properties.

Where it would not be valid, is if the larger HIU was fitted to cover additional outlets or people - larger properties at standard luxury. In this case diversity needs to be applied as further outlet numbers reduce the chances of coincidence.


Scaling by Total Capacity

A better approach, to the above example, may be to treat one of the larger properties as 2 standard properties.

Then the peak diversified load for the 10 properties (= 20 standard) would be 126kW.

In summary, to scale diversity, one does not scale on power, but rather scale the number of properties using the number of standard 37.6kW properties that would deliver the same total power before diversity.

For example:

50 single bathroom properties with a peak of 45kW, plus 25 double bathroom properties with a peak of 75kW

Equivalent number of properties = (50 * (45/37.6)) + (25 * (75/37.6))  =  110 standard properties

Peak diversified DHW load (Danish) = 346kW

Calculation of Peak DHW Load per HIU


If one took a temperature rise for DHW of 37C, then the first line in the chart calls for a 38kW (roughly) HIU.

The second line for a 56kW. Then 70kW, 91kW, & 106kW.

Our examples above are close to lines 1 and 3.

Live Anonymous Diversity


This data provides 3 variables as standard, in one second resolution:

  • DHW flow rate (litres/minute)
  • DHW Power delivered (kW) based on mains at 10C and recorded output temperature
  • How many systems running

The following graph uses the same data but overlaps days to simulate more properties, although overestimates diversity loading.


Ways to Reduce Peak Load

  • Shift heating load.
  • Keep heating constant,
  • Heating on earlier on the coldest days (optimum start), to avoid morning surge.
  • Hot water cylinder.
  • Set peak rate costs, from 7:30 to 8:30 on cold Winter weekdays.
  • Peak rate on/off indicated to user so they can choose to avoid a peak rate time. No charge for draw-offs that start in cheap rate but continue into peak.
  • Option to have heating linked to auto-off during peak times.
  • Option to reduce DHW temperature at peak. Doesn't reduce load, but increases primary dT (reduces flow).

Load Shedding for DHW Priority

How does one account for load shedding in the sizing of buffer storage and pipework in DH schemes?

Its one thing getting a site capable of load shedding, which they now are, but quite another to get it past designers with PI.


A buffer store levels out the instantaneous loads so boilers are not over-sized like a combi boiler. (graph 1)

Hot water priority on HIUs will result in a small reduction at peak by turning off heating in a property when tap is running (graph 2).

So far ok.

Add in the load shedding - where the system turns off all residential heating load (HIU load) for 5 minutes when the buffer store starts depleting, or the DHW load starts spiking (<10 times per day below) - the peak load is reduced by as much as the total heating load. (graph 3).

In effect, we are including the thermal mass of the building into the instantaneous buffering. A few minutes of no heating load lets the boilers focus entirely on buffer recharge and current DHW load - spikes last seconds-minutes. After 1 to 5 minutes, HIUs randomly come back on slowly, nobody has noticed anything, but the peak DHW load is met and any spare goes to charging the buffer store. The episode will be followed by a less significant climb in CH load as buildings thermal mass recharges.

Its a bit like getting the room stat's to synchronise so they are off at peak DHW.

Strategy can be applied on network as a whole, effecting plantroom, or at a local level such as a riser, effecting local pipe sizing.

But how would you do the calculation so it gets sign off under PI?

We would take the predicted hot water use in an hour (EST or IOP, largest of the two), all run at peak diversified load (DS439) in a single block. This may be approaching 10 minutes, but gives us a time that is needed to turn off the heating to deliver all the expected hot water each hour. We would multiply that time by the heating output saved, giving us a block of energy that we allow into plantroom sizing.

For now I think the strategy will not benefit sizing, but rather the operators, allowing them to drop network temperatures further without exceeding pipework limits. i.e. lower peak load = lower delta T for same velocity. Doing a similar job to a topping up boiler.

Or just adding another level of redundancy.

Minimum Load

It becomes clear from data that a more common condition than peak load, is no load, with short moments of demand lasting but a few seconds.

Substations or central plant designed to meet peak loads may struggle with the low trickle flows in standby or the speed of response from a single tap opening. There may well be enough buffering in pipework to overcome fluctuations, and the correct use of central buffer storage and jockey (low load) pumps covers the problem, but systems fed by boilers instantaneously may cause boiler cycling and inefficient operation.

A particular problem may exist on systems where the network is expected to expand. The plantroom will be built to cover the final load, possibly a whole estate, but the initial connection to smaller numbers will push the limits of low load.

Low Load Storage

Storage may be used to cover low load issues, as well as high loads.

A 250 litre buffer store would cover the overnight loads of many properties, removing the need for low load demand on the plantroom. When the plantroom fires it will be to recharge low load buffers in a single burn, then go back to sleep.

Buffer stores would have their own pump (and non-return valve), typically 180kPa peak, for supplying minimum network DP at no/low load, and a valve in parallel with the pump to control recharge. See Distributed Communal Heating.

Solar thermal may work well in such applications, with storage positioned close to solar thermal arrays, charging during the day in preparation for overnight low load provision.

1st Diversity Field Trial

Below are three screen shots from two days in a row (days 8 & 9) of the total DHW loads from the 2 bed system been used to examine diversity for a retired couple.

The reason for posting it is, it demonstrates the theory nicely. You can spot the additional load from yesterday, with a new peak just after the highest peak. The peaks last approx 4 seconds each and are 10 minutes apart.

9 days of data - or 9 HIUs - gives a peak of 52kW against a potential peak of 342kW if all HIUs drew 38kW at the same time. Danish diversity gives 85kW. But this is too few HIUs to define a standard from.

If we want diversity up to say 1000 properties, then the proposition is:

Monitor 10 HIUs for 100 days gives you 1000 days of data from which you can create a standard for UK diversity, that is more relevant than the Danish standard referred to in guidance (but not yet translated into English).

Live system on http://heatweb.ddns.net:1881/diversity