The Analysis Workflow

The whole of climate analytics, stripped to its bones, is five repeatable moves. One: get and check the data. You obtain the weather and climate data your analysis needs - a weather file for the site, and where you are looking ahead, future or 'morphed' weather files for a future decade - and, crucially, you check it before you trust it. Two: analyse the climate. Before simulating any building, you understand the climate itself: how hot and humid it gets, when, how the sun and wind behave, how many cooling and heating degree-days accumulate, and how all of that is projected to shift. Three: simulate the design. You run the actual building - its form, fabric, glazing, shading and openings - through building performance simulation against present weather, and then against future weather, to see how it will really perform: whether it overheats, how its energy and comfort change, whether it stays survivable in an extreme event. Four: interpret honestly. You read the results as a *range* across scenarios and models, not a single number, and you separate the robust signal (the direction and severity of the risk) from the false-precise noise. Five: feed it back. You take that understanding into the design - change the orientation, add shading, improve the fabric, provide a passive fallback - and, because the design has changed, you loop back and re-analyse.

The word to hold onto is *loop*. A one-shot analysis at the end of a project is not this workflow; it is a report. The value lives in the iteration: each pass makes the design a little more resilient and the understanding a little sharper, and the loop continues until the design is robust across the plausible futures you tested, not merely optimised for one. Notice too that only the middle moves are software-heavy. The first move is judgement about data quality, the fourth is judgement about uncertainty, and the fifth is design judgement - which is exactly why the workflow belongs to the designer even though the binding numbers belong to a specialist. Analysis informs the decision; it does not make it, and it never replaces the engineering that a qualified building-physics or energy specialist, validated tools and the codes must ultimately sign.

Every downstream result inherits the quality of the data it started from, so the first move is also the most quietly consequential: get the right data, and then *check it* before you build anything on top of it. 'Garbage in, garbage out' is not a slogan here; it is the difference between a useful study and a confident-looking mistake. Start by getting a weather file for the location - most commonly a typical meteorological year (TMY) assembled from historical measurements - and, where you are designing for the future, a future or 'morphed' weather file for a target decade like the 2050s under a stated emissions scenario. Getting the file is the easy part. Checking it is the discipline.

Ask a short, ruthless set of questions of any data before you use it. *Is it actually for this place?* A file from an airport twenty kilometres away, on open ground, can badly misrepresent a dense, hot city centre where the urban heat island adds several degrees at night. *Is it complete and plausible?* Real records have gaps, sensor errors and impossible spikes; a quick plot of temperature and humidity through the year will reveal a stuck sensor or a missing month faster than any table. *Does it match reality you can feel?* If the file says the peak is far cooler than the heatwaves the city is known for, be suspicious - a TMY represents *typical*, not extreme, conditions, and typical is exactly what a resilience question should not rest on alone. *And for a future file: what scenario and model made it, and does it come as one file or several?* A single future file hides the very spread that matters; you generally want more than one so you can see a range.

Document what you used and why - the source, the year, the scenario, the known limitations - because an honest study is one whose foundations can be inspected. This checking step is not glamorous and it is routinely skipped, which is precisely why so many analyses are precise about the wrong thing. The binding judgement of whether a data set is fit for a compliance or life-safety determination rests with the specialist and the governing standards; the designer's job at this step is to refuse to reason on data they have not looked at.

With trustworthy data in hand, the middle of the loop does the analytical work - and its output is deliberately *not* a single confident figure. Begin by analysing the climate itself, separately from any building. Plot the temperatures and humidity through the year; count the cooling and heating degree-days; study when the sun is a problem and when it is a gift; read the wind for natural ventilation; and, for a hot-humid country, look hard at wet-bulb conditions where heat becomes dangerous. Do this for the present climate and then for the projected future, so you can see the *direction* of change - hotter summers, more cooling degree-days, longer and fiercer heatwaves - before a single wall is simulated. This climate study is what turns generic worry into a specific design brief.

Then simulate the design. Building performance simulation runs your actual building - geometry, fabric, glazing, shading, openings, occupancy - hour by hour against a weather file, and reports how it performs: hours of overheating, cooling and heating energy, comfort, resilience in an extreme event. The move that makes it climate analytics rather than ordinary energy modelling is to run it against *future* weather as well as present, and against *more than one* future - different scenarios, ideally more than one model - so you see how performance drifts as the climate warms. The output is therefore a spread, and that spread is the point.

Now interpret honestly. The single most important habit of the whole workflow is to read that spread as a *range*, not to collapse it to one tidy number. The robust, trustworthy signal is the direction and severity of the risk: 'overheating hours rise sharply across every future we tested, and the building is not survivable in a future heatwave if cooling fails.' The false-precise noise is the decimal place: 'it will overheat for 214 hours in 2050.' Report the former, distrust the latter. A future weather file looks exactly as precise as a measurement but is a scenario carrying deep uncertainty, so treating its numbers as a prediction is the classic error this course warns against. Interpret for range, direction and severity - and leave the binding, signed result to the specialist, the validated tools and the codes.

The final move is the one that justifies all the others: feed the understanding back into the design. An analysis that ends in a folder has changed nothing. An analysis that ends in a decision - reorient the plan away from the worst sun, deepen the shading, improve the fabric so the building drifts less in a heatwave, add openable windows and a night-purge path so there is a passive fallback when the power fails - has done its job. And because the design has now changed, the loop runs again: the new scheme is re-analysed, and the iteration continues until the building is *robust across the futures you tested*, not merely tuned to one. Resilience is reached by looping, not by a single verdict.

Which makes *timing* decisive, and it is the part most often got wrong. The influence of climate analysis over a building collapses as the project proceeds. At concept, everything that matters most for a warming climate - orientation, massing, the ratio and placement of glass, the depth of shading, the weight and insulation of the fabric, whether there is any passive survival strategy at all - is still free to move, and analysis can steer it for almost no cost. By detail design the big moves are fixed and only trims remain. On site, analysis can do little but confirm or regret. So the workflow should run *earliest when it is roughest* - fast, approximate studies at concept when the design is soft - and get more precise as the design firms up, never the other way round. The worst pattern is a single, elaborate analysis at the very end, when its only possible use is to justify decisions already made.

This is why the loop belongs inside the design process, not bolted onto its end. Run it early and often, let it be crude when the design is crude, feed every pass back into the drawing, and keep looping. The binding engineering - the signed energy model, the compliance and any life-safety determination - still sits with qualified specialists, validated tools and the codes (NBC India, ECBC, IS). The designer owns the loop, the questions and the decisions it informs; the specialist owns the numbers that bind.