Sent from my iPhone 3G
On Aug 27, 2009, at 10:38 AM, Chuck Utzman <chuckutzman@gmail.com>
wrote:
> Conrad
> Brevity is the soul of wit.
>
> Conrad Harrison wrote:
>> Gil,
>>
>> I am not aware of any mandatory serviceability criteria in the steel
>> structures codes. Though they do suggest a need to recalculate all
>> section
>> properties for deflection checks. And getting nonlinear analysis to
>> converge
>> can get a structure to be a lot stiffer than would otherwise need
>> be. The
>> main serviceability criteria I have come across are those in the
>> crane code,
>> and the industrial stairways and platforms code, and industrial
>> racking
>> code: but these aren't buildings and AS1170 is primarily for
>> buildings and
>> its serviceability criteria are informative suggestions. Also aware
>> of
>> criteria for communications antenna and electricity power poles,
>> these based
>> on acceptable loss of service: but once again not buildings.
>>
>> Mandatory is also a matter of perspective. It is relative to the
>> needs of a
>> particular design. If check of deflections at the ultimate strength
>> loads
>> doesn't increase member size, then no need to carry out analysis
>> for smaller
>> wind loads. For small structures this may be the case because
>> cannot find a
>> smaller section to use to meet strength requirements alone. Also
>> changing
>> return period, changes Vz, which in turn changes qz (no longer in
>> code), so
>> can ratio serviceability and ultimate strength loads based on ratio
>> of
>> square of the velocities. Only complication is serviceability load
>> factors
>> and combinations. For simple structures not a major problem, and more
>> complex structures tend to use analysis software which permits easy
>> combination of load cases: and people have different ways in which
>> they use
>> such load case combination features of software: some inefficient.
>> Also
>> depends on how pedantic the building officials are, and if
>> everything has to
>> be written out to the letter of the code: like qz not in code
>> therefore
>> cannot use.
>>
>> Also I don't believe, alternative return periods has anything to do
>> with
>> accuracy. It is more to do with serviceability being a subjective
>> judgment
>> and dependent on the needs of the particular situation. Thus the
>> mandatory
>> 20 year mean return period for serviceability in the 1989 code,
>> changed to
>> recommendation in the 2002 code.
>>
>> A steel fabricators building with the main doors open in the rain
>> and wind,
>> needs to be serviceable under such conditions, a 20 year mean
>> return period
>> may not be adequate. But then the now 500 year mean return period for
>> ultimate strength design may achieve adequate level of
>> serviceability at the
>> desired operational wind load.
>>
>> The limit states: stability, strength and serviceability are really
>> broad
>> classes of states . There is a whole spectrum of limit states for a
>> building
>> or other structure, and each has differing performance criteria. It
>> is the
>> designers responsibility to determine what limit states and
>> performance
>> criteria need to be assessed. The loading code and BCA simply
>> mandate the
>> performance criteria for ultimate strength.
>>
>> Codes increase in complexity, so that application of more complex
>> theories
>> can be granted approval for compliance. But the individual users can
>> collapse that complexity down to suit the needs of their particular
>> activity. Competent building officials, can see the relationship
>> between the
>> simplifications and the complexity of the code. Day to day design
>> needs to
>> be practical, but do need some control for those more complex
>> proposals so
>> that not declared noncompliant. In that respect I think there
>> should be
>> multiple tiers to the codes.
>>
>> As for statistics. We have to deal with variance, uncertainty and
>> risk. We
>> have simply progressed : lies, damned lies and statistics. So now
>> using
>> statistics instead of lying about provision of safety. Safety never
>> present
>> only risk.
>>
>> Risk based design, fits better with your earlier view about over
>> regulation
>> to protect people tripping over own two feet. If choose to walk,
>> then have
>> the risk of tripping: if don't accept the risk, then don't walk.
>> Or the case of two youths fighting in stairwell. They fall down the
>> steps
>> and one becomes a paraplegic. The designer was held responsible
>> because the
>> handrail was 50mm lower than the standards specify. Such ignores the
>> statistical variation in heights of people and their arm length.
>> The code
>> specified heights can be a hazard to life for many people: if they
>> slip the
>> handrail could prove to be either too low or too high for the
>> individual
>> concerned to regain their balance: vertical infill rails may provide
>> something to grab. Specifying a specific height or height range
>> implies the
>> provision of safety to the lawyers and public. Further more the
>> height of
>> the handrail, may be uncomfortable for the user and be the direct
>> cause of a
>> fall.
>>
>> Quality robust design, aims to find a design solution which can
>> accommodate
>> variance in the operating environment of the end-product, as well as
>> variance in the production process, and variance in the design
>> process. It
>> requires a adding greater level of focus on the qualitative aspects
>> of
>> design, not just aesthetics, but the functional requirements, and
>> not just
>> function as regards strength and stiffness, but the point for
>> making the
>> thing in the first place. What is the purpose of a hand rail and
>> guard rail,
>> can they be integrated into the one object, or do they need to be
>> kept
>> separate? What is a house, does it simply provide shelter, and
>> shelter from
>> what?
>>
>> Routine design is simply to go with the codes, and follow tradition.
>> Progress comes from questioning the status quo, and changing
>> perspective:
>> design a car or mode of transport, design a house or a shelter.
>> Regression
>> also comes from same approach.
>>
>> Variance all around. Some think changes to wind loading code
>> stupid, others
>> don't. The writers of a quality robust code would have taken that
>> variance
>> into consideration when writing the code, to reduce opposition to
>> it. I
>> guess they didn't. Therefore code not quality robust: complexity
>> opposed by
>> many, and therefore likelihood of unwarranted errors in design
>> creeping in.
>> Using the code becomes risky.
>>
>> On the other hand the mandated requirements are also less certain,
>> because
>> code accommodates a greater variety of circumstances, for which
>> designers,
>> suppliers and end-users are all made more accountable. Therefore
>> variance
>> from compliance with the code more difficult to detect: providing
>> designers
>> with a lot more scope for innovation. Far better than mandated
>> prescription,
>> yet the designers have opportunity to create and develop more
>> prescriptive
>> solutions for efficiency in production.
>>
>> If codes are highly prescriptive and lock a great deal in, then no
>> need to
>> keep on producing calculations, only need to produce once, since
>> variance
>> from the input parameters and the results are not permitted. In
>> which case
>> remove time consuming prescription on calculations, and simply
>> specify
>> prescription on what can construct. No, no, too much regulation,
>> want to
>> innovate!
>>
>>
>>
>> Regards
>> Conrad Harrison
>> B.Tech (mfg & mech), MIIE, gradTIEAust
>> mailto:sch.tectonic@bigpond.com
>> Adelaide
>> South Australia
>>
>>
>>
>>
>> ******* ****** ******* ******** ******* ******* ******* ***
>> * 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@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
>> ******* ****** ****** ****** ******* ****** ****** ********
>>
>
>
> ******* ****** ******* ******** ******* ******* ******* ***
> * 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@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
> ******* ****** ****** ****** ******* ****** ****** ********
******* ****** ******* ******** ******* ******* ******* ***
* 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@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
******* ****** ****** ****** ******* ****** ****** ********