Weather Data & EPW Files

An energy model, a comfort study, a daylight run - none of them know anything about the weather until you hand them a weather file, and in almost every tool that file is an EPW: EnergyPlus Weather format. It is a plain-text file with a short header (location, latitude, longitude, elevation, time zone) followed by 8,760 rows - one for every hour of a year. Each row carries the hour's dry-bulb temperature, dew point and relative humidity, atmospheric pressure, the three solar components (global horizontal, direct normal, diffuse horizontal irradiance), wind speed and direction, sky cover, and more - dozens of columns in all.

This is the single most important input in building performance simulation, and the most overlooked. The physics engine is just machinery; the EPW is the reality it runs against. Feed it the weather of Delhi and your Chennai design will look wrong for reasons that have nothing to do with the design. Every kWh, every comfort hour, every daylight lux the model reports is the EPW acting on your geometry and materials. That is why professionals say a simulation is only as good as its weather file.

It helps to picture what those columns actually drive. The dry-bulb temperature column sets the heat flowing through every wall and window and the load on any cooling system. The humidity columns decide latent loads and whether evaporative cooling can work at all. The three solar columns - direct, diffuse and global - feed both solar heat gain through glass and every daylight calculation, and they are why a west window matters more than a north one. The wind columns drive natural ventilation and infiltration. So the EPW is not background data; it is the direct, hour-by-hour cause of nearly everything the simulation reports. A designer who has actually opened one, scrolled its rows and seen these columns for real never again treats the weather file as a checkbox.

Most EPW files are a Typical Meteorological Year (TMY). This is not a single real year of data; it is a synthetic year stitched together from many years of records - the algorithm looks across (say) 15-30 years and picks the most statistically typical January from one year, the most typical February from another, and so on, then splices the twelve chosen months into one representative 8,760-hour file. The point is to represent the long-run normal climate rather than the quirks of any one year - if you simply grabbed the single most recent calendar year, you might land on a freak-hot or unusually mild one and bias every result, so the stitching deliberately averages that luck out.

That design choice has a consequence you must respect: a TMY smooths away extremes. The record-breaking heatwave, the freak cold snap, the once-in-a-decade still-and-humid week - these are exactly the conditions that size a cooling system or cause a comfort failure, and a typical year underweights them. So a TMY answers 'how will this building perform in an average year?' well, and 'will it cope with the worst day?' poorly. For that second question you use a different file - an extreme or design year, or a specific hot real year - and you will meet that idea again when sizing equipment. Match the file to the question.

You do not make EPWs by hand; you download them. The EnergyPlus Weather (energyplus.net/weather) collection is the standard free source, with thousands of locations worldwide, and tools like Ladybug can fetch and map them for you. But there are several TMY families - TMY3, IWEC and IWEC2 (international), the newer TMYx built from recent hourly records - and they are derived from different periods and stations. So you can legitimately find two files both labelled 'Mumbai' that differ, because they summarise different years of data from possibly different weather stations.

This is not a defect to fear but a fact to manage. When you report a result, you name the weather file you used, just as you would cite a source. If you compare two designs, run both against the same file so the difference is the design, not the data. And prefer a recent-vintage file (TMYx) where you can, because a warming climate means a 1980s-2000 TMY may already understate today's cooling loads. The file is a citeable assumption; treat it like one. In practice, a good habit is to write the exact file name and vintage into the model's notes and into any report figure caption, so that a reader - or you, six months later - can reproduce the run and knows precisely which slice of climate history the numbers describe.

An EPW describes conditions at a specific weather station - very often an airport, sitting on open, flat, windy ground far from any city. Your building may be on a dense street, beside a lake, up a hill, or deep in a heat-island city core that runs several degrees warmer than the airport at night. The gap between the station's climate and your site's actual micro-climate is a real source of error, and no amount of engine precision closes it if the input is off.

Good practice is to ask, every time: how representative is this file of my actual site? Sometimes you pick the nearest of several stations more carefully; sometimes you apply a morphing or urban-heat adjustment; sometimes you simply flag the limitation in your report. The deeper lesson connects straight back to Module 0: a simulation result is an estimate with error bars, and the weather file is one of the biggest bars. Choosing and naming it well is not admin - it is half of doing the study honestly. Get the EPW right and everything downstream has a chance; get it wrong and precision elsewhere is wasted.

The TMY is the workhorse, but it is not the only weather file you will meet, and knowing the family helps you match the file to the question. Design-day or extreme-year files weight the hot or cold extremes so equipment can be sized for conditions a typical year would never show - remembering, as Module 0 stressed, that the sizing calculation itself is an engineer's responsibility, not the modeller's. Actual meteorological year (AMY) files carry the real, un-smoothed weather of one specific past year, used when you calibrate a model against a building's measured bills: you must run the model on the same year the meter recorded, not a typical year, or the comparison is meaningless.

And increasingly there are morphed future weather files - a TMY adjusted by a climate-change scenario to represent, say, the 2050s or 2080s. These matter because a building designed today will operate for decades into a warming climate, and a facade or cooling strategy that just scrapes through on a 2000-vintage TMY can fail against a 2050 file. Running your design against both a current and a future file is fast, sobering, and quietly becoming best practice - it tests whether the design is robust or merely adequate for the climate we used to have. The through-line across all of these is the same discipline: the weather file encodes a specific question - typical performance, worst-case sizing, calibration, or future resilience - so you choose it deliberately and name it in the report. There is no single 'correct' weather file; there is only the file that matches what you are trying to learn, and the honesty to say which one you used.