Authors:
Jonathan Bean
What is it about the allure of measurement? For the past several years, as I have become more and more immersed in an ethnographic study of high-performance building, my predilection for precision and prediction has peaked. I just spent the better part of a weekend tweaking energy models in a fantastic free program called BEopt, which is a creative acronym for Building Energy Optimization. BEopt allows users to calculate the cost and energy savings of a breathtaking number of inputs. If you've ever replaced a furnace or an air conditioner and puzzled over whether the upgrade from 18 SEER to 22 SEER would pay for itself, or if energy savings would cover the cost of an upgrade to a 97 AFUE furnace, BEopt has the answers.
Speaking of acronyms and allure: AFUE and SEER are measurements of efficiency for furnaces and air conditioners, respectively. AFUE, or Annual Fuel Use Efficiency, tells you how much useful heat you get out of each unit of gas that goes into the appliance, so that a 97 AFUE furnace wastes only 3 percent of heat, which is, as of now, the best you can get in the U.S. market. SEER, or Seasonal Energy Efficiency Ratio, is not as intuitive, but higher numbers mean greater efficiency and lower electrical bills. They also mean higher equipment costs. Are the added costs worth the added savings? This is a question worthy of exploration.
When I decided to consult on a high-performance remodel of a typical 1970s house in suburban Chicago, my first stop was not BEopt, but rather another program called WUFI Passive, about which I have written before [1]. It's capable of running both static and dynamic energy models; it was interesting to see the difference. Static energy models work on monthly averages, and while there are a lot of variables in the equation, it's a relatively low computational load. The software evaluates how much energy is coming into the building in the form of solar gains and how much is leaving through walls, ceilings, windows, and air leakage. It also runs 12 separate computations to arrive at an estimate of annual energy use. Passive House Institute US (PHIUS) elaborated on the calculations that WUFI runs to arrive at these estimates. It touts that the static estimates are within a few percentage points of actual measured energy use, an impressive feat for any mode of prediction, let alone one that an aged Windows PC can perform comfortably on the fly. Nonetheless, I also used the dynamic side of the software, in part because I wanted to explore the summertime overheating of a room with south-facing glass. The dynamic calculation is done 8,760 times, one for each hour of the day, with the last result used to start the next one. That calculation took only 20 minutes on my old laptop—a small price to pay to learn that the family room should not, once built, overheat.
If you've ever replaced a furnace or an air conditioner and puzzled over whether the upgrade from 18 SEER to 22 SEER would pay for itself, or if energy savings would cover the cost of an upgrade to a 97 AFUE furnace, BEopt has the answers.
Yet I still had questions about the precision of the calculations. One concern of mine stemmed from an interaction with the WUFI user interface. When I was inputting the windows for the house in Chicago, I noticed an odd graphic representation of a front porch. The roof of most front porches extends some distance to the left and right of the door it shelters. WUFI was rendering the porch roof as a plane extending the correct distance outward from the house, but the width of the roof was incorrectly rendered—rather than the broad sweep of a porch roof, it showed a skinny plane corresponding to the exact width of the front door assembly (Figure 1). This suggested that over the course of the year, the program would sometimes incorrectly account for sunlight shining on the glass. It turns out this concern was valid, but could be partially corrected through manually inputting a shading factor. I returned to my SketchUp model to come up with an informed guess.
 |
Figure 1. WUFI rendering showing the incorrect shading of the front porch. |
To estimate the thermal performance of windows, WUFI Passive requires the dimensions of the frame, the insulation performance of the glass and the frame, and the heat loss around the interface between the window frame and the wall assembly. Answering that particular question with precision requires firing up a free software program called THERM, developed by the lovely people at the Lawrence Berkeley National Laboratory. Its calculations may be "state of the art" [2], but the user interface is biased toward the cognitive style of engineers, requiring a user to execute a carefully ordered plan before commencing [3]. Upon hearing me complain about my struggle to learn THERM on my own, consultant Skylar Swinford suggested I try a more user-friendly program called HTflux.
HTflux was in fact so much easier to use that I came down with a case of thermal-model madness. How cold would the bedroom floor be when it was 25°F outside and 72°F inside? I'll work up a quick model! What will be the coldest spot in the basement at 5°F? –5°F? –10°F? Would it be enough to use 2 inches of insulation, or should we double up and go to 4 inches? Thermal modeling opened a world of minutiae to me that, quite frankly, had never before been interesting. As I became more familiar with the software, I was captivated with quantitative results such as 0.017 BTU/hr ft °F. This number, referred to in this context as a psi value (or Ψ if you really want to leave others in a wake of impressed confusion), expresses how many BTUs (units of heat) flow per hour and degree Fahrenheit through each foot of a linear intersection, such as one around a window frame. And so I went back and forth between my model and permutations of assembly details in HTflux, looking for the best possibility, until my eyes were bleary.
Like so many other exercises in design, there is no single right or best answer. That's part of what makes high-performance building fascinating to those of us who, as one of my research participants said, have drunk the Kool-Aid. But there's also a dark side, beginning with the specter of occupant behavior, which WUFI Passive and other modeling programs do attempt to address. Suppose you stash the holiday decorations in the attic and forget to turn off the incandescent lights before closing the hatch. While this would barely register as a blip in a conventional building, it would blow through most energy savings in a high-performance building. Furthermore, WUFI Passive, HTFlux, THERM, and many other energy-modeling programs are blissfully unaware of the economic costs of building assemblies. They provide plenty of incentive to create designs that save as much energy as possible regardless of cost. That's certainly the behavior I modeled... until my client turned out to be a certified public accountant! When he asked me to evaluate the cost tradeoffs of backing off just a bit on energy performance, I found myself in less familiar territory, nervously presenting calculations of net present values that I generated from multiple cases in WUFI Passive. It was not too long into that exercise that I realized BEopt would be a much better tool for the job, since it models the trade-off between energy performance and capital investment, and even allows the user to tweak the discount rate, inflation rate, and cost escalation of energy. Down the rabbit hole I went.
BEopt facilitates hundreds of options beyond the typical selections of thermal performance for walls and windows, and the efficiency of the mechanical equipment. You can vary the orientation of the building (helpful for a builder trying to put an existing plan on a lot), the amount of shading from eaves and overhangs, how tightly the house is sealed—even the color of the roof, which can impact heating and cooling usage depending on climate. I made my selections, clicked calculate, and left my computer to run overnight. When I came back in the morning, I realized it was going to need a lot more time. Four days later, it finished. For future optimization runs, I configured a virtual machine with 64 processors on Amazon Web Services. It ran my first optimization in a comparatively speedy four hours. All that time and processor power vindicated what high-performance builders have been talking about since the 1970s: The most economic approach for the long term is to design a building that is tightly sealed and continuously ventilated, well-insulated, and with high-efficiency equipment and excellent windows. The more startling result from the BEopt analysis was the cost optimization. In our particular retrofit project, the software demonstrated how the same dollars spent to achieve a 60 percent reduction in energy use could, through strategic choices of assemblies, be better allocated to reach a 90 percent savings. Just think of the energy a design approach like this could free up for Bitcoin mining! [4]
My experience with BEopt has left me wondering about all of the human time and effort—not to mention the electrical energy—pouring into ever more precise modeling and prediction of all types. In the case of autonomous vehicles, where the lives of pedestrians and bicyclists are at stake, absolute certainty is the only goal worth pursuing. But in the case of energy modeling, when we can economically reduce energy use by 60 to 90 percent compared with code-minimum construction and predict actual use within a margin of just a few percentage points by running a quick calculation, shouldn't that be good enough?
References
1. Bean, J. It's not that hard. Interactions 23, 1 (Jan.–Feb. 2016), 24–25; https://doi.org/10.1145/2852227
2. THERM. Windows and Daylighting. https://windows.lbl.gov/software/therm
3. Suchman, L.A. Plans and Situated Actions: The Poblem of Human-Machine Communication. Cambridge Univ. Press, 1987.
4. O'Dwyer, K.J. and Malone, D. Bitcoin mining and its energy footprint. Proc. of the 25th IET Irish Signals & Systems Conference 2014 and 2014 China-Ireland International Conference on Information and Communications Technologies. 2014, 280–285; https://doi.org/10.1049/cp.2014.699
Author
Jonathan Bean is assistant professor of architecture, sustainable built environments, and marketing at the University of Arizona. He researches domestic consumption, technology, and taste. [email protected]
Copyright held by author
The Digital Library is published by the Association for Computing Machinery. Copyright © 2018 ACM, Inc.
Post Comment
No Comments Found