Hello there
I am facing some issues when running the urbanopt simulation. It seems something similar to the issue in this thread. It gives me “solution exception” because it is not able to find the file.
Similarly to the thread, dragonfly is able to generate the files in the folder. As suggested I also tried to run the files in the command prompt with no success.
I am using the example file of the tutorials (I am unable to attach the file at the moment).
By the way, I am using windows 10, rhino 7. Ladybug and Honeybee 1.4 work fine.
(Sorry, discourse is making me send one image at time. I was unable to sign in to older profile, with an old institutional email that I don’t possess anymore, so I had to create another profile)
It looks like there is something wrong with your URBANopt installation such that it cannot find openstudio-common-measures. Do you get the same error when you use the latest URBANopt with the latest LBT 1.5?
Hi @chris, thanks for the reply and apologies for late responding. So, the weird thing with me is that I managed to run a sample of 177 buildings in London, but when I created a new shapefile of 15 buildings by removing the rest buildings, I got the error. Also, I have done the tutorials in YouTube channel from Ladybug Tools channel and I managed to run this too.
It’s possible that your issue is not the same one as @Thiago_Goes since I think his issue is probably fixed in the latest version of Dragonfly/URBANopt. Can you run the run_simulation.bat file from command line just like @Thiago_Goes did and then send a screenshot of the terminal?
That will help me figure out whether it’s the same issue or a different one.
Hi @chris ! Thanks for that. This is what I am taking from simulation.bat file… But if I leave it for a while it seems like something is running very quickly I have a red text and it automatically turns off.
That first screenshot is very helpful and shows that this is, in fact, the same issue that @Thiago_Goes was having.
I requested some input from the URBANopt development team at NREL to help figure out what is going on but, in the meantime, I have a suggestion for you to try:
… and then re-run the Grasshopper script that currently isn’t successful.
If the simulation runs successfully after this, then we know that the issue is with how we clean up the URBANopt project folder whenever you go to overwrite previous results with a new simulation.
Hi @chris , I have done what you said. At first I thought it would run, cause it took more time for the error. But the same error occured. However, at the LB version I can see that in your computer you have a newer one.
Hi @chris , to update you… I updated the version to LB 1.5.8. Then, I got error about URBANopt and I updated it from 0.8.0 to 0.8.2. However, I tried to rerun now the script and again I got error.
The error is the same as you can see.
Thank you, @Nasia_Apostolopoulou . This is all really helpful and I think the NREL team will be particularly interested in the fact that this error still occurs using the latest version of URBANopt CLI.
Unfortunately, this means that what I originally thought was the issue is not the underlying cause but, fortunately, I have finally been able to recreate the issue on my machine!
It seems that this issue is the result of the name that you gave to your Dragonfly Model (or the name of the folder into which you are writing the GeoJSON). I was able to recreate your error by calling the Dragonfly Model London_-_10_Dwellings_Sample_Region but, when I changed this to London_10_Dwellings, everything simulates correctly.
It’s possible that the - in the file name was causing this error (or perhaps the name of the model was too long). In any event, I will do some tests to get to the bottom of it and push a fix that prevents this from happening in the future. In the meantime, changing the name of your Dragonfly model should give you a way to proceed until I get the fix merged.
Thanks again for reporting and for running all of these tests for us.
Hi again @chris . Thank you so much for helping me, too. Really appreciate it!
I have changed the score " - " and the file name and now I managed to run the project.
Really thank you and looking forward for the upgrade.
I have narrowed the issue down to the fact that the path to the project folder contained too many characters and this was causing the URBANopt simulation to fail. I imagine that NREL would consider this a bug and we will all work towards fixing it or finding better workarounds. In the meantime, I have added a fix into the latest version of Dragonfly, which will try to truncate the project folder in cases where it is too long. I included it in this update here:
This should give an automated fix for your case for the time being and you can get it on your end with the LB Versioner in an hour or so.
This also gives me some confidence that @Thiago_Goes was experiencing the exact same issue. It’s just that the reason why his URBANopt project folder was too long was because he has a particularly long username and not because the name of the model was particularly long.
