Can an explicit solver be used for a slow, static problem?

Yes, via "dynamic relaxation" or quasi-static explicit analysis — artificially speeding up the loading (or adding mass scaling/damping) so the event completes in far fewer of the tiny Courant-limited steps than the real-time event would need, while keeping inertial effects small enough not to distort the result. This is a common workaround when a problem has severe contact nonlinearity that would stall an implicit solver, even though the actual physical event is quasi-static.

What is mass scaling, and why do explicit solvers use it?

Mass scaling artificially increases element mass (often only for the smallest, most restrictive elements) to raise the stable time step, since Δt scales with the square root of mass over stiffness. It trades a small, deliberately bounded increase in inertial effects for a large reduction in run time, and is a standard technique in explicit metal-forming and quasi-static simulations — but it must be checked (via kinetic-energy-to-internal-energy ratio, typically kept under a few percent) to confirm it hasn't distorted the physical result.

Does "implicit" always mean "nonlinear-capable" and "explicit" always mean "for crash only"?

No — both schemes handle linear and nonlinear problems; the labels describe time integration, not nonlinearity. Implicit solvers run the vast majority of linear-static analysis by far, but also handle nonlinear statics and moderate-rate dynamics. Explicit solvers are not limited to crash — they are also the standard choice for sheet-metal stamping, forging, blast/impact, and other severe, short-duration events outside literal vehicle crash testing.

Why does refining the mesh cost more in an explicit solve than an implicit one?

Refining a mesh (making elements smaller) reduces Lₑ in the Courant condition, which directly forces a smaller stable time step across the entire model, not just the refined region — so a locally refined mesh can inflate total run time dramatically. An implicit solve's time step is chosen for accuracy, not tied to element size, so mesh refinement there mainly adds cost through a larger, more expensive matrix to factorize each step, not through a shrinking time step.

← Engineering Software Studio

Concept Explainer · Engineering Software

Explicit vs. Implicit FEA Solvers

It isn't about accuracy. It's about whether the solver ever has to invert a stiffness matrix at all — and that single choice decides your time step, your run time, and which problems you can even attempt.

A frequent assumption is that implicit solvers are "more accurate" and explicit solvers are a lower-fidelity shortcut for when you need speed. That's backwards for the problems each one is actually built for. A car crash simulation run implicitly will grind through failed equilibrium iterations as contact status flips dozens of times per millisecond; a static bracket deflection run explicitly will technically produce an answer, eventually, after simulating far more time steps than the problem needs. The real dividing line is how each method advances the solution from one time step to the next: does it solve a system of equations that includes the next step's unknowns, or does it compute the next step directly from what is already known?