"URBANopt' Dragonfly Running requires a lot of hard drive space



My dragonfly can run well and get results, but during the calculating progress, it seems that it needs upgrading something each time.
Also, it is surprising that the result folder is so big, a folder called “.​ bundle” occupies the most memory, and often a small test (with 4 buildings and its’ context) needs about 2GB.
I don’t know whether it is normal or if I need to update something.
​THX!

Hi, I may have encountered the same problem as you did, but my simulation is very unstable (sometimes it runs well and fast, but sometimes it reports error). Have you resolved the problem yet?

Hey @Iris_YY ,

It should not need to re-download the dependencies each time if you are using the same folder for writing the GeoJSON file. The old dependencies in the .bundle folder get re-used as long as you are using the same folder. But making a new folder each time will result in downloading a new copy of the dependencies before the EnergyPlus simulation starts.

I know the .bundle folder is big and it’s because URBANopt is currently designed such that each project folder gets it’s own copy of the Ruby dependencies. At least half of the .bundle is the OpenStudio Standards gem and I know that NREL has been trying to make it slimmer but it’s still pretty colossal. I think this may eventually be addressed with a restructure of the URBANopt SDK so that all projects can use the same .bundle. But, for now, rest assured that the big .bundle file is expected.

Thank you! @chris
The new destination folder really results in dependencies re-download!
However, if I use the same folder for writing, the former “run” folder will be covered. I don’t know what I should do if I want to retain the “sql”, “eplusssz” and "eplustbl"data. There seems no way to rename the “run” folder to “run_x” before each running.

Hi~ @Rowena
I think the unstable running may be influenced by the network speed, the CPU utilization and RAM of the computer. When it loaded the dependencies, the cmd window wrote so slowly. But when it ran into the calculation process, the character strings rolled so quickly!
And sometimes I also met errors like "……honeybee_scenario.csv cannot find "when re-calculated a same model. The solution I tried was deleting the older “.bundle” folder in the destination folder and let it reran.

Yeah, according to the Gemfile the process generates, it mainly involves downloading dependencies from http://rubygems.org, and this process could be slow due to network conditions. And I also found that Gemfile in the project folder is actually copied from urbanopt_gemfile within the %HOMEPATH%/ladybug_tools folder, so after I edit the gem source to a more stable one in urbanopt_gemfile, the dependencies loading process is much faster and never stuck!

I agree with you that recalculating the same model can have many problems. Whenver that happens, I just unstall and reinstall UrbanOpt CLI and LBT, delete the .bundle folder and let it rerun.

@Rowena That sounds great!
And could you tell me how to “edit the gem source” before the simulation starts?
What I can do now is just wait and wait………

Happily. Just find the urbanopt_gemfile file within the C:/Users/USERNAME/ladybug_tools folder (need to open a lot of sub-folders to find it, or just search it), open it using Notepad, and you can see the top line writes “souces 'http://rubygems.org'” , you can then edit this address with another stable one, and finally remember to save the file.

1 Like

Wow~ Thank You~
However, recently some new errors about gemfile happened.
When I started the simulation, the strings in black cmd window seemed like that in previous, but when simulation was done, there were no results that could be found. Also, I got a “failed” txt, and the folder of “run” indicated that some rb cannot load.
Have you ever met this situation? Actually, I didn’t change any components.

Hi @Iris_YY ,

Sorry for the late response. You are encountering a bug that happened in URBANopt, which is essentially the same as what happened here:

The same solution there will work for your case and your issue will be fixed if you run the LB Versioner. This will give you the latest version of the URBANopt GemFile, which has a correct version of the adressable gem that is failing there. FYI, if you’re ever curios, here is where you can always find the latest Gemfile that we use:

You can see that both the addressable and the parser gems have given us a bit of a headache recently. :upside_down_face:

Also, that’s a really clever solution, @Rowena. I’ll keep this in mind and point people to this discussion if they are looking for a way to get around the download of all the ruby gems for each project folder.