Performance improvement for openstudio-hpxml

I've noticed that >50% of my execution time for openstudio-hpxml based workflows is executing the model measures and not the actual energplus simulation.

I'd like to know if there's options for improving this performance. Is this possibly bottlenecked by Ruby execution speeds?

|                   Timer                   |  start   |   end    |  duration  |
|:------------------------------------------|:--------:|:--------:|:----------:|
| Initialization                            | 23:30:58 | 23:30:58 |    18ms    |
| o Wiping directories                      | 23:30:58 | 23:30:58 |    0ms     |
| OpenStudioMeasures                        | 23:30:58 | 23:31:04 |   5647ms   |
| o ModelMeasure:apply_measures             | 23:30:58 | 23:31:04 |   5647ms   |
|   o Measure::BuildResidentialHPXML        | 23:30:58 | 23:31:00 |   1956ms   |
|   o Measure::BuildResidentialScheduleFile | 23:31:00 | 23:31:03 |   2166ms   |
|   o Measure::HPXMLtoOpenStudio            | 23:31:03 | 23:31:04 |   1523ms   |
| Translator                                | 23:31:04 | 23:31:04 |    81ms    |
| o Translating to EnergyPlus IDF           | 23:31:04 | 23:31:04 |    80ms    |
| EnergyPlusMeasures                        | 23:31:04 | 23:31:04 |    0ms     |
| o EnergyPlusMeasure:apply_measures        | 23:31:04 | 23:31:04 |    0ms     |
| PreProcess                                | 23:31:04 | 23:31:05 |   446ms    |
| o ReportingMeasure:apply_measures         | 23:31:04 | 23:31:05 |   409ms    |
|   o Measure::ReportSimulationOutput       | 23:31:04 | 23:31:04 |   188ms    |
|   o Measure::ReportUtilityBills           | 23:31:04 | 23:31:05 |   220ms    |
| o Saving Final IDF to Run Dir             | 23:31:05 | 23:31:05 |    37ms    |
| EnergyPlus                                | 23:31:05 | 23:31:08 |   3470ms   |
| o Saving IDF                              | 23:31:05 | 23:31:05 |    37ms    |
| o Running EnergyPlus                      | 23:31:05 | 23:31:08 |   3338ms   |
| ReportingMeasures                         | 23:31:08 | 23:31:09 |   740ms    |
| o ReportingMeasure:apply_measures         | 23:31:08 | 23:31:09 |   735ms    |
|   o Measure::ReportSimulationOutput       | 23:31:08 | 23:31:09 |   639ms    |
|   o Measure::ReportUtilityBills           | 23:31:09 | 23:31:09 |    94ms    |
| PostProcess                               | 23:31:09 | 23:31:09 |    0ms     |
| Cleanup                                   | 23:31:09 | 23:31:09 |    0ms     |
| Save IDF                                  | 23:31:09 | 23:31:09 |    39ms    |
|                   Total                   | 23:30:58 | 23:31:09 |  10447ms   |

143

cmui

asked 2024-04-27 18:50:49 -0500

14.1k

Aaron Boranian

updated 2024-04-29 09:13:18 -0500

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

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 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.

11.8k

shorowit

answered 2024-04-29 16:24:12 -0500, updated 2024-04-29 16:24:55 -0500

edit flag offensive 0 remove flag delete link

Comments

Thanks for the detailed answer, and all of the work that goes into improving these tools!

cmui (2024-04-29 23:43:47 -0500) edit

"Limit requests for timeseries output (e.g., --hourly, --daily, --timestep arguments) and limit the number of output variables requested." That is a good tip to remember...

sashadf1 (2024-05-01 14:56:00 -0500) edit

add a comment see more comments

Performance improvement for openstudio-hpxml edit

Comments

1 Answer

Comments

Performance improvement for openstudio-hpxml