column buckling check
column buckling check
(OP)
I tried following the procedure in this thread (suggested by 271828) to get a column buckling load out of a program, but it just isn't working. It keeps upping the lateral displacement, but it never becomes unstable near (or above) the elastic critical buckling load. I could double the euller buckling load, but the lateral displacement is always appropriately proportional.
thread507-211026: Column Effective Length
thread507-211026: Column Effective Length






RE: column buckling check
What type of analysis? Small-displacement P-Delta?
RE: column buckling check
RE: column buckling check
RE: column buckling check
RE: column buckling check
RE: column buckling check
RE: column buckling check
THis makes me think you are running a first-order analysis. Are you sure the second-order feature is turned on?
Also, you might try the AISC App. 7 Commentary benchmark problems to make sure RAM's second-order analysis actually works.
RE: column buckling check
Do you only have to divide a frame element into finite pieces to capture p-δ or should you break them into finite pieces and also introduce a "kink" in that node?
RE: column buckling check
In StrlEIT's analysis, he is trying to compute the buckling load for a specific mode using a very specific kind of analysis. He needs to displace the modes into the shape of the mode that he's looking for. If it's simply supported on both ends, then this initial shape is something like a half-sine wave.
RE: column buckling check
RE: column buckling check
([Ke] + Lambda*[Kg]){Delta}={0} where
[Ke] = elastic stiffness matrix (the one everyone thinks of as the "stiffness matrix"
[Kg] = geometric stiffness matrix
Lambda are constants.
Of course, {Delta}={0} is a solution, but that's worthless to know.
If you set the determinant of [Ke]+Lambda*[Kg]=0, you get values of Lambda that correspond to non-trivial solution--hence the term "eigenvalue analysis." These relate to the buckling loads. Corresponding {Delta} are the modes.
[Ke] and [Kg] can be for any kind of element. [Kg] has P's in it if you have frame elements, membrane stresses if you have shells, etc.
RE: column buckling check
I'm working with W8x31 (arbitrarily decided on by me). I have the buckled shape modeled for weak axis buckling. I'm coming up with a critical elasic buckling load of right around 185K (on paper). The problem is that the program is giving me results that aren't making sense to me. The lateral displacement that increases upon initial loading (as expected). What isn't expected is this - The lateral displacement stays small up until around 100k (it's around 0.17"), from there it starts jumping up faster. At 135k, the lateral displacement is 0.28", at 170k it's 0.82", at 180k (just below critical buckling) it's 1.4" (like it's already buckled, but I would have expected much higher displacements for a buckled shape), at 190k (just above critical buckling) it's 3.8" (again, possibly buckled, but I would have expected much higher displacements for the buckled shape).
Here's the real kicker. At 200k, it's buckling mode changes. It jumps from the buckled mode that I assumed to a half-sine wave in the opposite direction (i.e. my assigned half-sine wave had positive 'displacements', but the buckled shape half-sine wave has negative displacements) and of much larger magnitudes (6.9" at mid-height), more along the lines of what I would expect from a critical buckling load.
Any ideas?
RE: column buckling check
RE: column buckling check
RE: column buckling check
Loads and center displacements as follows:
160k -6.6"
170k -12.19"
175k -19.64"
180k -46.58"
185k -156"
RE: column buckling check
RE: column buckling check
Here's what I did. Maybe there's something in there that'll help:
Create 20' long beam of two frame elements with a node in the middle. End nodes are set up to create a pinned-pinned condition. Move the middle node 0.01" and auto submesh the members to get nodes at 1' apart. Note that the initial shape is not exactly a sine wave. This won't matter in the end. It's close enough to the mode shape we're after.
Give the W8x31 zero shear areas to ignore shear deformations (your issue might be this or something similar). Give it 1000x bigger area so axial deformations won't make the plot hard to read in its deformed shape.
Use P-Delta, which solves [Ke+Kg]{Delta}={F}, so no iteration is required. No need to use P-Delta plus large displacements option that would move nodes and iterate.
Pe = 184.352 kip
Results:
P (kip) Delta (in.)
170 0.0961
182 0.6272
184 4.229
184.32 45.68
184.349 403.0
185 -2.32
The shapes look like half sine waves, but I didn't pull numbers out and verify mathematically.
Try to see what happens between 190 kips and 200 kips. My guess is that your model has something in it that causes a little more stiffness than that used to compute Pe, and you'll see the deflection take off somewhere between 190 and 200 kips.
RE: column buckling check
Either way should work. Like you typed, the displacement will more suddenly increase with smaller initial displacement.
RE: column buckling check
RE: column buckling check
RE: column buckling check
I actually thought that until it buckled in a different mode than I originally assigned (which is making no sense to me whatsoever).
RE: column buckling check
I tried modeling it without the initial curvature and it never buckles.
RE: column buckling check
I don't know why it never represents buckling if you take out the initial curvature.
RE: column buckling check
RE: column buckling check
Here's my results:
Load Defl at midpoint
w/o Shear Def. w/ Shear Def.
100 k .058" .058"
150 k .207" .210"
175 k .808" .842"
180 k 1.561" 1.695"
185 k 13.86" 42.30"
186 k buckles buckles
Per AISC 13th Edition - Equation E3-4, Fe x Ag = 184.9 kips
RE: column buckling check
RE: column buckling check
RE: column buckling check
First-order analysis won't give the buckling load using this method because the following system is being solved: [Ke]{Delta}={F}. Because [Ke] only has material props, section props, and lengths in it, if you increase {F}, then {Delta} MUST increase proportinally.
Without iterating and moving nodes, the following must be solved: [Ke+Kg]{Delta}={F} [Kg] has P/L terms if it's linearized and higher order terms if it's geometrically consistent. This allows non-proportionate {Delta} growth with tiny {F} increases. This is very, very similar to how AISC's B1 grows as Pr approaches Pe1 in Eq. C2-2. Pr is analogous to [Kg] and Pe1 is analogous to [Ke].
StrlEIT, try breaking the members up into shorter members. If Ram uses a linearized Kg, then it's internally overly-restrained which would make it a little stiffer than it should be. SAP uses a geometrically consistent Kg, so this doesn't happen as much. I seem to remember that RAM used the goofy linearized Kg. It's about 10 min. extra effort to use the geometrically consistent one.
RE: column buckling check
Don't use RAM Advanse? I had a bad experience with an oddly shaped truss where RAM Ad was telling me certain web members were zero force. I didn't believe it. Risa3D and RAM Ad were giving very different answers and the Risa3D results seemed to make sense to me. (It wasn't P-delta related.) To this day I still don't know why the difference.
RE: column buckling check
RE: column buckling check
I'm curious if the RAM guys were ever contacted and asked to explain the differences between their P-Delta results and the other programs.
It would be interesting to hear what they said. Oftentimes, tech support guys can give a simple explanation for what seems like a very complex difference.
I find it hard to believe that the average user can be expected to play with convergence tolerances and solution algorithms (Modified Newton Raphson vs what?). That sounds more like what is expected from the users of a true non-linear analysis program.
Josh
PS Disclaimer: My interest is really related to the strengths and weaknesses of various methods of accounting for the P-Delta effect. I work for another analysis program. We are considering adding an alternate method of P-Delta analysis. Hence my interest in better understanding the strengths and weakness of the various methods.
RE: column buckling check
After reading it, I have no idea why StrlEIT's analysis didn't work or work without tweaking the parameters. They're using the geometrically consistent [Kg] so that's not it. They're using element geometric stiffness matrices instead of story-wide matrices, so that should be OK. I don't see the difference between their description and what SAP2000 does. Maybe SAP2000's default second-order parameters are better. I had forgotten that iteration is still required because P in each element might change from iteration to iteration, changing each element's [Kg].
My only guess is that there's something basic wrong with the model, making it stiffer than it should be.
RE: column buckling check
How 'bout adding response history analysis?!
100000e
RE: column buckling check
They do not form [Kg] for shell elements. Not saying that I know it's wrong, but I'd sure do some careful checking if I had a shearwall structure or was creating a member out of shells to do an analysis similar to StrlEIT's.