dispBeamColumn element

[khosravifar]

I'm not sure if my post delivered correctly, so I'm posting it again, sorry for duplicate.

Hi,

I have a problem finding the locations of ip's in dispBeamColumn element. In the manual the integration rule is mentioned to be "Gauss-Legendre quadrature", whereas when I back-calculate the location of ip's (by deviding the recorded moment at ip's by the applied force) I get the following:
element dispBeamColumn 1 1 2 $numIntgrPts $SecTag 1

numIntgrPts=2:
Xi = -0.3333, +0.3333

numIntgrPts=3:
Xi = -1.0, 0.0, +1.0

numIntgrPts=4:
Xi = -1.0, -0.4472, +0.4472, +1.0

numIntgrPts=5:
Xi = -1.0, -0.6547, 0.0, 0.6547, 1.0

By comparing it to available intergration methods (opensees.berkeley.edu/cgi-bin/cvsweb2.cgi/OpenSees/SRC/element/forceBeamColumn/) it seems that for ip>=3 it follows "Lobatto". So, my questions are:

1. Why manual refers to "Gauss-Legendre quadrature rule"?
2. If dispBeamColumn element uses Lobatto, why doen't it follow the same rule for numIntgrPts=2?
3. Is it possible to choose the integration method in the current version of OpenSees? If yes, what is the syntax?
4. I found that when I push my cantiliver column further to yield the element, then the location of ip's change. I wonder if such thing could be true.

Thanks much,
Arash

[fmk]

it is Gauss-Lobotto and not Gausee-Legendre, i.e. the manual is incorrect.

2 points does use -1 and 1, not sure where you are getting 0.333.

3. yes, after transformation tag you can specify one of:
Lobatto, Legendre, Radau, NewtonCotes, Tapezoidal or UserDefined. If USerDefined for each you add secID pt weight (where pt's between -1 and 1)

4. the integration points DO NOT MOVE during an analysis.

[khosravifar]

Thank you Frank,

I double checked 2 point and got +/-0.3333 instead. Even when I use UseDefined it still gives +/-0.3333.
Also I think UserDefined gets pt locations between 0 and 1.

Thank you,
Arash

[fmk]

it is between 0 and 1.

use a recorder to record something at a section and instead of using -file use -xml. look at output file to see location along length of section. when i do it i see 0 for section 1 and L for section 2.

[khosravifar]

I used -xml. It showes eta being 0 and L but when I divide the recorded moment by the applied force (to back-calculate the location of the ip) it is +/- 0.3333 (in range of [-1 +1]). It might be an integration error though, i.e. 2 integration pnts might not be accurate enough to integrate the polynomial that appears in the equation. I decided to use at least 3 pnts to overcome this.

Another question: The axial force chages dramatically at integration points. Any reason? You don't actaully see this if you call "recorder Element .. force;". It appears when you record force at one specific section, i.e. "recorder Element .. section 1 force;"
This huge change in axial force occurs when the element approaches yielding. In one element some of the integration points start to increase axial force, and some of them decrease. This affects the moment-curvature behavior of the integration points.

I don't know if it would be correct to relate this to the fact that different int pnts should have different plastic moments, since each have different distance to the applied force (M_p=force*L). Therefore the axial force changes at the int pnt to comply with the difference in plastic moment (just a thought). Note that there is no source of axial force on my column or nodes other that the constant axial force exerted on top node before my pushover force. "geomTransf" is Linear.

[yfeng]

Frank, the manual says that dispBeamColumn element is linear curvature distributed. Is this mean that the integration rule just control the distribution of integration points but the curvature between the points is linear distributed?

[quote="fmk"]it is between 0 and 1.

use a recorder to record something at a section and instead of using -file use -xml. look at output file to see location along length of section. when i do it i see 0 for section 1 and L for section 2.[/quote]