Weather Files & TMY

Open a weather file and, past the header, you find a long table: roughly 8,760 rows, one per hour of the year, each carrying a set of numbers that together describe the weather at that moment. A few of these columns do most of the work in building analysis. The dry-bulb temperature is the ordinary air temperature a thermometer reads - the headline number, and the one that most directly drives heating and cooling. Beside it sits a measure of moisture: the dew-point temperature or the relative humidity, telling you how much water vapour the air holds. Humidity matters enormously and is easy to underrate - it governs how muggy a space feels, how well sweat and evaporation can cool a body, and how hard a cooling system must work to dry the air, not just chill it.

The next block describes the sun. A weather file usually splits solar radiation into components - the global horizontal (total falling on a flat surface), the direct beam (straight from the sun's disc), and the diffuse (scattered by sky and cloud) - each in watts per square metre. These numbers let a simulation work out how much heat pours through each window and wall depending on orientation and time of day, and how much daylight a room receives. Then comes the wind: its speed and the direction it blows from, which drive natural ventilation, infiltration through gaps, and convective heat loss from the building's skin. Around these headline fields sit others - atmospheric pressure, cloud cover, sometimes rainfall, sky temperature, ground temperature and illuminance.

What matters is the shape of the thing: a weather file is not a single 'climate' number but an hour-by-hour story of a year, rich enough that a simulation can replay the year and feel every swing - the cool of a dawn, the blaze of a June afternoon, the humid stillness before a monsoon burst. That richness is exactly why the file is so powerful and so consequential: it is the entire weather world the virtual building will ever experience. Get the file right and the analysis has a fighting chance of being meaningful; get it wrong, or out of date, and every careful calculation downstream inherits the error. Which raises the obvious question - where do these thousands of numbers come from?

The thousands of numbers in a weather file are not invented, and they are not a forecast; they are drawn from real measurements. But here a subtlety appears. You might expect a design weather file to be simply 'a real recorded year' - say, 2019 at this airport. The trouble is that any single real year is an accident: it might have had a freak heatwave, a strangely wet spring, an unusually mild winter. Design to one odd year and you design to that year's quirks. So the profession invented the typical meteorological year (TMY) - a way to distil many years of records into one representative, 'typical' year.

The method, in outline, is this. Take a long run of historical data at a station - commonly twenty to thirty years. For each calendar month, compare that month across all the years and pick the single real month whose weather is statistically closest to the long-term average for that month - the most 'typical' January, the most representative July, and so on, judged across temperature, humidity, solar and wind together. Then stitch the twelve chosen months - each a real month from a possibly different year - into one synthetic year, smoothing the joins so the transitions are seamless. The result is a composite: a year that never actually happened, assembled from twelve real months that did, chosen to represent the ordinary, expected conditions at that place.

This is genuinely clever and genuinely useful. A TMY strips out the flukes of any one year and gives a stable, reproducible baseline that everyone can design and compare against - which is exactly why energy codes and simulation tools lean on it. But notice two things that will matter for the rest of this course. First, a TMY is deliberately typical, so by construction it plays down extremes - the very heatwaves that increasingly threaten buildings are smoothed away in favour of the average. Second, and more fundamental, a TMY can only be built from data that already exists, which means it looks entirely backward, into the past. It is a beautifully engineered rear-view mirror. In a stable climate that is fine. In a warming one, as we will see, it quietly describes a world that is slipping away.

In practice, all of this arrives in a file format, and the one you will meet most often is the EPW - the EnergyPlus Weather file, a plain-text format that has become a common currency across simulation tools worldwide. An EPW opens as a readable table: eight header lines naming the location, its latitude and longitude, elevation, time zone and the source and period of the data, followed by the 8,760 hourly rows carrying the fields we met earlier. Because it is an open, documented, text-based format, almost every serious building-energy and comfort tool can read it, and large public libraries of EPW files exist for thousands of locations around the world, free to download.

It helps to know the vocabulary around these files, because 'weather file' is a family, not a single thing. A TMY file (and its regional cousins, assembled by national meteorological or energy agencies) is the typical-year composite we just described - the default for standard design and code work. Sitting beside it you may find files labelled for extreme or hot years, built to represent an unusually severe year rather than a typical one, used to stress-test a design; and the future weather files that later modules explore, which take a historical file and adjust it to reflect a projected future climate. Some files also carry design-day summaries - concise statistical extremes (a very hot summer condition, a very cold winter one) used for sizing equipment rather than running a full-year simulation.

Two practical honesties belong here. First, the header is not decoration: it tells you *which station*, over *which years*, the file was built from - and a file assembled from 1991 to 2010 is already describing a decades-old climate the moment you open it. Always read the provenance before trusting the numbers. Second, coverage is deeply uneven: rich, well-instrumented regions have dense, high-quality files, while much of the global south - India very much included - is served by sparser stations and older or interpolated data, a gap the next lesson takes up directly. The competent designer treats a weather file not as a fact handed down from on high but as a dated, sourced, constructed data product - to be identified, questioned and, where the stakes are high, checked against local knowledge and specialists rather than accepted on faith.

Now to the assumption that makes this whole lesson matter, and that shadows the rest of the course. Every historical weather file - every TMY - rests on a quiet premise called stationarity: the idea that the statistics of the climate are stable over time, so that a synthesis of the recent past is a fair description of the present and near future. Build a typical year from 1991 to 2020 and use it to design a building opening in the late 2020s, and you are assuming, without usually saying so, that the climate of the 2020s and beyond is close enough to the climate of that thirty-year window. For most of the history of building science, that assumption was reasonable - the climate wandered within a fairly stable range, so yesterday's typical weather was a fair guide to tomorrow's.

That assumption has now broken, and this is the hinge of climate analytics. The climate is warming rapidly and unevenly: average temperatures are rising, heatwaves are growing more frequent, more intense and longer, humidity and rainfall patterns are shifting, and once-rare extremes are becoming ordinary. A weather file assembled from the last few decades therefore describes a climate that is already receding into the past - it systematically understates the heat, and especially the extremes, that even today's buildings face, and it drifts further from reality every year. Because a TMY is built to be *typical*, it doubly understates the danger: it smooths away extremes and anchors to a cooler past at the same time. A cooling system sized to a TMY may be too small for the heatwaves that now actually arrive; a naturally ventilated home judged comfortable by the old file may already spend dangerous hours overheating.

So the first real skill of climate analytics is not running a tool but reading a weather file with clear eyes: knowing it is a constructed, backward-looking composite that assumes a stability the world no longer has. This does not make weather files useless - they remain the essential foundation of building analysis, and every future method builds on them. It means using them honestly: knowing their provenance and their age, treating the typical year as a smoothed and dated picture rather than the truth of the climate the building will face, and understanding that any binding energy, comfort or sizing result must rest on verified data, validated tools and qualified engineers working to the governing codes - not on a file whose central assumption has quietly failed. The rest of the course is, in a sense, the disciplined response to this single realisation.