ZippyDDoodah
Structural
Typical pipe stress load cases commonly used for ASME B31.1/B31.3 code stress calculations seem mathematically inconsistent for nonlinear analyses (+Y supports, gaps, friction), relying on linear algebraic subtractions when dealing with nonlinear (NL) load cases. Superposition doesn’t apply in NL analysis.
Let’s take a basic example assuming P1 is only used for axial pressure stress calculation and generates no reactions (W = Weight load, T1 = Thermal load):
L1 = W+P1+T1 (Operating)
L2 = W+P1 (Sustained)
L3 = L1-L2 (Expansion)
This commonly used approach to B31.1/B31.3 code compliance cases (also recommended by the Caesar II folks and probably the other pipe stress software vendors too) seems to mix apples with watermelons, at least partially. In NL analysis, the W+P1 component of L1 would have different displacements, reactions and stresses than the W+P1 in L2. Subtracting the “ambient” W+P1 in L2 from the “hot” operating case as shown in L3, is different than subtracting the W+P1 component of L1 from the operating case. Consideration of, and subtraction of only 1 sustained case would seem to result in incomplete displacement stress range considerations, as well as incomplete sustained stress evaluation.
We’re told, with justification, that in NL analysis we can’t simply run a T1 case by itself for the expansion/displacement stress case. If it’s important to capture the range of T1 by subtracting L1-L2 rather than simply running T1 by itself, then using ONLY the ambient W+P1 would similarly seem to be inadequate.
I recognize that B31.3 Appendix P alternate method is an attempt to deal with some related inconsistencies, but that’s a separate issue from what I’m trying to flesh out. My primary concern is the issue of when and whether it’s acceptable and justifiable to use linear algebraic subtractions between nonlinear load cases for code compliance.
For sustained stress cases to be handled consistently and accurately, in principle wouldn’t you need to take each and every operating case and then use path dependent load sequencing to subtract the Thermal load? That would necessitate one or more ambient sustained cases as well as a sustained case from each operating case. For example, run W+P1+T1 case and then sequence the subtraction of T1 using NL sequenced analysis, not algebraic, in order to obtain each “operating sustained case" for lack of a better term. The result of that procedure would be different than the results from W+P1 in L2 above, and very different than (W+P1+T1) minus (T1) using algebraic. If you used NL load sequencing to generate those sustained cases, then I suppose you could justify linear algebraic subtractions of operating case minus sustained case as shown in L3 in order to determine expansion/displacement stress, although you'd have multiple sustained cases.
Things become more complicated with multiple thermal cases, especially in cases where standby lines become operational into a piping network which has already displaced due to weight and thermal loads.. those newly operational lines do not start from an ambient system.
I haven’t heard or read any discussions about these seemingly questionable assumptions in current approaches to calculating code stresses. Everyone seems to be doing pretty much the same thing.
Let’s take a basic example assuming P1 is only used for axial pressure stress calculation and generates no reactions (W = Weight load, T1 = Thermal load):
L1 = W+P1+T1 (Operating)
L2 = W+P1 (Sustained)
L3 = L1-L2 (Expansion)
This commonly used approach to B31.1/B31.3 code compliance cases (also recommended by the Caesar II folks and probably the other pipe stress software vendors too) seems to mix apples with watermelons, at least partially. In NL analysis, the W+P1 component of L1 would have different displacements, reactions and stresses than the W+P1 in L2. Subtracting the “ambient” W+P1 in L2 from the “hot” operating case as shown in L3, is different than subtracting the W+P1 component of L1 from the operating case. Consideration of, and subtraction of only 1 sustained case would seem to result in incomplete displacement stress range considerations, as well as incomplete sustained stress evaluation.
We’re told, with justification, that in NL analysis we can’t simply run a T1 case by itself for the expansion/displacement stress case. If it’s important to capture the range of T1 by subtracting L1-L2 rather than simply running T1 by itself, then using ONLY the ambient W+P1 would similarly seem to be inadequate.
I recognize that B31.3 Appendix P alternate method is an attempt to deal with some related inconsistencies, but that’s a separate issue from what I’m trying to flesh out. My primary concern is the issue of when and whether it’s acceptable and justifiable to use linear algebraic subtractions between nonlinear load cases for code compliance.
For sustained stress cases to be handled consistently and accurately, in principle wouldn’t you need to take each and every operating case and then use path dependent load sequencing to subtract the Thermal load? That would necessitate one or more ambient sustained cases as well as a sustained case from each operating case. For example, run W+P1+T1 case and then sequence the subtraction of T1 using NL sequenced analysis, not algebraic, in order to obtain each “operating sustained case" for lack of a better term. The result of that procedure would be different than the results from W+P1 in L2 above, and very different than (W+P1+T1) minus (T1) using algebraic. If you used NL load sequencing to generate those sustained cases, then I suppose you could justify linear algebraic subtractions of operating case minus sustained case as shown in L3 in order to determine expansion/displacement stress, although you'd have multiple sustained cases.
Things become more complicated with multiple thermal cases, especially in cases where standby lines become operational into a piping network which has already displaced due to weight and thermal loads.. those newly operational lines do not start from an ambient system.
I haven’t heard or read any discussions about these seemingly questionable assumptions in current approaches to calculating code stresses. Everyone seems to be doing pretty much the same thing.
