commit 41d877529a09558e36e99d61be591f246971889b
parent 053e3c0a8fc1f852c23e9a799da9587f7af6d61e
Author: Christophe Coustet <christophe.coustet@meso-star.com>
Date: Wed, 17 May 2017 17:39:47 +0200
Fix some typos.
Diffstat:
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/doc/solstice-output.5.ronn b/doc/solstice-output.5.ronn
@@ -4,10 +4,10 @@ solstice-output(5) -- output format of `solstice`(1) results
## DESCRIPTION
The `solstice-output` describes the output format of the `solstice`(1) program.
-The data generated by a `solstice`(1) invocation are all written in a single
-file or on the standard output whether an _output_ file is defined by the `-o`
-option or not, respectively. Note that submitting several sun directions to
-`solstice`(1), through the `-D` option, will produce as many outputs as sun
+All the data generated by a `solstice`(1) invocation are written in a single
+file or on the standard output whether an _output_ file is defined through the
+`-o` option or not, respectively. Note that submitting several sun directions
+to `solstice`(1), through the `-D` option, will produce as many outputs as sun
directions. In other words, invoking `solstice`(1) with N several sun
directions looks like calling `solstice`(1) N times and concatenating their
associated output.
@@ -153,7 +153,7 @@ the same line while a closed quote mark is not defined.
## SIMULATION
A `simulation-output` begins by a line that stores the sun direction used by the
-simulation. The next line list the numbers of global, per receiver and per
+simulation. The next line lists the numbers of global, per receiver and per
primary results as well as the overall number of Monte-Carlo experiments used
by the simulation and the number of experiments that failed due to unforeseen
errors as numerical imprecisions.
@@ -169,24 +169,25 @@ errors as numerical imprecisions.
### Receiver map
A receiver defined in the submitted `solstice-receiver`(5) file, can have a
-per-primitive irradiance estimation if their `per_primitive` flag is active. In
+per-primitive irradiance estimation if its `per_primitive` flag is active. In
this case, `solstice`(1) generates a `receiver-map` that is actually an ASCII
VTK file [2] that stores the triangular mesh of the receiver and, for each
triangle, the estimation of its associated irradiance. The "definition" of the
-receiver map is thus controlled by the discretisation of the receiver shape as
-described in the `solstice-input`(5) file. Note that to obtain a good
-estimation of the per triangle irradiance, one have to ensure that the number
-of per triangle experiments is sufficient regarding the targeted accuracy.
+receiver map is thus controlled by the discretisation of the receiver's shape,
+as described in the `solstice-input`(5) file. Note that to obtain a good
+estimation of the per-triangle irradiance, one have to ensure that the number
+of per-triangle experiments is sufficient regarding the targeted accuracy.
Since only a small fraction of the overall sampled radiative paths reach a
-given triangle, the total number of experiments provided by the `-n` option of
-`solstice`(1) should be increased significantly, as 1 or 2 order of magnitude.
+given triangle, the total number of experiments required through the `-n`
+option of `solstice`(1) should be increased significantly, as 1 or 2 order of
+magnitude.
If only the front or the back side of the receiver is active, then only one set
of per triangle irradiance estimation is written. If the `side` attribute of
the receiver is set to `FRONT_AND_BACK`, the irradiance estimation for the
-front facing triangles are written priorly to the estimation of the back facing
+front facing triangles are written before to the estimation of the back facing
ones. The following grammar gives a brief description of the formatting of a
-`VTK-RECEIVER-MAP`. Refer to the VTK format specification [2] for more
+`VTK-RECEIVER-MAP`. Please refer to the VTK format specification [2] for more
informations on the VTK file format.
@@ -231,24 +232,24 @@ informations on the VTK file format.
A `dump-geometry-output` is generated when `solstice`(1) is invoked with the
`-g` option. In this mode, for each submitted sun direction, `solstice`(1)
converts the geometry of the submitted `solstice-input`(5) file in triangular
-meshes that is then written to the output with respect to the format provided
+meshes that are then written to the output with respect to the format provided
by the `format` parameter of the `-g` option. The only format currently
-supported by `solstice`(1) is the Alias Wavefront OBJ [3]. With no more
-sub-option, `solstice`(1) will thus generate an OBJ file that will contain the
-whole solar plant mesh. However, the `split` parameter of the `-g` option
-allows to generate several OBJ files: one file is generated per `geometry` or
-per `object`, as defined in the `solstice-input`(5) format, whether the `split`
-sub-option is set to `geometry` or `object`. In this situation, each OBJ file
-is followed by a line with 3 minus characters in order to identify where the
-OBJ definition stops in the output stream, and thus where the next OBJ
-definition begins.
+supported by `solstice`(1) is the Alias Wavefront OBJ [3] format. With no more
+sub-option, `solstice`(1) will thus generate an OBJ file containing the whole
+ solar plant mesh. However, the `split` parameter of the `-g` option allows to
+generate several OBJ files: one description is generated per `geometry` or per
+`object`, as defined in the `solstice-input`(5) format, whether the `split`
+sub-option is set to `geometry` or `object`. In this situation, each OBJ
+description is followed by a line with 3 minus characters in order to identify
+description boundaries.
Independently of the `split` strategy, each `solstice-input`(1) geometry is an
OBJ group whose name is the `entity-identifier` of the entity in which it is
-encapsulated. Finally, the `dump-geometry-output` use the `usemtl` directive of
-the OBJ format to associate to a mesh the name of its material type. The
-following grammar succinctly describe the formatting of an `OBJ-FILE`. Refer to
-the OBJ format specification [3] for more informations on the OBJ file format.
+encapsulated. Finally, the `dump-geometry-output` uses the `usemtl` directive
+of the OBJ format to associate to a mesh the name of its material type. The
+following grammar succinctly describes the formatting of an `OBJ-FILE`. Please
+refer to the OBJ format specification [3] for more informations on the OBJ file
+format.
OBJ-FILE ::= g <entity-identifier>
<obj-mesh>
