Question about validation of electric lighting simulation in Radiance

That eliminates interpolation and measurement errors as a possible cause of the discrepancy. Over to Greg, I think.

Well, it doesn’t eliminate photometry measurement errors, entirely. The measurement of two planes could be neglecting some asymmetry in the luminaire distribution where the output at 45° and 135° is slightly lower.

However, it does seem likely to be a calculation shortfall, especially since it’s on the order of a few percent. Did you try a different -av setting, or change the other parameters as I suggested?

Hello Greg,

Thank you for the suggestions. I tried them out and got the best match by setting -av 2.8 2.8 2.8 in the scene. Here, the maximum error was just 2% in the problematic points.

Setting -ab to 9 improved the results only by a little and setting -aa to 0 (with -lr -10) actually created a larger discrepancy. For each of the options, I had to assign a new candela multiplier that I found by matching the simulated illuminance to the measured illuminance at point 1 (center). Here is the comparison:

“New options” refers to the options that you recommended (-dp 64 -ds .1 -dt .05 -dc .25 -dr 2 -st .03 -lw 1e-4 -ab 5 -ad 4096 -as 1024 -ar 32 -aa 0.15). And here is a closer look at the graph:

Best,

Rita

1 Like

OK, this is good. Once you’re within 2% or so, you are about as close as you are going to get with photometric data, especially given the other uncertainties about the room materials.

It is not surprising that the -av setting makes such a difference. If we only add in 5 interreflections, an 85% spherical enclosure would still have about 38% of its energy left. Your enclosure is not spherical, so this estimate is high, but it just points out that there’s a lot of light bouncing around, and the easiest way to account for it is a good estimate of the remainder.

Of course, it is unacceptable to tweak your -av setting until the measurements agree, as the calculation needs to be a useful predictor, not just a reproduction of what you already know. Therefore, I usually recommend setting -av based on the average scene radiance from a -ab 0 calculation, which is usually close enough. You can do this by generating a “-dv- -ab 0” fisheye image of your interior, then running:

pvalue -h -H -o -df image.hdr | total -if -m

The -dv- turns off light source visibility, which is very important as you don’t want to average the direct portion of the calculation.

I should add that the rarely-used -aw option is a reasonable way to automatically set the ambient value to the average for electrically-lit enclosed scenes such as this one. A setting of -aw 8 should work well in your case, even with -av 0 0 0.

Hi Greg,

sorry for the delay, I just got to test out your recent suggestion (-aw 8) and thought to post it here. In this option, the illuminance on the vertical points is overestimated in comparison to the other options and the measurements.

Best regards,

Rita

Hi Rita,

Interesting. Thanks for trying it. The -aw setting has never lived up to my expectations. I should have had you set a -av value on the low side (say -av 0.5 0.5 0.5) with -aw. That might have helped, so too might a larger setting. If you feel like trying “-av .5 .5 .5 -aw 64”, I’d be curious if that works better.

Meanwhile, I’m going to think about the -aw implementation and try to improve on it. This is very helpful!

Cheers,
-Greg

I have tried “-av .5 .5 .5 -aw 64” but it turned out slightly worse than without these options at all (compare with “new options” line).

Then I also tried “-av .5 .5 .5 -aw 32” and “-av .5 .5 .5 -aw 8” for a quick sensitivity check, but that did not bring much of a change. I think the improvement is coming from adjusting -av option.

Best,

Rita

OK, thanks for testing it. That’s different from what I was expecting to see, meaning that the setting of -aw is more sensitive than I thought. Interesting.

Hi Rita,

Your results prompted me to investigate the behavior of the -aw option further, and I think I’ve come up with an improvement to its performance that avoids the “sea level rise” which results in overestimation when the averaged ambient value feeds back on itself. So, this has been very helpful for me.

If you want to try the new -aw behavior, it should get compiled into a new HEAD distribution over the weekend, which shows up on our github site. You can try “-aw 0 -av 0 0 0” with the new version.

Thanks,
-Greg

Hi Greg,

glad to hear this! This is interesting. I will try out the new version and post my results here next week.

Best,

Rita

1 Like

Hello Greg,

as promised here is the update:

There was just a small difference between the new and old -aw 64 -av 0.5 0.5 0.5 (old version is not in this figure but I posted it here previously).

I used the following options, are they still correct for this case?
-I -h -dp 64 -ds .1 -dt .05 -dc .25 -dr 2 -st .03 -lw 1e-4 -ab 5 -ad 4096 -as 1024 -ar 32 -aa 0.15 -aw 0 -av 0 0 0

Best,

Rita

Hi Rita,

I’m so sorry – I mistyped the options to try out the new code. It should have been “-aw 1 -av 0 0 0”. Using “-aw 0” turns the function off, which is the default. My apologies!

-Greg

Hi Greg,

no problem, I should have noticed that also. Here are the new result. It looks good on the horizontal points (1-5), but the error is greater on the vertical (especially corner) points. I should mention that the maximum error is 7% is on the vertical plane. That being said, what is the acceptable percentage deviation for validation of electrical light and also daylight?

Best,

Rita

Hi Rita,

Thanks – you can’t be blamed for doing what I asked you to do! However, I would have expected more of a difference with the new change. What does “rtrace -version” tell you? I just want to make sure you’re actually executing with the new code.

My general rule of thumb is that <= 5% error is good for electric lighting, and <= 20% is good for daylighting based on the usual conditions (i.e., unmeasured sky and surroundings).

Cheers,
-Greg

Hello Greg,

This is the version that I am using: RADIANCE 5.4a 2021-11-21 LBNL (5.4.e71c3c6cc6), should be the correct one, right?

I am currently also working on the daylight validation and had a higher error than with the electric lighting but still within the above mentioned limit. Thanks for the good news.

Best,

Rita

Yes, it seems you are running with the new changes. Interesting. Well, at least -aw isn’t over-estimating any longer, which was a bigger problem.

Cheers,
-Greg