Hi, I’m trying Pollination for the first time to run a large-scale Dragonfly Model (District level). But I encountered a rapid error, and the simulation crashed.
Hi @batiste, Welcome to the forum.
Can you share the model with us? Or the link to the simulation that you ran on Pollination? That will make it much easier to debug the model.
Hi @batiste ,
Yes, this was a bug that was fixed a while ago. What recipe are you using so that I can make sure that it gets updated with the fix?
Hi @mostapha. This is the link to the simulation: Pollination Cloud App (I’m not sure if this is how you asked me to share the simulation link).
HI @batiste ,
Yes, that dragonfly energy use recipe has not been updated in while so I’m sure it still has this old bug for shaded window constructions. Give me until the end of today and I will push a new release of it that will not give you that error.
Hi @chriswmackey ,
Thank you. It is possible to add mappers, or extract the eplusout.eso? I’m new in Pollination and the recipe concept is new for me
2 posts were split to a new topic: Running energy simulation for 200 buildings using the dragonfly-annual-energy-use recipe
Hi @batiste ,
I just pushed an updated version of the dragonfly-annual-energy-use recipe (version 0.3.4), which will no longer give you this issue that you encountered:
Before answering your questions, I should clarify that the dragonfly pollination recipe is not using the URBANopt CLI, which is what sounds like you are using for your local simulations. The dragonfly recipe uses OpenStudio/EnergyPlus directly, bypassing the use of URBANopt. Granted, the result is effectively the same since all that the URBANopt component is doing is running OpenStudio in parallel but this means that certain types of URBANopt-specific post-processing is not currently supported through the recipe (like REopt integration, RNM integration, and OpenDSS simulation). In the future, we may add some support for this if there’s enough demand for it.
Now, to answer the specific questions:
All of the data that you would find in the .eso files is contained in the .sql files output by the recipe. So I recommend downloading the SQLs and using the Ladybug Tools components to parse in the data from them that you want. If this download and parsing process becomes really time consuming, this type of post-processing can be integrated into the recipe (this is effectively how you get a single eui JSON for the energy usage of the whole district). More on that later.
You can apply a measure to all of the buildings in the dragonfly Model (this is what the measures input for the recipe allows you to do). Applying different measure arguments to each building of the model like the mappers do is not currently supported. It can be added if there is a enough demand for it.
I would just check to be sure that the simulation of these buildings didn’t start and then fail (if so, you would see an error in the log file for that building in the project folder). If the folder for the building doesn’t exist at all, this sounds like your machine running out of memory or maybe your CPU overheating (I’ve definitely done that a couple of times with URBANopt simulations). But I think you are right that Pollination can help you here.
@mostapha can tell you a lot about how to add custom post-processing to the recipes since he’s made a lot of improvements recently in this area. If what you need to modify is the recipe inputs, this is a little tougher and usually requires a little experience. If all that you need is mapper functionality, I can add it but I’d want to be sure that you couldn’t do this with the native Dragonfly components first.
I just ran a test simulation of the dragonfly-energy-use recipe so that you can get a sense of how it runs.
If you check the debug for the run, you can see that each dragonfly Building can run on a separate worker if you used Building as the input for obj-per-model in the recipe. So you study with 14 buildings used 14 workers in parallel. As you can see on the Pollination pricing, the free pollination account gets you 60 parallel CPUs, which will allow you to run larger districts pretty fast, though beware that you may quickly run out of storage and CPU-hours. If you pay for an account, you can get up to 1200 parallel CPUs, which would clearly improve your run time a lot. @mostapha can answer more of your questions about how CPU usage is computed.
