First things first: technical competency

May 20, 2012

I’ve written several blogs recently about the cutting edge of structural design. While it’s true that new modeling software and analytical techniques are changing the occupation, it remains extremely important to have a solid understanding of basic principles. If anything, implementing the fancy new software techniques require an even more thorough knowledge of first principles, because there are few assurances that the initial output is at all valid.

Again, it’s the season of new hires and summer internships. Over the past few years, I have noticed that young engineers have a better aptitude for software use and programming. However, many of the same young engineers do not appear to have the same familiarity with traditional hand calculation. Now, I’ve long argued against old-timers that would suggest that all computer analysis be backed up with hand calculations, but I do find myself becoming more critical of younger engineers and their computer modeling. I’ve become that guy that always saying, “that just doesn’t look right.”

I encourage my junior staff to use computer models to analyze any condition beyond the classic simply supported, uniformly loaded beam. It’s beneficial for them and me to view the resulting behavior visually. The results are worthless, though, if the boundary conditions, connectivity, and loads are input incorrectly. When you’re reviewing the work of someone else, that’s where an engineers intuition comes into play. If the members seem too small, they probably are, and the input was messed up. Despite all the advances in materials and analysis, structures still largely comply with the theories of proportion that were the underpinnings of architecture all the way back to the Middle Ages.

First you identify that something doesn’t look right, but where is the problem. The next thing I always do is ask to see the deflected shape. It always stuns me when new engineers report a “finished design” to me before having looked at the way the structure deflects. I always thought that was the coolest output from the computer program. You can typically identify modeling errors right away by seeing of any members are flying off into space or if the the structure is moving far more than anyone would find comfortable to experience.

RISA 3D is one of my favorite analysis tools, because the output is conveniently shown graphically. It also has the added benefit of refusing to run any ill-conditioned or unstable model. Well, duh. Other programs, like SAP2000, do find ways to run these bad models, leaving engineers to judge whether the 1000 lines of calculation errors are meaningful or not. It must be said, that for complicated schematic designs, I sometimes turn to SAP and let it chuck through error-fraught routines in order to determine whether there’s any potential in an early design. But when you’re doing permit calculations, you shouldn’t be taking such risks. RISA’s refusal to run is my first line of defense against bad models.

Unfortunately, I can recount several occasions where a young engineer has reported to me that RISA wasn’t working, because it wouldn’t run the model. It’s embarrassing to have an experience engineer take 5 seconds with your model and report that you’ve missed a constraint. Always assume that the problem is in your model and not the program. Oh, how I wished the program was error-prone when as a grad student, I had to compute the complicated analyses by hand and compare against the computer result. When a model is built correctly, it’s more infinitely more reliable than pages of complicated hand calculations.

So while I write at length about the cutting edge of structural design, that’s not to say that basics aren’t important. It’s also my opinion that the basics don’t really sink in after just one or two undergraduate courses. For me the knowledge took time to absorb. Grad school helped; teaching other people helped more; years of experience were absolutely essential. Young engineers should take time to fully understand the underpinnings of advanced modeling and analysis. Fortunately, many mistakes are easy to spot by managers. Unfortunately, you’re going to hear about those mistakes on you annual review. The worst review to get is that you struggle with basic concepts. That reputation is very hard to shake, so be meticulous in your calculations and models. The most amazing design programs are only as good as the engineer that uses them.

What’s your experience with computer programs? Are you in the “hand calculation only” crowd? How often do you use ‘canned’ design programs? Do find them fraught with errors, or do you find the error typically lies with the user input? How quickly do you think the industry is changing? Please leave your comments below.

5 Comments
  • Wow! It is really nice that you have shared your personal experience with us. Thanks a lot for this interesting story.

  • Hi Ken,

    I have accidentally found your blog on the internet while searching for some architectural design related stuff. First of all, I just want to say this is one of the best blogs I have ever read. I am an architecture student in Australia and wondering about the latest technology in the AEC industry, for instance the Parametric Design tools Rhino+Grasshopper that you mentioned in one of the other posts. From an architectural point of view, I think fundamentals and creative thinking is very important and tools are just tools. What’s your opinion on the importance of hand drawing skills of an architect? And do you have connections to some architects’ blogs that are as interesting as yours?

    Cheers

    • Thanks for the compliment. If you are interested in parametric design you have to check out the Proving Ground blog by Nathan Miller of NBBJ. http://nmillerarch.blogspot.com/

      I think hand sketching is extremely important. I’ve read about studies that show strong correlations between sketching and problem solving. It’s also essential for being able to quickly communicate your ideas in a meeting. Rarely is anyone able to update a computer model fast enough to show changes in real time during a meeting. I’ve seen people try. The hand sketcher always gets to the point first, and that’s the idea that gets implemented digitally after the meeting is over.

  • william hayden jr.

    “Amen” to Anantha’s comment above.

    While walking through an engineering office a few years ago, I overheard an engineer tell another engineer “I don’t care what your model provided, waves don’t look like that.”

  • I have to say that I agree with you completely. My grad school professor used to say that nothing can generate a wrong answer faster than a computer. Unless you know what you are doing or have a ballpark estimate of what to expect, it is GIGO (Garbage in Garbage out).

    I always try to validate my answers with quick and dirty hand calcs to see if I am in the ballpark. Structures are no doubt getting complicated and we rely extensively on the tools available to us. However, a sanity check of the results is always necessary.

    My old boss used to say….”If it doesn’t look right (proportionally), then it is not right.”

Leave a Reply

— required *

— required *