OpenSees Cloud

OpenSees AMI

Pruning OpenSees

Original Post - 05 Feb 2023 - Michael H. Scott

Visit Structural Analysis Is Simple on Substack.


Most OpenSees pull requests add to the code base. Often incremental and sometimes innovative, the new additions keep OpenSees moving forward, offering something for everyone.

But it’s rare that we remove code. Although it would be great to purge OpenSees of Concrete23 and all its unused variations, to prune code in frequently used OpenSees classes is a much better use of time.

A question posted online last week led me down a couple of rabbit holes, one of which contained unnecessary methods in the BeamIntegration class. The methods dealt with the elastic interior of force-based elements with plastic hinge integration, a concept that gave way to more general numerical integration many years ago.

It turns out these superfluous methods were still being called during the state determination of ForceBeamColumn (2D and 3D)–at every iteration of every time step. Fortunately, the overhead was minimal as the methods were inline return statements. But a few zero ops ensued, as shown below in the code removed from ForceBeamColumn2d in PR #1161.

Dead code removed from force-based beam-column

This block of code prepares the force-based element to integrate its flexibility (f) and “resisting” deformations (vr) by first asking for contributions from the elastic interior, which no longer resides in the BeamIntegration object, or anywhere else for that matter.

A similar chunk of code was removed from ForceBeamColumn3d where the flexibility and deformations use six basic DOFs instead of three.

A good compiler may have been able to figure out this block of code was all zero ops. But, like dishwashers, compilers are not miracle workers. And you should never assume anyone compiles code with optimization flags turned on in the first place. So why not remove the dead code altogether?

In the grand scheme of a nonlinear dynamic response history analysis of frame models with force-based elements, this particular pruning will not make a noticeable difference in execution time. But pruning and code rewriting efforts in other element formulations have and will make a difference, e.g., here and here.

So, keep looking for opportunities to prune. Every little bit helps.