Polymorphic Pitfall

Polymorphism is what makes OpenSees, and other object-oriented software, flexible and extensible. With polymorphism, you can program to an interface, not an implementation.

You see this approach all over OpenSees–elements don’t care how materials compute stress and tangent (more here); integrators don’t care how the elements form resisting force and tangent stiffness (more here); and so on.

C++ supports polymorphism with virtual functions. Other languages support polymorphism differently and some don’t support it at all, but you can always achieve polymorphism with switch statements.

In C++, it’s easy to break polymorphism with mismatched method signatures, as discovered recently with recorders.

When they are created, element recorders call setResponse to obtain an integer code that indicates which element response will be recorded. Then, when they are asked to record during an analysis, element recorders call getResponse with that integer code in order to retrieve the requested response.

An old method signature for setResponse made it so recorders did not record anything for ZeroLengthContact2D and a few other elements. The signature for ZLC2D::setResponse did not match the base class Element::setResponse, so the base class implementation of setResponse was called and returned an integer code that was not recognized in ZLC2D::getResponse. As a result, nothing was recorded the analysis.

To make a long story short, this issue was fixed with PR #610, but more work needs to be done with recorders. This video from the OpenSees Cafe gives a more detailed explanation of the issues and their solutions.