INTRODUCTION

The test case under consideration consists of the ASTRI heliostat field which is the heliostat field of the solar tower power plant considered as reference within the Australian Solar Thermal Research Initiative (ASTRI). The ASTRI reference plant is a typical two tank molten salt solar tower plant with a gross capacity of 111 MWe, a net capacity of 100 MWe, four hours of thermal storage and solar multiple of 1.8, which is located in Alice Springs (latitude:-23.8◦North, longitude: 133.88◦East, elevation: 547 m). This heliostat field, shown in Figure 2, is of a surrounded type and it is composed of 6,177 mirrors of 37.21 m2(6.1 m x 6.1 m) each, with a total reflecting area of 222,846 m2. Initially, the reference power plant of ASTRI was designed for 110 MWe and had a receiver of 15 m in diameter and 18.67 m in height. Later on, a 25 MWe was designed based on the initial one, by reducing the dimension linearly by 2 times. In the later case, the receiver had a diameter of 7.5m and a height of 9.335m. The results shown here refer to the annual simulation of this reference 25 MWe ASTRI field. This heliostat field, shown in Figure 1, is of surrounded type, it is composed of 6177 mirrors of 37.21m2 (6.1m x 6.1m), and it is assumed to be located in Alice Spring, Australia. For this example we will perform annual simulation analysis of the ASTRI heliostat field, following the workflow shown in Figure 1.

Figure 1: Workflow to perform annual FluxTracer simulations

Note: Please request all the relevant files mentioned in this tutorial from [email protected]

ANNUAL SIMULATION POINTS CALCULATION (SUNPATH)

To calculate a set of representative annual simulation points, SunPath is used for the specific location of Alice Spring where the ASTRI heliostat field is located. In total, 50 simulation points representative of the annual performance of the plant are used for this test case.

MONTE CARLO RAY TRACING RUNS (TONATIUH)

The output list of sun-sampling points obtained during the sun-sampling stage is then fed into Tonatiuh, which is responsible for performing the ray-tracing simulations for each point of the annual sun-sampling list. The sun-sampling list is loaded into the scripting editor of Tonatiuh, in which a dedicated script takes over and automatically performs the annual simulation point by point. At this stage of the optimization workflow, Tonatiuh outputs the annual set of rays, which combines all the rays obtained for each simulation point for the heliostat field being investigated. Within Tonatiuh, the different segments that define a ray can be identified based on their interceptions with the surfaces of the solar concentrating system. For this case, the ray segments that are saved for post-processing are those that are reflected by the heliostat field and reach a "virtual" plane that is placed at an appropriate distance over the focal point as shown in Figure 2. Virtual here means that the plane's optical properties are treated so as to allow the rays to pass freely from the light source surface (i.e. the sun) to the heliostat field without changing any of their characteristics, but the reflected rays form the heliostat to the virtual plane are stopped on the latter. The absence of a receiver in the ray-tracing simulations and the addition of the virtual plane, allows obtaining rays from Tonatiuh which are independent of the receiver size and dimensions. Of course, all the heliostats are set to aim at the focal point of the heliostat field, usually located along the vertical center axis of the receiver.

Figure 2. Screen shot of the simulation of the ASTRI heliostat field in Tonatiuh. The white surface on top is the Virtual Roof

For each one of the sun-sampling points, the entire heliostat field of the ASTRI reference plant was simulated in Tonatiuh, with each heliostat aiming at the focal point. As discussed before the scene includes no receiver component but instead includes a virtual surface (a horizontal plane) above the focal point. This virtual plane was placed parallel to the ground and centered along the vertical axis, 20 m above the focal point, ensuring that the rays reflected from the heliostats towards the aiming point will cross the focal region of the heliostat field. The reference center for the configuration (0, 0, 0) m is placed at the center of the tower base and the aiming point coordinate is at (0, 95.0, 0) m. In the details of the simulation, the sunshape selected was the Buie sunshape with a circumsolar ratio (CSR) of 2%. The reflectivity of the heliostats was set to 100% and their slope error distribution was set to normal with a standard deviation of 1.53 mrad. For the ray-tracing simulations, 300 million rays were cast over the entire heliostat field resulting in many millions of rays traversing the region of interest.

In order to automatically run the 50 Tonatiuh simulations, please go trough the following following:

Load a Tonatiuh (.tnh) file containing the ASTRI heliostat field layout scene by clicking the following link: ASTRI_50_field.tnh Load an automation script ASTRI_50_auto_sim.tnhs by clicking the following link: ASTRI_50_auto_sim.tnhs Create a folder for the results and name it for example ASTRI_50_POINTS. Within this folder create 50 sub-folders and name them by the simulation Points order, i.e. Point_1, Point_2 ..... Point_50 as shown in Figure 3.

Figure 3. Screen shot of the generated simulation folder

After downloading the required files, start Tonatiuh software and open the ASTRI_50_field.tnh file. The ASTRI field layout should be loaded along with the Virtual Roof. Press on the Automation tab of Tonatiuh and select the Script Editor as shown in the image above. The Script Editor dialog box should come up. Within the editor, load the ASTRI_50_auto_sim.tnhs. Typically the only thing you have to change here is the mainExportDir path to point to the folder where the sub-folders are located:

var mainExportDir = "C:/Users/k.milidonis/Desktop/FLUX185/ASTRI_50_POINTS";
(Very Important: make sure that the / are forward if using a windows machine)

Press Run. The simulations should now start running and saving the ray data for each simulation Point in the previously created sub-folders.

Figure 4: The scripting editor of Tonatiuh

At this stage of the optimization process, the output of Tonatiuh simulations are ASCII binary ray data files storing the intersection related information of each ray intersecting the heliostats and the virtual plane of the scene. In sequence, these binary files are fed and read by FluxTracer, which then performs various simulations with respect to what user wants to do by selecting the appropriate functionality. Figure 5 shows the generated ray data for one of the simulation points, i.e. Point_7.

Figure 5: The ray content of folder related to simulation Point_7

FLUXTRACER SIMULATIONS

When the ray-tracing simulations are completed, FluxTracer can be set-up and run to perform various kind of analyses. For this example we will use several functionalities of FluxTracer to analyze the radiant field of the concentrated solar radiation around the focal point of the heliostat field during the year.

Finding the minimum bounding box to intersect a given percentage of rays

To minimize the computational effort prior to carry out this analysis, it is essential to select appropriately the dimensions of the region of interest around the focal point of the heliostat field and the number of voxels into which this region is partitioned. One of the functionalities of FluxTracer enables to analyze for every input ray the minimum distance from the focal point to the ray and to sort all the input rays with regard to that distance. By post-processing this information, the user of FluxTracer can compute the radius of the sphere centered on the focal point of the heliostat field needed to intersect a given fraction of rays, and use that information to decide the dimensions to consider. To generate this, the bounding box calculator functionality will be used. In FluxTracer's input xml file, the user needs to use the SphericalReceiver functionality as shown in Figure 6. The corresponding command line for this functionality is line 6 as shown below. It should be noted here that the user can add several functionalities to run at once. As shown in Figure 6, for this case three different functionalities will be run at the same time, the SphericalReceiver, the VoxelTraversal and the SphericalReceiverVoxelized functionalities.

Figure 6: Setting up the required functionalities in FluxTracer

For the this functionality, the user needs to add the following information: <SphericalReceiver center="0., 95., 0." rMin="0." rMax="12." rDivs="50" output="SphericalReceiver.csv"/>

The output of the functionality is a .csv file that contains values relating the interception efficiency with the radius of the receiver. The input above means that FluxTracer will look for a sphere from zero radius to a maximum of 12m, around the focal point center which is 0., 95., 0. In the current case, as shown in Figure 7, 98% of all input rays to FluxTracer will be intersected by a sphere of approximately 4.89 m. For this reason, the region of interest is defined as a cube of 10 m side centered at the focal point of the heliostat field.

Figure 7. Total reflected ray intersection as a function of distance (radius) from the focal point

Voxel Traversal

Based on the findings of the previous calculation, to perform the voxel traversal we will use a bounding box of 10x10x10 m in dimensions. We can the partition this cube into equal size cubic voxels by dividing the cubic region into 120 parts in each of the three orthogonal three-dimensional directions. This is set in the voxel traversal functionality as follows:
<VoxelTraversal cornerMin="-5., -5., 95" cornerMax="5., 5., 100" dimensions="120, 120, 120" output="VoxelTraversal.vtk"/>

Of course, the selected number of voxels should be the result of a sensitivity analysis conducted to determine the maximum voxel size that will provide voxel-insensitive results. Figure 8 shows the results of the voxel traversal functionality, showing contours of normalized annual radiant energy around the focal region of the heliostat field.

Figure 8: Normalized annual energy around the focal region of the field obtained with voxel traversal

Point Analysis

Similarly working, the user can define the parameters for the point analysis functionality as follows: <SphericalReceiverVoxelized center="0., 95., 0." cornerMin="-5, -5, 90" cornerMax="5, 5, 100" dimensions="120, 120, 120" output="SphericalReceiver.vtk"/>

The energy densities associated to the points of shortest distances to the focal point is shown in Figure 9 as obtained from applying the Point Analysis functionality. On the same figure, the cylindrical receiver of the actual ASTRI 25 MWe field is superimposed in actual scale. The results shows how well the point analysis functionality results fits within the actual ASTRI cylindrical receiver. Actually, what is show in Figure 9, is the optimum receiver geometry to intersect 98% of the reflected rays from the heliostat field.

Figure 9: Annual Energy in kWh obtained by the point analysis functionality. The result can be considered as the optimum receiver geometry to intercept 98% of the rays. In fade gray is the actual cylindrical receiver geometry