Sundar's Notes

deal.II and LibTorch Integration Patterns

5 min read

deal.II and LibTorch Integration Patterns

Patterns for embedding libtorch in C++ simulation codes, matrix-free operator implementation for thermal problems, and block preconditioners for coupled systems.

Existing deal.II + LibTorch integration

The only published integration: Roth, Schröder & Wick (2022)

deal.II solves the primal FEM problem; LibTorch solves the adjoint problem with a feedforward neural network. Demonstrates NN-guided goal-oriented a posteriori error estimation with excellent effectivity indices for both linear and nonlinear PDEs.

Citation: Roth, M., Schröder, J. & Wick, T. (2022). “Neural network guided adjoint computations in dual weighted residual error estimation.” SN Applied Sciences (Springer). Cited 20 times.

This is the only published deal.II + LibTorch integration. No published work on:

  • Embedding LibTorch for in-situ training within deal.II
  • Using LibTorch for surrogate inference during time-stepping
  • Matrix-free neural operator evaluation within deal.II’s MatrixFree framework

Matrix-free operator implementation for thermal problems

deal.II matrix-free framework

deal.II’s MatrixFree class provides infrastructure for matrix-free FEM computations:

  • Cell-wise operator evaluation using FEEvaluation
  • Face-wise evaluation for DG and interface terms
  • SIMD vectorization over multiple cells
  • Compatible with geometric multigrid preconditioning

Key papers

Münch (2024): Comprehensive treatment of matrix-free framework for high-order FEM with preconditioning at extreme scale.

Citation: Münch, P. (2024). “Matrix-free finite-element computations at extreme scale and for challenging applications.” Universität Augsburg.

Jodlbauer, Langer & Wick (2020): GMG-preconditioned matrix-free for phase-field fracture problems.

Citation: Jodlbauer, D., Langer, U. & Wick, T. (2020). “Parallel matrix-free higher-order finite element solvers for phase-field fracture problems.” Mathematical and Computational Applications.

Munch, Dravins, Kronbichler & Neytcheva (2024): Matrix-free with block preconditioners for heat equation with stage-parallel implicit Runge-Kutta.

Citation: Munch, P. et al. (2024). “Stage-parallel fully implicit Runge-Kutta implementations with optimal multilevel preconditioners at the scaling limit.” SIAM J. Scientific Computing.

Relevance to adamantine

adamantine uses deal.II’s matrix-free infrastructure for the thermal operator. The thermal operator is evaluated cell-wise without global matrix assembly, which is critical for:

  • Memory efficiency (new architectures have little memory per core)
  • Memory-bound problems (reducing memory access even at cost of more computation)
  • Time-dependent nonlinear problems (matrix must be rebuilt every timestep anyway)

Block preconditioners for coupled systems

For thermo-mechanical coupling

In a fully coupled TMM system, the block structure would be:

[A_TT   A_TM   0  ] [T ]   [f_T]
[A_MT   A_MM   0  ] [u ] = [f_u]
[0      0      A_z] [z ]   [f_z]

where T = temperature, u = displacement, z = phase fractions.

Block preconditioners exploit this structure:

  • Schur complement for thermal-mechanical coupling
  • Diagonal block preconditioner for phase fraction ODEs (local)
  • AMG or GMG for the thermal and mechanical diagonal blocks

Key papers

Margenberg, Bause & Munch (2025): Matrix-free multigrid preconditioner for coupled systems (Stokes equations, but patterns transfer).

Citation: Margenberg, N., Bause, M. & Munch, P. (2025). “A Multigrid Approach for Tensor-Product Space-Time Finite Element Discretizations of the Stokes Equations.” SIAM J. Scientific Computing.

Adaptive mesh refinement with solution transfer

deal.II patterns (step-26, step-31, step-40)

  • SolutionTransfer class handles interpolation when mesh changes
  • For AM: refine near heat source, coarsen in cooled regions
  • Element activation via FE_Nothing (adamantine’s approach)

Relevant deal.II tutorials

  • step-40: Parallel distributed computation with p4est
  • step-42: Parallel computing with deal.II (advanced)
  • step-55: Block preconditioners for coupled Stokes-Darcy
  • step-26: Adaptive mesh refinement for heat equation
  • step-31: Convection-diffusion with AMR and solution transfer

LibTorch embedded in C++ simulation

Model loading and inference

#include <torch/script.h>
 
// Load TorchScript model
torch::jit::script::Module model =
    torch::jit::load("surrogate.pt");
 
// Prepare input tensor from FEM data
std::vector<torch::jit::IValue> inputs;
inputs.push_back(torch::from_blob(
    fem_data_ptr, {batch, features},
    torch::TensorOptions().dtype(torch::kFloat64)));
 
// Run inference
torch::Tensor output = model.forward(inputs).toTensor();

Gradient computation for in-situ training

// Enable gradient tracking
torch::Tensor input = torch::from_blob(
    fem_data_ptr, {batch, features},
    torch::TensorOptions()
        .dtype(torch::kFloat64)
        .requires_grad(true));
 
// Forward pass
auto output = model.forward({input}).toTensor();
 
// Compute loss
auto loss = torch::mse_loss(output, target);
 
// Backward pass
loss.backward();
 
// Access gradients
auto grad = input.grad();

Memory management for large tensor operations

  • Use torch::NoGradGuard for inference-only passes
  • Pre-allocate tensors and reuse with torch::from_blob (zero-copy)
  • Use torch::Tensor::contiguous() before passing to FEM
  • Consider torch::kFloat32 for inference (2x speedup, acceptable accuracy for surrogates)

ONNX export for framework interoperability

// Export from Python
torch.onnx.export(model, dummy_input, "surrogate.onnx")
 
// Load in C++ via ONNX Runtime
#include <onnxruntime_cxx_api.h>
Ort::Session session(env, "surrogate.onnx", session_options);

Integration architecture for TMM surrogate

Option A: adamantine + LibTorch (original plan)

Pros:

  • adamantine already uses deal.II matrix-free infrastructure
  • Kokkos GPU path available
  • Built-in EnKF for data assimilation

Cons:

  • Heavy template parameterization makes adding physics difficult
  • No plugin system
  • One-way coupling only (would need major refactoring for TMM)
  • Must implement JMAK/KM/TRIP from scratch in templated C++

Option B: MALAMUTE/MOOSE + LibTorch (recommended)

Pros:

  • MOOSE already has LibTorch integration in stochastic_tools
  • ADKernel/ADMaterial with automatic Jacobians for custom physics
  • Fully coupled multiphysics in one Newton system
  • HIT input files (no recompilation for experiments)
  • MultiApp for multiscale coupling

Cons:

  • libMesh-based (not deal.II)
  • Less mature GPU path
  • Larger dependency tree
  1. Phase 1: Implement JMAK/KM as MOOSE ADKernel objects
  2. Phase 2: Implement TRIP as MOOSE ADMaterial
  3. Phase 3: Train GNO offline on MALAMUTE FEM data (Python)
  4. Phase 4: Export GNO as TorchScript, load in MOOSE via stochastic_tools LibTorch surrogate infrastructure
  5. Phase 5: Implement in-situ training loop:
    • MOOSE FEM solves thermal at each timestep
    • GNO predicts thermal field (surrogate)
    • Compare and compute uncertainty
    • Trigger retraining when uncertainty exceeds threshold
    • Use MOOSE’s LibTorch integration for gradient computation

Research gaps

  1. No matrix-free neural operator evaluation in deal.II’s MatrixFree framework
  2. No in-situ training of neural operators within any FEM code
  3. No LibTorch integration for surrogate inference during deal.II time-stepping
  4. No block preconditioner design for coupled FEM + neural operator systems
  5. No AMR guided by neural operator uncertainty estimates

Connection to TMM surrogate project

See TMM Surrogates and Adamantine vs MALAMUTE.

The recommended path is MALAMUTE/MOOSE with its existing LibTorch integration, implementing custom JMAK/KM/TRIP physics as ADKernels, and deploying trained GNO surrogates via the stochastic_tools module.

See also:

Graph View

Backlinks