Building energy models are physics-based mathematical representations of the interactions of (mass and energy fluxes) of the building systems, mechanical-electrical systems and the occupants under the environmental boundary conditions of indoor and outdoor (ambient) climates. What do all models have in common and how to approach them carefully?
NEED FOR COMPLETENESS: All components have to be defined (with all input parameters) to perform a whole-building energy simulation. You may not be interested in it but for an energy model to be simulated the metabolic activity rate of an occupant has to be entered somewhere into the program (as W/m2 or MET). What if you never realize such an input? It means that the program or the interface is using some defaults or templates to complete all the details to obey the completeness principle.
THINGS ARE CONNECTED, INTERLINKED and HIERARCHICAL: In every energy model there is a complex and sometimes hidden (opaque) interconnectedness between different sections, components, objects and individual input parameters. Users can get a sense of these connections as they spend more time with their model set up. Some objects of building energy models have an hierarchical relationship (such as parent-child relationships). For instance, a window frame is a child of a window surface which is a child of an external/internal wall which is a child of a thermal zone which is a child of single building model. These hierarchies become very handy when modifying a complex model since when you geometrically shift a wall surface or geometrically modify (scale up or down) a window surface all the child objects below their level of respective decompositions follow their parents. Similar hierarchies can be established for the modifications of thermo-physical properties as much as physical and geometric ones. Can we break the parent-child relationships between different model objects and customize them individually?
NEED FOR A GRAPHICAL USER INTERFACE (GUI): This is needed for you to interact with the simulation engine under the hood. GUI will save time, streamline the input process and help you to post-process the outcomes, accepts geometric data from external sources, offer you pre-defined set of input parameters (i.e., templates), etc. However, always remember that your simulation capabilities are confined by the capabilities of the GUI and sometimes the core simulation engine has more to offer which is not captured by your interface. Then ask this question, is it possible to export my source more outside the GUI for in-depth modeling studies?
GARBAGE IN GARBAGE OUT: Energy modeling program doesn't check and correct things for you to be logical or architecturally correct and to make some sense from engineering point of view. And the program generates outcomes based on your inputs (no matter how representative they are or not). You can define an external window with dimensions of 0.127m x 0.1127m (5"x5") and your program will accept it without a complain or warning and run trough the simulation with a tiny little window surface at the corner of a space.
KEEP IT SIMPLE: Stick with the law of parsimony (i.e., Occam's Razor) while dealing with complex building models. This simply means that keep things simple and if you see two different/alternative paths of modeling always go with the most straightforward and simplest one. Over-parametrized models are prone to simulation errors (run-time or logical type errors) which will cost your time and unexpected modeling efforts. Always create a "prototype" first to see if it runs in the first place and then start adding details progressively (Progressive Loading to your model).
NEED FOR BENCHMARKING AND BASELINING of your results: When you end up with simulating a design alternative and have the feeling that your reducing the energy consumption always do some extra work to compare your results against a known benchmark or a hypothetical baseline model. This is needed to answer the hard question: Your new design is saving energy but with respect to what? Your previous iteration?, building next door?, building in your neighborhood?, city?, or state? or all building the U.S.? Never forget the "relativity" of your energy performance outcomes offered by the energy program.
NEVER FORGET THE Temporal and Spatial DIMENSIONS: Simulation results can be analyzed through their variation or "aggregation" in time (sub-hourly, hourly, daily, weekly, monthly, seasonal, annual, over the years). Some output variables can be aggregated such as kWh of electricity consumption but aggregating some variables make no sense at all (think about the indoor temperatures in F or C). Simulation results can also show variability through building spaces (e.g., surface temperatures, heating-cooling loads). And when you combine both types of variability, you'll need to consider the SPATIO-TEMPORAL variations or relationships.
ABSOLUTE ACCURACY vs. RELATIVE ACCURACY: Absolute accuracy defines the accuracy of the results of an energy modeling program in predicting the actual performance of an operational building (i.e., ground truth data for the comparisons). Relative accuracy defines the accuracy of the differences of the results of an energy modeling program while evaluating multiple building design alternatives. It always take a lot of effort to calibrate and subsequently validate an energy model to have high fidelity in absolute accuracy (i.e., how close can be predict the performance of an operation building?). Relative accuracy is inherently achieved between different simulation runs since the there is no ground truth data and the differences are represented in relative terms (such as percentage of savings over a baseline building model). Today's energy modeling programs are mature enough (equipped with solid physics) to guarantee a relative accuracy. However, achieving absolute accuracy both relies on simulation engine's predictive capacity and the robustness of input parameters (defined by the user) in terms of representing the actual building case under consideration. Therefore, energy modeling programs (and the underlying simulation engines) are accurate in relative terms but it's the users' interaction with the program that brings about the concerns of absolute accuracy. Do we need to see absolute accuracy at all times? When does relative accuracy would be enough to have confidence in our simulation-based approaches?
Omer T. Karaguzel, PhD
Comments