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.

3 thoughts on “Polymorphic Pitfall

  1. Dear Prof,
    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.
    Sukumar Baishya
    Professor
    Department of Civil Engineering
    NERIST

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

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