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.
3 thoughts on “Polymorphic Pitfall”
Thank you very much for highlighting the issue with contact2d elements. In fact, in the fall of 2018, me and one of my PG students were trying to use this element in DDSI of retaining wall-backfill systems. However, after many different trials, we were unable to get any response at the interface, even for static loading. We thought it to be a convergence issue, because the command manual mentioned about convergence issue in dynamic case. We ultimately had to abandon the idea of using this element and attached the beam elements representing wall to plane strain quad elements via zerolength springs. Since then of course I haven’t tried the same problem again.
Hope this bug is fully resolved now as you have mentioned. Thanks once again for correcting my old wrong idea on the matter.
Department of Civil Engineering
LikeLiked by 1 person
Glad to hear the issue was finally addressed! Fortunately, there’s enough modeling options in OpenSees to circumvent issues like this.