Software Quality in XDEM

To ensure and maintain the quality of XDEM Software, the LuXDEM research group uses and enforces the following practices.

Strong Documentation

XDEM source code is documented with Doxygen and the developer documentation is updated nightly. The design and main features of XDEM are also documented separately.

Additionally, the physics models and equations, the validation tests and results are presented and published regularly in scientific conferences, articles and theses.

Extensive Tests

There are 4 main types of tests in XDEM:

  • Unit Tests: Check basic functionalities independently
    • Test classes individually
  • Testcase Executions: Check that execution is going through
    • Run simulations on specific testcases
    • Different simulation modules: Dynamics, Conversion, DynConv, OpenFOAM coupling, …
    • Sequential and Parallel executions
  • Regression Tests and Result Checking: Check that results are still correct
    • Compare result of a testcase execution
    • Based on a reference result which has been validated
  • Plot Tests: Check that results are meaningful
    • Plot results of a testcase Execution
    • Comparison with experimental data from other sources
    • Create screenshot of ParaView visualization

XDEM test output with Paraview
Paraview screenshot to validate the porosity calculation in XDEM

XDEM test output with R
Validation of Beech Wood pyrolysis by comparison with data published by Petek in 1998

Code Coverage and Analysis

The quality of the XDEM code and tests is tested nightly with the following tools:

  • Checking warnings from various compilers: GCC, Clang, Intel Compiler, Microsoft Visual C++
  • Static code analysis and diagnosis with Clang-Tidy
  • Code coverage with Gcov
  • Memory error detection with Valgrind Memcheck and Clang AddressSanitizer

Systematic code review and bug tracking

XDEM Software is hosted on the Gitlab platform of the University of Luxembourg. It allows a smooth collaborative development:

  • source code is versioned using Git
  • issues/bugs and milestones are documented and followed
  • a wiki provides an internal documentation
  • merge requests used for systematic code review

Each new development, feature or bug fix must be developed in a separate branch which must be documented, tested and reviewed before being included.

Continuous integration and nightly tests

The Continuous Integration framework of Gitlab is used to test each branch independently. A new feature cannot be merged to the main branch if all the does not pass.

Additionally, tests are performed nightly on various and configurations:

  • 4 compilers supported, for about 12 different versions: GCC, Clang, Intel Compiler, Microsoft Visual C++
  • Operating Systems: Windows, Linux and MacOS X
  • Processor architectures: Intel 32-bit, Intel 64-bit and ARM
  • More than 16 software configurations