Hi @mostapha,
Has this limitation been removed in newer versions of Pollination? If not, when will multiple runs be available to run locally? Is there a work around for this in the meantime? Debating if we would be better off using Colibri in the meantime.
Best,
Justin
Hi @justinshultz,
This was not under my radar. Technically, it will be possible to support this feature but we have to make a few changes to how the executor runs the simulations locally and how we report the progress. If it is an important feature for you, we can make it a priority.
Meanwhile, the easiest workaround is to use Colibri or fly to feed them to the Pollinate component one at a time. Make sure to change all the downstream components to be blocking. Otherwise, it will start the next run before finishing the previous one.
We were thinking of shifting from Pollinate to Colibri, thank you for the confirmation.
Internally to our firm, we have a few powerful computers with over 40 CPU cores. I was hoping to find a workflow where we could run many studies simultaneously, similar to cloud computing. I’m not sure I would classify it as a high priority but it would be great to have!
I’m not sure if I understand this correctly. By Collibri, are you suggesting using Collibri with Honeybee recipes? That can work but you can also use Collibri with the Pollinate component itself.
Noted! Thank you.
Thank you for clarifying that! I was thinking of Colibri with Honeybee-Radiance and Honeybee-Energy. But hadn’t considered the workflow with Colibri + Pollinate.
We’re trying to run a coupled daylight and energy simulation. I’ll have to try if I can the load asset from the daylight recipe Pollination run into an electric lighting schedule for the energy simulation. Unless there is a better workflow?
I don’t think we have an automated workflow for that right now. I know that we have a component that can be used to create the lighting control schedules.
We can automate the workflow to put both of these in a single recipe but in that workflow, we should generate the sensor grids in a certain way to be able to map the lighting schedule per room. Otherwise, it can get tricky.
This would be a great recipe addition! We commonly run daylight and energy simulations together.
Yes, we use the Daylight Control Schedule component you linked.
For what it’s worth, I agree. I would like to be able to run a parametric study on a local machine.
In your example video from a few years ago, the small room model took 1.5 minutes (x6 iterations), so any study of size with hundreds of iterations will easily use up the allotted free cloud hours.
Maybe this is a non-issue for subscribers, but limits free users a bit.
Hi, @jmarsh4087! Thank you for sharing your thoughts. Makes sense!
We have drastically improved the performance of our cloud computing for smaller models. The free options should give you a good amount to run the studies but I understand your point, and it is valid.
Hi @mostapha,
The limitation of one run at a time locally is still in place. Are there any plans of supporting multiple runs locally as well?
Ideally what I’d love to see is that you can input multiple runs into the Pollinate component (e.g. using Colibri or Fly) and Luigi/Queenbee efficiently uses its workers/CPU cores to run all of the tasks in parallel, and works on multiple runs at a time over all workers.
I’d love to have this functionality for especially the Radiance simulations.
Why I am asking is that, when running one daylight study at a time using Pollination or Honeybee, you will often see inefficient use of the number of workers because there’s a lot of waiting happening to finish a task before being able to go to the next one. That is reflected in the CPU utilization graph:
For EnergyPlus, it’s possible to be more efficient using HB Run OSM. But even in the case of E+, there’s room for improvement if we’d be able to utilize the workers better. Because if you have e.g. 30 CPU cores in HB Run OSM, it’ll wait for each set of 30 simulations to be done before running the next set. I feel like Luigi/Queenbee could do that more efficiently without having to wait for a set of 30 to be done.
Also our firm has a couple very powerful computers with 40 CPU cores that would be great to utilize in this sense. But even for laptops with 8 or 16 cores it would be a significant speed improvement.
Kind regards,
Marc
Hi @marctavenier,
This is one of those topics that I personally love to be addressed but is going to break many of the existing workflows including how the Rhino panel works.
I totally agree with all the comments that you are making here. It is not a limitation of Luigi. It is mainly an issue with the way I have implemented the execution. The Luigi local scheduler works in a strange way so it is not the most straightforward approach to send multiple Pollination runs to it but it is doable.
I just wanted to make sure I commented here letting you know that I saw the request and I agree with it but you need to be patient with us until we get a chunk of time to make this change and also update all the downstream parts of Pollination that will be affected by this change.
The good news is that we will be introducing some simulation workflows for generating code compliance reports to the Model Editor early next year which make sure revisit the local execution implementation.
I appreciate you sharing your thoughts. I wish I could have had a better answer and offer a quicker solution. Cheers. 
