Why Building Simulation Software Is Stuck in the Past

Part 3 – Unpacking the 3 T’s - Technology

Technology carries a lot of weight in AECO (architecture, engineering, construction, and operations) – and is probably going to carry more going forward.  Computers have improved: your smartphone is roughly 1000x more powerful than a desktop computer was circa 2000.  That desktop computer used 50 to 150 watts to operate.  Your smartphone uses around 10 watts.  We can run building simulation models from our phones and tablets – even without the cloud.

The cloud is widely available and enables scalability of compute and storage that a single PC or smartphone can’t touch on its own.  The software code and infrastructure for many building performance simulation tools are still dated and haven’t been overhauled in decades.  This means the speed advantages of cloud computing have largely been unrealized for building simulation.

Buying a new computer is relatively simple and cost-effective.  Re-coding or creating a brand-new software tool to leverage the advances in hardware has not been very cost-effective.  That’s changing rapidly. 

Technology problem 1: software interoperability & data standards

Software companies have had proprietary data structures to protect their IP and grow their customer base for a long time (since the invention of software?).  Data schemas were developed to serve as a common “translator” between proprietary software tools and open-source software alike.  Few of these have really worked all that well in practice owing to a number of interrelated challenges:

• Inconsistent data input standards across AECO

• Inconsistent “enforcement” of developed standards across AECO

• Limited validation of the schemas

• Challenges with legacy software architectures

The first bullet refers to the reality that individual AECO entities have their own “BIM (Building Information Modeling) Standards” for how to model a building or group of buildings.  Some industry organizations publish their own standards as well.  Relatively few have standards relating to building performance models. 

The second bullet refers to the fact that, in many cases, these modeling “standards” aren’t enforced consistently even within the same organization.  

This isn’t to place blame; it is to acknowledge the reality that project delivery is still largely analog (paper or PDF drawing sets, not full digital BIM delivery) and as such, “shortcuts” can be taken in a BIM environment to make sure the drawings “look good” even though the BIM itself may be poor.  As an example, the wall type can be generic and still plot to paper just as well as if the wall type contains all the assembly information including everything a load and energy model actually needs to know (how well it insulates, how much heat it stores, and so on).  There’s one set of data for pricing and constructing the building, and another set of data that’s needed for assessing how well the building might perform. 

Technology problem 2: siloed software tools that scale poorly and/or are “landlocked” inside other tools

You can find hundreds of building simulation tools today.  Most of them do only one or two things.  Many of them are decades old and only run on a PC, not a Mac.  Some of them can share data within their platform across multiple “applications” native to the full software suite.  Few of the ones used by architects are also used by engineers or simulation practitioners.  Very few of them are in the cloud and support multiple disciplines working on them at the same time from the same set of data.  Some are only available as plug-ins to other platforms that were initially designed for other purposes.  These “bolt-ons” require proficiency in some other tool before one can learn to use the simulation tool itself.  They still usually run on a local PC as well.

These siloed tools inherently limit cross-discipline collaboration, and the problem is more acute when the tools sit on a local PC and not in the cloud.  This limits the value to a specific user or discipline at best and reduces opportunities for cross-discipline learning to accelerate talent development.  It also hinders transparency for non-experts to build trust that the models being created in these tools properly reflect the parameters used for design.

Learning dozens of tools also means dozens of learning curves – which impacts the bottom line of the business.  It can be difficult to track how much time is spent learning and re-learning software that isn’t necessarily used frequently.  But this cost is real and likely significant to the business and its clients.

Technology problem 3: code and data structures (relates to problem 1)

Intertwined with problem 1 is the reality that most of today’s BIM and simulation tools were started in the late 1990s and early 2000s.  This is when dial-up was still the primary means of connecting to the internet and AOL was king.  Software was largely distributed on physical media (floppy disks, CD-ROMs, etc.).  Broadband internet came along shortly thereafter and AOL cratered.  But BIM and simulation tools kept chugging along on their original foundations – the software equivalent of still having dial-up internet in the age of broadband.

A little historical context (based on some light internet searches):

• DOE-2.2 (the engine beneath eQUEST) was released in 1998.

  • eQUEST was last updated in October 2018, with no further updates planned.

• The first commercial release of Revit was April 2000.

• The first commercial version of IESVE was released in 2000.

• The first version of EnergyPlus was released in April 2001.

• AWS (commercial cloud computing) became available in 2006.

• Rust, a modern programming language built for fast, safe, parallel computing, didn’t have its first stable release until May 2015 – roughly 14 years after the first release of EnergyPlus.

“Modern” BIM platforms and “modern” simulation tools are legacy products that were not built for today’s cloud computing systems, coding languages, and data architectures.  This is not shade on any of these software tools; it’s merely pointing to the reality of the limitations of the technology available at the time these tools were first conceived.

Handling large amounts of data (e.g. detailed building physics, large projects, or multiple buildings in the same model) can often be painful in these legacy tools.  Clicking on something simple like a wall surface might lead to seconds (or minutes) of waiting for the code to “catch up” to the user input.  And adding new technologies to these platforms (like a new HVAC system type or building material) generally takes years to implement and make available to practitioners.  Not all of that time is software development, but there is a lot of room to compress that timeline to bring solutions to market that can solve problems faster.

Technology problem 4: simulation times (relates to problems 1 and 2)

The code structures and methods of solving physics in engines were limited by the programming languages available and the compute available at that time (among other constraints and development decisions).  Nearly everyone was performing calculations on local computers and sharing files over local area networks when development started for these tools.  Compute was very limited as noted previously.  Code and data structure choices also limited how the calculations could be performed.  This meant extended simulation times or trade-offs in the engines to speed them up. One example of this trade-off is the lack of zonal heat balance calculation in DOE-2.  While DOE-2 runs fast, it calculates room loads and HVAC systems in sequence, without feedback between them – which led many practitioners to keep a separate model just for calculating thermal load and sizing HVAC equipment.  This limitation was one of the primary drivers for the development of EnergyPlus to replace DOE-2 and BLAST.^[1]

The problem of software not keeping up with hardware is not new.  As the EnergyPlus developers put it back in 2001: “Designed in the days of mainframe computers, expanding their capabilities further became increasingly difficult, time-consuming, and expensive.”^[2]

These are some of the technology-related problems that need to be solved.  Do you have any to add to the list?

^[1] Crawley, D.B., Lawrie, L.K., Winkelmann, F.C., et al. (2001). “EnergyPlus: creating a new-generation building energy simulation program.” Energy and Buildings, 33(4), 319–331. https://doi.org/10.1016/S0378-7788(00)00114-6

^[2] Crawley, D.B., Pedersen, C.O., Lawrie, L.K., Winkelmann, F.C., et al. (2001). “Software Tools for Building Envelopes: EnergyPlus: New, Capable and Linked.” Proceedings of Thermal Performance of the Exterior Envelopes of Buildings VIII, ASHRAE/DOE/ORNL. https://web.ornl.gov/sci/buildings/conf-archive/2001%20B8%20papers/153_Crawley.pdf