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

Response to Brad Cameron - and Software discussion

[Subject Prev][Subject Next][Thread Prev][Thread Next]
Thanks Brad, I appreciate this. I would have responded sooner to thank you
but my wife and I are just getting over a bout of food poisoning - not a
pleasant experience.

It is important to all professionals not simply to air our opinions,
professional questions or frustrations, but to have an open dialog between
one another so that rumor or inaccuracies don't fly in all directions. I'm
not infallible and neither is anyone else - we must have our facts straight
or the credibility of the argument is shot to pieces.

Keymark Software

I sure most of you know that I have been familiar with Keymark at least for
the last eight years- as a user of TJ-Beam (software originally designed by
Keymark Software) to reviewer of Truss Calculation and finally as a software
reviewer of the Keybuilder integrated system known, at the time of the
review, as Intelligent Take-off.

We have grown to be a society very critical of the software tools that are
available to us. This is especially true in the engineering profession
because the community is small and criticism can have a profound influence
on the future of a software developer. At times we seem to lose sight of the
difficulties that software developers face. When a developer does not poses
the programming skills needed to solve a problem, they hire professional
programmers. However, in order for a programmer to understand the
engineering methodology, the engineer must be able to create a logical path
such as a Flow Chart which displays the choices in the design process.

If the code contains loose ends which does not clearly explain or complete
the design intention, then the software developer must either decide on a
reasonable solution or back off from marketing the product - a do or die
situation.

The City of Los Angeles came up with a modification to the 97 UBC (City of
Los Angeles) Building Code and published it as ST-12. The Tri-County
solution from the City of San Jose had a similar modification which it
adopted. The problem, I think, is that these are conservative solutions that
provide equivalent or greater solutions to the problem than the code writers
intended. The problem, of course, being that either the code writers reached
a point of impasse in which agreement could not be achieved, or decided to
leave the decision to the engineer. Leaving the decision to the engineer is,
I believe, the best solution to the problem, but on that opens the door to
potential litigation if the engineers opinions do not meet the minimum
implied intent of the code writers who have chosen not to clearly define
this level.

To be more exact - the code fails to suggest when the engineer is required
to follow a rigid diaphragm analysis only or must combine the worst case of
the rigid analysis with the flexible (an enveloped solution). The code
writers or even the authors of the ICBO Seismic design manuals do not advise
the engineering community how to treat diaphragms with large cut-outs, or
how to distribute shear in a flexible diaphragm to skewed walls and much
more that occurs in daily practice.

It appears that the code creation community is relying heavily upon the
software developers to resolve these loose ends and to stick their neck out
in establishing a standard of practice.

In my opinion, Keymark is the only one of three products available to
engineers that comes closest to creating a software tool that is as accurate
or as creative as the engineer wishes to make it. I know there are critics
as to the lack of a user-friendly interface, but the fact is that none of
the other products have done any better - including the freeware spreadsheet
that Dave Merrick and I designed.

My point is that the professional community needs a software tool to
simplify the accurate design of a multi-story wood frame structure. We have
been waiting close to two years after the adoption of the building code for
a tool that would normally have occurred within days of the adoption of the
code. This is not the fault of the developers in my opinion, but reflects
upon the difficulties of addressing the loose ends and ambiguities in the
far less than perfect code methodology.

It is also my opinion that the software developer, in this case, may be the
best choice for tying together the loose ends and making some decisions as
to how the structure should be modeled so as to allow this to become the
accepted standard of practice. It places additional responsibility on the
software developer but it also offers the professional community some
closure to open issues that haven't been resolved within the profession for
almost two years.

I think we need to start looking at developers like Keymark, to help us
solve some of the design issues that we have not been able to resolve on our
own. I consider this an ideal mixture of logical programming with
engineering skills that can establish a standard that creates more
uniformity in design and less debate in court.

There use to be two choices - 1) Resolve it in the code or 2) Resolve it
between expert witnesses. Now we have a choice; If we can't resolve it in
the code then we should call on the assistance of a team of programmers and
engineers rather than leaving it to a debate of expert witnesses.

This takes a certain leap of faith that the programmer suddenly becomes a
resource to help translate engineering judgment into logical choices. The
results should be economical rather than overly conservative design.

So where are we going in the Lateral Design Methods? How many have created
in-house programs? How many are using ST-12? How many are only designing by
Flexible? How many are using Keylat or other software's? How many have
gotten away from doing wood design because it is simply not worth the
risk???????

Regards,
Dennis S. Wish, PE
The Structuralist Administrator for:
http://www.structuralist.net <http://www.structuralist.net>
AEC-Residential Listservice
admin(--nospam--at)structuralist.net
(208) 361-5447 E-Fax
ICQ # 95561393



-----Original Message-----
From: Brad S. Cameron [mailto:bcameron(--nospam--at)keymark.com]
Sent: Monday, January 15, 2001 4:24 PM
To: seaint(--nospam--at)seaint.org
Subject: RE: Question on wood Roof Trusses


OK, OK, Dennis - I will weigh in on this one!  I was one of the guys that
got a long email from Dennis saying that I should respond to the list
server, not directly to him.

The Alpine truss software has a very long and illustrious history to it -
but the folks at Alpine deserve the credit for this work, not Keymark.

Keymark has a long standing relationship as a software supplier for Eagle
Metal Products, based out of Mabank Texas.  Eagle supplies connectors for
metal plate connected wood trusses.  We also support Cherokee Metal Products
out of Morristown, Tennessee for the same thing.  Furthermore, users of our
KeyBuild(tm) three dimensional modeling system can export wood truss
information to the Alpine wood truss software.  Actually, we can export data
to many of the available wood truss design packages.

Dennis, keep stirring the pot! I appreciate the insights that you regularly
bring to the table.

Sincerely,
Brad Cameron, P.E.
Keymark Enterprises. Inc.
email: bcameron(--nospam--at)keymark.com