search

nljones / Accelerad

Accelerad is a free suite of GPU-enabled programs for lighting and daylighting analysis and visualization.
https://nljones.github.io/Accelerad/
Other
51 stars 10 forks source link

rfluxmtx with GPU ignores shading polygon when coordinates are far from the origin #4

Closed aschils closed 3 years ago

aschils commented 3 years ago

Hi,

First thank you for having developed this very useful faster version of radiance.

I am using an accelerad version compiled from the github source the 18/12/2019, therefore a version more recent than the last binary release but not containing changes on the github code since then. My system runs Linux. I write here to report what I think might be a bug when using accelerad-rfluxmtx with GPU (no bug when disabling GPU and falling back to classic CPU radiance).

rfluxmtx seems to ignore a shading polygon (I tested both with plastic and highly reflective glass) located between the light source and the point of interest only when the coordinates of the simulated geometry are far from the origin (i.e. it does not happen when the coordinates of the geometry are close to (0,0,z) but it happens in my case for geometries with coordinates, for example, around (x=4.5 10^6, y=6 10^6, z=6)). In this case, CPU-rfluxmtx yields close to 0 irradiance like expected (big shading plastic polygon in front of the point) , while GPU-rfluxmtx yields irradiances close to the global horizontal irradiance (in my case 800W/m² which is physically not possible).

Thanks, Arnaud

nljones commented 3 years ago

Hi Arnaud,

I would have to run an example to be sure, but it may be an issue with floating point precision. As noted in the documentation, the GPU uses singe-precision floating point arithmetic, whereas CPU Radiance uses double precision. As a result, some inaccuracy is to be expected for surfaces very far from the origin.

aschils commented 3 years ago

Hi Nathaniel,

Thank you for this quick answer. It would make sense wrt what we observed: errors seem to appear outside a circle having its center located at (0,0,0) and with a radius in the 100m order of magnitude. I checked the documentation a few times in the past, cannot believe I missed that point, sorry for that... Since dimension along one axis of what we simulate can be larger than 200m (like max 10km in extreme cases), do you think that expressing our coordinates in for example 10**2 m would be a good solution?

Thank you, Arnaud

nljones commented 3 years ago

Hi Arnaud,

Accelerad avoids floating-point error at the small end of the scale spectrum by applying a 1e-4 epsilon to many distance calculations. Since single-precision floating point arithmetic gives you about 6 significant figures, 1e2 is roughly the largest reliable distance, beyond which epsilon fails to have the desired effect. Scaling your model to fit within a 100 m bubble could solve your problem at distance, but may possibly introduce problems if distances between surfaces elsewhere become less than 1e-4 m.

aschils commented 3 years ago

Great, it should work for our use case then. Thank you again for these useful hints, Arnaud