# Computer Modelling of Heliostat Fields by Ray-Tracing Techniques: Simulating the Sun
## 4 Computational Details  
We implemented the algorithms developed by the astronomy community and reported by [PERSON] [22] and [PERSON] [23] as a list of 33 small functions, that can be called and combined to provide a variety of different functionalities. The code is organized as a small library, in a single file, and only a single call is needed to calculate the Sun's position, allowing easy implementations as standalone or graphic interface applications. The code was written in the C programming language, to maximize efficiency, and is integrated into our Light Analysis Modelling (LAM) computer package, to allow easy modelling of a wide range of concentrated solar facilities. The code amounts to 860 lines, including comments and all the inverse functions, implemented, tested, but not specifically used in this particular application (inverse functions are, for example, functions to calculate mean anomaly from eccentric anomaly, or equatorial coordinates from horizon coordinates, that are not needed to calculate the Sun's position). A stripped-down version, with only the essential code, amounts to 360 lines.  
To study heliostat fields in general, several choices must be made that are related with to the Sun's trajectory during the year:  
1. We need to set the location of the heliostat field, as latitude plays a significant role in determining the Sun's trajectory over the local site throughout the year. For this work we selected the two locations with the highest and lowest latitude from the list reported by SFERA-III [21] for European Union CSP research infrastructures with heliostat fields: Julich, Germany (latitude = +50.9133\({}^{\circ}\), longitude = +6.3878\({}^{\circ}\)) and Protaras, Cyprus (latitude = +35.0125\({}^{\circ}\), longitude = +34.0583\({}^{\circ}\)). This 15\({}^{\circ}\) difference in latitude between the two locations is enough to produce insightful changes between the two sets of results.
2. Regarding the working conditions, it seems logical to scan the heliostat field for a full year, from 1 January to 31 December, say 2024. But what should the daily working range be? We choose the schedule from 08:00 to 16:00 in LCT time. This depends on date and latitude but for most common places it seems a reasonable choice. As we will show later, the optimized working range also depends on the longitude of the heliostat field. We note that throughout this work we always ignore Daylight Saving Time (DST) and other purely administrative, political, changes to standard local time.
3. What should the scanning frequency of the Sun's position be? Every hour seems a good compromise, to detect blocking and shading events, as the danger of losing significant events seems small and the needed computing time is not impossibly high (for this particular task, using 10\({}^{6}\) rays is acceptable, as we are not attempting to create a very accurate image of the radiation on the target, we are only checking for interception events). However, to have an accurate measurement of the total mechanical rotations needed and the maximum mechanical angles achieved, we need to recalculate the Sun's position and the heliostat positions at least every minute (no time-consuming ray tracing is involved, as we only need to orientate the heliostats). We studied this important aspect, throughout the year, for [PERSON] and [PERSON], to assert what should the scanning frequency of the Sun's position be. The astronomy algorithm takes less than a millisecond to calculate the Sun's position, so computing time is not an issue here.