Explicit Solvers

Explicit solvers in automotive simulation

297 0

Explicit solvers are critical in automotive simulation, saving car companies millions in testing and countless driver and passenger lives. Laurence Marks looks at the development of explicit solvers and asks, in a world of multi-solvers, what are the sweet spots for today’s explicit users and workflows?

At one time, solvers were like religion. There were people who used traditional implicit methods to solve problems, and there were people with more radical outlooks, who used explicit techniques. And that, pretty much, was that. There were implicit people and explicit people, and meetings of minds weren’t common.

Implicit solvers are the non-linear extensions to everyday solvers that people are accustomed to using in finite element packages. Choose non-linear options in most commercial codes and the solver used will be implicit.

It’s the same ‘applied force (F) equals a constant (k), times the displacement or change in length (x)’, or F=kx solution approach, extended to handle the fact that, in the real world, when you double the load, you generally don’t get double the displacement.

(In lots of cases, you nearly do, and in the world of simulation, that is often enough to provide the necessary confidence and design insight.)

Explicit solvers at work

Explicit solvers, by contrast, are different. I’m in the last throes of putting together a course on explicit solvers for NAFEMS, the international association for the engineering modelling, analysis and simulation community. In the process of building this course, I’ve been researching the early history of the technology, which predominantly centres on two main sectors where the explicit people have typically plied their trade: defence and automotive.

It’s rare that you can say definitively that somebody was the first to do something, but the YouTube video of John Hallquist talking about writing the first version of Dyna3D for a project pretty much puts a stake in the ground.


While employed in the weapons lab at Lawrence Livermore National Laboratory (LLNL) for 15 years, Hallquist worked on a massive finite element programme called LLNL DYNA 3D, which modelled collisions and explosions. I love that sort of thing: a project, a need with no obvious solution, and then the invention of a new technology to drive the project forward. And this technology unlocked the simulation of high-speed events where the F=Ma bit dominates the F=Kx stuff.

While defence provided the motivation and incubator for explicits, automotive was the poster child. I guess that’s because motor manufacturers are more marketing-savvy than the military-industrial complex, and there are few areas where simulation can be said to have been such an intrinsic contributor to people’s safety and wellbeing.

Full vehicle crash impact models are large, complex and, as a result, require serious model build and solve resources. In fact, these complete car and occupant models prove an interesting point about simulation workflows. They take a lot of making. Even in this age of streamlined automated process, it would undoubtedly be cheaper to crash a real car than build a simulation model.

But the second real test costs about as much as the first, whilst for another run of the car simulation model with slight modifications, the additional costs are negligible.

A multi-solver world

Explicit Solvers
Vehicle crash impact models provide explicit solvers with a chance to shine

The automotive and defence sectors were, for years, the only place you encountered this technology, with the systems, packages, approaches and knowledge so domain-specific they rarely escaped into the wider world.

Yet we now live in a multi-solver world. If you understand the basic physics and essential mathematics of implicit solvers (and if you are using them, you really should!), you can understand the basic physics and essential mathematics of an explicit solver.

In some senses it’s easier. Everything you learned about traditional solvers is still relevant in this new and oddly nuanced world.

But how did this multi-solver world come to be? Well, in many respects, we can thank the acquisitive nature of the engineering software world, though in the first instance, it didn’t happen that way. Abaqus was probably the first code that offered users the chance to switch from one type of solver to another. They’d developed both themselves, but since then, the rest of the market has caught up. Today, you’ll find that most of the simulation mega corps offer both implicit and explicit solver options, often based on the same pre- and post-processing environments.

It’s even possible in mainstream CAD workspaces like Solidworks Simulation, though the solvers aren’t named as such. So you can now choose the best solver for your creative workflow without the need for some form of Damascene conversion.

So, in a ‘normal’ workflow, where are the solver sweet spots? Traditional implicit solvers suffer where events are rapid and responses extreme. And by “extreme”, I mean complex contact interactions, permanent deformations and materials working at the very outer limits of their capabilities. Generally speaking, you recognise it when you see it.

As we said, car and plane crashes qualify as use-case scenarios where explicit solvers work well, but so do processes like installing and operating medical devices and forming metal parts in manufacturing.

If the event being modelled takes more than a second or two, then implicit solving is probably the right answer.

However, given that we now live in a multi-solver age, it’s increasingly clear that the ability to experiment with both implicit and explicit solvers on the same application is critical to developing the creative workflows that drive product development. And that’s true, even if you aren’t part of the military-industrial complex.

Laurence Marks built his first FEA model in the mid-1980s and his first CFD model in the early 1990s. Since then, he’s worked in the simulation industry, in technical, support and management roles.

He is currently a visiting research fellow at Oxford Brookes University, involved in a wide range of simulation projects, some of which are focused on his two main areas of interest: life sciences and motorsports

Leave a comment