Simulation Software in the Age of AI

Peridynamics · Julia · Sustainable Data

Prof. Dr.-Ing. Christian WillbergORCID
christian.willberg@h2.de

Open Day — Hotel Albatros, Yaoundé, Cameroon
25 April 2026

Presentation link

"Just use AI for that."

What AI does well

  • Pattern recognition in large datasets
  • Fast inference once trained
  • Image classification, NLP, …
  • Interpolation within training distribution

What AI struggles with

  • Data hunger — needs millions of examples
  • Black box — no physical explanation
  • Extrapolation — fails outside training domain
  • Rare events — cracks, crashes, failures

The engineering problem: Structural failures are rare by design. You cannot collect enough real crash or fracture data to train a reliable AI model from experiments alone.

The Data Scarcity Problem

In image recognition

  • ImageNet: 14 million labelled images
  • Training is cheap, data is abundant

In structural mechanics

  • A single fracture experiment: days of preparation, expensive specimen, one data point
  • Statistical analysis requires hundreds of tests

Simulation as a data generator

Physics-based simulations can produce thousands of consistent, labelled, physically meaningful data points — at a fraction of the cost of experiments.

This is not anti-AI. This is what makes AI possible in engineering.

Fracture & Fatigue

Aloha Airlines Flight 243 (1988)

Eschede Train Disaster (1998)

Simulation and AI — Not Competitors

Simulation provides:

  • Synthetic training data
  • Physical constraints (loss functions)
  • Interpretable reference solutions
  • Extrapolation beyond observed data

AI provides:

  • Fast surrogate models
  • Parameter identification
  • Uncertainty quantification
  • Pattern discovery in simulation output

Physics-informed neural networks (PINNs), neural operators, surrogate models — all rely on simulation data or physics constraints.

But: Garbage In, Garbage Out

If simulations generate the training data for AI models, then the quality, reproducibility, and traceability of simulations becomes critical.

  • Wrong simulation → wrong training data → wrong AI model
  • Irreproducible simulation → irreproducible AI result
  • Untraceable data → untrustworthy decision

Three requirements follow:

  1. Good physics — the simulation must capture the right phenomena
  2. Sustainable software — results must be reproducible
  3. Data provenance — every result must be traceable

This is the thread of today's talk: physics → software → data.

Crack Propagation

  • Crack already exists (from manufacturing, inspection limit, LCF/HCF initiation)
  • Governed by fracture mechanics
  • Paris Law:

where

  • Three regions: threshold → stable growth → unstable fracture

Characteristic:

  • Crack grows cycle by cycle
  • Basis of damage tolerance design
  • Inspection intervals derived from crack growth rate

Part 2 — Peridynamics

Why a New Simulation Method?

Classical continuum mechanics

  • Requires spatial derivatives of
  • At cracks: derivatives undefined
  • Cracks must be prescribed or tracked (XFEM, CZM)
  • Mesh distortion → remeshing

FEM

  • method to approximate classical continuum mechanics
  • cracks lead to infinite stresses, because no valid solution exists

Peridynamics (PD)

  • Integral equation — no spatial derivatives
  • Valid across cracks
  • Cracks emerge naturally from material failure
  • No remeshing needed

Silling (2000): "Reformulation of elasticity theory for discontinuities and long-range forces."

The Peridynamic Horizon

  • Each point interacts with all neighbours within horizon
  • Reference bond:
  • Relative displacement:
  • Damage: bond breaks, e.g. when stretch exceeds

Key insight: The horizon is a material length parameter. As , peridynamics converges to classical continuum mechanics. No special crack tracking is needed — damage is a natural outcome.

Horizon ratio Effect
Good compromise
Better convergence
and Classical CM

From Bond-based to Correspondence

Formulation Key idea Poisson's ratio Anisotropy
Bond-based (BB) Pairwise spring force fixed No
Ordinary state-based (OSB) Collective, central force Arbitrary No
Non-ordinary state-based (NOSB) Deformation gradient Arbitrary Yes
Correspondence (CCM) → classical Arbitrary Yes

Correspondence model: compute from the PD neighbourhood, apply any classical material model to get , convert back to PD force density state. Enables direct reuse of existing constitutive models.

Correspondence — Core Equations

Shape tensor (computed once):

Deformation gradient:

Linearised strain:

Stress (any classical model):

Force density state:

Equation of motion:





Application: Additive Manufacturing

Challenge: Material properties in 3D printing are created during the process

  • Crystallisation (PEEK)
  • Thermal gradients → residual stress
  • Layer-by-layer activation

PD approach:

  • Progressive node activation follows G-code
  • Thermo-mechanical coupling
  • Crystallisation kinetics via HETVAL subroutine
  • adapted per node based on degree of crystallisation

Why PD for AM?
Residual stresses cause delamination and cracking — exactly the discontinuous phenomena where PD is strongest. No remeshing as layers are added.

Simulation workflow:

  1. Print specimen (layer activation)
  2. Cooling step (thermal field)
  3. Tensile test (fracture)

Simulation Results


Simulation Results

  • Crack initiation and propagation similar, only initiation time slightly differs

Part 3 — Sustainable Software

The Reproducibility Crisis in Simulation

Common scenario:

  • Paper published with impressive results
  • Code not released, or released without documentation
  • Dependencies change → code no longer compiles
  • Result cannot be reproduced 2 years later

This matters for AI:

  • If simulation data cannot be reproduced → training data is untrustworthy
  • Published benchmarks become irreproducible

A concrete example: Peridigm

Dependencies: CMake, MPI, Python, Fortran, C, C++, Trilinos (Blas, Lapack, X11), Boost, HDF5, NetCDF-C

Installation time: 1 day to 1 week — if it works.

A solution that does not run requires infinite time to solve a problem.

What Makes Software Sustainable?

Technical criteria

  • Reproducible builds (package manager)
  • Version control (Git)
  • Automated testing (CI/CD)
  • Clear dependency management
  • Documentation

Community criteria

  • Open source licence
  • Modular architecture (easy to extend)
  • Low entry barrier
  • Long-term maintenance plan
  • FAIR principles for code

FAIR for software: Findable · Accessible · Interoperable · Reusable — the same principles applied to research data now increasingly applied to research software.

Why Julia?

The two-language problem:

  • Prototype in Python (easy, slow)
  • Rewrite in C++ for performance (hard, fast)
  • Two codebases, two maintenance efforts

Julia solves this:

  • Python-like syntax, C-like speed
  • JIT compilation
  • Native package manager (Pkg)
  • First-class parallelism (MPI, threads)
  • Easy to learn for PhD students

Performance comparison
(2×2 matrix inversion, inner loop)

Method Time
inv(Matrix) Julia ~302 ns
StaticArrays Julia ~2 ns
Equivalent C++ ~2 ns

Julia achieves C-level performance with Python-level readability — without sacrificing either.

PeriLab — Design Philosophy

Goal: Reduce the entry barrier to peridynamic simulation

Key decisions:

  • Julia as implementation language
  • Package manager for all dependencies
  • Macro-based module loading (no recompilation for new models)
  • New material model: 1 file (vs. 5+ in Peridigm)
  • New input parameter: in YAML (vs. 6 files + recompile)
  • MPI parallelism built in
Criterion Peridigm PeriLab
Installation Manual Package manager
Build time ~10 min < 5 min
New material 5+ files 1 file
New parameter 6 files + compile YAML only
Libraries Manual update Automatic
Compilation knowledge Deep None

Adding a New Material Model in PeriLab

# One file, one module — no recompilation of the core
module MyPlasticModel

using PeriLab

function compute_stress(strain, history, params)
    # your constitutive law here
    σ = params["E"] .* strain
    return σ, history
end

end

# Reference in the YAML input deck — that is all
Material Models:
  MyMaterial:
    Material Model: MyPlasticModel
    E: 210000

The macro system discovers and integrates the module at runtime. No changes to the core codebase, no recompilation, no deep knowledge of the solver internals required.

PeriHub — Making Simulation Accessible

PeriHub is a web-based front end for PeriLab

  • Browser-based model setup
  • No local installation required
  • Results visualised interactively
  • Models shared via URL

Target users:

  • Students exploring PD for the first time
  • Researchers running parameter studies
  • Industry partners without HPC expertise

Access:
perilab-results.nimbus-extern.dlr.de

Examples available:

  • DCB fracture
  • Dogbone tensile test
  • Additive manufacturing

Examples - RVE


Examples - Impact


Part 4 — Data Provenance

What Is Data Provenance?

Provenance = the complete history of how a result was produced

  • Which software version was used?
  • Which input parameters?
  • Which mesh, which material model?
  • Who ran it, when, on which hardware?
  • Which pre- and post-processing steps?

Why it matters:

If a simulation result is used to train an AI model, and later found to be wrong — can you trace back which training data to discard?

Without provenance: no.

Provenance is not just good practice — in regulated industries (aerospace, medical devices) it is a legal requirement. In research, it is the foundation of reproducibility.

FAIR Data Principles

Principle Meaning In practice
Findable Persistent identifier DOI for every dataset
Accessible Open access protocol Zenodo, DaRUS, …
Interoperable Standard formats HDF5, JSON, CSV
Reusable Licence + provenance CC-BY + metadata

For simulation data this means:

  • Input files versioned alongside results
  • Software version recorded (Git hash)
  • Environment captured (container / environment file)
  • Output linked to input via metadata

A Zenodo record with DOI costs nothing and lasts forever. A GitHub repository without a release tag disappears when the project ends.

Provenance in PeriLab

What PeriLab records automatically:

  • Software version (Julia + PeriLab package version)
  • Input YAML (complete, as run)
  • Git hash of the codebase
  • Timestamp and compute environment
  • Output linked to input by unique run ID

What PeriHub adds:

  • Web-accessible results with permanent URL
  • Model sharing between collaborators
  • Version history of model configurations

The chain:

G-code / geometry
      ↓
PeriLab input (YAML, versioned)
      ↓
Simulation run (version + hash recorded)
      ↓
Output (HDF5 + metadata)
      ↓
PeriHub (interactive, shareable)
      ↓
Zenodo / repository (DOI, FAIR)
      ↓
AI training dataset (traceable)

Why This Matters for the Next Generation

The current situation:

  • Many simulation codes are written once, never maintained
  • Results in papers often cannot be reproduced
  • Data is stored on personal laptops and lost when people leave
  • AI models trained on this data inherit the problems

What we can do differently:

  • Open source from day one
  • Package manager, not manual installation
  • FAIR data deposit for every publication
  • Provenance as a default, not an afterthought

You — as the next generation of engineers and researchers — will decide:

Will the simulation data generated in the next 10 years be usable by the AI models of 2040?

Only if it is stored correctly today.

Conclusion

Peridynamics

  • Integral formulation — valid across cracks
  • Natural fracture without remeshing
  • Correspondence model: reuse classical material laws
  • Applications: AM, composites, metals

Sustainable Software

  • Julia: performance + accessibility
  • PeriLab: modular, low entry barrier
  • PeriHub: browser-based access
  • Open source + package management

Data Provenance

  • FAIR principles for simulation data
  • Every result traceable to its inputs
  • Foundation for trustworthy AI training data
  • Zenodo / repositories with DOI

The message:

Simulation and AI are not in competition. Good simulation software with traceable data is what makes AI in engineering reliable.

Thank You

Prof. Dr.-Ing. Christian Willberg
Magdeburg-Stendal University of Applied Sciences
christian.willberg@h2.de

Resources:

References

  1. Silling, S.A. (2000). Reformulation of elasticity theory for discontinuities and long-range forces. J. Mech. Phys. Solids, 48(1), 175–209.
  2. Willberg, C., Hesse, J.-T., Hein, R. & Winkelmann, F. (2024). Peridynamic Framework to Model Additive Manufacturing Processes. Adv. Theory Simul. doi:10.1002/adts.202400818
  3. Willberg, C., Hesse, J.-T. & Pernatii, A. (2024). PeriLab – Peridynamic Laboratory. SoftwareX. doi:10.1016/j.softx.2024.101700
  4. Wilkinson, M.D. et al. (2016). The FAIR Guiding Principles for scientific data management. Sci. Data, 3, 160018.

Showcase