Performance improvement for openstudio-hpxml

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

cmui
143 ●5

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

Aaron Boranian

13890 ●76 ●24 http://bigladdersoftware.com/

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   |

answered 2024-04-29 16:24:12 -0500

shorowit

11096 ●184 ●9 https://www.nrel.gov/b...

updated 2024-04-29 16:24:55 -0500

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.

edit flag offensive 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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Performance improvement for openstudio-hpxml

1 Answer

Comments

Your Answer

Training Workshops

Careers

Question Tools

Stats

Performance improvement for openstudio-hpxml edit

1 Answer

Comments

Your Answer

Training Workshops

Careers

Question Tools

Stats

Performance improvement for openstudio-hpxml