Crack-band vs nonlocal damage in dynamic crack branching

Both crack-band scaling and nonlocal averaging give mesh-independent fracture energy in OOFEM. Only the nonlocal model also fixes the band width and the direction of the branching cracks under dynamic biaxial load.

Strain-softening damage models need a regularisation, otherwise the dissipated energy and localisation width depend on the mesh. The crack-band approach and the nonlocal averaging of equivalent strain are two common fixes, but they don't fix the same things. This post is about what each one actually does, and where the difference shows up under dynamic loading.

Two models, one specimen

I ran two analyses of a 254 x 254 mm Homalite-100 cruciform plate with a 50 mm central crack under biaxial impulsive loading. The geometry and loading are inspired by one of the dynamic-photoelastic experiments of Hawong et al., doi.org/10.1007/BF02319466.

Same mesh, same elastic and damage initiation, same explicit time integration (NlDEIDynamic, dt ~ 2e-7 s). Only the regularisation differs:

What changes

Crack-band model (idm1):

Nonlocal model (idmnl1):

Two things are different:

Both runs dissipate the same energy per unit crack area (if calibrated like this), which is what the crack-band approach is for. The difference is in what the crack path looks like, and how many cracks are initiated.

When each matters

The crack-band approach is fast and stable, and enough whenever you mainly care about global load-displacement and energy balance; most engineering analyses fall in that category. For quasi-static loading, crack patterns are often reproduced well. Nonlocal regularisation pays off when the crack pattern itself is the result you want: branching, deflection, multi-crack scenarios, and any case where the band width sets a length scale that interacts with the structure.

Reproduce

Each analysis takes more than 30 minutes (explicit dynamic, ~1000+ steps), so this isn't a coffee-break example. Inputs and Docker recipe:

git clone https://github.com/githubgrasp/oofem-examples.git
cd oofem-examples/nonlocal-dynamic-idm1/idm1nl
docker run --rm -v "$PWD":/work ghcr.io/githubgrasp/oofem-public:nonlocal-dynamic-idm1 bash run.sh --yes

The committed oofem.in has the mesh already included, so the analysis runs as-is. Regenerating the mesh from mesh.in requires the T3D mesh generator, which is not bundled in the public Docker image; if T3D is on your PATH, run.sh automatically uses it.

The example folder is at github.com/githubgrasp/oofem-examples/nonlocal-dynamic-idm1; issues and questions go on the issue tracker.

Built with OOFEM.

All posts