Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

RE: Simplified Seismic Design Trends

[Subject Prev][Subject Next][Thread Prev][Thread Next]
>What we had as standard code requirements about a dozen
>years ago is what I would call a simplified design.  I do not use the
>current simplified methods in the code.
I think you have to think about what simplification constitutes. I've 
heard a million arguments like this all the time with pressure vessel 
codes. Sometimes I've heard, 'A damn cookbook--I need more freedom' and 
'Too vague--it doesn't specify details,' from the same person on 
alternate days.

If you mean directions-on-a-TV-dinner simplification, the code will do 
all the thinking and analysis beforehand and all the creative stuff and 
isolate the engineer from decision making. The designer just peels back 
the foil, sticks it in the micro-wave, punches the 'Frozen Dinner' button 
and it heats in the time needed to look for a clean fork. The results 
will sustain life, but ti won't be dinner like mom used to make with all 
the tasting and planning and understanding of what does what. The 
designer figures a few things, looks up the general purpose bugger factor 
in a table and lives with the results. Too bad the code hasn't 
anticipated something that might be useful for some special purpose. This 
kind of 'simple' code necessarily incorporates a lot of worst-case 
anticipation, and sometimes overdoes things a bit because this kind of 
simplification is intended to remove thinking and decision making, along 
with the dreaded paralysis-by-analysis.

If you mean just-use-your-basic-mechanics simplification, what you'll 
have is a code listing specific performance requirements to meet. It 
means you'll end up doing a lot of fairly complex analysis--response 
spectrum and modal analysis for seismic design instead of seismic 
coefficient and aerodynamic analysis for wind loading, for example, and 
you'll probably have a lot of different categories of response to deal 
with--members that mustn't collapse before others or members that mustn't 
collapse at all, and the designer has to demonstrate, using basic 
mechanics, calculus, dynamics, continuum theory and all, that the service 
requirements are met. The advantage is that all the bugger factors--R's, 
omega's and what not--are eliminated in favor of detailed stress and load 
analysis to justify performance under load. The analysis burden is tough, 
but there are no restrictions on what detail to use. And no time wasted 
on hair-splitting arguments about which factor does what and how to 
'shave corners off the load calculation.'

Actually it seems like we want all the advantages of both approaches--a 2 
paragraph collection of absolutely infallible rules-of-thumb that cover 
every single detail and every engineer's ass as well. Good luck. 

>We have become "load" engineers, not building design engineers.
Thin about it for a minute--You can't know how a structure will perform 
if you don't know the loading. 


Christopher Wright P.E.    |"They couldn't hit an elephant at
chrisw(--nospam--at)skypoint.com        | this distance"   (last words of Gen.
___________________________| John Sedgwick, Spotsylvania 1864)
http://www.skypoint.com/~chrisw



******* ****** ******* ******** ******* ******* ******* ***
*   Read list FAQ at: http://www.seaint.org/list_FAQ.asp
* 
*   This email was sent to you via Structural Engineers 
*   Association of Southern California (SEAOSC) server. To 
*   subscribe (no fee) or UnSubscribe, please go to:
*
*   http://www.seaint.org/sealist1.asp
*
*   Questions to seaint-ad(--nospam--at)seaint.org. Remember, any email you 
*   send to the list is public domain and may be re-posted 
*   without your permission. Make sure you visit our web 
*   site at: http://www.seaint.org 
******* ****** ****** ****** ******* ****** ****** ********