Tolerable Convergence

Trying to design and analyze piping systems can be a complicated, and difficult task for engineers. This was especially true before the advent of easily accessible computer technology. Hand calculations required hundreds of hours of painstaking work, by entire teams of people. Great care had to be taken to ensure the reliability and accuracy of the results. Human beings do make mistakes, after all.

In today’s engineering world, there are a multitude of computer tools designed to make the design process simpler, faster, and more reliable, such as AFT’s family of analysis products. AFT products revolve around graphically based, drag and drop interfaces that makes creating a computer model of piping systems quick, and easy. Being able to create simulation models with little effort, however, can be a bit of a double-edged sword.

If an engineer isn’t careful, the simplicity with which a computer model can be created can cause the engineer to become a bit complacent. Just as in the days of long, painstaking hand calculations, due diligence is required to ensure information being entered into the model is good and valid data. It’s also important that the results presented by the analysis are correct and make physical sense. The threat of having to work through numerous days of hand calculations again to correct a mistake created an atmosphere of care and diligence that doesn’t always exist in the world of “easy” computer analysis programs. The engineer must never set aside their training, and abdicate this responsibility to a computer program. In truth, programs like AFT Fathom, or AFT Arrow, are just tools which create and solve the same systems of equations that were solved by hand before computers. The only difference is, the engineer sets up the mathematics using symbols, and pictures, and the computer solves the equations. It is just that simple. The engineers using the software must always keep this idea in the back of their mind.

The types of mistakes that can be made are many.  Some are obvious things, such as entering incorrect numbers, or selecting incorrect units. One of the mantras I teach when training engineers to use AFT software is “Units Kill!” While a bit glib, it can also be quite true. At the very least, making mistakes can result in very expensive problems or failures. Just ask the Russian engineers who designed the space probe that was supposed to land on one of the moons of Mars, but instead, was destroyed when it impacted the surface because incorrect units were used somewhere in the design process. Other modeling problems are subtler, and can be difficult to uncover. Some are a result of mathematical difficulties that can arise in the solution process.

AFT recently worked with a customer to resolve an issue that revolved around “tolerances” and “convergence”.  In AFT software, “convergence” occurs when the changes in pressures, flows, and temperatures from one iteration to the next in the solution process are very small. “Tolerance” is the criteria which is used to determine when the change from one iteration to the next is small enough to constitute “convergence”. One must be careful to use tolerances that are small enough to ensure a good convergence. If the selected tolerance is too large, then there is a correspondingly large band of error around the calculated values once convergence is reached. It is possible to come to a mathematically converged solution which does not provide good results, if the tolerances selected are not appropriate. Typically, the default values for tolerance used in AFT software are more than sufficient to provide a valid solution.

However, the engineer who contacted us noticed that after his model converged, one of the pipes in the system had an unreasonably high pressure drop for the calculated flows. What’s more, if he changed the initial conditions slightly, the end result was much more reasonable, which didn’t appear to make sense. Different initial starting points for the solution should lead to the same final result, which is the solution of the governing equations.  But that did not appear to be the case.

The key to understanding the issue was realizing that the fluid being used in the analysis was highly viscous (about 20 times more viscous than water). With a highly viscous fluid, slightly different values of flow can result in significantly different pressure drops. By changing the starting conditions of the solution, two different mathematical paths to the final solution were followed. These solutions resulted in slightly different flows being calculated, causing the significant differences in pressure drop that were noted.  Both solutions were valid, mathematically, and met the criteria for convergence (values no longer changing from iteration to iteration), within the specified tolerances.

The solution to this apparent dilemma was to make the tolerances for flow smaller. By doing this, it reduced the error band around the flow solution, forcing the program to iterate longer before convergence occurred. The end result being that either starting point resulted in nearly identical flows being calculated, and consequently, the pressure drop in the pipes were also nearly identical. What appeared to be an error in the calculations, was actually a mathematical issue caused by insufficient tolerances on a highly viscous fluid. This problem was solved easily by making the flow tolerances smaller.

This case was a perfect example of how an engineer acted exactly as one should when dealing with a computer analysis. He carefully examined the information in front of him using his knowledge and experience as an engineer, and consequently uncovered a possible issue with the results. He then sought to understand the source of the problem, and found a way to rectify it. He practiced due diligence. If he had not taken the time to look at the results to ensure that they were sound and reasonable, and were consistent with physical reality, the system design could have been compromised.

This is a valuable lesson for all of us who are practicing engineers. Despite the ease with which engineering analysis can be performed with the aid of computer tools, engineers must never set aside their responsibility to examine and validate the end results. The ultimate responsibility for a good analysis rests upon the engineer, and not the software. After all, analysis programs are merely tools, and like all tools, they must be used properly to obtain the desired results!