Eigenvalue Buckling Analysis Trivia Question

[271828]

A thread in another forum brought up an interesting topic.

The upcoming AISC Stability Design Guide will put forth the idea of using eigenvalue buckling analysis capabilities of modern programs.

I think there's a very dangerous trap that's very easy to fall into and I'd like to throw it out there for discussion.

I'll illustrate the concept with an example:

10' long simply-supported steel column, 3" square cross-section. Pcr=pi^2*EI/L^2=134 kips.

Put this in SAP and it comes back with 134--no problem.

Now put this in SAP with a small bending moment. Still comes back with 134--maybe ok, maybe not.

Now put this in SAP with a 10000 kip-ft bending moment. It STILL comes back with 134--whoa!

The reason is that the eigenvalue problem is [Ke-lambda*Kg]{phi}={0} where Kg is the geometric stiffness matrix. It's filled with constants times P/L. It never sees the effect of the moment.

I'm not totally sure about this, but I think this type of analysis fails for ANY problem that has a nontrivial solution. In other words, put load on it and it deflects.

Opinions?

 

[271828]

Oh, I should elaborate a little more.

Examples of frames for which I think this fails are:

Portal frames with one column longer than the other.
Unsymm single gable.

Pretty much anything that remains undeflected as load is applied, then all of a sudden, it bifurcates at a critical load.

Another example might be a symm portal frame with unif loads applied to the girders. This will cause bending in the columns and therefore a nontrivial solution. I think this one works fine as long as the loads are applied to the joints only.

It will also matter if the members are subdivided. Not sure if this works at all if column just go from floor to floor, for example.

I'm not totally sure about all this, so throwing it out there for discussion.

 

[haynewp]

Just first reading through this I am thinking that the design guide coming out is focused on direct analysis which requires certain imperfections to be modeled into the frame when doing a first order analysis to capture second order effects. An AISC based compression-moment interaction check still has to be performed in the end to reduce the axial that can be applied given a moment.

 

[271828]

haynewp, that's not the part I'm referring to.

The new DG does focus on the DAM, but has sections on the Effective Length Method. They discuss eigenvalue buckling analysis for ELM and use it in some examples to get elastic buckling loads.

Later on, Chapter H stuff gets checked.

 

[haynewp]

Hasn't ELM always been based on eigenvalue buckling? Can you point me to a page number of an example you are talking about?

 

[271828]

It has, but the difference is the proposition of using buckling features in the various programs out there on more of a system basis rather than individual elements. I suppose this has always been allowed, but I doubt many people thought about using it or this purpose. Now, presumably, there will be a lot more people using these features, but they are subtle, IMO.

A page number in what? Draft Stability DG?

 

[haynewp]

Yes, the draft.

 

[271828]

Top of Page 45.

Example 5, Page Ex 5-9

Example 11, Page Ex 11-9, Line 352

Example 12, Page Ex 12-8, Line 281

It might work great for these cases. I'm just wondering if there are other cases for which the approach will be completely wrong, but non-obvious to engineers not intimately familiar with computational stability.

Perhaps I'm the one who doesn't understand it!

For one thing, I think they made their point--use the DAM to avoid all this garbage!!

 

[haynewp]

The story buckling "K" (C-C2-8) equation appears to be have been around for awhile (1970's). (See the discussion in the AISC 2005 commentary to Chapter C, starting on page 244.) .

What you were finding with SAP is the elastic critical buckling load which is only a part of frame stability, which also depends on the buckling mode chosen.

As you know, DM is the better way to go. This is according to the authors of the stability guide and from what I understand, AISC will be adopting this as the preferred method in the future.

I don't think I would mess with trying to get these old story buckling "K" equations to work with software when there is DM, I am SURE there are some situations where the ELM story equations don't really fit. Just like ELM in general; and the stability guide authors and AISC realize this. All of this "K" stuff can get really confusing...

If you really want to investigate frame stability, there is a program called MASTAN which looks very simple but is actually quite advanced in terms of investigating frame behavior and allows you to look into different analysis techniques. It is free to download, but unfortunately I can't find the link right now.

 

[271828]

FWIW, this is the thread that got me thinking:

http://www.eng-tips.com/viewthread.cfm?qid=188467&page=1

I agree that Appendix 7 is the way to go, especially for any problem with non-obvious K calcs.

Still not sure that the derivation of K through the use of modern programs' buckling analyses is a good idea for many engineers, though. It is more of a trivia question, I suppose, because most people won't try to do that anyway.

 

[mrMikee]

haynewp,

Your mention of MASTAN which I'm not familiar with made me think of MYSTRAN authored by Dr. Bill Case a member of the team that developed NASTRAN. The home page has an illustration of a truss eigenvalue problem.

http://www.mystran.com/index.htm

Regards,
-Mike

 

[Dinosaur]

My problem with this is that there are very few folks that can compute eigenvalues to check a computer program. In grad school, I wrote a basic program to find eigenvalues in a two degree of freedom system which would provide a more precise solution to the milti-story frame nomograph used for the past century or so. The problem was that the solution sometimes skipped a lower value and reported the second or third value. The user had to know enough to see that the first mode buckeled shape had been skipped and then have the computer look for lower roots, which was a time consuming option. The funny thing is that while I wrote this program, I couldn't do it today. If someone like me can't even reproduce a solution like that 20+ years later, how are these young guys going to even know what an eigenvalue is? In my opinion, if you ccan't do some kind of approximate calculation to check a computer, then you shouldn't be allowed to use the computer.

 

[mrMikee]

Back in the 80s I wrote a FORTRAN program to do a dynamic analysis of a mechanical system using modal analysis. I borrowed a lot from programs that the professors had available, but it was still a huge amount of work. Now I use Mathematica with all the matrix math and eigenvalues capabilities built in.

Wow, things have really changed.

I'm not sure I know what an eigenvalue is anymore, let alone check one by hand.

-Mike

 

[271828]

These are the kinds of things I'm typing about. Strl engineers are not aerospace or mechanical engineers, so don't sleep with stability and vibration books under their pillows.

My problem with eigenvalue buckling analysis stems from my opinion that almost no design engineer will be able to spot subtle modeling problems that might cause huge errors. I think it would've been better left un-said in the DG. If somebody knows enough to go looking for it, then fine--they probably have a background in this stuff.