HB Daylight factor not giving uniform results

grasshopper honeybee-legacy
#1

Hi all,

First of all, thank you for being such a supportive forum. I need some help to understand what’s going on with my daylight factor analysis and I hope this is the right place to ask.

I created some uniform boxes with a simple window on them, and ran a HB daylight factor analysis in different directions. What strikes me is that these results vary in the different directions, regardless whether I choose uniform or cloudy sky. I would expect them to be equal in every direction - can someone explain why they are not?

I know daylight factor shouldn’t depend on the weather file, but if this has something to do with the default one that is set, can I somehow change it to my own?

Attached are some images of my output and a snippet of my code.

image
image.png881×755 59.1 KB
Ladybug_code
Ladybug_code.PNG819×484 58.9 KB
Ladybug_uniformSky
Ladybug_uniformSky.PNG762×763 56.2 KB

#2

Hi Liv,

It will be difficult for us to help you with this issue without being able to test your file locally and reproduce the error. Please refer to the forum guidelines and post your file :slight_smile:

From the get go I can suspect 1 thing: raytracing has a probabilistic sampling element to it I think and therefore the variations you see could be very slight variations due to that. Can’t confirm this without seeing your file or having a scale beside your pretty mesh though :slight_smile:

#3

Sorry Antoine - a bit too fast sending it off there.
GH file attached.

181025_windows_testFile.gh (105.7 KB)

#4

ps: currently at work on a mac without Rhino so won’t be able to test until this evening maybe. If anyone else is reading this please get involved! Also @sarith any wisdom to add here?

#5

@AntoineDao This should be the case:

@liv.andersson Do you see any improvements in the results if you set the following parameters -aa 0.1 -ad 2048 -ar 1024 ? You can set these through the radParameters component. They will likely make the calculation run for a longer period of time.

1 Like
#6

@sarith I do indeed! Not only is it the output smoother, but all the different directions also produce the same results, as I’d expect them to do. Thank you for your help.

If I understood it correctly, this is due to a simplification in the original run?

#7

Nice one glad that worked out. Mind marking this issue as resolved for others to use it as a reference in the future? Ladybug Tools Forum Guidelines :slight_smile:

In essence yes. Here’s a quick explanation of the parameters @sarith asked you to change:

-ar res   Set the ambient resolution to res. This number will determine the maximum density of ambient values used in interpolation. Error will start to increase on surfaces spaced closer than the scene size divided by the ambient resolution. The maximum ambient value density is the scene size times the ambient accuracy (see the −aa option below) divided by the ambient resolution. The scene size can be determined using getinfo(1) with the −d option on the input octree.
-aa acc   Set the ambient accuracy to acc. This value will approximately equal the error from indirect illuminance interpolation. A value of zero implies no interpolation.
-ad N     Set the number of ambient divisions to N. The error in the Monte Carlo calculation of indirect illuminance will be inversely proportional to the square root of this number. A value of zero implies no indirect calculation.

For more info I’d strongly reccomend reading through radiance documenation, the one for rtrace parameters can be found here