Key takeaway
A typical-year file can support a representative-resource scenario while failing to describe a particular operating year. Preserve the product type and month origins before interpreting a simulation.
Choose the comparison before choosing the weather file
A building-performance owner wants to compare a simulation with an operating incident in 2024. The model archive has a weather file with a complete-looking annual calendar, but its January came from one year and its February from another. A successful rerun of that file would reproduce the scenario; it would not turn those hours into the weather of 2024.
System Advisor Model documentation distinguishes typical-year data, assembled from representative months selected across multiple years, from single-year data used to evaluate a specific operating year. Both can be useful. The owner must match the weather basis to the question instead of treating every annual file as interchangeable.
This is a provenance decision about model inputs. It does not reconstruct actual weather, validate a building model or establish whether a particular design can withstand extremes.
Annotate the calendars and complete the comparison choice
The hypothetical archive below invents three candidate files. File T has January from 2001 and February from 1999 as two annotated examples of its stitched representative months. File Y represents the single calendar year 2024. File F is explicitly a projected scenario. No station observations or weather values were acquired.
For the stated 2024 incident comparison, Y has the appropriate year type, subject to checking its location, clock, variables and actual provenance. T remains available for a typical-resource scenario. F answers a scenario question about projected conditions; it cannot be relabeled as observed 2024 weather.
The completed choice is conditional rather than a data-quality certification. A single-year file can contain modeled values. Its calendar match does not prove that every variable was measured at the facility or that a gap was filled appropriately.
| Fictional file | Calendar and provenance description | Use in the stated comparison |
|---|---|---|
| T: typical-year file | Representative months; January 2001 and February 1999 shown | Retain as a typical-resource scenario; not the 2024 incident history |
| Y: single-year 2024 file | One historical calendar year; source methods still to inspect | Candidate basis for the 2024 comparison, conditional on provenance |
| F: projected scenario | Future conditions derived under a stated scenario | Separate scenario; not actual-year observations |
Read the year in the product name correctly
The SAM documentation explains a filename example in which TMY-2016 refers to a typical dataset selected from a pool ending in 2016, rather than simply the weather observed during 2016. Preserve the producer’s product description and source-year range. A filename alone should not populate an “actual operating year” field.
For the fictional file T, the owner records the product type, producer, location basis, source-period description and any retained month-origin mapping. If the month origins are unavailable, say so. Do not guess them from the assembled calendar or manufacture a continuous historical year to satisfy an export schema.
The same distinction belongs in the model-run description. “Run using typical-year weather” is meaningful evidence about a scenario. “Run reproduces the site’s 2024 weather” requires a different input basis and supporting review.
Keep historical typical and future scenario products separate
NOAA NCEI’s TMY product description discusses historical representative months selected from its stated source period and separately describes future projections. The page read on 16 October 2026 identified the product as experimental and not yet peer reviewed. That qualification should travel with a reference to the product rather than disappearing in a generic “NOAA weather” label.
The historical typical product and a projected or adjusted future scenario have different meanings. A future scenario is not a log of weather that has occurred, and it does not guarantee the exact sequence of future conditions. Nor does a representative typical year promise to capture every extreme relevant to a particular design question.
This article does not impose one producer’s selection method on every TMY file. Record the method actually claimed for the selected product. The provenance review can then distinguish representative selection, single-year reconstruction and scenario transformation without rejecting useful simulation inputs merely because they are not raw measurements.
Give each run a description that survives reuse
The completed fictional run description is: “Run R-T uses stitched typical-year file T for a representative-resource scenario. Run R-Y uses single-year 2024 file Y for the proposed operating-year comparison; location, timing and variable provenance remain to be checked. Future file F is outside that historical comparison.”
The distinction survives even if all three files have identical column names and every simulation reruns successfully. Reproducibility establishes what was run; the weather-product description establishes which question that run can support.