commit 9cdf813bdb0faa5f3a7bc11be05c0111b924c9ed
parent 314ef2917d9add189c235cc1e4e86d9db9dc93db
Author: Christophe Coustet <christophe.coustet@meso-star.com>
Date: Wed, 10 May 2017 11:43:26 +0200
Some rewritting.
Diffstat:
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/doc/solstice-input.5.ronn b/doc/solstice-input.5.ronn
@@ -6,8 +6,8 @@ solstice-input(5) -- solar plant description for `solstice`(1)
The `solstice-input` is the format used by the `solstice`(1) program to
represent a solar plant. It relies on the YAML 1.1 data serialization standard
[1]; assuming that the file is compatible with the `solstice-input` semantic, a
-solar plant can be described by using the whole YAML 1.1 functionalities as
-compact notation or data tagging.
+solar plant can be described by using the whole YAML 1.1 functionalities
+including compact notation and data tagging.
A solar plant is composed of a `sun`, an optional `atmosphere` and a collection
of `geometries`, i.e. `shapes` with their associated `material`. Beside the raw
@@ -16,7 +16,7 @@ the `entity` item to efficiently structure the geometries in the scene. An
entity is a node in a tree data structure where the position of each child
entity is relative to the position of its parent. An entity can either
encapsulate a `geometry` or a `pivot` that controls the dynamic positioning of
-its children entity with respect to the pivot constraints and the sun direction
+its child entities with respect to the pivot constraints and the sun direction
submitted to the `solstice`(1) program.
## GRAMMAR
@@ -330,7 +330,7 @@ The available material descriptors are:
Excepted the `virtual` material descriptor, all the material descriptors
provide an optional `normal-map` attribute that defines a path toward a
-Portable PixMap image [2] whose each pixel stores a normal expressed in the
+Portable PixMap image [2] whose pixels store a normal expressed in the
tangent space of the interface. By default the un-perturbated tangent space
normal is {0,0,1}. The PPM image can be encoded on 8 or 16-bits per component
either in ASCII or binary. The parameterization of this 2D image onto the shape
@@ -342,9 +342,9 @@ normal-mapped material on these shapes leads to undefined behaviors.
## SHAPE
A `shape` is used to describe a geometric model. A `shape` is defined in its
-local space, i.e. in a repair whose origin is proper to the shape. No space
-transformation can be defined on the declaration of a shape: it is transformed
-externally through an `object` and/or `entities`.
+local space, i.e. in a coordinate system whose origin is proper to the shape.
+No space transformation can be introduced through the declaration of a shape:
+it should be transformed externally through an `object` and/or `entities`.
### Quadrics
@@ -365,7 +365,7 @@ domain is defined from the bounds of its clipped mesh in the {X,Y} plane:
with `u` and `v` the mapped 2D coordinates from a 3D position {`x`,`y`,`z`}
onto the quadric, and `lower<X|Y>` and `upper<X|Y>` the lower and upper
-bounds of the clipped parabolic cylinder mesh along the X and Y axis.
+bounds of the clipped quadric mesh along the X and Y axis.
The available quadrics are:
@@ -425,7 +425,7 @@ behaviors.
The available triangular meshes are:
* `cuboid`:
- Axis aligned cuboid centered in 0 whose dimensions along the 3 axis is
+ Axis aligned cuboid centered in 0 whose dimensions along the 3 axis are
defined by the `size` parameter. The front side of the cuboid surface looks
outside the cuboid shape.
@@ -443,7 +443,7 @@ The available triangular meshes are:
sphere shape.
* `stl`:
- Path toward an external mesh defined with respect to the `ST`ereo
+ Path toward an external mesh file defined with respect to the `ST`ereo
`L`ithography file format. The front side of the loaded triangles is defined
with respect to their vertex ordering: a triangle is front facing when their
vertices are clock wise ordered.
diff --git a/doc/solstice.1.ronn.in b/doc/solstice.1.ronn.in
@@ -10,17 +10,17 @@ solstice(1) -- compute the power collected by a concentrated solar plant
## DESCRIPTION
-`solstice` computes the total power collected by a concentrated solar plant
-described in the `solstice-input`(5) _file_. If _file_ is not set, the solar
-plant is read from standard input. To evaluate various efficiencies for each
-primary reflector, it computes losses due to cosinus effect, shadowing and
-masking, orientation and surface irregularities, reflectivity and atmospheric
-transmission. The efficiency for each one of these effects is subsequently
-computed for each reflector.
+`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 cosinus
+effect, shadowing and masking, orientation and surface irregularities,
+reflectivity and atmospheric transmission. 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 follows the `solstice-output`(5) format and are written to the _output_
+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`'s algorithm is based on the
Monte-Carlo method, which means that every result is provided with its
@@ -36,13 +36,13 @@ including the input solar spectrum and the transmissivity of the atmosphere, at
any spectral resolution. Refer to `solstice-input`(5) for more informations.
In addition of the aforementioned computations, `solstice` provides three
-others functionalities. The `-g` option can be used to convert the
+other functionalities. The `-g` option can be used to convert the
`solstice-input`(5) geometries in CAO files. The `-p` option saves the sampled
radiative paths used by the estimations, allowing 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 exclusives, and once defined, they replace the
-default `solstice` comportment.
+default `solstice` behaviour.
## OPTIONS
@@ -67,7 +67,7 @@ default `solstice` comportment.
Alias Wavefront OBJ file format is supported.
`split=<geometry|object|none>`<br>
- Define how the output mesh is split in sub-meshes. A sub mesh can be
+ Define how the output mesh is split in 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, the `split`
@@ -175,7 +175,7 @@ the regular expression `^---$` used to split the output file:
Trace 100 radiative paths into the solar plant described in `input.yaml`, with
respect to the sun direction whose azimuthal and elevations angles are `0` and
`90` degrees, respectively. Write the `solstice-output`(5) result to the
-standard output and post-treat it with the `sed`(1) Unix command to remove the
+standard output and postprocess it with the `sed`(1) Unix command to remove the
first line that stores the sun direction from which the radiative paths comes
from. The remaining data that lists the radiative paths geometry are redirected
into the `paths.vtk` file:
