How to parallel run annual daylight simulations?

Hi guys,
My master’s thesis involved daylighting simulation and optimization, but so far my daylighting model (Figure 1) was running and yielding results, it was still too slow to calculate.

After my tests, setting the number of wokers in the HB Recipe Settings does not speed up the calculation, regardless of whether the number of wokers is 1, 10, or even the system’s default maximum number of CPUs minus 1, the simulation time is almost the same in these cases. Also as shown in Figure 2, I’m using a 100+ CPU server and have enough memory, but when doing the simulation calculations, it seems that only 1 or 2 CPUs are working, so I don’t think my model is using parallel computing, resulting in very slow speeds.

I’ve tried using Accerarad to assist calculations, but the results show that there is not much difference between using and not using it. I wonder if I’m simulating by parallel computing or not, and if there are other simple ways to speed up simulation calculations.

Hi @JerrySun,

How many sensor points do you have in the grid?

about 80,the size of the grid is 0.5m,and the size of the room is 4m*5m

That is too few sensors to benefit from many workers. When running the grid-based studies the grids will be split and distributed among the workers, but there is a “minimum sensor count” for each distributed grid. This minimum value is 500 sensors and it ensures that the distributed grids will not be too small, which will just add overhead and make the study slower even with many workers.

Thank you for your reply. I found that the problem was that I kept counting multiple rooms separately, which required multiple annual daylight simulations. Now I’ve combined the grids of these rooms into one model, and the simulation is much faster!

But at the same time, a new problem has emerged: some rooms have the error ‘Solution exception: Failed to compute data collections.’ in the annual to data module. The thing I’ve found is that this error occurs when there are more points in that room, like 100 and 200. This does not happens in other rooms, such as the 80-point room mentioned above. Also, when I adjust the grid size of the error room, the room can be calculated normally again.

Hi @JerrySun,

Can you share the Grasshopper file with internalized geometry?

Office.gh (1.1 MB)
Hello and thanks for replying again. Here is my gh file, I marked the location of the construction model and UDI model, I hope this will save you time. In addition, when you open the file, you will find that the part of my UDI model that processes the data after the simulation is very large and complex. After my calculations, these data took even longer to process than the simulation. My goal in processing these data is to get the exact number of hours that at least 60% of the area of each room meets the UDI range throughout the year, and I wonder if a grasshopper master like you will have an efficient and concise way to handle these data. Sorry my request may sound a little greedy, but I really need some help :slight_smile:

FYI

An earlier incarnation of this module could not handle many datapoints:

Could this be something similar?