Hi, I'm running a floor plate with around 100 windows and a band of open office along the facade and then meeting rooms in the core.
I have 22 simulation surfaces and it surprises me why DIVA is running a lot of annual runs, looking at the diva outputs.
First I thought it had to do with the manual-schedule on my windows that it was pairing in a lot of groups. This made my simulation run with 88 annual runs, for 20 hours on medium quality. Then I tried on low quality with automatic shading schedules. Still 70+ annual runs, only 4 hours though.
Now i inputted a list of 1 and 0s for my shading schedules. Still quite long runs.
I just remember some files I've run where it only had a limited number of annual runs.
Why is the simulation split up in so many annual runs, and does it affect simulation time?
Any way to "guess" a progress bar based on how many annual runs are finished?
The number of runs should be related to the number of window groups. But DIVA may also separate grids if it thinks said grids are in different spaces (that is, affected by different shades). This is supposed to be computationally efficient, because you don't waste time testing shades a sensor can't see. No idea what your model looks like, but if there are 22 grids and 100 windows, I suppose it's possible to end up with 70+ runs. Unfortunately there's no good progress bar for this (other than looking at how many runs have finished).
You could force simplicity by consolidating window or grid surfaces, and see if this changes run times. Surfaces that touch can be joined, and even those that don't can be appended to each other with a scripting component:
DIVA will always treat a single brep as a single grid or window.
Thanks for the answer, clarified a lot for me!
I did have a big zone of open office and several cell offices. The grids for the cell offices covered 4 offices per grid, so you have a point here with the automatic split up.
I ended up running a run for each of the similair-ish zones to define schedules and then applied them to all of the windows in each orientation speeding up the second run.
In the end i had all but one of the runs finished and the last one took quite long time, relatively. I could see in the task manager that in the end i was only running rtrace on one core. Could there be some optimizing in how it splits up in cores in order to use them all effecient. (an idea could be if only one run was remaining, the remaining (7?) cores could try and pick up the same run and pass it in speed).
The append function looks very neat - we have facade elements with two glass parts in each, should be possible to append them two and two.
Is it possible to do the append through grasshopper for all items in same tree branch etc?
Something like this in a c# component should convert a list of breps into one (and would therefore also work on trees):
Brep b = breps; // first brep in list
for (int i = 1; i < breps.Count; i++) // loop through rest of list
b.Append(breps[i]); // append
A = b; // set output
It's true that the longest running process will be left hanging on a single thread. Dividing sensors (or direct sources, as DIVA does) can speed things up slightly, but the gains are pretty minimal due to the way DAYSIM works. In any case, we are dropping DAYSIM in favor of rcontrib soon, so my tinkering motivation is admittedly low. :)
Thanks a lot, that's great news!
Are you thinking of integrating some of the accelerad parts of rcontrib?