Open up any engineering magazine today and you will see countless advertisements concerning engineering tools. The tools are predominately computational fluid dynamics (CFD), finite element analysis (FEA), data reduction, process analysis, rotating equipment, and pressure containment equipment software. Most articles do not reference the limitations of the software. In fact, great emphasis is placed on “user friendly” software. Frequently, no reference is placed on the qualifications of the individual or their experience level. Unfortunately, most software vendors suggest you do not have to worry about the internal numerical engines or methodology used for solving the physical problem. Many of the cheaper software packages offer little information concerning the theory and limitations of the software. Many of the numerical methods employed to solve the problems, have multiple options concerning the numerical controls that can be used to solve the problem. Most engineers that graduate from the institutions are highly computer literate and have had at least one course in numerical methods. They are all “gung-ho” and ready to be the “jet-jockey” of the software tools. There are a few things wrong with this picture. Consider the following:

Software Limitations

  1. No analysis can be more accurate than the data going into it. Many times, in simulations, loads or process conditions at best are an estimate. If that’s the case, it is impossible for any simulation to be anything more than an estimate.
  2. The solution methodology must be validated by some manor either through testing or modeling a known solution similar to the problem at hand. Any numerical method utilizing an iterative procedure, can converge to a false solution. For any simulation that involves a solution of partial differential equations, the solution is complex. Even though, each year the solution methodologies are advancing, there are still problems with false solutions. Unfortunately, some of the converged solutions using the new numerical engines are false and would have diverged with the old numerical engines. Sometimes “user-friendly” can bite you like a snake.
  3. The boundary conditions calculated, or assumed for the model are as important as the simulation itself. Many times the software tool that is being used, requires boundary conditions that are calculated by hand or with other simulation packages.These boundary conditions will always affect the results.
  1. Software tools have disclaimers that relieve them of all responsibility, if there are errors or false solutions that are related to a problem. Ultimately, the engineer is responsible for the solution, not the software vendor. Federal, state, and local courts and agencies do not listen to the excuse “the program calculated it wrong”. If an engineer uses a tool in a critical situation, he or she is the responsible party.
  2. Experience of the physical situation is required to determine the correct control volume for the analysis of the physical system. The problem with many solutions, is just determining how much to model.
  3. Experience is required for finite element, finite volume, and finite difference modeling, to determine the correct mesh or grid density, to adequately model the response. Once the control volume is defined, it is important that the grid or mesh be defined properly, to obtain good results.
  4. Experience is required to interpret the validity and accuracy of the results. Engineering judgement is required to assess the results.

Mitigating Mistakes:

In the aerospace industry, many critical analyses are run in parallel with several different software packages performing the same task. They cannot afford a failure due to false convergence or an inaccurate converged solution. The aerospace industry has been aware of the limitations and the best way to insure an accurate solution for many years now. In fact, most all of today’s high-end software originated from the aerospace industry.

There are many ways to mitigate errors. I have found great success on performing analysis of the problem with the “hand calculation” methodology. This has involved equation solvers, such as “TK Solver”, and or “Math Cad” as well as others. Using this methodology, my colleagues and I have caught major errors in simulations. In some cases, we have had the parties model exactly what we found in our simplified hand calculation approach. Many of the “user-friendly” software packages have many coefficients, that are transparent to the user, for the actual problem. It is so important to have verification and testing to prove the complex simulations are correct.

Professional Takeaways:

So, what is the best way to protect your company’s interest? The first thing to do is to realize that all of the simulation packages are tools for competent engineers to use. Those with a background in numerical methods and those that have an appropriate understanding of the theory behind the program. There is nothing that beats experience. An experienced individual can see if the results make sense and should review all numerical solutions. Many times, the most experienced engineers are not computer literate and it is not worth it for them to spend the time learning the program. Sometime a good team is a computer savvy, rookie engineer and an experienced engineer working together. In this team approach, the best of both worlds will be beneficial to all.

Regarding experience – does it really count? You bet it does – in a big way. Any inexperienced engineer, in any particular area, should review their solutions with experienced engineers.