commit cfcadaf52fdf8a818f5720b45ab17dd41eb07471
parent e039876329a5b2c99f57ac00ea8ed98904c99125
Author: Vincent Forest <vincent.forest@meso-star.com>
Date: Wed, 10 May 2017 16:06:06 +0200
First draft of the sun part of solstice-input man
Diffstat:
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git a/doc/solstice-input.5.ronn b/doc/solstice-input.5.ronn
@@ -221,7 +221,7 @@ submitted to the `solstice`(1) program.
<sun> ::= sun:
dni: REAL # Direct Normal Irradiance in ]0, INF)
[ <spectrum> ] # Default is the smarts295 spectrum
- [ <radial-angular-distribution> ]
+ [ <rad-ang-distrib> ]
<rad-ang-distrib> ::= <pillbox> | <buie>
@@ -255,6 +255,29 @@ submitted to the `solstice`(1) program.
<spectrum-data> ::= wavelength: REAL # in [0, INF)
data: REAL # in [0, INF)
+## SUN
+
+The `sun` describes how the solar plant is lit. However, its position is not
+defined into the `solstice-input`(5) file but is provided by the `solstice`(1)
+command. This allows to use the same unmodified `solstice-input`(5) file for
+several simulations with different sun directions.
+
+The main `sun` property is its direct normal irradiance or `dni`. Its value is
+a scalar defining the average direct normal irradiance of the sun on its whole
+spectrum. The optional `spectrum` parameter describes the per wavelength
+distribution of the sun `dni`. Note that this distribution is automatically
+normalized by `solstice`(1).
+
+Finally, the `rad-ang-distrib` parameter controls the radial angular
+distribution of the sun directions. If not defined, the sun directions are
+assumed to be parallels. The available radial angular distributions are:
+
+* `pillbox`:
+TODO
+
+* `buie`:
+TODO
+
## MATERIAL
A `material` describes the properties of an interface. These properties can be
@@ -351,7 +374,7 @@ the latter describes triangulated surfaces.
### Quadric
A quadric shape is defined from a quadric equation and a set of 2D clipping
-operations listed by its `clip` parameter performed in their {X,Y} plane .By
+operations listed by its `clip` parameter performed in their {X,Y} plane. By
convention, the front side of the quadric surface looks toward the positive Z
axis. Internally, the clipped quadric surface is discretized in a triangular
mesh with respect to the quadric discretization parameters. This mesh is used
@@ -359,7 +382,7 @@ by `solstice`(1) as a "proxy" to speed up the access toward the quadric shape:
the quadric position and its associated normal are in fine computed from the
quadric equation.
-The quadric surface is parameterized in the {X,Y} plane. Its parametrization
+The quadric surface is parameterized in the {X,Y} plane. Its parameterization
domain is defined from the bounds of its clipped mesh in the {X,Y} plane:
u = (x - lowerX) / (upperX-lowerX)
@@ -410,17 +433,15 @@ The available quadrics are:
* `plane`:
Plane whose normal points along the positive Z axis. The `slices` attribute
- controls the discretisation of the plane cut with respect to the clipping
- operations defines by the `clip` parameter.
+ controls the discretisation of the clipped plane.
### Clipping
-A clipping operation, or `polyclip`, is used to remove some parts of the,
-possibly infinite, quadric surface. It is defined by a 2D `contour-descriptor`
-expressed in the {X,Y} plane and a clipping `operation`. The `AND` and `SUB`
-clip operands, remove the quadric surface that intersects or does not intersect
-the `contour-descriptor`, respectively. The available `countour-descriptor`s
-are:
+A clipping operation, or `polyclip`, is used to remove some parts of the
+quadric surface. It is defined by a 2D `contour-descriptor` expressed in the
+{X,Y} plane and a clipping `operation`. The `AND` and `SUB` clip operands,
+remove the quadric surface that intersects or does not intersect the
+`contour-descriptor`, respectively. The available `countour-descriptor`s are:
* `circle-descriptor`:
Circular contour whose size is defined by the `radius` parameter. Actually,
@@ -429,7 +450,7 @@ are:
circle.
* `vertices-descriptor`:
- Polygonal contour describe by a list of 2D vertices. The polygon edges are
+ Polygonal contour describes by a list of 2D vertices. The polygon edges are
defined by connecting each vertex to its previous one. To ensure that the
polygon is closed, the first and the last vertex is automatically connected.
Note that `solstice`(1) assumes that the defined polygon does not overlap
@@ -442,7 +463,7 @@ instance, the following example defines 5 clipping operations on a plane to
describe a rectangle with a circular hole at each of its corner. The first
`polyclip` limits the infinite plane to a rectangle centered in 0 whose
size in X and Y is 8 and 4, respectively. The 4 subsequent `polyclips` drill
-the rectangle near of its corner with circles whose radius is 0.5.
+the rectangle near of its corner with circles whose radius is 0.5:
plane:
clip:
@@ -456,12 +477,10 @@ the rectangle near of its corner with circles whose radius is 0.5.
Triangular meshes are generated by `solstice`(1) from a shape description or
loaded from a CAO file. Note that the mesh normals are defined per triangle.
-They are thus discontinuous even though for smooth shapes as spheres.
-
-The triangular meshes are not parameterized, i.e. they do not provide a mapping
-from a 3D position onto its surface to a 2D coordinates. Applying a
-normal-mapped material to a triangular meshes will thus produce undefined
-behaviors.
+They are thus discontinuous even for smooth shapes as spheres. The triangular
+meshes are not parameterized, i.e. they do not provide a mapping from a 3D
+position onto its surface to a 2D coordinates. Applying a normal-mapped
+material to a triangular meshes will thus produce undefined behaviors.
The available triangular meshes are:
@@ -495,15 +514,15 @@ An `entity` is used to declare and position shapes into the solar plant.
Actually, the entity is the only item that effectively spawns a `geometry` into
the solar plant: if a geometry is declared but not referenced by an entity, it
is ignored by `solstice`(1). An entity is a hierarchical data structure that
-can have child entities whose transformation is relative to their parent. If
+can have child entities whose transformation is relative to their parent. If
not defined, the `transform` parameter of an entity is assumed to be the
-identity, i.e. the `rotation` and the `translation` of the entity are nulls.
+identity, i.e. its `rotation` and `translation` are nulls.
Each entity has a `name` which must be unique per hierarchy level: 2 root
entities (i.e. entities without parent) cannot have the same name as well as
the children of a same parent entity. A child entity is identified into the
solar plant by successively concatenating, with the '.' character, the name of
-its parents with its own name. This naming convention is used in the
+its ancestors with its own name. This naming convention is used in the
`solstice-receiver`(5) format to define the entities to track during the
`solstice`(1) computations. For instance, in the following example, the
`entity-identifier` of the child entity named `level2` is
