Hi,
We are looking at ways to speed up our Radiance simulations. We are calculating the irradiation at pre-defined positions in space, in an application related to photovoltaics (similar to bifacial_radiance).
Our simulation has the following characteristics:
Thousands of sensors in each rtrace execution, for each scene.
Multiple rtrace processes running concurrently, with each process simulating a different scene.
So far, we have been able to accelerate the simulation time with the following changes:
We changed the definition of the geometries in the scene from a meshes (.rtm) to a list of triangles (polygon primitive). We tried this after reading this post.
We tuned the rtrace parameters to our desired precision where any further changes yield poor results in terms of accuracy.
We have reduced the number of sensors to the minimum we need.
We communicate the inputs/outputs of rtrace throught streams with the data in binary (-fdd rtrace parameter).
We would like to know if:
Are there any other known optimizations which we could further use to improve the simulation time?
We observed a quite suboptimal speedup scaling when running multiple rtrace processes each with a different scene (e.g. 8 concurrent processes had a less than 4 speedup rate) when running them in Windows (we will try it on Linux in the future). Could there be some interference between the different processes that affects their speed?
We run an annual simulation where the geometry and sensors’ position/direction can change between intervals. Is there a way to do an annual simulation for this use that doesn’t involve running a rtrace for each interval?
This seems like a good use case for Accelerad if you have a compatible graphics card. Note only that Accelerad doesn’t support running multiple concurrent processes because it manages concurrence internally.
You should get a linear speed-up so long as you really have as many cores as you have processes, the processes are not running out of memory on your hardware, and there are no serious competing processes. That said, I don’t know what kind of overhead Windows imposes on parallel processes.
Could you be more specific in your final question about changes between intervals? An annual simulation often employs a matrix method, perhaps using rfluxmtx or rsensor and rcontrib, but the scene geometry cannot change over the course of the year. Or, you need to rerun the ray tracing for each geometric configuration.
Thank you for your response. It’s great to know it’s possible to get a linear speed up. When we did some analysis to study the scaling we didn’t see any resource running low: we have 20 cores when running 8 rtrace processes and the system had multiple GBs of heap memory available at any point of the execution. Knowing this we will do other tests to narrow the possible causes.
Regarding my last question, it refers to sun-tracking structures, which are used in most PV plants. Each structure moves independently, and their precise position at each interval is non trivial. That means that the geometry configuration in each interval is most likely unique through the year, and our sensors are positioned on top of these moving structures.
Ah, OK. I was afraid that might be the case. If you have a PV tracking system and the neighboring structures affect what the sensor sees (not just its orientation), then you do need to redo the calculations at each distinct positioning. You could discretize the positions using a subsampled matrix of tilt and azimuths based on time of day & year, and slightly reduce the number of calculations needed that way, but I’m not sure the added complexity woud be worth the gains.
On the other hand, if your solar farm is simple, like an array of tiltable panels, you could probably ignore the movement of the panels themselves and focus instead on aggregating your senors by computing low-resolution fisheye images and compute from these irradiance for different orientations as a post-process. I would have to understand the nature and variety of your layouts, and you would have to run some tests to ensure that your approximations were within the desired tolerances.
It seemed like depending on the configuration of Accelerad rtrace, we got big differences in irradiance results compared to Radiance, up to 90% less (this was the dealbreaker for us).
Our intended use is to do automatic simulations where the plant layout is an input. We can’t manually validate every result, and we need very consistent results. The other major cause was that Accelerad doesn’t seem to be maintened regularly.
When we studied Accelerad, we did observe much better execution times than Radiance, and this was very encouraging for us. However, because of the issues described above, we had to discard it as an option at that time.
What are your thoughts about these issues? Particularly, we are interested in understanding the large difference in results we observed. It may have been a parameter configuration issue but we are not sure if there is a set of parameters that would work for any arbitrary scene.
Thank you very much for the suggestion to use a subsampling matrix. We did consider it at the beginning, but we discarded it for the same reasons you mention. It adds complexity, and the potential gains didn’t seem to be worth it. Additionally, it would have been an additional source of calculation error we would have had to study and validate.
We don’t fully understand your suggestion in the second paragraph, but based on the complexity of our layouts it doesn’t seem like it would work. Our layouts have complex terrain features, as well as multiple orientations per interval. We are also calculating the irradiation on the back-face of the panels, so the ground reflections matter. Additionally, we require to know the position of the shades in the front face (we also do this using a rtrace process with -ab 0 pointing to the sun and checking which rays from a grid reach the sun). Hopefully this information will shed some light on the challenges we are facing.
I agree with @Taoning_Wang1’s suggestion that the ambient cache may be your issue. Turning it off using -aa 0 will usually reduce discrepancies between Accelerad and Radiance. Some other things to look at are the way you have set up the light sources in your model and the distance to origin. I think the mesh in your post the the Accelerad forum was a bit of a red herring, because the mesh appeared to be shaped correctly and the problems seemed to be with the way it was lit, but there was not enough information in your post to perform any sort of debugging.