Need a book? Engineering books recommendations...

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

RE: Plan Check (was Re: Rigid Wood Diaphragm?)

[Subject Prev][Subject Next][Thread Prev][Thread Next]
Scott,
You bring up a point I failed to mention in my post and that is very
important to understand. Many engineering software companies do not use
engineers to program - they use programmers and attempt to explain the
logic in the code so that the programmer can evaluate it in flow-chart
format and write coding around it.
However, some of the smaller companies - Enercalc, Risa to name a couple
(and of course my own spreadsheet) use engineers with a vast background
in the specialties that they produces software for. Mike Brooks
(Enercalc) and Bruce Bates (Risa Technologies) are both licensed
professional engineers (SE's) with advanced degrees. Ignoring minor bugs
that get buy, these guys (and others like them) are deeply involved in
both understanding the design methodology and code requirements for
different materials contained in their software, but are deeply
committed to having learned coding languages and translating the
programming language into a representation of their understanding of the
intent of the code.
Other companies, such as Keymark Industries, have engineers or EIT's on
staff that understand the code, but are not actually doing the
programming. On the surface their checks and balances seem like enough -
but I don't think this is true. I don't believe that a non-engineer can
write engineering software without having some major problems or not
being able to overcome the obstacles that we solve by our own
engineering judgment. I've seen this happen and the software company
ends up simplifying their product and focusing on a less technical field
that they can profit from.
Ultimately, it is as you said - the responsibility of the engineer of
record to identify an error in the results - but with dramatic changes
in some portions of the code, the professional intuition begins to
reduce and the EOR becomes less likely to catch an error if he
misinterprets the intent of the code writer. It would be easy if every
code writer were to justify their work to the community in a flow chart.

When SEAOSC wrote the ordinance for unreinforced masonry retrofit for
the city of Los Angeles (RGA 1-91), they did just this. They created a
flow chart for engineers to follow in order to insure that the
designer's logic was correct and in the process, the designer began to
understand a different concept or methodology based on designing a
retrofit to the weakest element in the building. Simply put, you can do
no better (economically) than to tie a building together based on
designing retrofit anchors and straps to either current seismic design
standards or to the failure of the diaphragm or weakest element -
whichever is worse. The flow chart helped many engineers understand this
change in logic over the typical design of lateral distribution from
which all other elements are made to comply.
In short - if the engineer is not doing the coding then I would not
trust the output or I would not expect there to be much creativity and
ability to make the software bend to creative uses in order to solve
non-typical problems.
This is important and although most of us are critical of the software
from Enercalc or Risa to some degree, the truth is that none of us who
are critical can do a better job (at least 98% can't). How do I judge
this - well out of hundreds who have downloaded and used Multi-lat(tm)
and understand the previous versions limitations, only one or two have
done anything (or have told me that they have changed the software) to
improve upon what we have done. It is easy to sit back and list what the
ideal software should have, yet being on the other side and trying to
figure out the logic in coding these solutions is not as easy as it
seems.
Hope this helps understand why it is so important to rely upon the
engineer's judgment in the end over the output from the software. This
is also why it angers me when the local truss company has so much faith
in the plate manufactures software that they claim their engineer does
not review the output. This put me at odds with the owner who blamed me
for delays when the problem was that the truss design was not as I had
designed the home and I want it done right.

Enough - I have more detailing to do tonight.

Regards,
Dennis

-----Original Message-----
From: Scott Maxwell [mailto:smaxwell(--nospam--at)engin.umich.edu] 
Sent: Friday, October 17, 2003 7:51 PM
To: seaint(--nospam--at)seaint.org
Subject: RE: Plan Check (was Re: Rigid Wood Diaphragm?)

Dennis,

A lot of what you point out is very true.  I would just say that
software
programmers don't necessarily understand the intent or wording of the
code
better because the look any more closer or have more insight.  Instead,
it
is to some degree a function of lots of people looking over their
shoulder.  Even though they absolve themselves of responsibility and
liability, they do have a vested interest in making sure it is right
(who
would buy a program that does things the wrong way...but then we all buy
Microsoft stuff, so go figure).  Thus, they do things like alpha and
beta
testing.  They will also misinterpret the code on occasion and have it
pointed out to them, at which point they will create a "bug" fix.  I
will
certainly admit that they likely spend a lot more time making sure that
they have a solid rationale for their interpretation.  But, then they
usually don't quite have the same pressure in terms of deadlines that
engineering working on construction projects do (their deadlines are
more
self-imposed...take RISA...they considered it much more important to get
it right than hit a date, thus they only just released RISA-3D with
concrete support recently even though they intended to get it out
earlier
this summer).

Regardless, use of _ANY_ computer program software requires care.
Whether
or not the computer programmer understands the code or not does not
really
matter...the individual engineer sealing the drawings is the one
required
to understand the code and takes on the potential liability and
responsibility in that regard.  Thus, those that assume that the
programmer got the code interpretation stuff right makes a you know what
of themself.  Thus, a software company can test their product till hell
freezes over, but the plain simple fact is that THEY don't lose their
license if something is wrong...I do.  So, even though they might
potentially have better access to information and may even have a better
chance at interpreting the code that one individual engineer, it is
still
that one individual engineer that must be confortable with the results
that get put on paper since it is that individuals tushie on the line.

Regards,

Scott
Ypsilanti, MI


On Fri, 17 Oct 2003, Dennis Wish wrote:

> Scott,
> This is true and I have made errors (only one that I know of) in the
> first spreadsheet that I wrote for seismic retrofit of unreinforced
> masonry. This was also an error in the interpretation of the code.
> With that said, the point I was trying to make relates well to
Multi-Lat
> - the freeware spreadsheet on the Structuralist.Net website. Multi-Lat
> required probably close to a thousand hours writing and releasing with
> known limitations. However, to accomplish this I was able to draw upon
> the knowledge of those I knew who were closest to the SEAOC Seismology
> Committee as well as the sample problems in the ICBO Seismic Design
> Manual Volume II. I was even on the review committee for the cold-form
> problem in the manual and as such had documentation (drafts) that were
> given to reviewers that also allowed me to question and debate changes
> from previous codes. I didn't simply accept that Doug Thompson or Bill
> Nelson's problems that were published in the Wood Frame (Light-frame)
> section of this design manual were correct - if I couldn't trace the
> numbers I was compelled to contact them and ask. Furthermore, the use
of
> spreadsheets like this made it easier for others to questions those
> issues in the code that SEAOC has backed down from and would make it
> easier for future code writers.
> The point here is that when I walked away from the finished product, I
> felt that I had a much more in-depth understanding of the code.
Whether
> or not I agree with it won't be resolved anytime soon. However, those
> that use the spreadsheet probably won't have as deep an understanding
of
> the code or the spreadsheets working as those who are willing to open
> the program up and study it - questioning those issues they don't
> understand.
>
> We need to do this with the code and I don't think many of us do. Most
> assume intent of the code writer and leave it at that. If they debate
> the issue with the plan reviewer then it is a question of who is more
> convincing. To this day SEA has never published an Erratum on the code
> that tracks back to the original ideas that led to the publication of
> the code section for light-framing. We have a good idea, especially
with
> the help of ACI, PCA, AISC, MIA and other material groups how to
design
> using the materials and historically the methodology to resist lateral
> loading for seismic and wind has been pretty good. Yet the same is not
> true of light-framing and there is no record of the step taken to
arrive
> at the current code.
>
> Look, my opinion of the code for wood structures is well known. My
point
> is that those who write computer programs may have errors - but most
of
> the errors are probably logic errors and not interpretation of the
code
> unless the code is "unfinished" with it is published. The example I
used
> was the use of RGA 1-91 for the retrofit of unreinforced masonry back
in
> the 80's as we were learning and SEAOSC was "tweaking" out the code
> based on the originally published ABK Method done around 1980 (give or
> take a few years). I'm sure Nels Roselund has more specific
information
> on ABK as he worked for the "K" - John Kariotis back then.
>
> I think this was an exception to the rule, but the results have held
up
> to this date that the methods are valid but detailing has changed and
> probably will continue to evolve.
>
> Dennis
>
> -----Original Message-----
> From: Scott Maxwell [mailto:smaxwell(--nospam--at)engin.umich.edu]
> Sent: Thursday, October 16, 2003 10:41 PM
> To: seaint(--nospam--at)seaint.org
> Subject: RE: Plan Check (was Re: Rigid Wood Diaphragm?)
>
> Dennis,
>
> Ah, be careful my friend.  Those that program/make structural software
a
> just as prone to misinterpreting the intent and wording of the codes.
> That is why they include a nice little disclaimer that (attempts to)
> absolve of all liability/responsbility.  Thus, I am _ALWAYS_ careful
> when
> using structural software, especially design software that makes use
of
> code provisions.
>
> Regards,
>
> Scott
> Ypsilanti, MI
>
>
> On Thu, 16 Oct 2003, Dennis Wish wrote:
>
> >
> > Outside of writing computer software (the ultimate in an engineers
> > evolution to understanding fully what the code writer intended and
to
> > find mistakes in the logic of the intention at the same time) the
plan
> > checker offers the great majority of us who are in SOHO or small
> offices
> > that don't have the time or the employees to provide peer review an
> > opportunity to find even one mistake or misinterpretation of the
code
> > that we might have that can save a life.
> >
>
>
>
> ******* ****** ******* ******** ******* ******* ******* ***
> *   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
> ******* ****** ****** ****** ******* ****** ****** ********
>
>
> ******* ****** ******* ******** ******* ******* ******* ***
> *   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
> ******* ****** ****** ****** ******* ****** ****** ********
>


******* ****** ******* ******** ******* ******* ******* ***
*   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 
******* ****** ****** ****** ******* ****** ****** ******** 


******* ****** ******* ******** ******* ******* ******* ***
*   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 
******* ****** ****** ****** ******* ****** ****** ********