Variance in Calculation times

old forum
1

Hi all,

I discovered something that doesn’t make sense to me. I was messing around with the Number of CPU’s for an annual daylight simulation, and I found that 8 CPU’s took longer to calculate than 4 CPU’s. This doesn’t make sense to me. I tried closing out of rhino and grasshopper and opening it up. When I opened grasshopper, I selected my weather file, and it took about 1-2 minutes to calculate. This is what I found weird. When I calculated it again, with the same number of CPU’s, it took much longer to calculate (~20-30 minutes). This is worrisome for me because I am using Ladybug/Honeybee for my grad project to optimize daylight delivery in a space. Therefore, I will be doing thousands of simulations.

What am I doing wrong? Is there a way to keep the calculations to 1-2 minutes? Why did I experience this phenomena?

I have uploaded the grasshopper file and rhino file.

Thanks,

Geof

Parameteric Model.gh (725 KB)
SOO Model.3dm (613 KB)

2

Hi Geof,

There are two separate topics here:

  1. How is it possible that using 8 CPUs take longer than 4 CPUs?

Well this is possible if you know how Radiance really works. I remember that Rob wrote a very nice short post about this which I can’t find right now. I will ask him and if he couldn’t find the link then I will rewrite it here. What you’re doing is the right approach to find the optimum number of CPU’s for your case.

  1. Why running the same analysis for the second time with Daysim takes much longer than the first time?

Well, this should not happen. I have been told about this another time too but I couldn’t recreate the issue. I will test your file and let you know the results. This is something that we can definitely fix.

Mostapha

3

Mostapha,

Thanks for the quick response. There’s another wrinkle in this problem. I started creating my script for a MOO algorithm, and I tested this on this new script that utilized the previous script. This time I found:

  1. 8 CPUs takes a few seconds longer than 4 CPUs.

  2. The first analysis took about 1 minute or so, whereas the 2nd and 3rd attempt took little more than 2 minutes.

I don’t understand why, but I thought I would update you. When I was first learning Ladybug/Honeybee, I repeated analyses without much discrepancy in duration. So I’m not sure what is different about my first script.

If you could still look at my original script to see if you can reproduce the results, I would appreciate it. Additionally, if you notice that the script is inefficient, I’d appreciate input. Thanks.

Geof

4

Geof,

  1. The problem is solved. Honeybee has an internal extra check for daylighting analysis to make sure the radiance parameters are set to minimum for any grid based analysis. The first analysis was passing this extra check and because of that it was running faster. It doesn’t mean that the first analysis is totally wrong as it depends on the analysis case and should be checked and optimized before running the final analysis.

You can read more about radiance parameters here (http://radsite.lbl.gov/radiance/refer/Notes/rpict_options.html), and here (http://radiance-online.org/community/workshops/2011-berkeley-ca/pre…). Since you have a light-shelf I suggest you to add to the number of ambient bounces (ab).

Now back to your wish to have the analysis run faster you can comment the line hb_writeRADAUX.checkInputParametersForGridBasedAnalysis() inside Honeybee_runDaylightSimulation and it won’t overwrite the initial values but make sure that you run a number of test cases and compare the results between the runs.

Back to your definition, it looks good to me. You could have saved yourself some time by using MassToZone component and then just adding the ceiling separately but there’s nothing wrong with your approach.

The main place in the definition that can change is how you’re generating the vertical fins. I imagine you can use a single set of components to generate every group of the fins but again your definition will work.

I updated your file to the latest version, which means you also need to update Honeybee and Ladybug in case you’re looking to modify the file.

Hope it helps,

Mostapha

ParametericModel_updated.gh (760 KB)

5

Mostapha,

Thanks for the help and looking at the problem. Just a couple of things.

  1. To update Honeybee and Ladybug, I just need to open that grasshopper file, correct? I assume I’ll need to close out of grasshopper and rhino for it to go into affect, right?

  2. You mentioned I could comment the line **hb_writeRADAUX.checkInputParametersForGridBasedAnalysis(). **What does that exactly mean and how do I do that?

  3. It appeared that I was getting the same result for both tests. So if that’s the case, I would do number 2 to skip the extra check. Is that correct?

Thanks,

Geof

6

  1. Correct!

  2. Double click on Run Daylight Simulation component. Find the line and add # in front of the line or simply remove it! Then close the editor and save the changes.

  3. Yes. But you always want to test your model first with a very higher quality and then compare the results against that. This means for the reference run the analysis for one of your complex options with setting Radiance Parameters to a high or medium quality-which will take so long. Then compare the results with a lower quality with that model as the reference.

Attached is the answer to your initial question about the number of CPUs. Rob was nice enough to send me the file until he gets the website fixed.

rtrace multiprocessing option - initial test results _ rumblestrip.pdf (310 KB)