There is a lot to know about physics, and early on, a great deal of time must be spent learning theory, and applying it to solve simple problems. As such, a student cannot be faulted for thinking that a few equations, pencil and paper, and a calculator, are all the tools necessary to complete real world engineering problems.
In real life, when one is designing anything from a bridge to a car, today’s engineering problems are solved with two overlapping methods. The first method is analytical, and the second is numerical.
The analytical method is similar to the approach taught in science courses. The complex problem is simplified via good approximations – it is transformed into something that can be solved with a pencil and paper. Problem solving of this sort gives the engineer a rough estimate of what the result might look like in the end. It gives a sense of direction for where the design might be headed; it is sometimes called a ‘first cut’, or an ‘order of magnitude solution’.
However, the majority of an engineer’s problem solving time is spent using numerical methods imbedded in virtual tools. There are many software tools for every field of engineering that allow the user to solve very complex problems with a high degree of precision. At the click of the mouse, a simulation calling on some governing equations of physics can be run on whatever design you have fed to the software in whatever environment you desire. Want a picture of the stress distribution in the body of a roller coaster car as it travels along a track? There is a virtual tool for that. Want to see the temperature distribution within a satellite as it orbits the Earth? There is a virtual tool for that too.
Virtual tools such as these employ what is known as FEM (the Finite Element Method). Rather than treat a complex structure as a simplified whole, and get a rough analytical solution, the complexity is allowed to remain in the structure, and a solution is sought numerically. The structure is broken down into thousands of tiny pieces, or elements, which are connected to one another at nodes. The governing equations are then applied to each individual node, taking into account the properties of the elements that interconnect them. A person can sit there with a calculator for years solving the equations that the processor solves in seconds.
I sometimes feel guilty when I impose a tiny design change on a virtual model and then rerun the simulation – as though there are thousands of little monkeys inside the computer chugging away at the immense system of equations. Numerical tools make computing time very small. The advent of FEM and the increase in computation speed has greatly reduced the design phase duration in the engineering workplace.
For example, the design phase for a complex satellite lasted a couple of years in the 1980s. Today, this same satellite can be designed in as little as six months. What is more, the final product will be significantly lighter today, because lower margins of safety are now acceptable (as the analysis behind them is more precise). So, not only is the design process up to four times faster, but the synthesized design is up to 50% lighter! Both of these factors lead to major cost savings. Thanks to FEM, engineers can have their cake and code it too.
As wonderful as our virtual tools are, the responsible engineer must see beyond the glitz of the colourfully animated solutions, and continuously ask whether the results make sense. Analytical checks are applied regularly as the design iteration process moves forward; these checks are often referred to as “back-of-the-envelope” calculations. The danger with a virtual tool creeps up when we trust it too much. The gap between the engineer and the coded equations can become dangerously large when software is given too much respect. A third and final check usually involves historical comparison. Do these results and this design bare resemblance to previous designs?
As the engineer’s virtual toolbox fills up with fancy processing systems, there is an inherent risk that they will be given blind faith. Engineers must remember that software is merely a tool. There is nothing virtual about a real product failure. The numerical solutions that are processed must always be validated by the kinds of analytical problem solving skills you were grilled on test after test way back when.
Numerical tools give flight to fast and precise complex designs, but must be complimented by a foundation of conceptual understanding. It turns out that all of those blocks sliding down inclines are necessary in a ‘Karate Kid, wax-on wax-off’ sort of way. Not surprisingly, an engineer’s most valuable tool remains the one fixed squarely inside his or her skull.
