Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question

Revision history [back]

Good question. To be honest, the fact that you're even asking this question shows how much progress has been made.

Five to ten years ago, EnergyPlus was the bottleneck and no one was asking about the performance of the balance of system steps. There was a lot of effort dedicated towards making our residential EnergyPlus simulations faster -- partly through EnergyPlus improvements (like this or this), partly through choice of EnergyPlus algorithms to find an appropriate balance of accuracy vs speed (like this), and partly through how we process outputs (like this).

Now that our simulations are so fast (at least with hourly timesteps), yes the balance of system runtime can be as much or greater. There are a lot of reasons for it, but the primary ones are arguably:

  • Ruby (including loading gems for, e.g., XML/JSON processing)
  • OpenStudio CLI & SDK
  • XSD & Schematron validation
  • Inefficient code in OpenStudio-HPXML

There have been some improvements to the balance of system (like this or this), but we haven't focused as much attention here in general.

I'll note that in your example simulation, you're including two steps (the BuildResidentialHPXML and BuildResidentialScheduleFile measures) that are not often used and account for almost half of the total runtime. If a software tool is providing an HPXML file to us, they won't see these steps. And it's true that we've spent less time trying to optimize these two measures (though we have done a bit).

We continually look for opportunities to improve speed further, but there are diminishing returns to finding hotspots that are low effort and provide significant gains. And user requests for us to focus on performance improvements have tailed off significantly in recent years -- probably because most users remember how slow things used to be!

Finally, we do point out a few areas in the documentation where one can improve speed when using OpenStudio-HPXML.

Good question. To be honest, the fact that you're even asking this question shows how much progress has been made.

Five to ten years ago, EnergyPlus was the bottleneck and no one was asking about the performance of the balance of system steps. There was a lot of effort dedicated towards making our residential EnergyPlus simulations faster -- partly through EnergyPlus improvements (like this or this), partly through choice of EnergyPlus algorithms to find an appropriate balance of accuracy vs speed (like this), and partly through how we process outputs (like this).

Now that our the EnergyPlus simulations are so fast (at least with hourly timesteps), yes the balance of system runtime can be as much or greater. There are a lot of reasons for it, but the primary ones are arguably:

  • Ruby (including loading gems for, e.g., XML/JSON processing)
  • OpenStudio CLI & SDK
  • XSD & Schematron validation
  • Inefficient code in OpenStudio-HPXML

There have been some improvements to the balance of system (like this or this), but we haven't focused as much attention here in general.

I'll note that in your example simulation, you're including two steps (the BuildResidentialHPXML and BuildResidentialScheduleFile measures) that are not often used and account for almost half of the total runtime. If a software tool is providing an HPXML file to us, they won't see these steps. And it's true that we've spent less time trying to optimize these two measures (though we have done a bit).

We continually look for opportunities to improve speed further, but there are diminishing returns to finding hotspots that are low effort and provide significant gains. And user requests for us to focus on performance improvements have tailed off significantly in recent years -- probably because most users remember how slow things used to be!

Finally, we do point out a few areas in the documentation where one can improve speed when using OpenStudio-HPXML.