Applies To
Product(s):	AutoPIPE
Version(s):	ALL;
Area:	Reporting
Date Logged & Current Version	Oct 2023 23.00.00.230

Problem:

In some of the fatigue results, I am seeing high CUF values, which seem contrary to much lower results at neighboring locations. When looking at the moments used in the fatigue assessment, as given in the Fatigue Reports in the output, the first thing given in the summary is a list of the load sets available for equation 10, including the corresponding moments for each case. At one of the locations of interest, the global moments on the negative side of node A07 (where the high CUFs occur) are (for a relevant selection of load cases):

Load case: MX MY MZ

Thermal 17{18} -21166 -60454 -140144

Thermal 18{19} -21226 -60634 -140556

Thermal 33{34} -21175 -60479 -140201

Thermal 34{35} -21216 -60605 -140489

Thermal 44{45} -21570 -61669 -142913

The moments are of the same order in each case, which makes sense as each load case is fairly similar. Each component has the same sign (i.e. all x components are negative, and in this case the y and z components are also all negative). On the positive side of this node, they are all positive. Looking through the global force and moment results, this is consistent. Obviously, some signs change depending on the orientation of the elements attached to each node, but the x components always have the same sign, as do the y and z components. However, the moments given in the fatigue assessment for the same cases are:

Load case: MX MY MZ

Thermal 17{18} -21166 -60454 -140144

Thermal 18{19} -21226 -60634 -140556

Thermal 33{34} -21175 -60479 140201

Thermal 34{35} -21216 -60605 140489

Thermal 44{45} 21570 -61669 142913

It can be seen that some of the x and z moments have opposite signs. The moment ranges should be small, and where the signs match they are, but where the signs differ, artificially high moment ranges are going to the fatigue calculation. This incorrectly inflates the Equation 11 stress, and hence the alternating stress, and hence the fatigue damage for any such pair (e.g. 17-44).

I note that the location this occurs at is a tee. However, the branch is a much smaller diameter than the run, and it is currently just modelled as a stub (i.e. a short length of pipe not attached to anything and ending in a free end). Therefore there are no moments in the stub component. I see no reason why this location being a tee should reverse the signs of some (but not all) moment components, which is inconsistent. In addition, I ran an alternate version of the model without the stub, but with retaining the stress indices needed for the tee. The moments are not reversed in this case, and the CUFs are of the lower order expected. I don't think AutoPIPE's reversal of some moments when the tee is present is correct.

This is demonstrated at nodes A04 and A07 in the supplied model to technical support. Both are nodes at small bore stubs attached to larger bore pipe. The CUF is high at node A04, but not A07 (although both exhibit some opposite signs). In the full model, both nodes have a high CUF, so cutting down the model has changed this, when I don't think it should have. I can understand that there might be a transformation of moment from global to whatever system the tee requires for the fatigue assessment, but I can't see why it would be inconsistent, as I've previously described.

In addition, it took about an hour for me to get the output text file, for just a subset of nodes in this reduced size model. For the full model it is taking 3-4 hours (using the Quick Reports --> Output Report option). Does this get any quicker if you select fewer options to add to the file? I've found that using the output grid is even slower, taking further time to switch between the different stress summaries and whenever the view is manipulated (e.g. to look at equation 9 only results). Any advice to streamline this would be most helpful.

Why?

Solution:

Without the model we have no way to test if there is an error here or if it is as it should be. We cannot comment on why Thermal 17 provide opposite moment sign. Moments at tees go through a complex summation process defined in ASME NB, although I would suspect something like what was mentioned above.

Requested the user to send an example with both arrangements in the same model for review.

After the investigation, the problem in this case occurred at the stub tee points, presumably part of some instrumentation pipework and only modelled due to them being discontinuities and having Delta T’s applied. The solution to the problem would be to remove this stub and manually intensify the point as a Tee, or model the rest of the pipe route to a convenient support. The stresses at the stubs will not be accurate when model the way found in the example model provided to technical support. Therefore, their inclusion is questionable.

The problem occurs because there is no thermal load in the stub; the moment on either side of the tee should be the same, but due to minute differences in the “floating point” values there is a difference of <0.01 ibf-in and this is enough to trigger the tee summation to flip the sign. This difference in the moments on both sides of a header could result from a number of factors like the accuracy of the coordinates for a point that the database can store for a floating point number or small difference in the stiffness matrix used. It is only an issue with ASME NB as it requires tee summation and the fatigue assessment looks across load cases for the ranges and the alternating stress will always be higher at this node, all other code solutions are not affected.

Fractional geometry changes will change the location of this affect, in this specific case, moving it from case 21 to a different case; you can try this yourself to show how sensitive this model is to this minute geometry inaccuracies. Round tripping fixes some of these inaccuracies and solves the problem (you will have to recreate the stress summaries however), removal of the stub solves the problem, and modelling some geometry to connect the two stubs together or to a support somewhere also solves the problem.

We can provide a tolerance in the check across the tee, and have tested that this also solves the problem. However, providing this in the program would potentially prevent the case where a real small difference should exist across the tee and result in a less conservative result. Practically from an engineering point of view this should never happen, but programming has to be logical and we would rather not make this change as this is an issue of inaccuracies or incomplete geometry and as such shouldn’t occur very often, and if it did there is a simple solution and the result would be conservative.

12. High CUF values caused by Forces / Moments having opposite signs about a Tee node point in AutoP

Problem:

Solution:

See Also