Different results radiandance vs. accelerad using RTRACE

[Peutz Data]

Hi,

I want to use accelerad for our daylight software using rtrace.

Unfortunately, I am finding large differences between radiance and accelerad calculations using rtrace with a simple standard room.

Setup:

·         Thinkstation Win 11, GPU NVIDIA RTX A4000

·         Accelerad 0.7 beta

·         Radiance 5.4a (4/12/2022)

Room (square)                                                10 x 10 x 3 m (lxwxh)

6 windows on 3 sides of the room           1 X 2 m (wxh)  

rtrace -I -h -ab 5 -aa .08 -ar 512 -ad 2048 -as 512 test1.oct < test1.pts | rcalc -e $1=0.474*$1+1.20*$2+0.116*$3 >> test1.res

Contourplots on a rectangular grid with celsize : 0.05 m

Both calculations (radiance and accelerad) are ok, without error messages in the console.

Any ideas,

regards, Jur

[Nathaniel Jones]

Hi Jur,

It looks like you need to specify a larger irradiance cache size. Unlike Radiance, which uses a dynamically sized cache, the parallel structure of Accelerad requires that the cache size be specified in advance. As a starting value, you could set the irradiance cache size -ac to the number of sensor points. Alternatively, you could specify -aa 0 to turn off irradiance caching. You can find out more in the Accelerad documentation.

Nathaniel

[Peutz Data]

Hi Nathaniel,

Thanks for the suggestions. I did some calculations with a larger cache size (equal to the no. of sensor points 200 x 200).

I: Radiance rtrace.exe   -ab 5                     -aa 0.08 -ar 512 -ad 2048 -as 512    (result Dfmean = 2.15)

II: Radiance rtrace.exe   -ab 5                     -aa 0      -ar 512 -ad 2048 -as 512   

III: Accelerad_rtrace.exe  -ab 5 -ac 40000 -aa 0.08 -ar 512 -ad 2048 -as 512    (result Dfmean = 1.81)

IV: Accelerad_rtrace.exe  -ab 5                   -aa 0.0 -ar 512 -ad 2048 -as 512   

With -aa - 0 the results seem unrealistic, for both Radiance and Accelerad. 

With the larger cache (-ac ), the results with Accelerad are much better, but I find significantly lower values with accelerad  compared to radiance for the mean Daylight factor on the surface.

BTW, the calculation speed of Accelerad with these settings is much lower than the corresponding Radiance calculation. I wonder what will happen if I use even larger -ac values.

PS: I find that Accelerad sometimes gives triangulation errors (and subsequently wrong results) where Radiance gives no errors and correct results with the same input file.

Is there some limit in Accelerad (eg the minimum size of objects, closeness to other objects, ..)?

Thanks for any help,

regards, Jur

[Nathaniel Jones]

Hi Jur,

The difference between your -aa 0.08 simulations could arise from having -ar too large. One option would be to set a smaller -ar with a larger -aa to prevent the run time from increasing too much.

Do you have measurements to compare your simulation results to? Irradiance caching is a biased algorithm, so I would not immediately assume that the Radiance result is more accurate. Accelerad's built-in overture pass generally increases its reliability compared to Radiance.

For your -aa 0 results, it looks like you are using the default -lw value of 2e-3. This is probably too large, which would cause you to calculate a lower daylight factor. I recommend setting -lw to less than 1/ad, so no more than 4e-4 in your case.

Regarding triangulation, Accelerad does require that each polygon has a consistent winding direction. In Radiance, some programs also require consistent winding direction, but most do not. This mainly affects polygons that contain internal holes. Most geometry export tools wind polygons correctly, but there are a few such as su2rad which do not. If you are creating your .rad files with an export tool that does not wind polygons correctly, then the solution is to mesh them before exporting.

Radiance and Accelerad also both have limits on the size and closeness of objects due to their use of floating point precision, though their limits are different. This should not affect you unless your model is located very far from the coordinate system origin.

Nathaniel