commit 7cd5dd22730cfb1700cb0ae10d4d6176304be7fd
parent db0d6192c4c3ca17eda8b52fe91741442e71281f
Author: Vincent Forest <vincent.forest@meso-star.com>
Date: Wed, 7 Jul 2021 15:35:40 +0200
Merge branch 'release_0.7' into develop
Diffstat:
4 files changed, 278 insertions(+), 132 deletions(-)
diff --git a/README.md b/README.md
@@ -1,35 +1,47 @@
-# High-Tune: RenDeRer
-
-This program is a part of the [High-Tune](http://www.umr-cnrm.fr/high-tune/)
-project: it illustrates the implementation of efficient radiative transfer
-Monte-Carlo algorithms in cloudy atmospheres.
-
-htrdr is an image renderer in the visible part of the spectrum, for scenes
-composed of an atmospheric gas mixture, clouds, and a ground. It uses spectral
-data that should be provided for the pressure and temperature atmospheric
-vertical profile defined along the Z axis, the liquid water content in
-suspension within the clouds that is a result of Large Eddy Simulation
-computations, and the optical properties of water droplets that have been
-obtained from a Mie code. The user also has to provide: the characteristics of
-the simulated camera, the sensor definition, and the position of the sun. It is
-also possible to provide a geometry representing the ground. Both, the clouds
-and the ground, can be infinitely repeated along the X and Y axis.
-
-htrdr evaluates the intensity incoming on each pixel of the sensor array. The
-underlying algorithm is based on a Monte-Carlo method: it consists in
-simulating a given number of optical paths originating from the camera,
-directed into the atmosphere, taking into account light absorption and
-scattering phenomena. The computation is performed over the whole visible part
-of the spectrum, for the three components of the CIE 1931 XYZ colorimetric
-space that are subsequently recombined in order to obtain the final color for
-each pixel, and finally the whole image of the scene as seen from the required
-observation position.
-
-In addition of shared memory parallelism, htrdr supports the [*M*essage
-*P*assing *I*nterface](https://www.mpi-forum.org/) specification to
-parallelise its computations in a distribute memory environment; the htrdr
-binary can be run either directly or through a MPI process launcher like
-`mpirun`.
+# `htrdr`
+
+`htrdr` evaluates the intensity at any position (probe) of the scene, in any
+direction, in the presence of surfaces and an absorbing and diffusing
+semi-transparent medium, both for radiation sources that are internal to the
+medium (longwave) or external to the medium (shortwave). The intensity is
+calculated using the *Monte-Carlo* method: a number of optical paths are
+simulated backward, from the probe position and into the medium. Various
+algorithms are used, depending on the specificities of the nature and shape of
+the radiation source.
+
+Applications are theoretically possible to any configuration. However, it all
+eventually comes down to the possibility of using the physical data of
+interest, in their most common formats, in each scientific community. `htrdr`
+is currently suitable for two main application fields:
+
+1. *Atmospheric radiative transfer*: the clear-sky atmosphere is vertically
+ stratified, cloud thermodynamic data is provided on a regular 3D rectangular
+ grid, and surface optical properties can be provided for an arbitrary number
+ of materials. Internal radiation and solar radiation are taken into account.
+
+2. *Combustion* processes: thermodynamic data is provided at the nodes of an
+ unstructured tetrahedral mesh, while surface properties can still be
+ provided for various materials. The radiation source is only external: a
+ monochromatic laser sheet illuminates the inside of the combustion chamber
+ for diagnostic purposes.
+
+Since any observable radiative transfer is expressed as an integral of the
+intensity, and since there is a strict equivalence between the integral to be
+solved and the underlying Monte-Carlo algorithm (each integral results in the
+sampling of a random variable), the algorithms that calculate the radiance are
+used for computing various quantities:
+
+- *Images* on a camera sensor, in a given field of view. For combustion
+ applications, only monochromatic images are supported. In atmospheres, both
+ visible and infrared images are possible: CIE colorimetry is used for visible
+ images, while an infrared image is in fact a temperature map of luminosity,
+ over the required spectral interval.
+
+- *Flux density maps*, on a grid of sensors, integrated over an entire
+ hemisphere. In the case of combustion chambers, only monochromatic flux maps
+ can be calculated, while spectrally integrated flux density maps (both on the
+ visible part of the spectrum and on the infrared) are possible for
+ atmospheric applications.
## How to build
@@ -38,7 +50,6 @@ This program is compatible GNU/Linux 64-bits. It relies on the
[RCMake](https://gitlab.com/vaplv/rcmake/) packages to build. It also depends
on the
[AW](https://gitlab.com/vaplv/loader_aw/#tab-readme),
-[HTSky](https://gitlab.com/meso-star/htsky/),
[MruMtl](https://gitlab.com/meso-star/mrumtl/),
[RSys](https://gitlab.com/vaplv/rsys/),
[Star-3D](https://gitlab.com/meso-star/star-3d/),
@@ -49,9 +60,15 @@ on the
[MPI](https://www.mpi-forum.org/) specification to parallelize its
computations.
-First ensure that CMake is installed on your system. Then install the RCMake
-package as well as the aforementioned prerequisites. Finally generate the
-project from the `cmake/CMakeLists.txt` file by appending to the
+`htrdr` finally depends on the [HTSky](https://gitlab.com/meso-star/htsky/)
+library if the `HTRDR_BUILD_ATMOSPHERE` option is set and on
+[AtrSTM](https://gitlab.com/meso-star/atrstm/) when `HTRDR_BUILD_COMBUSTION` is
+set. These options enable/disable the build of the atmospheric part and the
+combustion part of htrdr. By default, both options are activated.
+
+To build `htrdr`, first ensure that CMake is installed on your system. Then
+install the RCMake package as well as the aforementioned prerequisites. Finally
+generate the project from the `cmake/CMakeLists.txt` file by appending to the
`CMAKE_PREFIX_PATH` variable the install directories of its dependencies. The
resulting project can be edited, built, tested and installed as any CMake
project. Refer to the [CMake](https://cmake.org/documentation) for further
@@ -59,6 +76,36 @@ informations on CMake.
## Release notes
+### Version 0.7
+
+#### Adds the simulation of radiative transfer in combustion media
+
+The new `htrdr-combustion` command performs radiative transfer computations in
+a scene representing a semi-transparent medium enlightened by a laser sheet. It
+uses Monte-Carlo to calculate a monochromatic image of the medium or the
+radiative flux density. Both computations are performed in the visible at a
+given frequency.
+
+The medium data are defined on the vertices of an unstructured tetrahedral mesh
+that may be surrounded by a triangular surface mesh representing the inner
+limits of the combustion chamber.
+
+#### Updates the `htrdr` command
+
+The previous `htrdr` command is renamed to `htrdr-atmosphere`. `htrdr` becomes
+a proxy for the `htrdr-atmosphere` command or the `htrdr-combustion` command:
+calling `htrdr` with the `<atmosphere|combustion>` options is equivalent to
+directly calling the `htrdr-<atmosphere|combustion>` commands.
+
+#### Miscellaneous
+
+- Major update of the entire codebase to add multiple applications to `htrdr`:
+ It was originally designed to handle atmospheric applications only.
+- Always displays the number of processes and the number of threads: previously
+ they were only printed on multi-node executions.
+- Fixed auto intersection issue on surfaces not facing the sun.
+- Fixed writing of pixel data: assumed pixel layout could be wrong.
+
### Version 0.6.1
- Fix the self-intersection issue in shortwave computations introduced by
@@ -193,13 +240,13 @@ regular image rendering), longwave or shortwave.
## Copyright notice
-Copyright (C) 2018, 2019, 2020, 2021 [|Meso|Star>](http://www.meso-star.com).
-Copyright (C) 2018, 2019, 2021 CNRS.
+Copyright (C) 2018, 2019, 2020, 2021 [|Meso|Star>](http://www.meso-star.com).
+Copyright (C) 2018, 2019, 2021 CNRS.
Copyright (C) 2018, 2019 Université Paul Sabatier.
## License
-htrdr is free software released under the GPL v3+ license: GNU GPL version 3 or
+`htrdr` is free software released under the GPL v3+ license: GNU GPL version 3 or
later. You are welcome to redistribute it under certain conditions; refer to
the COPYING file for details.
diff --git a/doc/htrdr-atmosphere.1.txt.in b/doc/htrdr-atmosphere.1.txt.in
@@ -22,7 +22,7 @@ htrdr-atmosphere(1)
NAME
----
-htrdr-atmosphere - simulate radiative transfert in cloudy atmospheres
+htrdr-atmosphere - simulate radiative transfer in cloudy atmospheres
SYNOPSIS
--------
@@ -31,16 +31,20 @@ SYNOPSIS
DESCRIPTION
-----------
-*htrdr-atmosphere* simulate radiative transfert in scenes composed of an
+*htrdr-atmosphere* simulates radiative transfer in scenes composed of an
atmospheric gas mixture, clouds, and a ground. It evaluates the intensity
incoming on each pixel of the sensor array. The underlying algorithm is based
on a Monte-Carlo method: it consists in simulating a given number of optical
paths originating from the sensor, directed into the atmosphere, taking into
-account light absorption and scattering phenomena.
+account light absorption and scattering phenomena. This algorithm and the way
+it is efficiently implemented in *htrdr-atmosphere* is presented in the
+following article: "A path-tracing Monte Carlo library for 3-D radiative
+transfer in highly resolved cloudy atmospheres", N. Villefranque et al, JAMES
+2019 [1].
-Radiative transfert can be evaluated in the visible or the infrared part of the
+Radiative transfer can be evaluated in the visible or the infrared part of the
spectrum. It uses spectral data that should be provided for the pressure and
-temperature atmospheric vertical profile [1] (*-a* _atmosphere_), the liquid
+temperature atmospheric vertical profile [2] (*-a* _atmosphere_), the liquid
water content in suspension within the clouds stored in a *htcp*(5) file (*-c*
_clouds_), and the optical properties of water droplets that have been obtained
from a Mie code and formatted according to the *htmie*(5) file format (*-m*
@@ -75,25 +79,21 @@ domain is longwave or shortwave.
In *htrdr-atmosphere* the spatial unit 1.0 corresponds to one meter and the
temperatures are expressed in Kelvin. The estimated radiances are given in
W/sr/m^2 excepted for monochromatic computations where the computed spectral
-radiance is defined in W/sr/m^2/nm. The fluxes are saved in W/m^2. The results
-are written to the output file if the *-o* option is defined and the standard
-output otherwise. The output image is a list of raw ASCII data formatted with
-respect to the *htrdr-image*(5) file format. Since *htrdr-atmosphere* relies
-on the Monte-Carlo method, each estimation is given with its numerical
-accuracy.
-
-During the simulation, *htrdr-atmosphere* dynamically loads/unloads cloud
-properties to handle clouds whose data that do not feat in main memory.
-*htrdr-atmosphere* also supports shared memory parallelism and relies on the
-Message Passing Interface specification [3] to parallelise its computations in
-a distributed memory environment; it can thus be run either directly or through
-a MPI process launcher like *mpirun*(1).
+radiance is defined in W/sr/m^2/nm. The flux densities are saved in W/m^2. The
+results are written to the output file if the *-o* option is defined and the
+standard output otherwise. The output image is a list of raw ASCII data
+formatted with respect to the *htrdr-image*(5) file format.
+
+*htrdr-atmosphere* supports shared memory parallelism and relies on the Message
+Passing Interface specification [4] to parallelise its computations in a
+distributed memory environment; it can thus be run either directly or through a
+MPI process launcher like *mpirun*(1).
OPTIONS
-------
*-a* _atmosphere_::
Path toward the file containing the gas optical properties of the atmosphere.
- Data must be formatted according to the fileformat described in [1].
+ Data must be formatted according to the fileformat described in [2].
*-c* _clouds_::
Submit a *htcp*(5) file describing the properties of the clouds. If not
@@ -132,7 +132,7 @@ OPTIONS
*-d*::
Write in _output_ the space partitioning data structures used to speed up
the radiative transfer computations in the clouds. The written data are
- octrees saved in the VTK file format [2]. Each octree node stores the minimum
+ octrees saved in the VTK file format [3]. Each octree node stores the minimum
and the maximum of the extinction coefficients of the cloud cells overlapped
by the octree node. In the _output_ file, each octree is separated from the
previous one by a line with three minus characters, i.e. '---'.
@@ -273,12 +273,62 @@ OPTIONS
*-v*::
Make *htrdr-atmosphere* verbose.
+OUTPUT IMAGE
+------------
+
+Images calculated by *htrdr-atmosphere* are saved in the *htrdr-image*(5) file
+format. This section describes the nature and arrangement of image data
+depending on the type of calculation performed by *htrdr-atmosphere*.
+
+XYZ image
+~~~~~~~~~
+
+For an image rendering in the visible part of the spectrum (default behavior or
+*-s cie_xyz* option), the pixel components store 4 estimates. The first,
+second, and third pairs of floating point values encode the estimated
+integrated radiance in W/sr/m^2 for the X, Y, and Z components of the CIE
+1931 XYZ color space. The first value of each pair is the expected value of the
+average radiance of the pixel. The second value is its associated standard
+deviation. The fourth and final pair records the microsecond estimate of the
+computation time per radiative path and its standard error.
+
+Longwave image
+~~~~~~~~~~~~~~
+
+If the image is an infrared rendering (option *-s* *lw*=_wlen-min_,_wlen-max_)
+the first and second pixel components store the expected value and the standard
+error of the estimated brightness temperature (in K), respectively. The third
+and fourth components record the expected value and the standard deviation of
+the pixel radiance which is either an integrated radiance in W/sr/m^2 or a
+spectral radiance in W/sr/m^2/nm depending on whether this radiance was
+calculated for a spectral range or at a single wavelength. The fifth and sixth
+pixel components are not used. Finally, the last 2 components of the pixel
+record the estimate in microseconds of the computation time per radiative path
+and its standard error.
+
+Shortwave image
+~~~~~~~~~~~~~~~
+
+For shortwave renderings (option *-s* *sw*=_wlen-min_,_wlen-max_), the data
+written to the output image are formatted as for a longwave image except
+that the first and second components of the pixels are not used because no
+brightness temperature has been evaluated.
+
+Flux density map (shortwave and longwave)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A flux density map (option *-p*) is saved in an *htrdr-image*(5) storing the
+expected value and the standard error of the pixel radiative flux density (in
+W/m^2) on its first and second component. All other components are unused
+excepted the seventh and eighth components that store the estimate of the
+radiative path computation time in microseconds and its standard error.
+
EXAMPLES
--------
Render a clear sky scene, i.e. a scene without any cloud, whose sun is at
zenith. The vertical atmospheric gaz mixture along the Z axis is described in
-the *gas.txt* file. the ground geometry is a quad repeated to the infinity
+the *gas.txt* file. The ground geometry is a quad repeated to the infinity
whose materials are listed in the *material.mtl* file. The camera is positioned
at *400* meters height and looks toward the positive Y axis. The definition of
the rendered image is *800* by *600* pixels and the radiance of each pixel
@@ -298,7 +348,7 @@ geometry was carefully designed to be cyclic and can be thus infinitely
repeated without visual glitches. Use the *-f* option to write the rendered
image to *output* even though the file already exists. Finally, use the
*htpp*(1) command to convert the *htrdr-image*(5) saved in output in a regular
-PPM image [4]:
+PPM image [5]:
$ htrdr-atmosphere -D0,90 -a gas.txt -m Mie.nc -g mountains.obj -R \
-M materials.mtl \
@@ -370,17 +420,27 @@ Use *mpirun*(1) to launch *htrdr-atmosphere* on several hosts defined in the
NOTES
-----
-1. High-Tune: Gas Optical Properties file format -
- <https://www.meso-star.com/projects/high-tune/downloads/gas_opt_prop_en.pdf>
-2. VTK file format -
- <http://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf>
-3. MPI specifications - <https://www.mpi-forum.org/docs/>
-4. Portable PixMap - <http://netpbm.sourceforge.net/doc/ppm.html>
+
+1. A path-tracing Monte Carlo library for 3-D radiative transfer in highly
+resolved cloudy atmospheres. N. Villefranque et al, JAMES 11, 2449-2473, 2019 -
+<https://doi.org/10.1029/2018MS001602>
+
+2. High-Tune: Gas Optical Properties file format -
+<https://www.meso-star.com/projects/high-tune/downloads/gas_opt_prop_en.pdf>
+
+3. VTK file format -
+<http://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf>
+
+4. MPI specifications - <https://www.mpi-forum.org/docs/>
+
+5. Portable PixMap - <http://netpbm.sourceforge.net/doc/ppm.html>
COPYRIGHT
---------
-Copyright $copy; 2018, 2019, 2020, 2021 |Meso|Star> <contact@meso-star.com>.
+Copyright © 2018, 2019, 2020, 2021 |Meso|Star> <contact@meso-star.com>.
+
Copyright © 2018, 2019, 2021 CNRS
+
Copyright © 2018, 2019 Université Paul Sabatier
<contact-edstar@laplace.univ-tlse.fr>.
diff --git a/doc/htrdr-combustion.1.txt.in b/doc/htrdr-combustion.1.txt.in
@@ -32,15 +32,15 @@ SYNOPSIS
DESCRIPTION
-----------
The purpose of *htrdr-combustion* is to perform radiative transfer computations
-in a scene representing a combustion semi-transparent medium enlightened by a
-laser sheet. The combustion medium may be surrounded by solid boundaries (inner
-limits of the combustion chamber). The program will currently compute the
-monochromatic image (in the visible, at a given frequency) of the combustion
-medium: collected light comes from the laser, and is scattered by soot
-aggregates within the flame before eventually reaching the camera.
+in a scene representing a semi-transparent medium enlightened by a laser sheet.
+The combustion medium may be surrounded by solid boundaries (inner limits of
+the combustion chamber). The program will currently compute, in the visible at
+a given frequency, the monochromatic image or the radiative flux density of the
+combustion medium: collected light comes from the laser, and is scattered by
+soot aggregates within the flame before eventually reaching the sensor.
Data about the gaseous medium have to be provided on the vertices of a
-unstructured tetrahedron mesh: pressure, temperature and concentrations of H2O,
+unstructured tetrahedral mesh: pressure, temperature and concentrations of H2O,
CO2 and CO have to be provided for every spatial position used to define this
mesh. These data have to be provided in anticipation of future developments for
the longwave range: since the gas is assumed to be transparent in the visible,
@@ -57,16 +57,23 @@ absorption and scattering cross-sections of soot aggregates, as well as their
scattering function.
The Monte-Carlo algorithm that accounts for the visible intensity is inspired
-from the algorithm used for solar radiation in the *htrdr-atmosphere* command.
-It was adapted to partially illuminated scenes in order to solve convergence
-issues. The algorithm is presented in the following article:
+from the algorithm used for solar radiation in the *htrdr-atmosphere*(1)
+command. It was adapted to partially illuminated scenes in order to solve
+convergence issues. The algorithm is presented in the following article:
"Null-collision meshless Monte-Carlo - a new reverse Monte-Carlo algorithm
designed for laser-source emission in absorbing/scattering inhomogeneous
media". M. Sans et al, JQSRT, 2021 [2].
+In *htrdr-combustion* the spatial unit 1.0 corresponds to one meter while the
+estimated monochromatic radiances and flux densities are saved in W/sr/m^2 and
+W/m^2 respectively. Computed images are stored in the *htrdr-image*(5) file
+format.
+
*htrdr-combustion* implements a mixed parallelism: on one computer (i.e. a
node) it uses a shared memory parallelism, and it relies on the message passing
-interface [4] to parallelize the computations between several nodes.
+interface [4] to parallelize the computations between several nodes. We can
+thus launch *htrdr-combustion* either directly, or via a process launcher
+like *mpirun*(1) to distribute the rendering over several nodes.
OPTIONS
-------
@@ -97,14 +104,15 @@ OPTIONS
*-d* <__laser__|__octree__>::
When define with the _laser_ argument, write in _output_ the geometry of the
laser sheet saved in the VTK file format [3]. With the _octree_ argument,
- write in _output_ the space partitioning data structure used to speed up the
- radiative transfer computations in the combustion medium. The octree is saved
- following the VTK file format [3]. Each node stores the minimum and the
- maximum of the extinction coefficients of the tetrahedra that the node
+ write in _output_ a VTK file that stores the octree leaves of the space
+ partitioning data structure used to speed up the radiative transfer
+ computations in the combustion medium. Each leaf stores the minimum and the
+ maximum of the extinction coefficients of the tetrahedra that the leaf
overlaps.
*-F* <__fractal-coefficients__:...>::
- Fractal parameters of the RDG-FA model. Available fractal coefficients are:
+ Fractal parameters of the RDG-FA model. This option disable the *-I* option
+ if it was previously set. Available fractal coefficients are:
**dimension**=_real_;;
Fractal dimension. By default it is set to
@@ -118,8 +126,15 @@ OPTIONS
Force overwrite of the _output_ file.
*-g* <__geometry-parameter__:...>::
- Define the geometry of the combustion chamber. Available geometry parameters
- are:
+ Define the geometry of the combustion chamber. Note that this geometry does
+ not prevent the camera from viewing the medium or the laser from illuminating
+ it, even if they are outside the combustion chamber. The rendering algorithm
+ ensures that they are not occluded by this geometry like with a two-way
+ mirror. When the laser is out of geometry, its emissive surface is seen as if
+ it were following the interior surface of the chamber. Likewise, the radiance
+ seen by the camera outside the chamber is the radiance that reaches it as if
+ its image plane were following the surface of the geometry. Available
+ geometry parameters are:
**mats**=__materials__;;
Path to the *htrdr-materials*(5) that defines the media and materials used
@@ -129,11 +144,11 @@ OPTIONS
Path to the *htrdr-obj*(5) file that represents the mesh of the combustion
chamber. Following the *htrdr-obj*(5) fileformat, the interface of the
submitted mesh must be defined as a thin interface, i.e. it must be
- composed of 3 components separated by the ':' character. By
- convention, *htrdr-combustion* expects the outside environment to be called
- "air" and the medium inside the combustion chamber to be called "chamber".
- No assumption is made on the name of the surface material excepted that it
- has to reference a valid material.
+ composed of 3 components separated by the ':' character. By convention,
+ *htrdr-combustion* expects the outside environment to be called "air" and
+ the medium inside the combustion chamber to be called "chamber". No
+ assumption is made on the name of the surface material excepted that it has
+ to reference a valid material.
*-h*::
List short help and exit.
@@ -202,8 +217,9 @@ OPTIONS
combustion medium.
*-R* <__rectangle-parameter__:...>::
- Switch in flux map computation. The rectangular sensor onto which
- the flux is integrated is defined by the following parameters:
+ Compute a radiatve flux density map rather than an image. The rectangular
+ sensor onto which the flux is integrated is defined by the following
+ parameters:
**pos**=**_x_**,**_y_**,**_z_**;;
Position of the center of the rectangle. By default it is set to
@@ -260,12 +276,38 @@ OPTIONS
Define the wavelength of the laser in nanometre. By default it is set to
@HTRDR_COMBUSTION_ARGS_DEFAULT_WAVELENGTH@.
+OUTPUT IMAGE
+------------
+
+Images calculated by *htrdr-combustion* are saved in the *htrdr-image*(5) file
+format. This section describes the nature and arrangement of image data
+depending on the type of calculation performed by *htrdr-combustion*.
+
+Shortwave monochromatic image
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For a monochromatic image rendering, the first and second pixel components are
+not used. The expected value and the standard deviation of the pixel radiance
+(in W/sr/m^2) are saved on the third and fourth components. The fifth and
+sixth components of the pixel are also not used while the last 2 components of
+the pixel (the seventh and the eighth) record the estimate in microseconds of
+the computation time per radiative path and its standard error.
+
+Shortwave flux density map
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A flux density map (option *-R*) is saved in an *htrdr-image*(5) storing the
+expected value and the standard error of the pixel radiative flux density (in
+W/m^2) on its first and second component. All other components are unused
+excepted the seventh and eighth components that store the estimate of the
+radiative path computation time in microseconds and its standard error.
+
EXAMPLES
--------
Make htrdr-combustion verbose (option *-v*) and render an image of a combustion
medium whose tetrahedral mesh is stored in *tetra.sth* and its associated
-thermodynamic properties are saved in *thermprops.atrtp*. The spectrally
+thermodynamic properties are saved in *thermprops.atrtp*. The spectrallyole
varying indices of the medium are listed in the *refract_ids.atrri* file. The
center of the laser surface emission is positioned at the origin and its
direction is aligned to the Y axis. The definition of the rendered image is
@@ -290,7 +332,8 @@ volumetric acceleration structure in *octree.cache* or reused it if it was
already populated in a previous run with compatible input data. Set the finest
resolution of this acceleration structure to 1000 along the major extend of the
medium and use a optical thickness criterion of 5 to build it. Use the *-f*
-option to force the overwrite of the *output* file if it exists.
+option to force the overwrite of the *output* file if it exists and use *-s* to
+speed up the rendering with the available SIMD instruction sets.
$ htrdr-combustion -v \
-m tetra.sth \
@@ -304,7 +347,27 @@ option to force the overwrite of the *output* file if it exists.
-O octree.cache \
-V 1000 \
-T 5 \
- -o output -f
+ -o output -f -s
+
+Compute a flux density map whose definition is *500* by *500* pixels. The flux
+density per pixel is estimated with *64* realisations; the flux density for the
+entire sensor is thus calculated with 16 million realisations (`500 * 500
+* 64`). The sensor on which the flux density is calculated is a square with
+sides measuring *0.05* meter. Its center is positioned at the origin and points
+to the Z axis.
+
+ $ htrdr-combustion -v \
+ -m tetra.sth \
+ -p thermprops.atrtp \
+ -r refract_ids.atrri \
+ -l pos=0,0,0:tgt=0,1,0:up=0,0,1:sz=0.001,0.2 \
+ -w 500 \
+ -R pos=0,0,0:tgt=0,0,1:up=0,1,0:sz=0.05,0.05 \
+ -i def=500x500:spp=64 \
+ -O octree.cache \
+ -V 1000 \
+ -T 5 \
+ -o map.txt -f -s
Write into *octree.vtk* a representation of the volumetric acceleration
structure.
@@ -335,7 +398,9 @@ Sans et al, JQSRT, 2021 - <https://doi.org/10.1016/j.jqsrt.2021.107725>
COPYRIGHT
---------
Copyright © 2018, 2019, 2020, 2021 |Meso|Star> <contact@meso-star.com>.
+
Copyright © 2018, 2019, 2021 CNRS.
+
Copyright © 2018, 2019 Université Paul Sabatier
<contact-edstar@laplace.univ-tlse.fr>.
@@ -351,6 +416,7 @@ SEE ALSO
*atrtp*(5),
*atrri*(5),
*htrdr-atmosphere*(1),
+*htrdr-image*(5),
*htrdr-obj*(5),
*htrdr-materials*(5),
*mpirun*(1),
diff --git a/doc/htrdr-image.5.txt b/doc/htrdr-image.5.txt
@@ -22,7 +22,7 @@ htrdr-image(5)
NAME
----
-htrdr-image - format of the images generated by htrdr(1)
+htrdr-image - two dimensional image format
DESCRIPTION
-----------
@@ -30,47 +30,20 @@ The *htrdr-image* is a raw image file format where data are stored in plain
text. Characters after the '#' character are considered as comments and are
thus ignored as well as empty lines. The first valid line stores 2 unsigned
integers that represent the image definition, i.e. the number of pixels per
-line and per column. Then each line stores 8 pixel components.
-
-If the image is a regular rendering in the visible part of the spectrum, the
-pixel components are actually 4 pairs of floating points data representing the
-pixel color encoded in the CIE 1931 XYZ color space and the per radiative path
-computation time. The first, second and third pairs encode the estimated
-integrated radiance in W/sr/m^2 of the X, Y and Z pixel components,
-respectively. The first value of each pair is the expected value of the
-estimated radiance while the second one is its associated standard deviation.
-The fourth pair saves the estimate in microseconds of the per radiative path
-computation time and its standard error.
-
-If the image is an infrared rendering the first and second pixel components
-store the expected value and the standard error, respectively, of the
-estimated brightness temperature in Kelvin. The third and fourth components
-save the expected value and standard deviation of the pixel radiance that is
-either an integrated radiance in W/sr/m^2 or a spectral radiance in
-W/sr/m^2/nm whether this radiance is computed for a spectral range or for one
-wavelength. The fifth and sixth pixel components are unused. Finally the last
-2 pixel components save, as for a regular rendering, the estimate in
-microseconds of the per radiative path computation time and its standard
-error.
-
-If it was generating from a shortwave rendering the image is formatted as in
-longwave rendering mode exepted that the first and second pixel components are
-unused since no brightness temperature was evaluated in shortwave.
-
-For flux computations, the first and second pixel component stores the
-expected value and the standard error of the pixel flux in W/m^2. As
-previously, the seventh and eighth pixel components store the estimate of the
-radiative path computation time in microseconds and its standard error. The
-remaining components, i.e. the components 3 to 6, are unused.
+line and per column. Then each line stores 8 floating point components per
+pixel.
Pixels are sorted line by line, with the origin defined at the top left corner
of the image. With an image definition of N by M pixels, with N the number of
pixels per line and M the overall number of lines in the image, the first N
pixels correspond to the pixels of the top line of the image, the following N
-pixels are the pixels of the second line and so on.
+pixels are the pixels of the second line and so on.
-Note that the *htpp*(1) program can be used to convert an *htrdr-image* into a
-regular PPM image [1].
+The *htpp*(1) program can be used to convert an *htrdr-image* into a regular
+PPM image [1]. Note that the nature and unit of the data stored in an
+*htrdr-image* is not determined by the file format itself. Refer to the
+program that generates the image for a full description of the data it
+contains.
GRAMMAR
-------
