Blog
I couldn't sleep for two weeks.
Not because something was broken. Because something finally started to work in a way that felt like a real shift for finite element analysis.
Nonlinear analysis has always been one of the places where structural engineering software slows down. It is powerful, but expensive. It can capture large displacements, second-order effects, buckling, and instability, but the price is usually long solve times, careful setup, and convergence behavior that can turn one model into an afternoon.
That cost changes how engineers work. Nonlinear analysis becomes something you reserve for late-stage validation, specialist studies, or cases where the risk is already obvious. It is too heavy to use while the design is still moving.
The Shift We Are Building Toward
With Awatif, we are trying to make nonlinear analysis fast enough to enter the workflow much earlier.
The goal is not to replace trusted FEM tools. Abaqus and similar solvers have earned their place in engineering practice. The goal is different: make reliable nonlinear feedback available while engineers are still exploring options, testing assumptions, and shaping the structure.
If a nonlinear result takes hours, it is a final check. If it takes seconds, it becomes part of the design conversation.
Why It Is Slow In The First Place
The bottleneck is not the physics. It is the route taken to it. Conventional FEM walks to the answer: apply a fraction of the load, iterate to equilibrium with Newton's method, repeat. Near a critical point the tangent stiffness becomes ill-conditioned, increments get cut and retried, and the iteration count climbs without the solution actually advancing. Almost all of the cost is spent traversing the load path, not resolving the final state.
Awatif removes the path. The solver does not step the load on and iterate its way forward; it resolves the equilibrium state directly, and it stays stable through the critical point that forces a conventional solver to cut increments and retry.
The Benchmark
To test the solver seriously, we benchmarked Awatif against Abaqus on three buckling-sensitive frame-element problems:
- a cantilever column under combined tip load,
- a 3D portal frame with a top-joint load, and
- a clamped-clamped IPE 300 column with prescribed end displacement.
These are not marketing animations. They are benchmark cases designed to compare displacement response, solver iterations, residual error, and convergence behavior. Both solvers get the same model: the same geometry, sections, material, boundary conditions, and the same mesh of 10 to 20 segments per member. Any difference that follows is attributable to the solver, not to the element or the mesh.
The Result
Across the three benchmark cases, Awatif closely reproduced the Abaqus displacement response. The reported displacement differences stayed at or below 1.00%.
The performance difference is where things get interesting. Compared with Abaqus, Awatif reduced the solver iteration count by:
- 51,438.8× for the cantilever column, with 257,194 Abaqus iterations versus 5 Awatif iterations,
- 42,105.9× for the portal frame, with 294,741 Abaqus iterations versus 7 Awatif iterations, and
- 94.5× for the IPE 300 column, with 5,669 Abaqus iterations versus 60 Awatif iterations.
The pattern tracks the difficulty of the load path. The cantilever and the portal frame are force-controlled, so the structure is driven toward a critical point with nothing external to stabilize it — exactly where an incremental solver cuts and retries. Both exceed a quarter of a million iterations in Abaqus and converge in fewer than ten in Awatif. The IPE 300 column is displacement-controlled, so the imposed displacement steadies the path and Abaqus never stalls in the same way, and that is where the gap narrows to 94.5×. The harder the load path, the larger the advantage, because the advantage comes from not having to trace it.
Fewer iterations does not mean a looser answer. On both force-controlled cases Awatif converges to a tighter final residual than Abaqus, by two orders of magnitude on the portal frame. And endpoint agreement alone would not prove much, so the white paper also compares the full mid-span out-of-plane displacement history of the IPE 300 column: the two curves track each other through the onset of weak-axis buckling, the peak response, and the unloading that follows. Awatif does not just arrive at the same final state, it follows the same physical response to get there.
What This Means
Faster nonlinear solving changes when engineers can ask nonlinear questions.
Instead of waiting until the end of a project to ask whether buckling behavior, second-order effects, or large displacement response may become important, engineers can bring those checks into earlier modeling and design workflows.
That is the part that kept me awake. Not one benchmark number in isolation, but the possibility of moving nonlinear analysis from a late-stage specialist task into everyday engineering iteration.
Read the White Paper
We wrote up the benchmark cases, assumptions, displacement comparisons, iteration counts, residual errors, and conclusions in a short nonlinear solver white paper.
The scope there is deliberate: elastic frame elements, three benchmark cases, geometric nonlinearity only. The formulation is not restricted to them. We are extending the same framework to shell elements and to material nonlinearity, with the goal of a nonlinear check fast enough to run inside the design loop rather than after it.
If you are building engineering software in AEC, mechanical, marine, energy, or another simulation-heavy industry, I am open to collaborations. Send me a message and I will show you a live demo.