Non-Convergence Does Not Mean OpenSees Crashed

I once had the following conversation with a concerned user (CU) of OpenSees:

CU: "I was running a response history analysis, then all of a sudden OpenSees crashed."
PD: "Really, it crashed? Did you get the blue screen of death?"
CU: "No. The analysis stopped and I saw 'Failed to converge'. It crashed."
PD: "Oh, I see. What did the convergence test show on the last time step?"

The conversation continued until we figured out CU should opt for the relative simplicity of Concrete02 over Concrete23 in their fiber sections. Another CU claimed OpenSees crashed, only to find out that increasing the maximum number of iterations in the convergence test will give ModifiedNewton a fighting chance to find equilibrium.

Nonlinear structural analysis is a dark art and OpenSees is not a magic spell. OpenSees can crash for several reasons: dereferencing an invalid or null pointer, memory leaks, unhandled exceptions, etc. It’s the usual suspects for code written by humans in a programming language (C++) that does not do its own garbage collection.

A crash is a failure of resource management while non-convergence is a failure of the analysis algorithms or the finite element model. Note that non-convergence does not necessarily mean the structural model entered a failed or collapsed state. More on that in another post.

Below is a screenshot of non-convergence. The model response is nonlinear but the ModifiedNewton algorithm has only 10 iterations to converge. The norm is decreasing, but we need (a lot) more iterations to reach equilibrium. A smaller time step would help.

And here is a screenshot of a crash resulting in a core dump. I’d rather not say how I did this, but has Commander La Forge returned from shore leave yet?

As a general rule, if you get back to the OpenSees > prompt, like in the first screenshot, OpenSees did not crash. Check the norms coming out of the convergence test, then play with the analysis options and time step.

If that doesn’t help, check the material models and their input parameters–nine times out of ten, they are the culprits of non-convergence. Try swapping out one material model at a time for its elastic equivalent until you get to an analysis that converges. Diagnose the issue, then reintroduce the nonlinearity.

If you back all the way up to a completely linear-elastic model and still have convergence problems, delete your scripts, reboot your computer, and start over from scratch.

If it really was a crash, send me as much information as possible about the circumstances and how I can reproduce it.

4 thoughts on “Non-Convergence Does Not Mean OpenSees Crashed

  1. I am doing convergence study on a dome model by varying elements from 2 elements to 12 elements per member [dispbeamcolumn element]. The model is working fine for all the elements except when 12 elements are used. In total there are 4560 elements in the model. the eigen value analysis works properly, however when running gravity analysis for model with 12 elements, the opensees closes automatically without any error messages [I assume it is crashing]. The system on which I am running is having 32 gb ram and intel i9 11 gen processor. Is it related to memory size needed for running the analysis?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.