-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extremely slow workflow run time (not including EnergyPlus runtime) for large models with many info messages in one or more measures #4821
Comments
@DavidGoldwasser Could #4919 help at all with "bypassing statements"? |
@DavidGoldwasser FYI I tried running a "Multifamily" building with
There's definitely a lot of log lines in I definitely could see updates/improvements here in terms of grouping like units (i.e., sort of a multiplier approach) and applying OS-HPXML on a smaller subset of unique units. Perhaps that would help reduce the size of |
@joseph-robertson Perhaps it is faster to store all of the model objects to be added in an array and then call |
@DavidGoldwasser I tried out the suggestion from @shorowit. It does appear to be faster, maybe like 10-20% (although I'm coming to this conclusion with very limited testing). It probably doesn't solve the large hurdles with huge |
Do you have to use |
I'm not real sure what the second argument is used for ( |
Given that this issue is still open and there are potentially multiple reasons for the slowness of this particular case, I opened a new issue that specifically targets one of the causes, which has to do with the adding new objects to the model when Model.size is large: I don't want to hinder the improvements to logging that were mentioned here but, given that the OSM of this case is 500 MB, I sense that a significant fraction of the slowness might be the result of what I raised in that issue. |
Issue overview
Typically runtime issues are related to EnergyPlus but here for workflows that take more than 24 hours to run (On my M1 Max mac, twice as slow on Window, I can share those times later) less than 2 hours of that is on the EnergyPlus simulation.
This is an URBANopt project using large (200-400 unit building) with hpXML > OSM approach merged into single model. The OSM file is about 500 MB, the out.osw file in some cases is larger than 40 MB and has more than 150k lines.
Current Behavior
Here is a plot on top of full runtime and below just EnergyPlus. Of the for largest and slowest models two of them (around 50k sqft in size) take much longer than linear scaling of time for the smaller models. I can try to produce this plot for Windows as well. I don't know what is unique about those to models than the larger models that run in less than half the time (it could be they have more units even though less sqft, but maybe something else as well).
Build Residential measure does take a few hours but a number of downstream measures are also slower. Also in on case I saw an odd multi-hour gap between when one measure finished and the next started. That may have been an anomaly. I already have a rake task that gets me the runtime total from the OSW, maybe that can be updated to isolate each measure, and look for any gaps in time between measures.
Expected Behavior
Unless sizing runs are part of a measure, they generally should run in a few seconds or few minutes. Maybe that isn't reasonable for large models, but at the worst the impact should be linear where a model twice as big is twice as slow, not 4x slower. If there are ways to speed up processing for larger models that would be helpful.
Steps to Reproduce
https://github.com/urbanopt/urbanopt-prototype-district-templates/tree/temp_slow_only/example_files/weather
Possible Solution
Some of this may fall on measure writing to minimize looping through objects. Logging is a complex question. I generally encourage good logging of warning and info messages for transparency and diagnostics. I'm wondering if we should have an enhancement request for when running osw in the CLI to not write info messages, and only warning and runner.register values.
Possible steps outside of core OpenSutdio
Possible steps within core OpenStudio
Details
The way URBANopt works is that all features in a scenario are run in parallel. I was running at one point 2x scenarios across 16x file locations. When I ran the default way I had all cores but one waiting for the last slow feature to run. To speed up process I ended running without the for slowest features. I then did separate run on separate computer of the slow features with just the right number of cores dedicated so that I could run multiple scenarios in parallel instead of just 1.
Related to the long out.osw one measure (reduce_epd_by_percentage_for_peak_hours) is largely responsible for that, because it is logging all schedules ,and other objects combined with a model that appear to have excessive amount of objects, multiple always on schedules.
Environment
Some additional details about your environment for this issue (if relevant):
Context
This has made running analysis for paper very slow and complex. Not something we would expect external URBANopt users to do.
The text was updated successfully, but these errors were encountered: