Receiver Raytracing

[kalebphipps]

Is your feature request related to a problem? Please describe.
ARTIST currently scatters rays from the Heliostat surface. For example, one "ideal" ray is reflected from each point on the heliostat surface, and these rays are then "scattered" based on reasonable distortions given the light source model. This approach has some advantages but also makes effects such as shading and blocking difficult to model since it is not a full raytracing approach.

Describe the solution you'd like
To increase the flexibility of ARTIST we should allow multiple raytracing options. Since the vast majority of rays sent from the sun will not meet the receiver (or even the heliostat), we should also implement a Receiver-Raytracing I.e. we send the rays out from the receiver to reflect off the heliostats and then towards the sun. This will enable:

• Shading via masks between the heliostat and the sun.
• Blocking -- since we know the positions of the heliostats from the receiver.
• Possibly more efficient -- each point on the receiver can be considered data parallel.

Describe alternatives you've considered
We considered traditional raytracing, which involves many rays being sent from the sun. However, this will be too computationally expensive, and insufficient rays will reach the receiver.

Technical details
Raytracing should be implemented separately from the field. Once the traced ray realises there are no objects between it and the light source (i.e., no more clouds or blockages), it should call on the sun to calculate the deposit strength responsible for generating the final bitmap. In this way, the raytracing is completely modular from the light source, and different light sources can be modelled separately.
Furthermore, each pixel on the receiver should send our rays as a torch.Dataset. This will enable data parallel computation.

Additional context
This raytracing will be implemented in addition to Heliostat-Raytracin and is not (yet) designed to replace the current method.