Release notes
The format used for this changelog
is based on Keep a Changelog, and this project adheres to Semantic Versioning. Notice that until the package reaches version v1.0.0
minor releases are likely to be breaking
. Starting from version v0.3.1
breaking changes will be recorded here.
Version v0.5.1 - 2025-07-03
Added
- New
Empty
boundary condition allowing 2D simulations with OpenFOAM 2D-compatible grids#63 - Tests for the
Smagorinsky
LES model have been included #63
Fixed
- No fixes included
Changed
- Transient simulation results for
VTK
andVTU
files use the formattime_<iteration>
#63
Breaking
- No breaking changes
Deprecated
- No functions deprecated
Removed
- No functionality has been removed
Version v0.5.0 - 2025-06-28
Added
- New boundary conditions
Extrapolated
andZerogradient
have been added. Both assign a zero gradient boundary condition, however, their implementation differs.Extrapolated
assigns the zero gradient condition semi-implicitly (using the cell centre unknown and the cell centre value from the previous iteration).Zerogradient
assigns the gradient in the boundary faces explicitly #61 - The workgroup size for the CPU backend can now be automatically chosen when
workgroup=AutoTune()
. This uses a simple ceiling division internally where the number of elements in the kernel are divided by the number of available threads. This results in a small 10% performance gain #61
Fixed
- Fixed the implementation for the calculation of the wall distance to work on GPUs #49
- The new approach for handling user-provided boundary conditions now allows extracting the wall velocity specified by the user for the
Wall
boundary condition #61
Changed
- In the calculation of wall function properties the user-provided wall velocity is now used, instead of hard-coded to no-slip #49
- The functions
set_production!
,set_cell_value!
andcorrect_nut_wall!
, inRANS_functions.jl
have been updated, removing conditional branch used in the generated calling them. Now these functions use multiple dispatch to allow specialising the wall function framework to ease the development of new wall functions #57 - New
NeumannFunction
has been created, mirroring the DirichletFunction, providing a Neumann boundary condition defined with a user-provided struct (a generic framework accepting a function to set the gradient at the boundary is not yet available) #57 update_user_boundary
function, extension has been reverted, overwriting the changes made to expose theModelEquation
type to it in #55- User-provided boundary conditions are no longer stored within fields, instead a
NamedTuple
is constructed using the functionassign
, which is passed to solvers using theConfiguration
struct. - Configuration setting provided by the user at the top-level API are now stored in predefined structs, instead of using
NamedTuples
, this change should put less pressure on the compiler #61 - Internally, kernel launches have been updated to use a static
NDrange
. This resulted in a 20% speed improvement on GPU backends (only NVidia GPUs tested) #61
Breaking
- The definition of Krylov solvers in the previous API used types exported directly from
Krylov.jl
. Now solvers are defined using instances of types defined inXCALibre.jl
. As an example, previously the CG solver was defined using the typeCgSolver
now this solver is defined using the instanceCg()
where the suffix "Solver" has been dropped. This applies to all previously available solver choices #60 - The Green-Gauss method for calculating the gradient is now
Gauss
which is more descriptive than the previous nameOrthogonal
- The internals for handling user-provided boundary conditions have been updated in preparation for extending the code for handling multiple regions. Thus, the syntax for assigning boundary conditions has changed. The most noticeable change is the removal of the the
@assign!
macro, replaced by the functionassign
. See the documentation for details #61 - The
set_solver
,set_hardware
andset_runtime
top-level functions have been replaced withSolverSetup
,Hardware
andRuntime
structures. This allowed storing user-provided setup information in structs instead ofNamedTuples
to reduce the burden on the compiler #61 - The implementation of the
FixedTemperature
boundary condition has been simplified, resulting in a breaking change. The definition of the boundary condition now requires users to provide anEnthalphy
model. This interface should make it easier to extend the current implementation to new forms of the energy equation #61
Deprecated
- No functions deprecated
Removed
- The functions
set_solver
,set_runtime
,set_hardware
and the macro@assign!
have been removed/replaced #61
Version v0.4.2 - 2025-04-02
Added
- A very simple 2D block mesh generator has been added (not ready for general use as it needs to be documented)#41
- Implementation of
Wall
boundary conditions specialised forScalarField
#45 - Simulation results can now be written to
VTK
andOpenFOAM
formats. The format can be selected using theoutput
keyword argument in therun!
function. The formats available areVTK()
andOpenFOAM()
#47
Fixed
- Fixed the implementation for the calculation of the wall distance #45
Changed
- In preparation for hybrid RANS/LES models, the object
Turbulence
is now passed to theTurbulenceModel
object to allow for a more general call ofturbulence!
. This changes the implementation ofturbulence!
for all models slightly #46 - Improved stability on meshes with warped faces by changing how face normals are calculated. XCALibre now uses an area-weighted face normal calculation based on the decomposition of faces into triangles #47
- Removed
VTK
module and moved functionality to a newIOFormats
module #47 - Internally the function
model2vtk
has been replaced withsave_output
within all solvers. The specialisation for writingModelPhysics
models to file has also changed tosave_output
. The arguements pass to this function have also changed, thename
of the file is not passed to the function, instead, the current runtime variabletime
is required #47 - The
Momentum
object, part of theModelPhysics
object, now includes theFaceScalarField
andFaveVectorField
in addition to existing fields in preparation for non-uniform boundary definition when using theOpenFOAM
output format #47
Breaking
- No breaking changes
Deprecated
- No functions deprecated
Removed
- No functionality has been removed
Version v0.4.1 - 2025-03-06
Added
- No new functionality has been added
Fixed
- Remove fragile precompile statements of the form
var"#*#*"
causing errors in Julia v1.12 #40
Changed
- In preparation for implementation of hybrid models e.g. DES, the signature of the
turbulence!
function has been updated to use theAbstractTurbulenceModel
#39 - New semi-implicit implementation for periodic boundary conditions (implicit treatment of laplacian terms)#40
Breaking
- No breaking changes
Deprecated
- No functions deprecated
Removed
- No functionality has been removed
Version v0.4.0 - 2025-02-17
Added
- Implementation of
Symmetry
boundary condition forScalarField
types #30 - New macro to help define boundary conditions that will dispatch to
Scalar
orVectorField
types #30 - Added
eltype
method for bothScalar
andVectorField
types to simplify the development of new kernels where type information is needed #30 - New gradient limiters
FaceBased
andMFaceBased
for limiting gradients based on cell faces, whereMFaceBased
is a multidimensional version, and it is generally recommended overFaceBased
#30 - Support for INTEL hardware #32
Fixed
- Calling
JacobiSmoother
now works on the GPU #30 - Implemented
SparseXCSR
as wrapper forSparseMatrixCSR
on the CPU to resolve display/print errors #30 - The convergence criteria for solvers is used consistently to stop/control simulation runtime #36
- Consistent display of residuals on screen during simulations #36
- Fixed calculation of wall distance and
apply_boundary_conditions!
arguments forLKE
model #36
Changed
- The calculation of gradients has been improved by merging computations into a single kernel, improving performance of gradient kernels by around 10-30%, most noticable for vector gradients #30
- Improved calculation of non-orthogonal calculation (more tests are still needed), although tests have proven to be stable #30
- Improved documentation/readme on supported GPU backends/hardware and make users aware of potential
F32
limitation on some hardware
Breaking
- The top level API for all solvers no longer takes the keyword argument
limit_gradient
for activating gradient limiter. New gradient limiters have been added and can be selected/configured when assigning numerical schemes with theSchemes
function #30
Deprecated
- No functions deprecated
Removed
- No functionality has been removed
Version v0.3.3 - 2024-12-24
Added
- Added experimental support for NVIDIA ILU0 and IC0 preconditioners #23
- Added
JacobiSmoother
that can be used with all linear solvers (improving initial guess) #23 - New function
activate_multithread
is available to set up matrix-vector multiplication in parallel on the CPU - Initial benchmark added in the documentation
Fixed
- No fixes
Changed
- Internally the sparse matrix format has been changed to CSR. This has improved performance by 2x-4x (case dependent)
- Multithreaded sparse matrix vector multiplication is now functional #23
- Precompilation errors on Julia v1.11 addressed by bringing code from
ThreadedSparseCSR.jl
#24 - Update compat entry for
Atomix.jl
to v1.0,0 #24 DILU
preconditioner is now implemented to work with sparse matrices in CSR format and uses a hybrid approach (running on CPU) to allow working when using GPU backends (further work needed) #26- The implementation of RANS models and wall functions has been improved for consistency (resulting in some computational gains). The calculation of
yPlusLam
is only done once when constructing the wall function objects. The calculation of the velocity gradient is now only done within the turbulence model main function (turbulence!
) #28
Breaking
- No breaking changes
Deprecated
- No functions deprecated
Removed
- The
ILU0
andLDL
preconditioners has been temporarily removed #23
Version v0.3.2 - 2024-11-08
Added
- Added support for CI testing, Dependabot, and CompatHelper
Fixed
- Fixed tests for mesh conversion and standardised tolerances for test checks of incompressible solvers #16
Changed
- No changes
Breaking
- No breaking changes
Deprecated
- No functions deprecated
Removed
- No functionality has been removed
Version v0.3.1 - 2024-10-18
Added
- Vastly improved documentation with new examples provided #12
- Changelog added to record changes more clearly. Record kept in Release notes
Fixed
- The calculation of gradients can be limited for stability. This functionality can be activated by passing the key work argument
limit_gradient
to therun!
function. The implementation has been improved for robustness #12 - Removed face information being printed when
Mesh
objects are created to stop printing aERROR: Scalar indexing is disallowed
message #13
Changed
- Master branch protected and requires PRs to push changes
Breaking
- No breaking changes
Deprecated
- No functions deprecated
Removed
- No functionality has been removed
Version v0.3.0 - 2024-09-21
- New name - XCALibre.jl - which is now registered in the General Julia registry
- Can do 3D and GPU accelerated simulations
- Can read .unv and OpenFOAM mesh files (3D)
- Can do incompressible and compressible simulations
- RANS and LES models available
- User-provided functions or neural networks for boundary conditions
- Reasonably complete "user" documentation now provided
- Made repository public (in v0.2 the work was kept in a private repository and could only do 2D simulations)
- Tidy up mesh type definitions by @mberto79 in #5
- Adapt code base to work with new mesh format by @mberto79 in #6
- Mesh boundary struct changes PR by @TomMazin in #7
- Mesh boundary struct changes PR fix by @TomMazin in #8
Version v0.2.0 - 2023-01-23
- New mesh format and type implemented that are GPU friendly.
- No functionality changes
Version v0.1.0 - 2023-01-23
Initial release
2D implementation of classic incompressible solvers for laminar and turbulent flows:
- Framework for equation definition
- SIMPLE nad PISO algorithms
- Read UNV meshes in 2D
- Capability for RANS models
- Various discretisation schemes available
- Planned extension to 3D and GPU acceleration!