Issue with the number of CPU workers on a Grid Based Analysis on LB 1.4

brenoveiga · January 19, 2022, 5:01pm

Hello!

I’m running a point-in-time grid based analysis with LB 1.4.
I ran the same simulation twice, with the same Radiance parameters, but with different numbers of CPU workers (1 and 8).

I noticed that, when I increase the number of CPU workers to 8, some failures appear in the mesh analysis. This problem doesn’t happen when I use only 1 CPU.
I believe this has something to do with the way that LB splits the analysis grid between each CPU worker, but I’m not sure how to get around this issue.

mostapha · January 20, 2022, 4:11am

Hi @brenoveiga, any chance that you can share your model with us so we can recreate the issue. You can share it privately by sending a private message or via an email.

If this is a bug we should fix it as soon as possible since it potentially affects all the Radiance-based recipes.

cc: @chris

brenoveiga · January 20, 2022, 6:43pm

Hi @mostapha
I have sent you an email with our model.
Thanks!

chris · January 21, 2022, 3:18pm

Hey @brenoveiga

With your file, I was able to recreate some of the lines that you are seeing between the grid subdivision:

However, they are a bit different from yours and I am pretty sure that this is because we are just seeing the stochastic behavior of Radiance’s ambient divisions here. Specifically, you are seeing a different set of randomly-generated divisions for each of the grid subdivisions because your Radiance parameters are not suited for this huge scene that is several orders of magnitude larger than the details of the floor you are studying.

So it seems that your large scene and your custom Radiance parameters are largely to blame here.

Unless you really know what each and every radiance parameter does, I would recommend not trying to change all of them like this:

There’s a good reason why we included the HB Radiance Parameter component to give you recommendations because even the most advanced Radiance gurus usually don’t know what all of them do.

Also, there’s a lot to be said about just simulating the things that you care about and not dumping hundreds of thousands of polygons into your Radiance model just because you can.

mostapha · January 21, 2022, 8:32pm

Thank you @chris for testing the model.

@brenoveiga, this is a more visual example of why you see this effect for a view-based simulation.

chris · January 24, 2022, 6:24pm

I just wanted to make a couple of corrections to my previous answer:

I know that I mentioned “ambient divisions” a lot in my previous post but it seems that the really relevant parameters in this case are ambient resolution (-ar) and ambient accuracy (-aa). Particularly when you’re jumping scales from super blocks of skyscrapers down to door handles, the value that you use for -ar should be computed using the relationship between the bounding box dimensions of the whole scene and the smallest detail of your model that you need to resolve.

In Legacy, we had a separate component to help you compute this since the HB Radiance Parameter component doesn’t know anything about the geometry you are trying to simulate (or the scales that its jumping across). So I decided that we should bring this component into the LBT plugin and I just merged it into the development version of the plugin:

It’s called “HB Ambient Resolution” and you can find it under the 3::Recipes tab:

When I set the ambient resolution properly using this component, the lines between the grid subdivision disappear:

brenoveiga · January 27, 2022, 2:50pm

Thank you @chris for testing our model!

We set the Radiance Parameters this way, due to the long processing time it takes to perform the analysis, since the geometry of our models, comes from Archicad and has a large number of polygons. We are still trying to figure it out the best way to exchage the geometry from Archicad to Rhino, so far we are doing via an .obj file.

Also, those Radiance parameters were set with an old version of our code, which used HB+ and Rhino 5, and back then, the results were quite consistent, and we didn’t have these grid subdivision lines. If I’m not mistaken, it wasn’t possible to use more than one CPU core in a grid point analysis with HB+, maybe that’s why we didn’t have this issue.

I did some testing with the HB Radiance Parameter, together with the Ambient Resolution Parameter. Thanks for this add to LBT 1.4 Chris!

My results were a bit different than yours, maybe because of the stochastic behavior of Radiance’s ambient divisions.
I can still see a thin line, on the grid, though much more smoother than my previous post. The problem here is the time of processing, it took 8 hours to complete, using detail level set to 2 on HB Radiance Parameter, and the same settings as yours for HB Ambient Resolution.
Wich gave me the following parameters:

-ab 6-ad 4096-as 4096-ar 416-aa 0.05-dj 0.7-ds 0.5-dr 0-dp 512-st 0.85-lr 12-lw 0.005-ss 0-n 8

@chris, when you tested our file, how long did it take to complete the analysis?

When I test the same file with only one CPU core, and smaller values for Radiance parameters (-ab 6-ad 1024-as 256-ar 150-aa 0.05 -n 1), the analysis mesh gets a little jagged, but the illuminance levels at the central point of the room is not very different - which is the most important result for us.
The biggest benefit is that this second analysis took 37 minutes to complete, and the subdividion lines disappears.

I would like to ask then, when is it really worth increasing the amount of CPU cores in a grid based analysis on LBT?
Correct me if I’m wrong, if I increase the amount of CPU cores I, invariably, have to increase the values for the Radiance Parameters also. Consequently, my analysis will take longer, unless I increase the amount of CPU cores to a very high number.
Perhaps this statement only works for cases similar to mine, where the model has too many polygons and the scene is very large.

Mathiassn · January 27, 2022, 6:05pm

well that’s not entirely true. Your simulation is more inaccurate with worse parameters, even on one core. You just don’t “see” the differences that much, as they arent placed next to each other 1:1.

However I would advice you to maybe split up this building in several simulation grids, one per room and split them in the door. Then eventual differences will be seen in the door thresholds and not crossing a room.

OlivierDambron · January 28, 2022, 12:05pm

@brenoveiga

I second @Mathiassn on the importance of the parameters. Showing colors is easy, but coming closer to more reliable/realistic results is why we are all here.

from your screenshots, considering the same highbound, its hard to say whether the case run with only 1 CPU does not reproduce the error. It’s all red so the line can’t be seen.

I would triple check the way you modelled the geometry. Sometimes when some walls are poorly modelled or have weird shapes, the meshing of HB gets confused and can deform the geometry simulated. To check you can use the HB Visualize components on grasshopper :

fatalay · November 25, 2022, 12:23am

Hello,
I was searching the forum about Daylight factor and PITGrid. In fact, when I run the simulation again after creating the model for both analyses, I am investigating the reason for the changed results. I learned that in order for this change to be at a minimum level, HB Radiance Parameter adjustment should be made from a different subject. Lastly, I entered the HB Ambient Resolution values in this post. Honeybee model is valid. However, I still get around 5% different results. Is this margin of variability something that should be accepted?

Can you help me understand this?

chris · January 11, 2023, 3:03pm

The amount of error that is “not wrong enough to be useful” is up to you but I think most people consider 5% to be pretty high. Most production-quality Radiance simulations that I run have an error below 1% so you may want to increase your parameters a little higher. The most relevant ones for PIT grid-based are -ab -aa -ad -ar.