commit 386e7f2e37ec83c855ad31331f7a05f76d4e5350
parent 13a05812d570ece346542337139936ea8b571b4c
Author: Vincent Forest <vincent.forest@meso-star.com>
Date: Thu, 25 Apr 2024 16:35:54 +0200
Merge branch 'release_0.10' into develop
Diffstat:
| M | README.md | | | 111 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 111 insertions(+), 0 deletions(-)
diff --git a/README.md b/README.md
@@ -33,6 +33,117 @@ Edit config.mk as needed, then run:
## Release notes
+### Version 0.10
+
+#### New conduction algorithm
+
+Addition of a new algorithm for sampling a potentially unsteady
+conductive path. The new `-a` option lets you select the algorithm to be
+used, i.e. either the sphere delta algorithm used until now (which is
+still the default algorithm), or the new Walk on Sphere algorithm (WoS).
+
+This new algorithm samples an unbiased diffuse trajectory in a solid
+with Dirichlet boundary conditions, unbiased with respect to what
+numerical accuracy can account for. Its coupling with other boundary or
+connection conditions behaves as with the delta sphere algorithm, i.e.
+the solution is exact when the length of the trajectory used as a
+first-order approximation tends towards 0.
+
+Currently, when using WoS, the initial condition must be constant for
+the solid. The power density is also taken into account, but cannot
+vary in time and space.
+
+#### External spherical source
+
+An external spherical source can be added to the scene using the new
+stardis-input keyword `SPHERICAL_SOURCE`. 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.
+
+The external net flux is calculated by evaluating the direct and diffuse
+part of the incident flux due to the external source. 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 a `diffuse-radiance` parameter.
+
+An external spherical source is defined by its position, radius, power
+and diffuse radiance. While the radius is constant, all other parameters
+can be programmed using the `SPHERICAL_SOURCE_PROG` keyword. In doing
+so, the user can provide a shared object as input, enabling him to
+define a time-dependent power and position, and a diffuse radiance that
+also depends on the direction along which the sampled trajectory reaches
+the environment.
+
+#### Making surface radiative properties source-dependent
+
+Emissivity and specular fraction can now be varied according to the type
+of source (internal or external). This is only possible using
+programmable properties (`H_BOUNDARY_FOR_FLUID_PROG`,
+`HF_BOUNDARY_FOR_SOLID_PROG` and `SOLID_FLUID_PROG`). Properties are
+otherwise assumed to be the same for all sources.
+
+#### Make the radiative environment programmable
+
+Addition of the `TRAD_PROG` keyword, which allows the user to define a
+radiative temperature and a reference radiative temperature that depend
+on a direction.
+
+#### Parallelize the resolutions of multiple boundary probes
+
+Add the `-L` option to calculate multiple boundary probes at once.
+Stardis will then parallelize the probe list calculations, rather than
+each probe calculation one after the other. Using this option is
+therefore more advantageous in terms of load distribution when the
+number of boundary probes to be evaluated is large compared to the cost
+of calculating a single probe (option `-P`).
+
+#### 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 (i.e. option `-o` whose argument is greater than
+one).
+
+This is a file format break that users *must* take into account. Until
+now, negative temperatures were considered unknown, 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 completely different systems
+before and after this version.
+
+#### Use POSIX make as a build system
+
+The build procedure is now written in POSIX make instead of CMake.
+In addition to the features already provided by its CMake alternative,
+the Makefile supports the use of static libraries and provides an
+uninstall target. In any case, the main motivation behind its writing is
+to use a good old well-established standard with simple features,
+available on all UNIX systems, thus simplifying its portability and
+support while being much lighter
+
+#### Proof-reading and editing manual pages
+
+Write the man pages directly in mdoc's roff macros, instead of using the
+asciidoc markup language as a source for man pages.
+
+Unlike writing manuals with man's roff macros, and even more so with
+asciidoc, mdoc macros take care of layout, font handling and all the other
+typesetting details which, by construction, guarantee the consistency of
+all manuals without leaving the responsibility to the individual author.
+This also facilitates translation into other formats and documentation
+tools. These are the main reasons for writing manual pages with mdoc
+macros.
+
+A complete re-reading of the manual pages was carried out during the
+translation into mdoc, with several corrections and rewrites to make the
+manual clearer.
+
### Version 0.9
#### Programmable properties
