Stardis Solver Release Notes git repository

Version 0.15.2

Correction of pkg-config file. A missing private dependency could lead to link editing errors when the user statically links to the library.

Version 0.15.1

Make the radiative environment time-dependent, so that it can vary not only with respect to the direction along path that reaches it, but also as a function of time at which it is reached.

Version 0.15

New conduction algorithm

Addition of a new algorithm for sampling a potentially unsteady conductive path based on the Walk on Sphere (WoS) algorithm. Currently, unlike the previous delta sphere algorithm, the initial condition must be constant for the solid. Power density is also supported, but unlike the delta sphere algorithm, it too cannot vary in time and space. In all cases, the two algorithms coexist and can be selected via a new input parameter to the resolution functions. By default, the delta sphere algorithm is used.

Note that the WoS algorithm is considered unbiased when sampling a diffuse trajectory in a solid with Dirichlet boundary conditions. Even if a numerical parameter is used to stop the algorithm when the trajectory is close to the boundary, this distance can be set to the machine's accuracy without significant impact on performance. Hence its unbiased nature in relation to numerical precision. Its coupling with other boundary or connection conditions behaves as with the delta sphere algorithm, i.e. the solution tends towards the exact solution when the delta tends towards 0.

External spherical source

An external spherical source can be added to the scene. Once defined, it is considered as a new boundary condition whose contribution is calculated at the solid/fluid interfaces in the form of an external net flux. A new interface parameter controls on which solid/fluid interfaces this external net flux is imposed. By default, when an external source is defined, its contribution is calculated on all solid/fluid interfaces. We point out that the radiative properties of the surface can now vary according to the radiative source, which can now be internal or external.

The net external flux is calculated by sampling the radiative paths to evaluate the direct and diffuse part of the incident flux due to the external source. We emphasize that Stardis-Solver does not manage semi-traparent media, but that the external source provides the optional diffuse_radiance parameter which, once defined, corresponds to the radiance emitted by the external source and diffused at least once into the environment. In this way, the diffuse part of the flux manages not only the radiation from the external source that reaches the interface after one or more reflections, but also the external radiation scattered in the environment, here simply represented by the diffuse_radiance parameter.

The external spherical source is defined by its position, radius, power and diffuse radiance (see above). While the radius is constant, the position and power are time-dependent, and the diffuse radiance also depends on the direction along which the sampled trajectory reaches the environment.

The external spherical source is fully supported when estimating the green function. Only the positions of the spherical source must remain the same between green function estimation and use.

Finally, as with net imposed fluxes and power densities, this external source term cannot be used when solving non-linear radiative exchanges using Picard iterations.

Allow relative temperatures

Allow to perform calculations relative to a given temperature T. In this case, the temperatures managed by Stardis would be relative to T and could therefore be negative, since they would express a deviation from T. It should be noted that reference temperatures must always be positive, i.e. expressed in the absolute domain. Finally, we emphasize that relative calculations only make sense in linear situations, i.e. negative temperatures are not valid for systems with non-linear radiative exchanges.

This is a major break in the API that callers must take into account. Until now, negative temperatures were considered as unknown temperatures, whereas they are now valid. For example, an interface with a negative temperature could be considered adiabatic, whereas it is now a Dirichlet boundary condition. In other words, the same data could define totally different systems before or after this version.

The macro SDIS_TEMPERATURE_NONE is added to define the unknown temperature value. The two helper macros SDIS_TEMPERATURE_IS_KNONW and SDIS_TEMPERATURE_IS_UNKNONW are also provided to test whether the temperature is known or not.

Parallelize multiple probe resolutions

Add sdis_solve_probe_list and sdis_solve_probe_boundary_list functions. Unlike their single-probe counterpart, these functions parallelize the list of probes, rather than parallelizing Monte Carlo realizations. Calling these functions is therefore more advantageous in terms of load distribution when the number of probes to be evaluated is large compared to the cost of calculating a single probe.

Miscellaneous

Version 0.14

Version 0.13.1

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 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.

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.

Reading the source code

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.

Version 0.12.2

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.

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.

Version 0.11

Version 0.10.1

Version 0.10

Version 0.9

Version 0.8.2

Version 0.8.1

Version 0.8

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.

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:

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

Version 0.6.1

Version 0.6

Version 0.5

Add support of fluid enclosure with unknown uniform temperature.

Version 0.4

Full rewrite of how the volumetric power is taken into account.

Version 0.3

Version 0.2

Version 0.1

Version 0.0

First version and implementation of the Stardis-Solver API.