No Exit

Have you ever seen OpenSees.exe vanish all of a sudden or received a “Kernel died” message when running OpenSeesPy in a Jupyter Notebook?

The C++ exit() function is the likely culprit. Or a segmentation fault. But this post will focus on the exit() function.

Some grepping and line counting reveals over 2,000 calls to exit() embedded in OpenSees/SRC. So why all the calls to exit()?

The one most frequently encountered occurrence is when the vector in the x-z plane supplied to the geometric transformation is parallel to the element x-axis. There’s an open GitHub issue on this topic along with a minimal working example and a proposed solution.

Beyond this common case with the geometric transformation, a large number of exit() calls are due to C++ constructors not being able to return an error code. If the input arguments are incorrect, the exit() function allows you to pull the plug on the entire analysis and not move on with bad inputs.

We used to have a g3ErrorHandler that would allow a graceful exit from a constructor, or elsewhere. Here is the error handler in use back in 2001–if the deformation points on the backbone of a HystereticMaterial are not strictly increasing, we signaled an error.

But for some reason, the error handler was removed from OpenSees and now exit() is called.

Automatically correcting the inputs for a backbone function is not so straightforward, so removing this occurrence of exit() will require some thinking.

However, fixing inputs is relatively easy in other cases. Consider the constructor of the HyperbolicGapMaterial, which calls exit() if the input gap is positive instead of the desired negative.

No offense to the author of this material model, but instead of calling exit(), you could have just written gap = -gap; and let users move on despite their mistake. No doubt, there are many other similarly punitive uses of exit() in OpenSees and HyperbolicGapMaterial was not the first.

Calling exit() in the constructor became standard practice as the number of material models exploded. However, not all 2000+ exit() calls are from material models. The calls come from all over the OpenSees framework for various reasons.

Getting rid of the exit() calls will be challenging. I got rid of a few exits today and in doing so found easily fixable bugs in nearby lines of code. So, it will be a good thing to examine all the occurrences of exit().

The segmentation faults will be much more difficult to find.

2 thoughts on “No Exit

  1. Thanks for this one! It would also be great to have a post on the “segmentation fault” as from a user’s end I have no clue what’s happening after having encountered it many times.

    Liked by 1 person

    1. You’re welcome! Segmentation faults are not obvious and can appear in strange places. Usually, they are due to uninitialized variables, dereferencing stray pointers, or indexing beyond array bounds.


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 )

Google photo

You are commenting using your Google 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.