Constraint Matrix Not Identity

The equalDOF, rigidLink, and rigidDiaphragm commands constrain one or more nodes to move in direct proportion to the motion of another node.

In the case of the equalDOF command, the constraint is of the form us = up, where us is the displacement of the secondary node and up is the displacement of the primary node. The constraint is typically based on the initial position of the nodes. The constraint matrix that is formed internally is the identity.

However, for the rigidDiaphragm constraint, the relationship between the displacements of the primary node and the secondary nodes is based on the initial locations of the nodes within the plane of the diaphragm, e.g., us = up + X rp, where rp is the rotation of the primary node and X is the distance between the primary and secondary nodes. As a result, the constraint matrix that is formed internally is not the identity matrix. Same goes for the rigidLink -beam constraint.

The Plain constraint handler–the default constraint handler–cannot handle constraints whose constraint matrix is not the identity. So, if you do an analysis with rigid diaphragm constraints with the Plain constraint handler, you will get a warning message from OpenSees.

Consider the following simple example of a rigid diaphragm.

import openseespy.opensees as ops

ops.wipe()
ops.model('basic','-ndm',3,'-ndf',6)

L = 10
k = 200

ops.node(0,L/2,L/2,0); ops.fix(0,1,1,1,1,1,1)
ops.node(1,L/2,L/2,0); ops.fix(1,0,0,1,1,1,0)

ops.uniaxialMaterial('Elastic',1,k)

ops.element('zeroLength',1,0,1,'-mat',1,1,1,'-dir',1,2,6)

ops.node(2,L,0,0)
ops.node(3,L,L,0)
ops.node(4,0,L,0)
ops.node(5,0,0,0)

for nd in [2,3,4,5]:
    ops.fix(nd,0,0,1,1,1,0)

ops.rigidDiaphragm(3, 1, 2,3,4,5) # dir, primary, secondaries

ops.analysis('Static')
ops.analyze(1)

Running this script, you will get the following output with warning messages about the constraint matrix not being identity and, for this simple model, the analysis failing because of floating nodes with the unenforced constraints.

The solution to this issue is to use the Transformation constraint handler, which uses the transformation method (essentially static condensation) to handle constraints.

ops.constraints('Transformation')
ops.analysis('Static')

Re-run the script and you should get no errors.

5 thoughts on “Constraint Matrix Not Identity

  1. If rigidDiaphragm and rigidLink are based on the initial coordinates, does that mean using them will result in loss of accuracy in geometrically nonlinear analyses?

    Like

  2. I always thought that any kind of constraints would require something other than the Plain constraint handler. So, the Plain handler works with equalDOF constraints. Good to know!

    Liked by 1 person

Leave a reply to Michael H. Scott Cancel reply

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