Code specified loads are minimums. Where designers have identified a need to design for criteria not set out in the code, such as possible resonance, it is incumbent upon them to design accordingly.
While that’s certainly the case the problem then becomes one of telling junior engineers that they are to second guess their engineering “betters” who write the codes. Not everyone in the position to need to do that necessarily has the confidence to do so. It’s akin to the situation of the junior copilot not having enough confidence to correct the senior pilot who’s flying the plane into the ground.
And when load factors are based on “sophisticated” statistical analysis the potential for problems increases. If nothing else it presents the moral hazard of built-in overconfidence in their validity…after all, they were developed by very “sophisticated” people…
We don’t have to go far to find an example of that occurring. Last week on this site we discussed a situation where using the code-proscribed loads would have materially under-designed a beam holding a roof snow load on one side and a Christmas party on the other. Some said it was realistic to consider that occurrence while others said it wasn’t. Meanwhile the owner presumably didn’t want to pay any more than he had to to have it built legally and safely, thus putting the engineer a difficult position of being arbiter of what constitutes that. (Pop says yes, Mom says no, make up your mind ‘cause I gotta go…)
The problem I have with statistics is not the math itself but the assumptions that go into formulating the pool from which the samples are drawn. I’m told that the math is ironclad and I don’t dispute that; what I question is who gets to decide from which pools and on what basis the samples are drawn. That always requires human judgement and that judgement call is virtually uncontestable by the end user because he’s too far removed from process to do so.
No situation is fool-proof and no law of man will ever be perfect but the custom-tailored “sophisticated” load factors provide one more opportunity for unsophisticated rube-like lesser engineers such as me to get it wrong. I miss ASD.*
*(Real ASD, that is, not the hoodwinking con that is Allowable Strength Design.)
ASD's 0.6 factor (or 0.66 or 0.75, or somewhere in between in some cases) all were based on actual experience over time based on what worked.
Engineers sometime in the past started using the 0.6 safety factor on yield, we used it over time with success, and voila! we had a consensus on a safety factor.
So ASD, whether we like it or not, was based on a limited pool of knowledge, limited tests and measures (if any), and probably many anecdotal experiences.
We could perhaps realize that it was extremely uncertain, unsophisticated and a very inaccurate way to ensure safety...but it worked over time.
So ASD is also based on statistics...just done in a very crude way.
LRFD was simply keyed/calibrated to ASD failure probabilities for typical ranges of dead and live loads. This isn't a real earth shattering concept in my view.
While we might consider the use of statistics to be "sophisticated" they are simply a good way to understand and visualize measures of safety.
I think your main point seems to be that with separate dead and live load factors that there is a vast pool out there of rube-like engineers who just won't properly understand it and screw it all up when confronted with a gray area in the codes. I guess I don't think a pair of load factors are all that difficult to work with when compared with 0.6Fy but that's just my opinion.
PS - I'm not trying to be a cheerleader here for LRFD vs. ASD - I started my career with ASD and use both today...(and I certainly hope and pray that, Lord help us!, we don't fall into a debate here on the merits and evils of the two systems).
Check out Eng-Tips Forum's Policies here:
faq731-376
>>>So ASD is also based on statistics...just done in a very crude way.<<<
Yes, certainly, I'm not saying otherwise. My point, as you noted, had more to do with the idea that the more we try to refine, segregate and statistically model the likelihood of various loads occurring -- and assigning them each their own statistically-likely load factor -- the more possibilities there become for getting them wrong while having a false sense of security about it. I contend that the assumed loads we work with are too approximate to merit all the various load combinations and, more importantly, said combinations can get in the way of each other, as we saw last week. I know we're not going back to how it used to be but I nevertheless reserve the right to my dinosaur opinion about it, statistical outlier though I may be. ;-)
So there is nothing like 100% safe. We take chances like in earthquake and wind combination.. They never comes together because the probability that both occur together is very less but not 0 still.
While that’s certainly the case the problem then becomes one of telling junior engineers that they are to second guess their engineering “betters” who write the codes. Not everyone in the position to need to do that necessarily has the confidence to do so. It’s akin to the situation of the junior copilot not having enough confidence to correct the senior pilot who’s flying the plane into the ground.
I actually agree with your general point (in fact last week I presented a paper at a conference making much the same points), but I don't agree that returning to ASD is the way to solve the problem (even if it is "real ASD" whatever that is).
The point is that specific provisions in codes only (and can only) deal with predictable events. All codes have general provisions intended to reduce the risk of failure as a result of unexpected or unpredictable events. Junior engineers need to be aware that when they consider events not covered by the specific provisions of the code they are not "second guessing" the code writers, they are doing their job as engineers, and following the requirements of the code (although in some cases those requirements are pretty well hidden).
In my opinion code requirements for this sort of analysis should be amplified and made clearer, and having an explicit third "collapse" limit state, in addition to serviceability and ultimate limit states, would be the best way to achieve that. Nonetheless, with the codes we have all engineers should be aware that their is more to their job than working through the detailed provisions of the code and ensuring that all individual members have adequate strength under the specified loads.
