Need a book? Engineering books recommendations...

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

RE: Flush Moment end plate connections

[Subject Prev][Subject Next][Thread Prev][Thread Next]

I was intentionally being ridiculous.

In Australia the Australian Building Codes Board (ABCB) simply adopted two
software programs for energy efficiency. Basically only these programs can
be used for assessing efficiency, they are black boxes. Only runs by
certified users are considered valid. Only persons who complete the
certification course can buy the software.

The ABCB could equally well replace the steel structures code by LimSteel.
Which I believe is still produced by the centre for advanced structural
engineering (CASE) at the university of Sydney: the same place research is
conducted for our steel structures code.

If it is the code, it doesn't matter what is inside the program, all that
matters is that a design-proposal when pushed through the program is found
compliant: that would be the regulation. If there is only one program, then
errors and differences in interpretation of the written code otherwise
present in 100's of spreadsheets would be removed. Just one source of error:
which doesn't necessarily mean everything becomes defective.

Just as the mathematical formula has to reflect behaviour of the real
system, the blackbox program also has to reflect the behaviour of the real
system. The blackbox would be like a go/no-go gauge. People can test the
blackbox against mathematical theory, or check against physical experiments.
They can criticise its relevance just as they criticise the written codes.
But for the most part people would be pushing proposals through the gauge to
see if their project is a go.

However, engineering design is not about code checking, it is about finding
design-solutions to specific problems subject to various constraints,
compliance with the codes of practice is but one constraint.

Using the formula from the codes it is difficult to find a solution to
anything except by trial and error, which makes a computer useful for wading
through many calculations several times.

However by making lots of assumptions, and using simple theory and
relationships between variables, solutions can be found rapidly. By
generating tables and plotting curves based on code data, design-solutions
can also be found faster. By knowing what the theory is and what the
relationships are, it is easy to adjust the right parameters and push
towards a solution.

Without such knowledge simply pushing random numbers through a blackbox in
the dark, getting no where fast. Then again as part of TQM studies we were
given a blackbox computer program, representing an out of control
manufacturing process; we had to investigate the process, discover the
relationship between the parameters, and bring the process in control: and
no theory in the textbooks was of any use to guide the decisions: except
design of experiments. A computer virus infecting the software also made the
task a lot more difficult. Still it is possible to investigate a blackbox.

But by creating own spreadsheets, not only can you incorporate own
assumptions and design philosophy, but also determine own input parameters,
and report presentation. Most commercial engineering software only really
allows code checking, it doesn't permit playing with the theory, plotting
one variable against another. Nor does it permit connecting to other
calculations and piping data in from one program, and out into another

Off-the-Shelf "engineering" software doesn't really allow the user to do
much of anything. Useful for code checkers: useless for engineering.

Gerards Madden's 40 hours, is probably 40 hours well spent. With pencil and
paper would probably take similar time frame, but from now on will only take
a few minutes, and no waiting in future for commercial vendors to get up to
date, no upgrade fees. Further more can start to develop large parametric
systems, experiment with the parameters, and investigate sensitivity of
various variables, and give consideration to potential variation in
operation of the system, seeking quality robust design and optimum

Whether it is the code of practice, research papers, computer software, or
engineers, people have certain expectations of quality, and a lack of
defects. If some one wants to purchase software, then chances are they do
not have the time to write the software themselves. We buy off-the-shelf
tools because we lack resources, including time to make ourselves. We also
tend to have expectations of a higher level of quality in purchased tools
than if we make ourselves. We expect robust quality systems filtering out
and removing errors.

If have to expend a great deal of time testing and validating software or
other tools then there is little point in buying them. If codes of practice,
research papers, classic texts, and the likes are full of defects, then we
end up back to the days of Coulomb, Navier and Telford, deriving the
theories ourselves and experimenting to validate.

Unwarranted variations to intent have to be removed throughout the entire
system, and products become more reliable. Reliable products can be built
upon, to create more complex systems.

All products once released to the market will be put to a million uses
beyond the intentions of the designers. Software and codes of practice are
no different, and can expect the majority of users will simply do that, use
the product. The majority do not waste time with their own internal quality
checks, they expect quality checks on the supplier side.

The majority will not check the software theoretically or numerically, but
on the basis of experience and intuitive awareness. Namely, if the answer
don't look right, then it ain't! If the software doesn't give the wanted
answer then it is defective. If the engineer doesn't give the builder the
wanted answer then the engineer is defective, and the builder goes
elsewhere, until someone takes the time to explain, why not going to get
desired answer. The builder relies on the engineer: or do they? The builder
will not follow an engineer's instruction if their experience indicates it
is a dangerous action to take.

People use differing characteristics of a system to judge quality and
acceptable levels of performance. So stresses and forces are irrelevant to
the builder: spacing, spans, sizes and quantities are what matters. The
existing built environment provides experience of what is and is not
adequate. New codes may require bigger or more, but seldom smaller and
fewer. An experienced builder will advise if attempting to use something too
small. After all at start, the builder is paying for labour and materials.

Inexperienced builder combined with inexperienced engineer could be a
problem. But that's why we have an AHJ, to code check and approve: and the
AHJ is expected to retain experience with the passage of time.

My point is the blackbox is not entirely the hazard it is made out to be.
Though it is an important hole in the Swiss cheese model of accident
prevention: when it lines up with other holes in other systems, have
potential for a major catastrophic event. 

So if not willing to accept the risks and consequences, then rigorous
internal quality checks on tools before putting to use is preferable.

(And a lot of the time the software is simply used on minor projects, where
extensive code checking is simply being pedantic: the answer in known
already: so the risk is minor.)

Conrad Harrison
B.Tech (mfg & mech), MIIE, gradTIEAust
South Australia

******* ****** ******* ******** ******* ******* ******* ***
*   Read list FAQ at:
*   This email was sent to you via Structural Engineers 
*   Association of Southern California (SEAOSC) server. To 
*   subscribe (no fee) or UnSubscribe, please go to:
*   Questions to seaint-ad(--nospam--at) 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: 
******* ****** ****** ****** ******* ****** ****** ********