SOLSTICE(1) General Commands Manual SOLSTICE(1)

solstice — compute the power collected by a concentrated solar plant

solstice [option ...] [file]

solstice -g sub-option[:...] [option ...] [file]

solstice -p sub-option[:...] [option ...] [file]

solstice -r sub-option[:...] [option ...] [file]

solstice computes the total power collected by a concentrated solar plant, as described in the solstice-input(5) file. If the file argument is not provided, the solar plant is read from standard input. To evaluate various efficiencies for each primary reflector, it computes losses due to cosine effect, shadowing and masking, orientation and surface irregularities, materials properties and atmospheric extinction. The efficiency for each one of these effects is subsequently computed for each reflector.

The entities on which computations must be performed are listed in the solstice-receiver(5) file submitted through the -R option. The estimated results follow the solstice-output(5) format and are written to the output file or to the standard output whether the -o output option is defined or not, respectively. Note that the solstice algorithm is based on the Monte-Carlo method, which means that every result is provided with its numerical accuracy.

solstice is designed to efficiently handle complex solar facilities: several reflectors can be specified (planes, conics, cylindro-parabolic, etc.) and positioned in 3D space, with a possibility for 1-axis and 2-axis auto-orientation. Multiple materials can be used, as long as the relevant physical properties are provided. Spectral effects are also taken into account: it is possible to define the spectral distribution of any physical property, including the input solar spectrum and the transmissivity of the atmosphere, at any spectral resolution. Refer to solstice-input(5) for more information.

In addition to the aforementioned computations, solstice provides three other functionalities. The -g option can be used to convert the solstice-input(5) geometries into CAD files. The -p option saves the sampled radiative paths used by the estimates, allowing the user to visualise them externally, which may be a great help to identify a design issue. Finally, the -r option is used to render an image of the submitted solar facility. Note that these three options are mutually exclusive, and once defined, they replace the default solstice behaviour.

All coordinates in solstice follow the right-handed convention.

azimuth,elevation
A sun direction, defined by two angles in degrees. The first one is the azimuthal angle in [0, 360[, and the second one is the elevation in [0, 90]. Each provided sun direction triggers a new computation whose results are concatenated to the output.

Following the right-handed convention, azimuthal rotation is counter-clockwise, with 0° on the +X axis. Elevation starts from 0° for directions in the XY plane, up to 90° at zenith. Thus -D0,0, -D90,0, -D180,0 and -D270,0 produce solar vectors {-1,0,0}, {0,-1,0}, {+1,0,0} and {0,+1,0} respectively, while -Dazimuth,90 produces {0,0,-1} regardless of the value of azimuth.

Force overwrite of the output files, i.e. the output file and the file where the state of the random number generator is saved (see the -G option).
sub-option[:...]
Save and restore the state of the random number generator. This option can be used to ensure statistical independence between successive simulations on the same system. Available sub-options are:
input_rng_state
Define the file from which the initial state of the random number generator is read. If not defined, the random number generator is initialised with its default seed.
output_rng_state
Define the file where the final state of the random number generator is written. If not defined, this state is simply discarded.
sub-option[:...]
Generate the shape of the geometry defined in the submitted file and store it in output. Available sub-options are:
Define the file format in which the meshes are stored. Currently, only the Alias Wavefront OBJ file format is supported.
⟨geometry|object|none⟩
Define how the output mesh is split into sub-meshes. A sub-mesh can be generated for each geometry or for each object as defined in the solstice-input(5) file format. The none option means that only one mesh is generated for the whole solar facility. By default, split is set to none.
List short help and exit.
samples-count
Number of Monte-Carlo samples used to estimate the solar flux. By default samples-count is set to .
latitude,longitude
Define the location of the solar plant. The latitude must be in [-90, 90] degrees relative to the equator, counting positive towards the north. The longitude must be in [-180, 180] degrees relative to Greenwich, counting positive towards the east. A location must be defined before any time is defined. It is then applied to any following time until a new location is defined.
output
Write results to output in the solstice-output(5) format. If not defined, write results to standard output.
sub-option[:...]
Register the sampled radiative paths for each sun direction and write them to output. Available sub-options are:
Use default sub-options.
length
Length of the radiative path segments going to infinity. By default, it is computed relative to the scene size.
length
Length of the radiative path segments coming from the sun. By default, it is computed relative to the scene size.
Do not print the helper message when no file is submitted.
receivers
solstice-receiver(5) file defining the scene receivers, i.e. the solar plant entities for which solstice computes Monte-Carlo estimates.
sub-option[:...]
Render an image of the scene through a pinhole camera for each submitted sun direction. Write the resulting images to output. Available sub-options are:
angle
Horizontal field of view of the camera in [30, 120] degrees. By default angle is degrees.
widthxheight
Definition of the rendered image in pixels. By default the image definition is x.
x,y,z
Position of the camera. By default it is set to {0,0,0} or it is automatically computed to ensure that the whole scene is visible, whether tgt is set or not, respectively.
⟨draft|pt⟩
Rendering mode. In draft mode, images are computed by ray-casting; all materials are lambertian, the sun is ignored and the only light source is positioned at the camera position. In pt mode, the scene is rendered with the unbiased path-tracing Monte-Carlo algorithm; the materials described in the committed file as well as the submitted sun directions are correctly handled and a uniform skydome is added to simulate the diffuse infinite lighting. By default rmode is set to draft.
samples-count
Number of samples per pixel. If rmode is draft, the sample positions within a pixel are the same for all pixels. With rmode=pt the pixel samples are generated independently for each pixel. By default, 1 sample per pixel is used.
x,y,z
Position targeted by the camera. By default it is set to {0,0,-1} or it is automatically computed to ensure that the whole scene is visible, whether pos is set or not, respectively.
x,y,z
Up vector of the camera. If rmode is pt, this vector also defines the direction toward the top of the skydome. By default, up is set to {0,1,0}.
utc_time
A time, defined by a string in Coordinated Universal Time (UTC+00:00).

The date must be in the format “YYYY-MM-DDThh:mm:ss”, i.e., as printed for the current date by the following date command:

date -u +"%Y-%m-%dT%H:%M:%S"

Each provided time is used in conjunction with the last provided location to compute a sun direction using the PSA algorithm (see ) and triggers a new computation whose results are concatenated to the output.

threads-count
Hint at the number of threads to use. By default, as many threads as CPU cores are used.
Make solstice more verbose.
Output version information and exit.

Launch two simulations for sun directions whose azimuthal and elevation angles are {45,70} and {50,75}. The solar facility is described in input.yaml and the receivers on which the integrations must be performed are declared in rcvs.yaml. 10000 samples are used by the Monte-Carlo estimates and the results are written to output even though this file already exists:

solstice -D45,70 -D50,75 -R rcvs.yaml -n 10000 -f -o output input.yaml

Launch one simulation at Toulouse, France, at 2 PM on May 1 2022 (UTC+2). The solar facility is described in input.yaml and the receivers on which the integrations must be performed are declared in rcvs.yaml. The results are written to standard output:

solstice -L43.605,1.445 -T"2022-05-01T12:00:00" -R rcvs.yaml input.yaml

Generate a mesh for each geometry described in input.yaml and save them in output in the Alias Wavefront OBJ format. The meshes are positioned according to their orientation constraints, for the sun direction whose azimuthal and elevation angles are {30,60}. Use csplit(1) to generate one Alias Wavefront OBJ file per geometry stored in output. The generated files are named geomNUM.obj with NUM in [0, N-1] where N is the number of geometries described in input.yaml. Refer to solstice-output(5) for information on the regular expression "^---$" used to split the output file:

solstice -D30,60 -g format=obj:split=geometry -f -o output input.yaml
csplit -f geom -b %02d.obj -z --suppress-matched output /^---$/ {*}

Trace 100 radiative paths into the solar plant described in input.yaml, for the sun direction whose azimuthal and elevation angles are 0 and 90 degrees, respectively. Write the solstice-output(5) result to standard output and postprocess it with sed(1) to remove the first line that stores the sun direction. The remaining data listing the radiative path geometry are redirected into paths.vtk:

solstice -n 100 -D0,90 -R rcvs.yaml -p default input.yaml | sed '1d' > paths.vtk

Use the path-tracing rendering algorithm to draw the solar plant solplant.yaml for the sun direction whose azimuthal and elevation angles are 180 and 45 degrees, respectively. Use 64 samples per pixel to estimate the per-pixel radiance and fix the camera up vector to {0,0,1}. Write the solstice-output(5) result to standard output, use sed(1) to remove the first line which stores the sun direction, and visualise the rendered picture by redirecting the remaining data to the feh(1) image viewer:

solstice -D180,45 -r up=0,0,1:rmode=pt:spp=64 solplant.yaml | sed '1d' | feh -

csplit(1), feh(1), sed(1), solstice-input(5), solstice-output(5), solstice-receiver(5)

Manuel Blanco-Muriel, Diego C. Alarcón-Padilla, Teodoro López-Moratalla, and Martín Lara-Coira, Computing the solar vector, Solar Energy, 5, 70, 431-441, 2001.

solstice was initially developed with funding from the (Laboratory of Excellence), in collaboration with the PROMES Laboratory of the French National Centre for Scientific Research (CNRS). Starting in 2026, a new development effort funded by Ademe is ongoing.

solstice was written and is maintained by |Méso|Star> <contact@meso-star.com>.

August 17, 2026 UNIX