Have you ever seen OpenSees.exe vanish all of a sudden or received a “Kernel died” message when running OpenSeesPy in a Jupyter Notebook?
exit() function is the likely culprit. Or a segmentation fault. But this post will focus on the
Some grepping and line counting reveals over 2,000 calls to
exit() embedded in
OpenSees/SRC. So why all the calls to
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.
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
The segmentation faults will be much more difficult to find.
4 thoughts on “No Exit”
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.
LikeLiked by 1 person
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.
while doing a static analysis of a dome I am encountering the same issue. When checked, the transient and eigenvalue analysis are working fine. I have no clue why it is just happening in the case of static analysis only