More than half of local structural engineers I know doesn't use manual computations anymore. They reason it's long process to get for example the biaxial interaction diagram, moments of each columns and beams and their interactions especially if they are designing very tall stories. So they rely on ETABs for example which is complete package and can even produce complex spectrum seismic analysis that would take 3 weeks for just one projects. As you know ETABs can automatically calculate all the moments and shears of each element and their combinations that you may miss out manually. So who amongst you also use such package and no longer do every process manually? And for those who do manually and spend 3 weeks for just one project writing dozens or hundreds of handwritten paper, what do you think the ETABS folks can miss out when they don't do each member manually?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
who doesn't use manual computations anymore? 5
- Thread starter pattontom
- Start date
When it comes to computers, Ronald Reagan said it best: "Trust, but verify."
Anyone that relies solely on hand calcs at this point will get left in the dust in terms of schedules and budgets.
Anyone that relies solely on what the computer says is not doing engineering, they are doing data entry.
Anyone that relies solely on hand calcs at this point will get left in the dust in terms of schedules and budgets.
Anyone that relies solely on what the computer says is not doing engineering, they are doing data entry.
-
1
- #42
more on the 24" slide rule before it disappears into obscurity...it had the following drawbacks listed in no particular order...
1. difficult to hang on one's belt...kept interfering with normal gait...
2. immediately placed more pressure on the engineer...everyone expected a more accurate design up to three decimal places in some cases..
3. had a tendency to bind-up under times of extreme pressure/tension like when you found out you were 4 weeks behind schedule with 2 weeks left to deadline...probably as a result of that death-grip...
4. had same design/member sizes as the 12" slide rule and in my opinion was under-designed..they probably used LRFD in the design to whack the last 0.2oz out of it and as a result had the common deflection problems...
5. not easy to carry...as a result, one would tend to carry it either as a cutting-edge engineering tool or as a stick...in fact, both came in handy at times depending on the make-up of your design office...
6. had no well-defined sweet spot so, as a result, one could loose 0.1 seconds in a normal engineering calculation which over the life of the engineer could really add up..
I could go on but I think you get the picture..
1. difficult to hang on one's belt...kept interfering with normal gait...
2. immediately placed more pressure on the engineer...everyone expected a more accurate design up to three decimal places in some cases..
3. had a tendency to bind-up under times of extreme pressure/tension like when you found out you were 4 weeks behind schedule with 2 weeks left to deadline...probably as a result of that death-grip...
4. had same design/member sizes as the 12" slide rule and in my opinion was under-designed..they probably used LRFD in the design to whack the last 0.2oz out of it and as a result had the common deflection problems...
5. not easy to carry...as a result, one would tend to carry it either as a cutting-edge engineering tool or as a stick...in fact, both came in handy at times depending on the make-up of your design office...
6. had no well-defined sweet spot so, as a result, one could loose 0.1 seconds in a normal engineering calculation which over the life of the engineer could really add up..
I could go on but I think you get the picture..
I haven't read it but apparently there's a book about unintended consequences. Among the examples I remember were:
* As football helments became stronger players started using their heads as battering rams thereby causing neck injuries.
* As tennis rackets became larger professional games turned into little more than serving contests and viewership declined.
I'm sure there were many non-sports examples as well. But in our industry, as computation machines improved there came with it some unintended and undesirable consequences. The main one, in my opinion, is that the building and material code writers seem compelled to keep up with them. Honestly, what firm could comply with the various codes without "black box" software to grind through all the requirements...and still stay in business? You don't even have to get past Ch. 2 of ASCE-2 to see that. Finding the worst load combination for each member by hand would take 1.2 Days + 1.6 Weeks + .5(Lightyears or Something Rediculous)...so off to the black box we go. (And remember, the affects of one or more of those factors not acting must also be considered and it's easy to get lost in all the numbers. And that's just to get started.)
Then there becomes the problem of people not having much clue how the output they are using was generated...
Seasoned engineers who saw this all slowly evolve on their watch don't usually have too much of a problem with it...one change at a time isn't hard to take and they can make their own real world sanity check without the computer. For the new engineers, on the other hand, it's a much different situation and their dependence on black box computer software is much greater. The situation does the whole profession a disservice, in my opinion.
All of which brings me back to the topic at hand. That is, it wouldn't hurt my feelings if the licensing exam required the use of slide rules and disallowed even simple electronic calculators. Maybe then there would be some push back to the Rube Goldberg philosophy of code writing.
* As football helments became stronger players started using their heads as battering rams thereby causing neck injuries.
* As tennis rackets became larger professional games turned into little more than serving contests and viewership declined.
I'm sure there were many non-sports examples as well. But in our industry, as computation machines improved there came with it some unintended and undesirable consequences. The main one, in my opinion, is that the building and material code writers seem compelled to keep up with them. Honestly, what firm could comply with the various codes without "black box" software to grind through all the requirements...and still stay in business? You don't even have to get past Ch. 2 of ASCE-2 to see that. Finding the worst load combination for each member by hand would take 1.2 Days + 1.6 Weeks + .5(Lightyears or Something Rediculous)...so off to the black box we go. (And remember, the affects of one or more of those factors not acting must also be considered and it's easy to get lost in all the numbers. And that's just to get started.)
Then there becomes the problem of people not having much clue how the output they are using was generated...
Seasoned engineers who saw this all slowly evolve on their watch don't usually have too much of a problem with it...one change at a time isn't hard to take and they can make their own real world sanity check without the computer. For the new engineers, on the other hand, it's a much different situation and their dependence on black box computer software is much greater. The situation does the whole profession a disservice, in my opinion.
All of which brings me back to the topic at hand. That is, it wouldn't hurt my feelings if the licensing exam required the use of slide rules and disallowed even simple electronic calculators. Maybe then there would be some push back to the Rube Goldberg philosophy of code writing.
-
2
- #44
Yeah, this isn't a thing that done by old engineers. It's a thing that's done by diligent engineers. I'm in my late twenties. Also, people have used computers to simplify work since they became available. I have my grandfather's punchcards that he used decades ago for p-delta checks on bridge structures sitting somewhere.
Confirming things by hand, or doing preliminary sizing by hand (where 'by hand' could include spreadsheets or things like mathCAD) doesn't take a lot of time.
It's not a question of not trusting computer programs. It's a question of not fully trusting anything. Fear is an engineer's friend. It shouldn't keep you from taking action, but it should be there in the back of your head reminding you of the consequences of what you're doing. You have to understand the action of your structure and be able to take responsibility for the actual math that went into it. With experience you can get the understanding of the structure from a computer model. That's great, it speeds things up and can let you do things that aren't reasonable by hand. There are two places where there are issues though. In the first case, you could have a situation where you become complacent and treat it as a black box without actually understanding the structure. This is dangerous. In the second case, there could be an error in the way the actual math, model or assumptions are implemented.
You have to be able to look at the structure and the results and be completely sure you understand why the reactions and stresses are what they are in each component. If you ever hit a situation where you look at something like the force distribution in a structure and don't immediately understand why it looks like it does and your response isn't to sit down and figure out why it looks like that, you're not actually engineering anything. If someone asks you why some critical load or reaction is what it is, and your answer is that the computer reported it, you've done something wrong. That's the first situation above.
In the second case, it's a question of verifying because it's not a perfect world and people screw up. It can be anything, but you have to be more careful with things like computer software because you didn't actually write it. If you don't check it, you're implicitly taking responsibility for the work of the software company. If your structure breaks because of an error in the software, they're still going to blame the engineer.
It's not like anyone goes and does a computer model and then checks it with a check of all the load cases and using all the special case code formulas on a piece of paper. You're going to use tables and simplified assumptions and formulas that you've simplified from the code or from other sources. I, personally, like to put pen to paper as much as I can, but it's personal preference more than anything. Nobody's going through the world checking things by doing hand checks for the code check on a beam-column using the full steel interaction formula on a piece of paper for every item in the structure. First off, people are really only doing math for items that could reasonably be critical. Secondly, they're either using a spreadsheet that they've verified or they're using a simplified formula (My/Myr+Mx/Mxr+C/Cr at the simple end, or incorporating as many additional factors as are reasonable) and then seeing if they're close enough to call it okay. If a case exists where it's reasonable to use the full code formula and you're doing things on paper, you're just doing it in the case that actually requires all the factors.
Doing enough math to make sure you're not getting a catastrophic failure and that your numbers are reasonable, when combined with some degree of judgement takes very little time. Hell, proper checking generally saves time because you're going to catch things that would be difficult to fix in the field.
Also, nobody's including any of this in their calculation package. Generally, a calculation package is the minimum necessary information required to satisfy people that the code has been appropriately applied and adhered to and that some degree of due diligence has been done. Additional information is confusing and takes time to prepare. I'm not going to write paragraphs in my checking calcs or my preliminary calcs to ensure it's clear to a code checker what my assumptions are. I'll write in simplified explanations that would make sense to another engineer that took a proper look at them, but anything more than that's a waste of time.
This is ignoring the things I'll do entirely by hand because it's just faster that way.
Confirming things by hand, or doing preliminary sizing by hand (where 'by hand' could include spreadsheets or things like mathCAD) doesn't take a lot of time.
It's not a question of not trusting computer programs. It's a question of not fully trusting anything. Fear is an engineer's friend. It shouldn't keep you from taking action, but it should be there in the back of your head reminding you of the consequences of what you're doing. You have to understand the action of your structure and be able to take responsibility for the actual math that went into it. With experience you can get the understanding of the structure from a computer model. That's great, it speeds things up and can let you do things that aren't reasonable by hand. There are two places where there are issues though. In the first case, you could have a situation where you become complacent and treat it as a black box without actually understanding the structure. This is dangerous. In the second case, there could be an error in the way the actual math, model or assumptions are implemented.
You have to be able to look at the structure and the results and be completely sure you understand why the reactions and stresses are what they are in each component. If you ever hit a situation where you look at something like the force distribution in a structure and don't immediately understand why it looks like it does and your response isn't to sit down and figure out why it looks like that, you're not actually engineering anything. If someone asks you why some critical load or reaction is what it is, and your answer is that the computer reported it, you've done something wrong. That's the first situation above.
In the second case, it's a question of verifying because it's not a perfect world and people screw up. It can be anything, but you have to be more careful with things like computer software because you didn't actually write it. If you don't check it, you're implicitly taking responsibility for the work of the software company. If your structure breaks because of an error in the software, they're still going to blame the engineer.
It's not like anyone goes and does a computer model and then checks it with a check of all the load cases and using all the special case code formulas on a piece of paper. You're going to use tables and simplified assumptions and formulas that you've simplified from the code or from other sources. I, personally, like to put pen to paper as much as I can, but it's personal preference more than anything. Nobody's going through the world checking things by doing hand checks for the code check on a beam-column using the full steel interaction formula on a piece of paper for every item in the structure. First off, people are really only doing math for items that could reasonably be critical. Secondly, they're either using a spreadsheet that they've verified or they're using a simplified formula (My/Myr+Mx/Mxr+C/Cr at the simple end, or incorporating as many additional factors as are reasonable) and then seeing if they're close enough to call it okay. If a case exists where it's reasonable to use the full code formula and you're doing things on paper, you're just doing it in the case that actually requires all the factors.
Doing enough math to make sure you're not getting a catastrophic failure and that your numbers are reasonable, when combined with some degree of judgement takes very little time. Hell, proper checking generally saves time because you're going to catch things that would be difficult to fix in the field.
Also, nobody's including any of this in their calculation package. Generally, a calculation package is the minimum necessary information required to satisfy people that the code has been appropriately applied and adhered to and that some degree of due diligence has been done. Additional information is confusing and takes time to prepare. I'm not going to write paragraphs in my checking calcs or my preliminary calcs to ensure it's clear to a code checker what my assumptions are. I'll write in simplified explanations that would make sense to another engineer that took a proper look at them, but anything more than that's a waste of time.
This is ignoring the things I'll do entirely by hand because it's just faster that way.
Yeah, I think you missed the point of my post.
Any good engineer will perform a reality check but whereas you used to do it to confirm the provisions of the code now you do it despite them. For example, how many engineers simply apply a 20 psf (or whatever) wind load and design the structure vs. pouring through all the gyrations the code requires? Plenty, I bet.
And yes, some software providers do indeed include code provisions in their packages...in fact, I think most of them do at this point.
And no, I'm not a young engineer any more so it's less of an issue for me...I've watched a lot of these things morph into their current Frankenstein-like forms so I've been able to absorb many of them one step at a time. But I feel bad for the recent graduates. I've seen some that I think would have made good design engineers but were too intimidated by it to try and instead migrated over to the project management side of the house. It amounted to a loss of good talent due to code intimidation. A shame, really.
Any good engineer will perform a reality check but whereas you used to do it to confirm the provisions of the code now you do it despite them. For example, how many engineers simply apply a 20 psf (or whatever) wind load and design the structure vs. pouring through all the gyrations the code requires? Plenty, I bet.
And yes, some software providers do indeed include code provisions in their packages...in fact, I think most of them do at this point.
And no, I'm not a young engineer any more so it's less of an issue for me...I've watched a lot of these things morph into their current Frankenstein-like forms so I've been able to absorb many of them one step at a time. But I feel bad for the recent graduates. I've seen some that I think would have made good design engineers but were too intimidated by it to try and instead migrated over to the project management side of the house. It amounted to a loss of good talent due to code intimidation. A shame, really.
I wasn't disagreeing with you at all, although I can see how you could read my response as a comment on your post. It was actually a response to the original poster. I agree with some of the sentiments of what you were saying in your previous posts. While I appreciate the more comprehensive checks being part of the codes when they're necessary I think a lot could be simplified if the more conservative checks that many people do were made part of codes as simplified methods with exceptions, leaving the option to use the full method when it's beneficial. The concrete code already does this in some cases. This could remove the situation where you do the structure design pretty much completely, and then do additional code checks that you already know don't govern.
I'm going to avoid going into it more than that, because we've all seen what happens to threads where we start the 'codes are too complicated' conversation
I'm going to avoid going into it more than that, because we've all seen what happens to threads where we start the 'codes are too complicated' conversation
-
1
- #49
TXStructural
Structural
It's not that I trust one method over another, just that without verification using at least a couple of methods, how can we trust any method. The simplest solution is to design using engineering judgement, compute using software and other tools, and verify a few small numbers (beam stresses and sizing) and the big numbers (base shear, foundation loading) with hand/calculator/spreadsheet/slide rule computations.
Don't confuse code compliance with design. Never the two shall meet. But all too often, designers think "it meets code, so I'm done."Archie said:
Oh, you needent worry that I will confuse the two; in fact, that speaks to a point I made on the thread related to the New Zealand earthquake thread in that an argument can be made that building codes reduce our safety rather than enhancing it.
- Status
Similar threads
- Locked
- Question
- Question
