BEMP common mistakes
BEMP · Understand the traps and how to avoid them.
Reporting a site energy use intensity (EUI) figure when the question asks for source (primary) energy, or quoting kBtu/ft² without stating which basis is used.
Candidates memorize a single EUI number from practice runs and treat site and source energy as interchangeable, forgetting that site-to-source multipliers differ by fuel and by reporting year.
What to do instead
Label every energy figure with its basis (site vs. source) and fuel, keep the conversion factors written at the top of the scratch sheet, and convert explicitly before selecting an answer or writing a conclusion.
Choosing a degree-day or bin-method estimate for a question that is really asking about part-load system behaviour, thermal mass, or hour-by-hour peak coincidence.
Simplified methods are quicker and candidates reach for the familiar formula, overlooking that the scenario describes a system whose performance depends on part-load ratio or on timing of loads.
What to do instead
Before computing, ask whether the question depends on when loads occur or on part-load efficiency; if yes, the answer must come from an hourly simulation result, not a steady-state formula.
Calculating percent savings against the proposed design's own annual consumption instead of against a properly constructed Appendix G baseline model.
Candidates see two annual numbers in a results table and subtract them, skipping the step of confirming that one of them is a code-compliant baseline built with the prescribed HVAC, envelope, and fan-power rules.
What to do instead
Verify the baseline was generated per the rating method (baseline HVAC type, fan power limits, no credit for proposed-only measures), then compute savings as (baseline − proposed) / baseline.
Submitting or interpreting results from a model that still reports unmet load hours above the accepted threshold, or that has not been autosized and re-simulated.
Candidates run the file once, see an annual EUI appear, and move on, not realizing that a model with convergence problems or undersized equipment produces meaningless end-use splits.
What to do instead
Build a fixed post-simulation check into every run: review unmet heating/cooling hours, severe errors, and autosize-then-simulate sequence before reading any energy number.
Zoning a building with one thermal zone per floor regardless of orientation, window distribution, or core-versus-perimeter exposure.
Single-zone-per-floor models run faster and look plausible in the summary table, and candidates underestimate how much zoning granularity drives cooling and heating results.
What to do instead
Define zones from the architectural plan's exposure and occupancy boundaries, and if simplifying, combine only zones with the same orientation, schedule, and system - then document the simplification.
Leaving default schedules, default lighting power densities, and default infiltration in place instead of entering project-specific values from the drawings and specifications.
Tools populate defaults that let the model run, and candidates interpret a successful run as a validated model rather than a first draft.
What to do instead
Maintain an input checklist tied to the design documents (LPD, plug loads, occupancy and HVAC schedules, envelope U-values, infiltration) and tick each item off before interpreting results.
Comparing EUI between two models whose conditioned floor area or unconditioned-space treatment differs, without normalizing the denominator.
Candidates pull the EUI field straight from the summary report and compare across variants or against a benchmark, missing that floor area changed when a space was reclassified.
What to do instead
Confirm the conditioned floor area is identical across variants or explicitly normalize energy to the same denominator before comparing, and report both the absolute energy and the intensity.
Drawing conclusions from a single annual total instead of examining monthly profiles, end-use breakdown, and coincident peak demand.
The annual summary is the first screen the tool shows, and candidates anchor on it, so they miss that a measure shifts load between end uses or seasons without changing the total much.
What to do instead
Use a standard review sequence - end-use breakdown, then monthly consumption versus weather, then peak demand - and state which view supports the conclusion.
Overwriting or renaming the baseline model file while iterating on design options, so the comparison point can no longer be reproduced.
Candidates work in one file and edit in place to save time, and version drift is invisible until a final number disagrees with an earlier one.
What to do instead
Lock the baseline as a read-only file, save each variant as a new version with a naming convention including date and option, and keep a run log linking file name to input changes and result.
Delivering results with no record of the weather file, simulation engine version, and key assumptions, so a reviewer cannot reproduce the number.
Candidates treat documentation as a final formatting chore and assume their own memory of the settings will be enough for themselves and for the reviewer.
What to do instead
Complete the assumptions-and-QA section as each input is set rather than at the end, listing weather file, tool version, schedules, setpoints, and known simplifications, and have a second person check the model inputs against the design documents.