Rigid Joint Offsets

The geometric coordinate transformation objects handle rigid joint offsets for frame elements in OpenSees. This is nice because the code for the transformations of displacements and forces is not duplicated in the element state determinations.

There are three things to keep in mind when using rigid joint offsets. First, the offsets are global with respect to the element nodes, making the offsets not invariant to the selection of the element I and J nodes.

Second, and perhaps most obvious, the offsets will change the deformable length of the element. As a result, you have to be careful defining element properties relative to the element length, e.g., plastic hinge lengths.

Finally, the offsets will change the direction of applied member loads (and also the resultant of distributed loads).

Consider an element defined between two nodes with a uniform distributed load. The definitions of the geometric transformation and the distributed load are shown below:

ops.geomTransf('Linear',1)

ops.eleLoad('-ele',1,'-type','beamUniform',-0.8)

For brevity, I omitted intervening commands like element, timeSeries, and pattern. With rigid joint offsets, the commands will be:

ops.geomTransf('Linear',1,'-jntOffset',4.0,1.0,-4.0,-1.0)

ops.eleLoad('-ele',1,'-type','beamUniform',-0.8)

These two cases are shown below.

The rigid joint offsets work for 2D problems with all three types of transformation: Linear, PDelta, and Corotational. For 3D problems, rigid joint offsets are implemented for only the Linear and PDelta transformations.

4 thoughts on “Rigid Joint Offsets

  1. Let’s say I have defined an element with distributed plasticity (plasticity length is lets say 0.3 m) such as this (without rigid offsets):

    element forceBeamColumn $eleTag $iNode $jNode $transfTag “HingeRadau $secTagI 0.3 $secTagJ 0.3 $secTagInterior”

    but I decided to define rigid offset such as this:

    geomTransf Linear $IDBeamTransf -jntOffset 0.2 0 -0.2 0

    should it be like this then?:

    element forceBeamColumn $eleTag $iNode $jNode $transfTag “HingeRadau $secTagI 0.5 $secTagJ 0.5 $secTagInterior”

    what do you think? thanks.

    Like

      1. It does not about my modeling objective. You say “As a result, you have to be careful defining element properties relative to the element length, e.g., plastic hinge lengths.”. My question is, if I define rigid end offsets, including rigid end offset length to the plastic hinge length is a right way? (At first question, j end plastic hinge lengths must be negative btw.)

        Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.