01 Feb

Rational Buckling Analyses to AS4100 or NZS3404 (Part 5)

So if you’ve been following along with this series you now hopefully know a little bit more about some of the methods involved in undertaking buckling analyses. Pat yourself on the back for making it this far through my ramblings I guess (if nothing else).

It’s pretty simple, and in most cases it will yield a capacity very similar to the code hand methods, albeit via a completely different path. It’s always good when different methods yield similar results.

Read More
25 Nov

Rational Buckling Analyses to AS4100 or NZS3404 (Part 3)

In the last post in this series we looked at a semi-real scenario where a rational elastic buckling analysis was undertaken in which we were able to determine the axial capacity of a system of members. The exact type of system of columns is sometimes referred to as a ‘lean-on’ system, whereby the column carrying no load helps to increase the capacity of the supported column. Basically, if we make the supporting column (or in other words the bracing system for the RHS) stiff enough it has the effect of producing a higher mode of buckling in the supported RHS column.

Read More
24 Nov

Rational Buckling Analyses to AS4100 or NZS3404 (Part 2)

In part 1 of this series we briefly explored the requirements related to calculating the capacity of a column via the use of a buckling analysis. Introducing the general methodology to follow and showing agreement with the normal hand methods for a known k_e.

In this follow-up post we look at the power and beauty of this method in being able to assess any complicated design scenario, typically ones that don’t fit in the mould of the typical idealised restraints.

Read More
20 Nov

Rational Buckling Analyses to AS4100 or NZS3404 (Part 1)

This post was inspired by a rather epic post at Eng-Tips forum, which came out of a seemingly simple request for some help on the segment length to consider for a continuous beam design to AS4100 (the Australian Steel code). Fast forward several hundred posts of debating issues of code interpretation, debates over critical flange definitions, everyone telling each other everyone else is wrong, backtracking, changing of minds, notionally proposing re-writing code clauses to suit particular sides of the argument, etc, etc. At the the end of it all there may or may not have been any real agreement reached, not unusual once engineers get to arguing.

You know when the original poster bows out at post #11, and the thread carries on for 200+ more posts that it’s a hot potato and there’s going to be a few virtual knife fights going down before it’s all said and done.

Read More