commit c5e25939e42078beba832e26f6bb352f88c5992e
parent 532270e78b4abfb770d1c4ab6bd7eaf644af0534
Author: Vincent Forest <vincent.forest@meso-star.com>
Date: Tue, 5 Dec 2023 15:10:22 +0100
Wraps the README text in 72 columns
This matches the convention of plain text e-mails. It can therefore be
sent as a publication announcement e-mail without being reformatted.
Diffstat:
| M | README.md | | | 557 | ++++++++++++++++++++++++++++++++++++++++++------------------------------------- |
1 file changed, 295 insertions(+), 262 deletions(-)
diff --git a/README.md b/README.md
@@ -1,92 +1,101 @@
# Stardis-Solver
-Stardis-Solver is *free software* that solves *coupled* convecto - conducto -
-radiative *thermal problems* in *complex* 2D and 3D *environments*. This C89
-library internally relies on *Monte-Carlo* algorithms based on reformulations
-of the main heat transfer phenomena as cross-recursive "thermal paths" that
-explore space and time until a boundary condition or an initial condition is
-found. The key concept here is that heat transfer phenomena are not considered
-separately but naturally coupled via cross-recursive [Monte-Carlo
+Stardis-Solver is *free software* that solves *coupled* convecto -
+conducto - radiative *thermal problems* in *complex* 2D and 3D
+*environments*. This C89 library internally relies on *Monte-Carlo*
+algorithms based on reformulations of the main heat transfer phenomena
+as cross-recursive "thermal paths" that explore space and time until a
+boundary condition or an initial condition is found. The key concept
+here is that heat transfer phenomena are not considered separately but
+naturally coupled via cross-recursive [Monte-Carlo
algorithms](https://hal.archives-ouvertes.fr/hal-02419604/).
The hypothesis these algorithms are based upon are the following:
-- *conduction*: the discretization of thermal heat transfer in solids introduces
- the notion of a conductive path length within the Monte-Carlo algorithm.
- Solutions obtained using this algorithm are formally exact at the limit of a
- null path length. In practice, this path length has to be adapted for a given
- geometric configuration so that its value is small compared to the smallest
- typical length of a solid.
+- *conduction*: the discretization of thermal heat transfer in solids
+ introduces the notion of a conductive path length within the
+ Monte-Carlo algorithm. Solutions obtained using this algorithm are
+ formally exact at the limit of a null path length. In practice, this
+ path length has to be adapted for a given geometric configuration so
+ that its value is small compared to the smallest typical length of a
+ solid.
- *convection*: fluid media are supposed to be isothermal, even if their
- temperature may vary with time. This hypothesis relies on the assumption of
- perfectly agitated fluids.
-- *radiation*: local radiative transfer is solved by an [iterative numerical
- method](https://hal.archives-ouvertes.fr/tel-03266863/) (Picard algorithm)
- that requires the knowledge of a reference temperature field. At the basic
- level (one level of recursion), and using a uniform reference temperature
- field, this algorithm translates into the hypothesis of a linearized
- radiative transfer. Using a higher order or recursion makes possible to
- converge the result closer to the solution of a rigorous
- spectrally-integrated radiative transfer (a difference of temperatures to the
- power 4 when integrated over the whole spectrum). The higher the recursion
- order, the better will be the convergence of the algorithm.
-
-In Stardis-Solver the system to simulate is represented by a *scene* whose
-geometry defines the contour of the object only: in contrast to legacy thermal
-solvers *no volumetric mesh* has to be provided. Each geometric primitive as an
-associated *interface* that defines its physical properties (e.g. surface
-emissivity) and reference the *media* defining the thermal properties on both
-side of the primitive. The boundary and initial conditions are defined defined
-on the interfaces (convection coefficient, fixed temperature/flux, etc.) and
-the media (known temperature). Once fully and consistently described,
-computations can be invoked on the resulting scene.
+ temperature may vary with time. This hypothesis relies on the
+ assumption of perfectly agitated fluids.
+- *radiation*: local radiative transfer is solved by an [iterative
+ numerical method](https://hal.archives-ouvertes.fr/tel-03266863/)
+ (Picard algorithm) that requires the knowledge of a reference
+ temperature field. At the basic level (one level of recursion), and
+ using a uniform reference temperature field, this algorithm translates
+ into the hypothesis of a linearized radiative transfer. Using a higher
+ order or recursion makes possible to converge the result closer to the
+ solution of a rigorous spectrally-integrated radiative transfer (a
+ difference of temperatures to the power 4 when integrated over the
+ whole spectrum). The higher the recursion order, the better will be
+ the convergence of the algorithm.
+
+In Stardis-Solver the system to simulate is represented by a *scene*
+whose geometry defines the contour of the object only: in contrast to
+legacy thermal solvers *no volumetric mesh* has to be provided. Each
+geometric primitive as an associated *interface* that defines its
+physical properties (e.g. surface emissivity) and reference the *media*
+defining the thermal properties on both side of the primitive. The
+boundary and initial conditions are defined defined on the interfaces
+(convection coefficient, fixed temperature/flux, etc.) and the media
+(known temperature). Once fully and consistently described, computations
+can be invoked on the resulting scene.
The main features of the solver are currently:
-- *probe computation*: Stardis-Solver will compute the temperature at any given
- position (spatial and temporal). The main idea is that thermal paths start
- from this probe position, and scatter in space while going back in time,
- until a (spatial) boundary condition or a (temporal) initial condition is
- met. In addition to the value of temperature, using a Monte-Carlo method
- makes possible to compute a numerical uncertainty (standard deviation of the
- weight distribution) over each result.
-- *flux computation*: Stardis-Solver can compute the flux over any surface (or
- group of surfaces) at any time. Alternatively, it can also compute the total
- energy output from a solid element where a internal source of power must be
- taken into account.
-- *green function*: the value of temperature computed at a probe position is
- the average of the Monte-Carlo weight for every thermal path. In practice:
- when no internal power sources have to be considered, the weight of any given
- thermal path is the temperature of the boundary or initial condition that has
- been reached; when internal power sources or imposed fluxes are taken into
- account, additional contributions to the weight must be continuously
- evaluated by the thermal conduction algorithm, but these contributions are
- proportional to the local dissipated power/imposed flux. In any case, the
- position and date at the end of each thermal path (and also accumulation
- coefficients) can be stored during a first complete Monte-Carlo simulation.
- This information, known as the Green function, can then be used in (very
- fast) post-processing to compute all required results for different boundary
- and initial conditions (and also different internal power sources/imposed
- flux). Note that when using the Green function, only boundary and initial
- conditions (as well as internal power sources) can be modified: in
- particular, the geometry, thermal properties and exchange coefficients have
- to remain identical. Furthermore, the green function is only valid under the
- assumption of linearized radiative transfer.
-- *path visualization*: Stardis-Solver can store the complete spatial and
- temporal position along a set of thermal paths, for latter visualization. In
- addition of their position and, each thermal path vertex register additional
- data as the type of thermal phenomena it simulates, the accumulated
- power/flux along the path, etc.
+- *probe computation*: Stardis-Solver will compute the temperature at
+ any given position (spatial and temporal). The main idea is that
+ thermal paths start from this probe position, and scatter in space
+ while going back in time, until a (spatial) boundary condition or a
+ (temporal) initial condition is met. In addition to the value of
+ temperature, using a Monte-Carlo method makes possible to compute a
+ numerical uncertainty (standard deviation of the weight distribution)
+ over each result.
+- *flux computation*: Stardis-Solver can compute the flux over any
+ surface (or group of surfaces) at any time. Alternatively, it can also
+ compute the total energy output from a solid element where a internal
+ source of power must be taken into account.
+- *green function*: the value of temperature computed at a probe
+ position is the average of the Monte-Carlo weight for every thermal
+ path. In practice: when no internal power sources have to be
+ considered, the weight of any given thermal path is the temperature of
+ the boundary or initial condition that has been reached; when internal
+ power sources or imposed fluxes are taken into account, additional
+ contributions to the weight must be continuously evaluated by the
+ thermal conduction algorithm, but these contributions are proportional
+ to the local dissipated power/imposed flux. In any case, the position
+ and date at the end of each thermal path (and also accumulation
+ coefficients) can be stored during a first complete Monte-Carlo
+ simulation. This information, known as the Green function, can then
+ be used in (very fast) post-processing to compute all required results
+ for different boundary and initial conditions (and also different
+ internal power sources/imposed flux). Note that when using the Green
+ function, only boundary and initial conditions (as well as internal
+ power sources) can be modified: in particular, the geometry, thermal
+ properties and exchange coefficients have to remain identical.
+ Furthermore, the green function is only valid under the assumption of
+ linearized radiative transfer.
+- *path visualization*: Stardis-Solver can store the complete spatial
+ and temporal position along a set of thermal paths, for latter
+ visualization. In addition of their position and, each thermal path
+ vertex register additional data as the type of thermal phenomena it
+ simulates, the accumulated power/flux along the path, etc.
Stardis-Solver is currently used in two frameworks. The
-[Stardis](https://gitlab.com/meso-star/stardis.git) CLI and its associated
-tools is the reference workflow of Stardis-Solver. It proposes a complete
-toolchain from fileformats describing the scene (geometry, thermal properties,
-limit and boundary conditions) to computations and post-treatments of the
-results ([Stardis-Green](https://gitlab.com/meso-star/stardis-green.git)).
+[Stardis](https://gitlab.com/meso-star/stardis.git) CLI and its
+associated tools is the reference workflow of Stardis-Solver. It
+proposes a complete toolchain from fileformats describing the scene
+(geometry, thermal properties, limit and boundary conditions) to
+computations and post-treatments of the results
+([Stardis-Green](https://gitlab.com/meso-star/stardis-green.git)).
Stardis-Solver is also integrated into
[SYRTHES](https://www.edf.fr/en/the-edf-group/world-s-largest-power-company/activities/research-and-development/scientific-communities/simulation-softwares?logiciel=10818),
-the general thermal free software developed by Electricité De France (EDF).
+the general thermal free software developed by Electricité De France
+(EDF).
## Requirements
@@ -113,190 +122,205 @@ Edit config.mk as needed, then run:
- The net flux imposed can be combined with other boundary/connection
conditions, i.e. a net flux can be set in addition to convective
exchange and radiative transfer.
-- Added support for plain text log messages. Until now, log messages were
- intended to be read by a VT100-like terminal and could therefore contain
- escape sequences that required post-processing to store them in plain text
- log files.
-- Added support for user-defined signature on the green function. It allows to
- check that, when reloaded, a green function is the one expected by the user
- according to its own constraints that the green function cannot check itself
- such as, for example, that the same deltas are used in conductive random
- walks.
-- Changes the value of the constant `SDIS_VOLUMIC_POWER_NONE`. Its previous
- value of zero caused problems during the evaluation of the propagator: a
- media with a power density of zero was not registered in the list of media
- with a volumic power. A volumic power that was not zero was therefore not
- taken into account during the re-evaluation of the propagator. The constant
- is now set to `DBL_MAX`, which means that the medium has no power density,
- while a value of 0 is now treated as any valid power density term.
+- Added support for plain text log messages. Until now, log messages
+ were intended to be read by a VT100-like terminal and could therefore
+ contain escape sequences that required post-processing to store them
+ in plain text log files.
+- Added support for user-defined signature on the green function. It
+ allows to check that, when reloaded, a green function is the one
+ expected by the user according to its own constraints that the green
+ function cannot check itself such as, for example, that the same
+ deltas are used in conductive random walks.
+- Changes the value of the constant `SDIS_VOLUMIC_POWER_NONE`. Its
+ previous value of zero caused problems during the evaluation of the
+ propagator: a media with a power density of zero was not registered in
+ the list of media with a volumic power. A volumic power that was not
+ zero was therefore not taken into account during the re-evaluation of
+ the propagator. The constant is now set to `DBL_MAX`, which means that
+ the medium has no power density, while a value of 0 is now treated as
+ any valid power density term.
### Version 0.13.1
-Fixed compilation errors and compilation warnings displayed on some versions of
-GCC.
+Fixed compilation errors and compilation warnings displayed on some
+versions of GCC.
### Version 0.13
#### Non linear radiative transfer
Uses a new [iterative numerical
-method](https://hal.archives-ouvertes.fr/tel-03266863/) to estimate radiative
-transfer. With a recursion level of 1, this is equivalent to a linearization of
-the radiative transfer but with a reference temperature that can vary in time
-and space. By using a higher-order recursion, one can converge towards a
-rigorous estimate that takes into account the non-linearity of the radiative
-transfer; the higher the recursion order, the better the convergence, but with
-the counterpart of an increase in calculation time.
+method](https://hal.archives-ouvertes.fr/tel-03266863/) to estimate
+radiative transfer. With a recursion level of 1, this is equivalent to a
+linearization of the radiative transfer but with a reference temperature
+that can vary in time and space. By using a higher-order recursion, one
+can converge towards a rigorous estimate that takes into account the
+non-linearity of the radiative transfer; the higher the recursion order,
+the better the convergence, but with the counterpart of an increase in
+calculation time.
#### Distributed memory parallelism
Uses message passing interface to distribute computation across multiple
-computers. Stardis-Solver now, uses a mixed parallelism: on one computer (i.e.
-a node), it uses a shared memory parallelism and relies on the message passing
-interface to parallelize calculations between several nodes.
+computers. Stardis-Solver now, uses a mixed parallelism: on one computer
+(i.e. a node), it uses a shared memory parallelism and relies on the
+message passing interface to parallelize calculations between several
+nodes.
#### Type and state of the random number generator
-Adds the member input variable `rng_type` to the solve functions. It defines
-the type of random number generator to use when no generator is defined. Note
-that the `sdis_solve_camera` function does not have a random number generator
-as an input variable and has therefore been updated to support it.
+Adds the member input variable `rng_type` to the solve functions. It
+defines the type of random number generator to use when no generator is
+defined. Note that the `sdis_solve_camera` function does not have a
+random number generator as an input variable and has therefore been
+updated to support it.
#### Reading the source code
-Refactoring and deep rewriting of the source code to simplify its reading.
+Refactoring and deep rewriting of the source code to simplify its
+reading.
### Version 0.12.3
-Fix green paths ending in a fluid (transcient computation): The path's end was
-not correctly registred and the path was later treated as failed.
+Fix green paths ending in a fluid (transcient computation): The path's
+end was not correctly registred and the path was later treated as
+failed.
### Version 0.12.2
-- Sets the required version of Star-SampPling to 0.12. This version fixes
- compilation errors with gcc 11 but introduces API breaks.
+- Sets the required version of Star-SampPling to 0.12. This version
+ fixes compilation errors with gcc 11 but introduces API breaks.
- Fix warnings detected by gcc 11.
### Version 0.12.1
-Updates the way numerical issues are handled during a conductive random walk.
-Previously, a zealous test would report a numerical error and stop the
-calculations when that error could be handled.
+Updates the way numerical issues are handled during a conductive random
+walk. Previously, a zealous test would report a numerical error and
+stop the calculations when that error could be handled.
### Version 0.12
-Add the support of thermal contact resistance between two solids: the new
-`thermal_contact_resistance` functor on the data structure `struct
-sdis_interface_shader` defines the thermal resistance contact in K.m^2.W^-1 at
-a given time and at a specific position onto the interface.
+Add the support of thermal contact resistance between two solids: the
+new `thermal_contact_resistance` functor on the data structure `struct
+sdis_interface_shader` defines the thermal resistance contact in
+K.m^2.W^-1 at a given time and at a specific position onto the
+interface.
### Version 0.11
-- Add support of unsteady green evaluation. The resulting green function can
- then be used to quickly evaluate the system at the same time but with
- different limit and initial conditions, volumetric powers and imposed fluxes.
-- Add checks on green re-evaluation to ensure that the system remains unchanged
- regarding its scale factor and its reference temperature.
-- Remove the ambient radiative temperature, the reference temperature and the
- geometry scale factor from the list of arguments submitted to the solve
- functions. They become scene arguments defined on scene creation.
+- Add support of unsteady green evaluation. The resulting green function
+ can then be used to quickly evaluate the system at the same time but
+ with different limit and initial conditions, volumetric powers and
+ imposed fluxes.
+- Add checks on green re-evaluation to ensure that the system remains
+ unchanged regarding its scale factor and its reference temperature.
+- Remove the ambient radiative temperature, the reference temperature
+ and the geometry scale factor from the list of arguments submitted to
+ the solve functions. They become scene arguments defined on scene
+ creation.
- Update the `sdis_scene_[2d_]create` function profile: its data are now
grouped into a variable of type `struct sdis_scene_create_args`.
### Version 0.10.1
-- In green function estimation, the time sent to the user callbacks is no more
- the elapsed time from the beginning of the realisation: as in a regular
- computation, it is now the observation time.
+- In green function estimation, the time sent to the user callbacks is
+ no more the elapsed time from the beginning of the realisation: as in
+ a regular computation, it is now the observation time.
- Fix the flux computation for boundaries with an imposed flux: it was
previously ignored. The new `sdis_estimator_get_imposed_flux` function
returns this estimated flux component.
-- Return an error if the flux is computed at a boundary whose temperature is
- known: this configuration is not currently supported.
+- Return an error if the flux is computed at a boundary whose
+ temperature is known: this configuration is not currently supported.
- Fix build with the CL compiler.
### Version 0.10
- Add support of green function [de]serialization. The
- `sdis_green_function_write` function serializes the green function into a
- stream while the `sdis_green_function_create_from_stream` function
- deserialize it. Note that the scene used to deserialize the green function
- must be the same of the one used to estimate it: the media and the interfaces
- have to be created in the same order, the scene geometry must be the same,
- etc.
-- Add the `sdis_scene_find_closest_point` function: search the point onto the
- scene geometry that is the closest of the submitted position.
-- Add the `sdis_compute_power` function that evaluates the power of a medium.
+ `sdis_green_function_write` function serializes the green function
+ into a stream while the `sdis_green_function_create_from_stream`
+ function deserialize it. Note that the scene used to deserialize the
+ green function must be the same of the one used to estimate it: the
+ media and the interfaces have to be created in the same order, the
+ scene geometry must be the same, etc.
+- Add the `sdis_scene_find_closest_point` function: search the point
+ onto the scene geometry that is the closest of the submitted position.
+- Add the `sdis_compute_power` function that evaluates the power of a
+ medium.
- Update the solver: the time of the sampled path is now rewind on solid
reinjection.
### Version 0.9
-- Update the API of the solve functions: the parameters of the simulation are
- now grouped into a unique data structure rather than separately submitted as
- function arguments. Thank to this structure and its default value, updating
- input parameters should now affect marginally the calling code.
-- Improve the logger. Add a prefix to the printed text to indicate the type of
- the message (info, error or warning). Add a progress message during
- simulation.
+- Update the API of the solve functions: the parameters of the
+ simulation are now grouped into a unique data structure rather than
+ separately submitted as function arguments. Thank to this structure
+ and its default value, updating input parameters should now affect
+ marginally the calling code.
+- Improve the logger. Add a prefix to the printed text to indicate the
+ type of the message (info, error or warning). Add a progress message
+ during simulation.
- Bump the version of the Star-Enclosures <2D|3D> dependencies to 0.5
### Version 0.8.2
-- Fix an issue when the `sdis_solve_boundary_flux` function was invoked on a
- boundary with radiative transfer: several sampled paths were rejected due to
- data inconsistencies.
+- Fix an issue when the `sdis_solve_boundary_flux` function was invoked
+ on a boundary with radiative transfer: several sampled paths were
+ rejected due to data inconsistencies.
- Fix a memory leak when the scene creation failed.
-- Enable parallelism on Star-Enclosure[2D] to improve the performances of the
- enclosure extraction on the setup of the Stardis-Solver scene.
+- Enable parallelism on Star-Enclosure[2D] to improve the performances
+ of the enclosure extraction on the setup of the Stardis-Solver scene.
### Version 0.8.1
- Fix a solver issue that led to reject valid sampled paths.
-- Bump the version of the Star-Enclosure[2D] libraries to 0.4.2. These versions
- fix a numerical issue that might led to an infinite loop at the scene creation.
+- Bump the version of the Star-Enclosure[2D] libraries to 0.4.2. These
+ versions fix a numerical issue that might led to an infinite loop at
+ the scene creation.
### Version 0.8
-- Drastically improve the robustness of the solver~: far less realisations are
- now rejected.
+- Drastically improve the robustness of the solver~: far less
+ realisations are now rejected.
- Add the estimation of the time spent per realisation estimate. Add the
- `sdis_estimator_get_realisation_time` function that returns this estimate.
-- Add the `sdis_estimator_buffer` API~: it manages a two dimensional array of
- regular estimators and provides global estimations over the whole estimators
- saved into the buffer.
-- Update the signature of the `sdis_solve_camera` function~: it now returns a
- `sdis_estimator_buffer`. It now also supports time integration as well as
- heat paths registration.
+ `sdis_estimator_get_realisation_time` function that returns this
+ estimate.
+- Add the `sdis_estimator_buffer` API~: it manages a two dimensional
+ array of regular estimators and provides global estimations over the
+ whole estimators saved into the buffer.
+- Update the signature of the `sdis_solve_camera` function~: it now
+ returns a `sdis_estimator_buffer`. It now also supports time
+ integration as well as heat paths registration.
### Version 0.7
#### Add Green function support
-Provide new solve functions that compute and save the Green function, i.e. the
-propagator used in regular solvers. The resulting Green function can be then
-evaluated to obtain an estimate of the temperature.
-
-The time spent to compute the Green function is comparable to the computation
-time of regular solvers; actually, they rely on the same code. However, its
-evaluation is instantaneous while it still handles the limit conditions, the
-boundary fluxes and the power term of the media *at the moment* of the
-evaluation. This means that one can estimate the Green function of a system
-only one time and then evaluate it with different limit conditions, boundary
-fluxes or power terms with negligible computation costs.
-
-Currently, Stardis-Solver assumes that during the Green function estimation,
-the properties of the system do not depend on time. In addition, it assumes
-that the boundary fluxes and the volumetric powers are constants in time and
-space. Anyway, on Green function evaluation, the limit conditions of the
-system can still vary in time and space; systems in steady state can be
-simulated with Green functions.
+Provide new solve functions that compute and save the Green function,
+i.e. the propagator used in regular solvers. The resulting Green
+function can be then evaluated to obtain an estimate of the temperature.
+
+The time spent to compute the Green function is comparable to the
+computation time of regular solvers; actually, they rely on the same
+code. However, its evaluation is instantaneous while it still handles
+the limit conditions, the boundary fluxes and the power term of the
+media *at the moment* of the evaluation. This means that one can
+estimate the Green function of a system only one time and then evaluate
+it with different limit conditions, boundary fluxes or power terms with
+negligible computation costs.
+
+Currently, Stardis-Solver assumes that during the Green function
+estimation, the properties of the system do not depend on time. In
+addition, it assumes that the boundary fluxes and the volumetric powers
+are constants in time and space. Anyway, on Green function evaluation,
+the limit conditions of the system can still vary in time and space;
+systems in steady state can be simulated with Green functions.
#### Add heat path registration
-Add the `int register_paths` mask to almost all solve functions to enable the
-registration against the returned estimator of the failure and/or successful
-random paths used by the solvers. For each path, the registered data are:
+Add the `int register_paths` mask to almost all solve functions to
+enable the registration against the returned estimator of the failure
+and/or successful random paths used by the solvers. For each path, the
+registered data are:
- the vertices of the path;
- the type of the path (failed or succeed);
@@ -304,119 +328,127 @@ random paths used by the solvers. For each path, the registered data are:
- the Monte-Carlo weight of each path vertex;
- the current time of each path vertex.
-Note that the amount of registered data can be huge if too more paths are
-registered. Consequently, this functionality should be used with few
-realisations to obtain a subset of representative paths, or to only register
-the few paths that failed in order to diagnose what went wrong.
+Note that the amount of registered data can be huge if too more paths
+are registered. Consequently, this functionality should be used with
+few realisations to obtain a subset of representative paths, or to only
+register the few paths that failed in order to diagnose what went wrong.
#### Miscellaneous
-- Add the `sdis_solve_medium` function: it estimates the average temperature
- of a medium.
-- Fix the setup of the interfaces: the interface associated to a geometric
- primitive could not be the right one.
+- Add the `sdis_solve_medium` function: it estimates the average
+ temperature of a medium.
+- Fix the setup of the interfaces: the interface associated to a
+ geometric primitive could not be the right one.
### Version 0.6.1
-- Bump version of the Star-Enclosures[2D] dependencies: the new versions fix
- issues in the construction of fluid enclosures.
-- Bump version of the Star-<2D|3D> dependencies: the new versions rely on
- Embree3 rather than on Embree2 for their ray-tracing back-end.
+- Bump version of the Star-Enclosures[2D] dependencies: the new versions
+ fix issues in the construction of fluid enclosures.
+- Bump version of the Star-<2D|3D> dependencies: the new versions rely
+ on Embree3 rather than on Embree2 for their ray-tracing back-end.
### Version 0.6
-- Add the `sdis_solve_boundary` function: it computes the average temperature
- on a subset of geometric primitives.
+- Add the `sdis_solve_boundary` function: it computes the average
+ temperature on a subset of geometric primitives.
- Add flux solvers: the new `sdis_solve_probe_boundary_flux` and
- `sdis_solve_boundary_flux` functions estimate the convective and radiative
- fluxes at a given surface position or for a sub-set of geometric primitives,
- respectively.
-- Add support of time integration: almost all solvers can estimate the average
- temperature on a given time range. Only the `sdis_solve_camera` function does
- not support time integration, yet.
+ `sdis_solve_boundary_flux` functions estimate the convective and
+ radiative fluxes at a given surface position or for a sub-set of
+ geometric primitives, respectively.
+- Add support of time integration: almost all solvers can estimate the
+ average temperature on a given time range. Only the
+ `sdis_solve_camera` function does not support time integration, yet.
- Add support of an explicit initial time `t0` for the fluid.
-- Fix a bug in the estimation of unknown fluid temperatures: the associativity
- between the internal Stardis-Solver data and the user defined data was wrong.
+- Fix a bug in the estimation of unknown fluid temperatures: the
+ associativity between the internal Stardis-Solver data and the user
+ defined data was wrong.
### Version 0.5
Add support of fluid enclosure with unknown uniform temperature.
- The convection coefficient of the surfaces surrounding a fluid whose
- temperature is unknown can vary in time and space. Anyway, the caller has to
- ensure that for each triangle of the fluid enclosure, the convection
- coefficient returned by its `struct sdis_interface_shader` - at a given
- position and time - is less than or equal to the `convection_coef_upper_bound`
- parameter of the shader.
+ temperature is unknown can vary in time and space. Anyway, the caller
+ has to ensure that for each triangle of the fluid enclosure, the
+ convection coefficient returned by its
+ `struct sdis_interface_shader` - at a given position and time - is
+ less than or equal to the `convection_coef_upper_bound` parameter of
+ the shader.
### Version 0.4
Full rewrite of how the volumetric power is taken into account.
- Change the scheme of the random walk "solid re-injection": use a 2D
- re-injection scheme in order to handle 2D effects. On one hand, this scheme
- drastically improves the accuracy of the temperature estimation in solid with
- a volumetric power term. On the other hand it is more sensible to numerical
- imprecisions. The previous 1D scheme is thus used in situations where the 2D
- scheme exhibits too numerical issues, i.e. on sharp angles.
+ re-injection scheme in order to handle 2D effects. On one hand, this
+ scheme drastically improves the accuracy of the temperature estimation
+ in solid with a volumetric power term. On the other hand it is more
+ sensible to numerical imprecisions. The previous 1D scheme is thus
+ used in situations where the 2D scheme exhibits too numerical issues,
+ i.e. on sharp angles.
- Add the missing volumetric power term on solid re-injection.
-- Add a corrective term to fix the bias on the volumetric power introduced when
- the random walk progresses at a distance of `delta` of a boundary.
+- Add a corrective term to fix the bias on the volumetric power
+ introduced when the random walk progresses at a distance of `delta` of
+ a boundary.
- Add several volumetric power tests.
-- Remove the `delta_boundary` parameter of the `struct sdis_solid_shader` data
- structure.
+- Remove the `delta_boundary` parameter of the `struct
+ sdis_solid_shader` data structure.
### Version 0.3
-- Some interface properties become double sided: the temperature, emissivity
- and specular fraction is defined for each side of the interface. Actually,
- only the convection coefficient is shared by the 2 sides of the interface.
- The per side interface properties are grouped into the new `struct
- sdis_interface_side_shader` data structure.
-- Add the support of fixed fluxes: the flux is a per side interface property.
- Currently, the flux is handled only for the interface sides facing a solid
- medium.
+- Some interface properties become double sided: the temperature,
+ emissivity and specular fraction is defined for each side of the
+ interface. Actually, only the convection coefficient is shared by the
+ 2 sides of the interface. The per side interface properties are
+ grouped into the new `struct sdis_interface_side_shader` data
+ structure.
+- Add the support of fixed fluxes: the flux is a per side interface
+ property. Currently, the flux is handled only for the interface sides
+ facing a solid medium.
- Add the `sdis_scene_boundary_project_pos` function that computes the
- parametric coordinates of a world space position projected onto a given
- primitive with respect to its normal. If the projection lies outside the
- primitive, its parametric coordinates are wrapped against its boundaries in
- order to ensure that they are valid coordinates into the primitive. Actually,
- this function was mainly added to help in the definition of the probe
- position onto a boundary as expected by the
+ parametric coordinates of a world space position projected onto a
+ given primitive with respect to its normal. If the projection lies
+ outside the primitive, its parametric coordinates are wrapped against
+ its boundaries in order to ensure that they are valid coordinates into
+ the primitive. Actually, this function was mainly added to help in the
+ definition of the probe position onto a boundary as expected by the
`sdis_solve_probe_boundary` function.
-- Update the default comportment of the interface shader when a function is not
- set.
-- Rename the `SDIS_MEDIUM_<FLUID|SOLID>` constants in `SDIS_<FLUID|SOLID>`.
-- Rename the `enum sdis_side_flag` enumerate in `enum sdis_side` and update its
- values.
+- Update the default comportment of the interface shader when a function
+ is not set.
+- Rename the `SDIS_MEDIUM_<FLUID|SOLID>` constants in
+ `SDIS_<FLUID|SOLID>`.
+- Rename the `enum sdis_side_flag` enumerate in `enum sdis_side` and
+ update its values.
### Version 0.2
-- Add the support of volumic power to solid media: add the `volumic_power`
- functor to the `sdis_solid_shader` data structure that, once defined, should
- return the volumic power of the solid at a specific position and time. On
- solve invocation, the conductive random walks take into account this
- spatio-temporal volumic power in the computation of the solid temperature.
-- Add the `sdis_solve_probe_boundary` function: it computes the temperature at
- a given position and time onto a geometric primitive. The probe position is
- defined by the index of the primitive and a parametric coordinates onto it.
-- Add the `sdis_scene_get_boundary_position` function: it computes a world
- space position from the index of a geometric primitive and a parametric
- coordinate onto it.
-- Fix how the `sdis_solve_probe` was parallelised. The submitted `threads_hint`
- parameter was not correctly handled.
+- Add the support of volumic power to solid media: add the
+ `volumic_power` functor to the `sdis_solid_shader` data structure
+ that, once defined, should return the volumic power of the solid at a
+ specific position and time. On solve invocation, the conductive random
+ walks take into account this spatio-temporal volumic power in the
+ computation of the solid temperature.
+- Add the `sdis_solve_probe_boundary` function: it computes the
+ temperature at a given position and time onto a geometric primitive.
+ The probe position is defined by the index of the primitive and a
+ parametric coordinates onto it.
+- Add the `sdis_scene_get_boundary_position` function: it computes a
+ world space position from the index of a geometric primitive and a
+ parametric coordinate onto it.
+- Fix how the `sdis_solve_probe` was parallelised. The submitted
+ `threads_hint` parameter was not correctly handled.
### Version 0.1
- Add the support of radiative temperature.
- Add the `sdis_camera` API: it defines a pinhole camera into the scene.
-- Add the `sdis_accum_buffer` API: it is a pool of MC accumulators, i.e. a sum
- of MC weights and square weights.
-- Add the `sdis_solve_camera` function: it relies on a `sdis_camera` and a
- `sdis_accum_buffer` to compute the radiative temperature that reaches each
- pixel of an image whose definition is defined by the caller. Note that
- actually this function uses the same underlying MC algorithm behind the
- `sdis_solve_probe` function.
+- Add the `sdis_accum_buffer` API: it is a pool of MC accumulators, i.e.
+ a sum of MC weights and square weights.
+- Add the `sdis_solve_camera` function: it relies on a `sdis_camera` and
+ a `sdis_accum_buffer` to compute the radiative temperature that
+ reaches each pixel of an image whose definition is defined by the
+ caller. Note that actually this function uses the same underlying MC
+ algorithm behind the `sdis_solve_probe` function.
### Version 0.0
@@ -424,8 +456,9 @@ First version and implementation of the Stardis-Solver API.
- Support fluid/solid and solid/solid interfaces.
- Only conduction is currently fully supported: convection and radiative
- temperature are not computed yet. Fluid media can be added to the system but
- currently, Stardis-Solver assumes that their temperature are known.
+ temperature are not computed yet. Fluid media can be added to the
+ system but currently, Stardis-Solver assumes that their temperature
+ are known.
## License
