We have all heard it countless times - "Garbage in, garbage out". As applied to engineering, and specifically to computational engineering software, the admonition is clear - we have to be certain we are properly specifying our engineering input to the software which will compute the behavior we seek to understand.
How can we as engineers maximize the productivity that comes from engineering software while minimizing the pitfalls? There is no one correct answer to this timeless question but I will attempt here to convey some insights I have gained.
When I started my engineering career almost 30 years ago I remember talking to some old timers about the software we used to calculate three-dimensional heat transfer. They expressed concern that the software had removed the engineer from the calculation and that they did not have to think about it as deeply and thoroughly. Going through a hand calculation forced the engineer to look at every number that went into the calculation. Allowing a computer to calculate the numbers meant the engineer did not have as much opportunity to think about each step and evaluate the reasonableness of each number.
Last night I was having dinner with a client and he expressed concern about the new generation of engineers not understanding what the output was from engineering software - and are thus less able to find errors in their input or their assumptions. Or, in some cases, errors in the software itself.
With these valid concerns as a starting point, let's make a list of the so-called blessings and curses. And then use that to suggest ways for all of us to get the most from computational engineering software.
The Blessings
- Avoiding drudgery - let's face it. Doing hand calculations, while valuable while in engineering school, is tedious and error prone. One mistype into a calculator can throw you off. With computational software you can let the computer do the dirty work of calculations and focus on higher level issues.
- Repeatability - software will yield the same results every time, whereas a hand calculation offers more opportunity for errors to creep in.
- Calculation is self-documenting - the computational model file itself largely documents the calculation input and output and, if used properly, the assumptions.
- Speed - computational software is a faster way to get a result than a hand or even spreadsheet calculation in all but the most trivial cases. In complex cases a hand calculation may not be possible without gross simplifications.
- Thoroughness - Since you obtain answers more quickly with computational software, you can look at many more cases in a given time. This allows you to consider things that might have been time prohibitive using hand calculations and in general obtain a better design.
- Built-in intelligence - good computational software includes many clues, checks and warnings to help engineers avoid common mistakes.
Wow, with all these positive aspects who could argue with the value of computational software? Well, the greybeards among us would offer some cautionary words.
The Curses
- Less need to understand the calculation and principles involved - it is true that using computational software allows you to lean on the software developers and their understanding of theoretical principles. While it is still just as important as ever that the engineer still understands the theoretical principles, they can get by without it easier when using software.
- Comfort with graphical interfaces can give false confidence - I personally have taught many training classes on computational software where a young engineer is extremely comfortable and fast at clicking buttons, menus and pick lists. That speed allows them to complete a task faster than typically older engineers lacking that familiarity. Which is good as far it goes. In some cases the young engineer just does not take the time or have the experience to see glaringly incorrect or inconsistent results.
- Overconfidence in the software - some engineers take the computational software results as gospel. This is dangerous as software is not infallible and cannot anticipate all the ways an engineer can potentially misapply it.
- Less aware of assumptions and limitations - in some cases engineers rely too heavily on computational software and do not take sufficient time to grasp the underlying assumptions and limitations of the software.
With the preceding list of blessings and curses, and with the obvious reality that computational software is here to stay, what are some good practices we should all keep in mind when using computational software?
- Think about what you are doing - do not let the software do your thinking. Pay attention to all the steps and what is happening.
- Never completely trust software - software is written by humans and humans all have the capacity for error.
- Double-check results whenever possible - even if you only do a small sample, double-checking results will never hurt and will likely help. If your double-check agrees with the software, you have reinforced your grasp of the principles involved while also building confidence in the software results.
- Educate yourself - if your understanding of the principles behind the software is weak or imperfect, dig in! Take a short course. Browse the internet. Buy a book. Talk to another engineer with more experience.
- Ask questions. And then ask more. - do not be afraid to ask questions. Ask colleagues, more experienced engineers, and the software developers themselves. If the software developers are reputable they will welcome your questions and the chance to help with your education.
Perhaps you can think of other blessings and curses. If so please feel free to add your comments!