Dragonfly simulation time optimization

Hello, I’m trying to optimize the calculation time for models created with DragonFly and simulated using URBANopt’s run the DragonFly. I’ve performed a calculation for the “Run Sizing Period” with a timestep of 2, and another simulation for the “Run Annual” with a timestep of 12. When I take an idf file from the “Run Sizing Period” simulation and simulate it with EP-Launch, the simulation takes about 5 seconds (I get the same results on another computer). However, when I do the same with an idf file from the “Run Annual” simulation, the simulation takes 88 seconds on my computer and 10 seconds on the other computer.

Why does this significant difference appear? I’m using the same EnergyPlus version as the idf. The only thing that comes to mind is that the weather file on the other computer might be different, but I understand that it shouldn’t have such a significant impact either.

HI @Batiste ,

I reread your post a couple of times but I’m still not able to understand exactly which simulation workflows you are comparing here and how many there are (I guess there are 4 things you are comparing here)? If you can clarify what exactly you are doing for each case, I can give you a rough idea of how much time is spent on different tasks in each situation.

For now, I will say that, if your actual simulation part is only 5 seconds, then it’s likely that the translation process from Honeybee > OSM takes just as long because OpenStudio CLI has some overhead. And the URBANopt CLI has even way more overhead than that given that it’s not just calling OpenStudio CLI but also downloading a bunch of ruby gems before the simulation if you do not already have them in your machine. So URBANopt tends to work best when the simulation of each building is at least a minute and you have a lot of buildings to make use of the parallel processing.

Chris,

I appreciate your response. To clarify the situation, I’m comparing two simulation workflows in two different machines:

  1. “Run Sizing Period” simulation: I performed this simulation with a timestep of 2. When I take the IDF file generated from this simulation and run it with EP-Launch, the simulation completes in around 5 seconds on both my computer and another computer.

  2. “Run Annual” simulation: This simulation was done with a timestep of 12. However, when I take the IDF file from this simulation and run it with EP-Launch, the simulation takes about 88 seconds on my computer and only 10 seconds on the other computer.

I’m puzzled by the significant difference in simulation times between the two cases. Both computers are using the same EnergyPlus version as the IDF files. While I thought the weather file might be causing the discrepancy, it seems unlikely to have such a dramatic impact.

Regarding your insight into the translation process and URBANopt’s overhead, I understand the additional time required for these tasks. It’s just perplexing that the “Run Sizing Period” simulation, despite having a shorter timestep, shows consistent simulation times, while the “Run Annual” simulation has such a notable discrepancy.

If you have any suggestions or insights on why this difference might be occurring, I’d greatly appreciate it.

Hi @Batiste ,

Thanks for clarifying and I understand your question now, though I can’t say that I really know the answer. My initial gut reaction would be to make sure that you’ve matched the timesteps in the simulations between both machines since this clearly has a big impact on the runtime.

If you’re sure that this is matched, then it’s possible that one of your machines is just benefiting from some of the work that has been done for the EnergyPlus 10x project, which I know is taking advantage of some things in modern CPU architecture that not all machines may have.

This study is old but it’s helpful for understanding how the speed of the E+ simulation is influenced by CPU architecture:

https://www.jeplus.org/wiki/doku.php?id=docs:eplustest

An 8-fold speed increase is a lot but 4-fold ones have historically been common.