SIGA

SIGA (Scalable Isogeometric Analysis) is a GPU-accelerated framework for solving large-scale nonlinear mechanics problems using Isogeometric Analysis (IGA).

The project focuses on high-order spline discretizations, nonlinear elasticity, and large-scale sparse systems, with most heavy computations executed on NVIDIA GPUs using CUDA.

SIGA is designed primarily for research in computational mechanics and high-performance finite element methods.

• High-order B-spline / NURBS IGA
• GPU accelerated assembly and linear algebra
• Efficient sparse matrix assembly
• Large-scale systems (>500k DOFs)
• Newton iteration framework for nonlinear problems
• CUDA-based parallel kernels
• Integration with AMGX GPU solvers
• Designed for high-performance computing

flowchart TD

A[Geometry & B-spline Basis] --> B[Element Integration]
B --> C[GPU Element Assembly]

C --> D[Sparse Matrix Construction]
D --> E[CSR Matrix]

E --> F[AMGX Solver]

F --> G[Newton Update]

G --> H[Convergence Check]

H -->|Not converged| B
H -->|Converged| I[Solution]

SIGA
│
├── src                  All source files
├── examples             Example simulations
├── external             Dependencies
├── AMGX_config          AMGX solver configurations
└── CMakeLists.txt

SIGA depends on a modern C++/CUDA toolchain together with a small set of scientific computing libraries.
The core requirements are listed below, followed by optional components that can be enabled at configure time.

• C++17 compatible compiler
• CMake
• CUDA Toolkit
• Eigen

• Enable AMGX when GPU-based sparse linear solves and AMG preconditioning are needed.
• Enable MKL when faster CPU-side dense or sparse linear algebra is desired through Eigen.
• Enable PARDISO when a robust MKL-backed CPU sparse direct solver is preferred over Eigen's built-in SparseLU fallback.
• Enable Spectra when you want use Spectra to compute eigenvalues. I found it is slower than cusolver's dense eigenvalue solver cusolverDnXsyevd.
• AMGX is not supported in Debug builds. If you need to run SIGA in Debug mode, configure the project with ENABLE_AMGX=OFF.
• When AMGX is disabled, SIGA falls back to:
  • Eigen::SimplicialLDLT or Eigen::SparseLU for linear solves on the CPU
  • Eigen::PardisoLU for CPU sparse direct solves when ENABLE_PARDISO=ON
  • cusolverDnXsyevd for eigenvalue computations on the GPU
• These fallback solvers remain efficient for small to medium-sized problems, and are convenient for development, verification, and debugging workflows.

SIGA uses an out-of-source CMake build.

SIGA includes several external libraries as Git submodules.
To clone the repository together with all required submodules, run:

git clone --recurse-submodules https://github.com/wj902911/SIGA.git
cd SIGA

If you already cloned the repository without submodules, run:

git submodule update --init --recursive

mkdir build
cd build

A minimal Release configuration can be generated with:

cmake .. -DCMAKE_BUILD_TYPE=Release

To enable optional components, pass the corresponding CMake options during configuration. For example:

cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_AMGX=ON -DENABLE_SPECTRA=ON

If Intel MKL is available and Eigen is configured to use it, you may configure with:

cmake .. -DCMAKE_BUILD_TYPE=Release -DEIGEN_USE_MKL_ALL=ON

To use Intel oneMKL PARDISO for SIGA's CPU sparse direct solves:

cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_PARDISO=ON

ENABLE_PARDISO=ON selects MKL's LP64 interface because SIGA stores sparse matrix indices as int.

For debugging, disable AMGX explicitly:

cmake .. -DCMAKE_BUILD_TYPE=Debug -DENABLE_AMGX=OFF

cmake --build . --config Release

For a Debug build:

cmake --build . --config Debug

• The exact availability of optional components depends on whether the corresponding third-party libraries are installed and discoverable by CMake.
• Since AMGX cannot be built in Debug mode, Debug configurations should be used with ENABLE_AMGX=OFF.
• In Debug mode, SIGA uses Eigen::SimplicialLDLT for linear solves and cusolverDnXsyevd for eigenvalue computations.
• These alternatives are still reasonably fast when the system size is not too large.
• On Windows, additional runtime configuration may be required for CUDA, MKL, or AMGX shared libraries.
• For best performance, use a Release build rather than Debug.

The examples folder currently contains two basic benchmark-style examples for nonlinear displacement-controlled simulations on multi-patch spline domains.

After building, run the corresponding executable from the build output directory.
The exact executable name depends on your CMake target names.

Typical usage is:

./test
./test_3D

Both examples generate output directories automatically and write visualization files that can be opened in ParaView.

• The 2D example writes results under ./TwoPatchesTest/
• The 3D example writes results under ./TwoPatchesTest_3D/

Each example outputs:

• the initial geometry
• deformed configurations for each load step
• a ParaView collection file for time-series visualization

GPUPostProcessor provides an option to export the computational mesh during output generation.

For models with a large number of elements, disabling mesh output is often recommended because it can:

• reduce memory usage
• lower post-processing cost
• improve visualization clarity by preventing the mesh lines from obscuring the solid body

In particular, for very fine discretizations, mesh rendering may visually cover the entire model.

When running an executable that uses the AMGX solver, the following files must be placed in the same directory as the executable:

• amgxsh.dll
• SOLVER_CONFIG_INUSE.json

Without these files, the executable will not run correctly with AMGX enabled.

Representative performance measurements on an NVIDIA RTX 3080 Ti are shown below.

• The reported timings correspond to a typical nonlinear analysis workflow and should be interpreted as representative rather than absolute performance figures.
• Assembly time denotes the cost of residual evaluation and tangent stiffness matrix construction for one Newton iteration.
• Linear solve time denotes the cost of solving the corresponding linearized system within one Newton step.
• Actual performance depends on several factors, including spline order, quadrature cost, constitutive model complexity, sparsity pattern, solver settings, and GPU hardware.
• For large-scale problems, solver performance is often the dominant cost, while for smaller problems the assembly and data movement overhead may be comparatively more visible.

Planned directions for future development include:

• Multiphysics coupling, including extensions to coupled field problems arising in advanced computational mechanics
• AMGX-based eigenvalue solvers, with an emphasis on large-scale instability and modal analysis
• Multi-GPU support, aimed at improving scalability for very large simulations