Heating & Cooling Loads

A peak load is the largest instantaneous heating or cooling demand the building throws at its systems - in kilowatts. It usually occurs on a design day: the hot, still, humid afternoon when solar, internal and ventilation loads all stack up at once (for cooling), or the cold, clear pre-dawn (for heating). Engineers size equipment to this peak, often with a margin, because a chiller that cannot meet the worst hour leaves the building uncomfortable exactly when it matters most.

Annual energy is a different beast: the sum of every hour's actual load over a full year - in kilowatt-hours. It is dominated not by the few extreme hours but by the thousands of mild, part-load hours in between, where the equipment runs at a fraction of capacity. This is why efficiency at part load matters so much: a system sized for the peak spends most of its life loafing, and how well it does that determines the bill. The design-day peak and the annual total come from the same load curve - the peak is its tallest spike, the annual energy is the area beneath the whole thing - but they answer different questions and drive different decisions.

It is worth being concrete about the units, because the confusion is so common. A peak is a rate - kilowatts, energy per unit time, the instantaneous demand your equipment must be able to meet. Annual energy is an amount - kilowatt-hours, that rate accumulated over time. A 100 kW chiller running flat out for one hour uses 100 kWh; the same chiller idling at 20 kW for a thousand hours uses far more energy while never approaching its peak. Sizing looks at the tallest bar; the bill looks at how the bars pile up all year.

The most useful thing a model prints is not the total load but its breakdown into components: solar gain through glazing, conduction through the envelope, internal gains (people, lights, equipment), and the ventilation/infiltration load of conditioning outside air. Each is a term of the heat balance from lesson 4.1, now quantified as a share of the peak or the annual cooling.

Read the tallest slice first, because it names the cheapest place to intervene. If solar dominates, deeper shading or better glazing pays; if internal gains dominate, efficient lighting and equipment do; if conduction dominates, the envelope U-values are the lever; if ventilation dominates, heat recovery or demand-controlled fresh air helps. A worked example makes it concrete: for a glassy, lightly-shaded office, solar might be ~34% of the peak cooling, internal gains ~26%, envelope ~22% and ventilation ~18% - so shading and glazing are the first move, not more insulation. The breakdown turns a vague 'it's too hot' into a ranked list of design actions, and it is why modellers always ask for components, not just totals.

The breakdown is also how you avoid solving the wrong problem. A designer convinced the building 'needs more insulation' may find, on reading the components, that conduction is the smallest slice and solar the largest - so the money belongs on shading and glazing, not wall build-up. Letting the breakdown, rather than intuition, rank the interventions is what turns an energy model from a report into a design tool.

In much of the world, energy codes grew up worrying about heating - keeping warmth in through a long winter. Most of India is the opposite: across the hot-dry, warm-humid and composite zones that cover the majority of the country, the dominant load is cooling, and often for most of the year. The sun is strong and high, outdoor temperatures sit well above the comfort band for long stretches, and internal gains (which are always trying to heat the space) add to the cooling burden rather than helpfully offsetting a heating one.

Humidity sharpens this. In warm-humid Chennai, Mumbai or Kolkata a large part of the cooling load is latent - the energy to dehumidify incoming air - so strategies that only address temperature miss half the problem. The design consequences are real: what helps a cold-climate building (heavy insulation, maximised solar gain, big south glass) can actively hurt an Indian one, where you want to reject heat, shade aggressively, cut solar gain, and manage humidity. This is exactly why India's codes - ECBC for commercial buildings and the Eco Niwas Samhita for homes - are framed around limiting envelope heat gain and improving cooling efficiency, and why simply importing a European detail is a mistake a model quickly exposes.

Loads tell you about one building; to compare buildings you need a normalised metric, and that is Energy Use Intensity (EUI) - annual delivered energy divided by floor area, in kWh/m2 per year. Because it is per-unit-area, it lets you set a small office against a large one, a design against a benchmark, or this year's model against last year's on a fair footing. It is the currency of energy benchmarking and underpins most rating and code targets.

Use it carefully, though. EUI depends heavily on climate (a Chennai office will out-consume a Bengaluru one for the same design), on building type (a hospital or data-heavy office runs far higher than a school), and on the boundary you drew - did you include the car park, the process loads, the plug loads? Comparing EUIs across different climates or types without saying so is a classic way to mislead. The honest use is like-for-like: same type, same climate, same boundary, comparing design options or a design against a peer benchmark. Done that way, EUI is the single most communicative number an energy model produces - the one you put on the cover of the report.

One subtlety trips up people moving from room-by-room hand sizing to whole-building simulation: the peak loads of individual zones do not all happen at the same moment, so the whole-building peak is smaller than the sum of the zone peaks. The east perimeter peaks in the morning as the low sun pours in; the west peaks in the late afternoon; the core, driven by internal gains, peaks around midday occupancy. Add the zone peaks naively and you size a central plant far bigger than the building ever actually needs - wasted capital and worse part-load efficiency.

Simulation captures this diversity automatically, because it solves every zone at every hour and simply reports the largest simultaneous total. This is a real advantage over rule-of-thumb sizing and one of the concrete reasons to model rather than guess. The same idea applies to occupancy and equipment: not everyone is present, and not every device is on, at once, and a diversity factor in the schedules reflects that. Get the schedules honest and the model gives you a defensibly lean peak; assume everything coincides and you inflate both the plant and the perceived load. This is also why the whole-building model, not a stack of worst-case room calcs, is the right basis for talking to the MEP engineer about plant size.

Diversity also explains a frequent field surprise: a whole-building model often justifies smaller central plant than a stack of room-by-room worst cases would suggest, which can free capital and plant-room space. But it cuts both ways - lean on diversity too hard, or assume unrealistically staggered occupancy, and you can undersize for a genuinely coincident peak on a heatwave afternoon when every zone really does demand cooling at once. The model lets you see the true simultaneous maximum for your climate and schedules, which is exactly the number the sizing conversation should turn on.