Nonconvergence in CAESAR II

Intergraph CAS
http://www.intergraph.com
Loren Brown

The equations in CAESAR II (and all pipe flexibility analysis programs) are linear in
nature and therefore are readily solved using matrix operations on computers.
Difficulties with numerical methods occur when nonlinear boundary conditions exist.
The computations solve a system of linear algebraic equations simultaneously until the
solution does not change appreciably between successive iterations. But nonlinear
boundary conditions may cause a change in the actual equations themselves between
successive iterations and is the basis for all convergence problems in this type of
numerical routine.
Once the iteration process begins the loads defined in the load case editor are applied to
the piping and the pipe displaces according to these loads, the stiffness of the pipe, and
how it is restrained. When gaps are closed then the stiffness changes from zero to
whatever stiffness is specified for the restraint in input. This changes the equations that
CAESAR II has to solve. On each successive iteration, CAESAR II must check the
status of the piping at each nonlinear restraint location to determine whether the restraint
is engaged or not engaged and then change the equations accordingly. Convergence is
not achieved until every restraint in the system retains the same engaged/not-engaged
state between several successive iterations (and of course the numerical solution also
changes inappreciably at each node in the system as well).
The various types of nonlinear boundary conditions, the convergence difficulties they
may cause, and methods for obtaining convergence in CAESAR II when encountering
these difficulties are explained in this article.

Nonlinear Restraints
A nonlinear restraint is defined as a restraint whose stiffness is not uniform along its line
of action. Unidirectional restraints (for example, pipe resting on a rack), restraints with a
gap, bi-linear (representing soil) restraints, and friction are all nonlinear. Bi-directional
restraints (X, Z, springs, etc.) are linear. The following illustration shows force vs.
displacement curves for several linear and nonlinear restraints in CAESAR II. Note the
slope of the curve dictates the stiffness of the restraint (rigid restraints have an almost
vertical slope). All nonlinear restraints have more than one stiffness in their force vs.
displacement curves while all linear restraints have a constant stiffness.

Z Restraint, high stiffness

Y Restraint, low stiffness

Nonlinear Restraints
F

gap
k=0
k

k=0
Z
-Z Restraint

X
X Restraint with gap

F
F

Fy
gap

k1

k=0

Z
-F y
Z2 (bi-linear) Restraint

Y
+Y Restraint with gap

Note that rotational restraints may also be linear or nonlinear in a similar manner. The
stiffness in these cases relate a moment to rotation resulting in a stiffness in units of ft.lb./degree (length*force/angle).

Diagnosing Convergence Problems

CAESAR II provides some good diagnostic tools for the user when the solution will not
converge. When the solution does not converge a window called the Incore Solver will
be available (it always comes up but in small converging systems this window may
simply flash by on the screen) as in the illustration below.

Pressing the F2 function key on the keyboard will freeze the solution so the user can
apply some diagnostics.
On the upper-left portion of the Incore Solver window is some general information about
the solution. The most important of these is the Current Case and Total Cases. The
current case is the load case that is being solved for and the total cases is the total number
of native (non-combination) load cases in the load case editor. The solver performs the
analysis on the load cases in the order they are entered in the load case editor.
The middle-right side of the window gives information on the total number of nonlinear
restraints in the model (23 in the figure above) as well as the number of these restraints
that did not converge on the previous iteration (8 in this case). On some models the
number of non-converged restraints may fluctuate and it is recommended to attempt to
freeze the analysis when this number is lowest. Once frozen, pressing the Continue
button will perform a single iteration of the analysis, so it is a simple matter to press

Continue several times to obtain a minimum number of non-converged restraints. Note

that pressing the F2 function key (or the F2 button in the Incore Solver window) will
continue the analysis normally.
In the white list box in the lower-right section of the Incore Solver is information on
individual non-converged restraints. The node number of the restraint is given as is the
direction cosine of the line of action of the restraint. This provides easy identification of
which restraint is causing the problem, which is useful when there are several nonlinear
restraints at the same node and only one or two of them are not converging. In the
example above, of the four restraints that can be seen without scrolling the list box, only
Y restraints are not converging (these are likely to be +Y restraints).
Below the direction cosine of each non-converged restraint is the state of the restraint.
Open means that the restraint is not in contact with the pipe and the stiffness at this
location is zero. Closed indicates that the restraint is in contact with the pipe and that its
stiffness is being used in the analysis. Old State is the previous iteration and New State is
the current iteration. A state of Sliding/Not Sliding indicates the friction state of the
restraint, which is discussed further below.
Make a note of all the non-converged restraint node numbers and perhaps their direction
cosines and then click the Cancel button to terminate this analysis (limited-run users are
not charged a run when terminating the analysis in this manner).
Next, return to input and review the non-converged restraints one-by-one. It is often
useful to review the model graphically with the node numbers turned on. In this way it is
quickly determined whether the non-converged restraints are clustered geometrically
close to one another or if they are more evenly spread throughout the model. When there
are large numbers of nonlinear restraints in a model it can be very difficult to determine
the best way to proceed. Determining the best method for obtaining convergence is as
much art as it is science since we cannot know exactly what is happening numerically in
the solution of so many simultaneous equations.
Sometimes, especially when there are a small number of non-converged restraints, a
simple change to the model may allow complete convergence. Small changes to
operating temperature, for example increasing it by 5 F, may cause the system to
converge (this is if it is the operating case that is not converging. For sustained case nonconvergence the temperature will not affect the solution).
Convergence Problems due to Friction
Numerical modeling of friction is a difficult process at best and it is notorious for causing
non-convergence in flexibility analysis programs. Friction always acts in a plane that is
normal to the line of action of the restraint it is applied to. For example, on a +Y restraint
the friction, if any, will act in the X-Z plane.

When pipe begins to move due to thermal expansion and other loads, static friction
opposes this motion and the force between the pipe and the restraint increases (see figure
below). As the load increases, usually due to heating of the pipe, it may eventually reach
a point where the pipe will break free from friction and begin sliding. This breakaway
force is equal to the normal force (the force along the line of action of the restraint) times
the friction coefficient, Mu. In reality if the heating is gradual the pipe may slide a small
amount and relieve a small amount of the friction force, but then increase again until it
once again exceeds the breakaway force. This may occur many times with such
ratcheting repeating until the pipe temperature reaches steady state and the system is in
equilibrium.

k=0
F n*Mu
k

X-Z
k=0
-F n*Mu
+Y Restraint with friction

At this point, it is important to note that the friction force is still opposing further motion,
even when in equilibrium. In reality when the pipe is sliding this force is equal to the
dynamic friction coefficient times the normal force, which is slightly smaller than the
static friction coefficient times the normal force. It is a common misconception that once
the system reaches equilibrium that there is no further friction force on the system. This
leads some to believe that friction is a transient phenomenon that only occurs during the
start-up or shut-down cycle of a piping system. This is definitely not true! From the time
the friction breakaway force was first exceeded until the system reaches equilibrium the
force opposing motion is between the static and dynamic breakaway force, which is a
fairly small range of force variability.
CAESAR II must calculate three primary quantities to simulate friction at a given node
where a friction coefficient is defined on a restraint. First, the direction of pipe motion
must be calculated. This is easy to do from the resultant displacements on a given
iteration. The angle that the resultant displacement vector in the friction plane makes
with one of the axes in this plane is known as the friction angle. Then a friction restraint
with a stiffness (given by the friction stiffness in Configure/Setup) is applied opposite
this direction of motion. The normal force is multiplied by the user-defined friction

coefficient, (Mu on the restraint definition) to determine the restraint breakaway force.
The equation for the given node is then changed to reflect the direction and stiffness of
the friction restraint for the next iteration.
For the node to be converged, the friction breakaway force, the state of the friction
restraint, and the direction of the friction restraint must all be within certain tolerances
between the current and last iteration. Sometimes, especially with many restraints with
friction, the solution will bounce between a situation where the pipe is sliding (remove
the friction restraint and replace it with the friction force opposing motion) and not
sliding (put in a friction restraint opposing motion). This is a discrete change in the
boundary condition, which can result in an infinite loop since the equations for the node
simply change back and forth repeatedly.
Obtaining Convergence on Systems with Friction
Fortunately, there are several simple settings that can affect the way that friction is
modeled in CAESAR II. When a solution will not converge there are three items that can
be changed that will determine whether or not the solution will be completed. All of
these items may be accessed in the CAESAR II Configuration File (shown below).

As previously discussed, the friction stiffness is set in the Configuration file and is seen
on the right side of the window (highlighted in light blue) in the illustration above. The
default is one million pounds per inch in the English system of units. Lowering this
stiffness results in a larger displacement of the pipe against the friction restraint prior to
exceeding the breakaway force. This effectively makes the friction effect softer. This
then reduces the variability of the friction force against the motion of the pipe between
successive iterations and will have a large impact on convergence.
There are also two friction calculation tolerances available in the Configuration file. The
first is the friction normal force variation. As implied, this allows successive values of
the normal force, and hence the friction breakaway force to have some variability and
therefore improve convergence. The second is the friction angle variation, which is the
number of degrees of change between successive iterations that the friction vector (either
restraint or force) can have. Increasing either of these values will allow more variability
in the friction solution between iterations and giving a better chance of convergence.
At this juncture it is important to note that reducing friction stiffness, and increasing the
normal force and angle variations will increase the error in the results. It should also be
noted that the choice of friction coefficient on the restraint definition can be difficult to
accurately determine. The friction coefficient is a function of the surface roughness of
both the restraint and pipe, which can have large variations due to moisture, corrosion,
pitting and other defects, and manufacturing processes.
Determination of the systems sensitivity to friction can be determined using CAESAR II
and will help the engineer determine, at least subjectively, the extent of error introduced
by opening friction tolerances in the configuration file to obtain convergence.
The CAESAR II Load Case Editor provides an item called the Friction Multiplier, which
can be found under the Load Case Options tab (see figure below).

A good comparison can be made with three different values of the friction coefficient by
creating two additional OPE load cases with identical loads to the primary operating load
case. Then change the friction multiplier on these two new load cases to .67 and .33
respectively. The friction multiplier will be applied to all the Mu values in the model.
Then a direct comparison between these three operating cases can be made in the
Restraint Summary report in output. Any sensitive equipment connections or restraint
loads can then be compared with one-third, two-thirds, and full friction applied. This
comparison should give the engineer a good understanding of the effects of friction on
the system. This then provides a basis to estimate the effects of changing the friction
tolerances in the Configuration File to obtain convergence.

Convergence Problems due to Nonlinear Restraints

Initially, the piping system is said to be in a neutral state, which is simply the geometrical
representation of how the system was input. This means that for bi-directional restraints
with gaps the pipe is resting with an equal gap on each side and is essentially
unrestrained. Unidirectional restraints are initially in contact with the pipe, but with zero
force since no loads are being applied to the piping system. For a unidirectional restraint
with a gap the pipe is resting where the restraint would be if it had no gap, but is not in
contact with the restraint.
Occasionally, a restraint will be in a numerical situation where the solution will change
back and forth due to the continual changes in the equations. At this point the solution is
in an infinite loop and will never converge. The analysis must be terminated and the input
changed to avoid this numerical methods problem.
Linearization of Non-converged Restraints
A very effective method for obtaining convergence is the changing of one or more
restraints from nonlinear to linear. Linear restraints always converge.
If the restraint is bi-directional with a gap it is often useful to either remove the gap
(linearizing the restraint) or change the gap dimension (remaining nonlinear, but
changing the solution domain). Often, engineers model restraints with very small gaps to
accommodate the diameter growth of pipe due to thermal expansion. Although you
should not change the design of such gaps, often these small gaps are unnecessary when
modeling a system for pipe flexibility analysis and the resultant error in the results should
be tolerably small. In such cases removal of gaps, at least on non-converged restraints,
will allow the analysis to converge.
If the restraint is unidirectional then it can be linearized by changing it to bi-directional.
In this way a +Y restraint can be changed to a Y restraint, a RZ restraint can be changed
to an RZ restraint, and so on.

Bi-linear restraints are rarely non-convergent, but if they are, a small change in the
breakaway force, Fy, or breakaway torque (on rotational bi-linear restraints) may
accomplish convergence. Altering the K1 and K2 values of stiffness may also help.
Since bi-linear restraints are only used in unusual circumstances to model a very specific
type of behavior (usually soil modeling or hinge joint modeling) it is not recommended in
most circumstances to completely linearize these restraints.
If the non-converged restraints are clustered in a relatively small geometrical area of the
system then linearization of one restraint near the middle of the cluster will sometimes
allow convergence. If that doesnt work, linearization of two restraints near the opposite
edges of the area of non-convergence will often do the trick. Experimentation with the
location of linearization of restraints will sometimes be required before the solution can
be obtained and in such systems there is no simpler method.
It should be mentioned at this point that if the model also contains friction at the locations
of nonlinear restraints, then the friction problem should be dealt with first, prior to
linearizing restraints (see discussion that follows).
It is important to realize that any time a nonlinear restraint is linearized to obtain
convergence that error will be introduced into the results, unless of course the design is
changed to accommodate the use of the new linear restraint. It is prudent therefore to
assess, at least subjectively, the amount of error introduced. The simplest method for
doing this is to review the restraint report in output once convergence is obtained. If the
force on a formerly non-converged restraint is relatively small then so will the error be.
But if the force on a formerly non-converged restraint is moderate to high then the error
may propagate far beyond the node point of the restraint. In such cases a design change
may be in order for such a location to actually use the same restraint that was modeled in
CAESAR II.
Convergence Difficulties due to Large Rotation Rod Restraints
Large rotation rods are primarily used in CAESAR II when rotations of rod hangers
exceed two or three degrees. This is to maintain the length of the restraint and force the
pipe to move in an arc. Without use of the large rotation rod restraint the pipe is not
forced to move in an arc because the degrees of freedom are de-coupled in pipe flexibility
analysis.
There are two tolerances associated with the convergence criteria for large rotation rods.
The first is the Rod Increment, which is defined as the maximum amount of change in the
angle of the rod rotation between successive iterations. The default is 1.0 degree, but this
number can be decreased in difficult-to-converge models. This forces the rod to not
change its rotation by more than the rod increment between iterations, which can help
convergence. The second tolerance is called the Rod Tolerance, which is defined as the
maximum change in rod rotation between iterations for convergence to occur. This
differs from the rod increment in that this is the actual tolerance for the angle change to

allow convergence, while the increment is the maximum change allowed by the program.
If the rod wants to rotate more than the rod increment then the increment is invoked
instead.
Systems with long rods or many of them are difficult to converge because while some
rods are converging this may cause others in the system to move away from convergence.
It is generally a good idea to add large rotation rods only in a system that is truly
experiencing large rotations. If small rotations are seen in the system then the use of
large rotation rods is not warranted.
Both the rod tolerance and the rod increment are available in the CAESAR II
Configuration File.
Summary
The foregoing discussion could lead one to believe that the use of nonlinear boundary
conditions in pipe stress analysis is difficult and should not be attempted. But this is far
from true, because many piping systems use these types of restraints and friction is
always present in real piping systems. Other pipe stress analysis programs do not
encounter the problems addressed above for a simple reason: the program has an iteration
counter which simply freezes the solution without convergence being obtained as soon as
the number of iterations reaches the counter limit. The results in such a solution are
unreliable, and the engineer is relying on results that have not converged. This is done to
avoid the annoyance involved in non-converged systems, but it is ignoring sound
engineering principals. Intergraph CAS has always believed that engineers are capable
and indeed responsible for applying sound engineering principals in the use of our
analysis tools such as CAESAR II.