The Linear Algorithm Strikes Again

This post on the OpenSees message board reminded me of another reason not to use the Linear algorithm, even when you have a linear model. Some elements need that second iteration in order to record all of their response.

Not only shellMITC4 mentioned on the message board, but also the beloved forceBeamColumn. If you define member loads on a forceBeamColumn element and use the Linear algorithm, the member loads are not applied correctly. I’m not exactly sure why.

Consider a simply-supported beam with a uniform distributed load. The midspan moment is , the support reactions are , and the support rotations are .

import openseespy.opensees as ops

L = 240.0
E = 29000.0
A = 20.0
I = 1400.0
w = 1.5

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

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

ops.geomTransf('Linear',12)

ops.section('Elastic',1,E,A,I)
ops.beamIntegration('Lobatto',1,1,5)

ops.element('forceBeamColumn',1,1,2,12,1)

ops.timeSeries('Linear',23)
ops.pattern('Plain',1,23)
ops.eleLoad('-ele',1,'-type','beamUniform',-w)

Nsteps = 2
ops.integrator('LoadControl',1.0/Nsteps)
ops.algorithm('Linear')
ops.analysis('Static')

ops.analyze(Nsteps)
ops.reactions()

The analysis results are shown below. Although the reactions are correct, the midspan moment is off by a factor of 2/3 and the rotations by 1/2.

Switch to the Newton algorithm and all is good.

You may ask “Why would you analyze an elastic beam using a force-based element in the first place?” Let’s say you had a nonlinear model, then backpedaled to an elastic model by switching from fiber sections to elastic sections. Then you had doubts about the analysis, so you give the Linear algorithm a try to see if everything makes sense. I do this all the time.