Model Set-up Guidelines |
 
|
Model Set-up Guidelines |
|
Pipe-in-pipe models tend to be quite complex, so the following guidance is provided to assist new users with model creation and help to avoid common pitfalls. Some of the following information may be very familiar to existing Flexcom users, but a coherent summary nonetheless serves as a helpful reference point.
•Construct the basic model first before concerning yourself with any pipe-in-pipe interaction. Most or all of the model may be constructed using the *LINES keyword but occasionally you may need to define nodes and elements explicitly using the *NODE and *ELEMENT keywords.
•If you are using the *LINES keyword exclusively to construct your model, it should be possible to use the *LINES PIP keyword to define the pipe-in-pipe interactions. This creates all the relevant pipe-in-pipe section definitions, standard connections, and nodal equivalences (to represent bulkheads). This is a very convenient approach as it requires very little user input, but you may find it overly restrictive as you cannot perform any personalised adjustments to the model subsequently. Many users, particularly experienced ones, will prefer to disregard the *LINES PIP keyword and opt to define the various pipe-in-pipe inputs individually. Much of the remainder of this article assumes that you are using *LINES (and possibly *NODE and *ELEMENT also) rather than *LINES PIP.
•Pipe-in-pipe models should always be set up such that primary and secondary sections are initially concentric. It is important to note that while Flexcom monitors the relative displacement of the connected nodes in the lateral direction (as outlined in Contact Modelling), it does not take any directionality into account. For illustrative purposes, let’s consider a dual-bore top tensioned riser. The sign of the displacement term is always positive when examined in plan view, regardless of the whether the inner section moves from right to left, left to right, upwards to downwards, or downwards to upwards, within the outer section. If you are modelling an eccentric pipe-in-pipe configuration, where the inner pipe is not concentric with the outer pipe, then you should set up the model such that both sections are concentric initially, and then apply a desired offset to the inner pipe subsequently.
oA related point therefore is that Power Law connections are recommended, as all displacement and force terms are inherently positive by definition. If you are using force-deflection curves which are explicitly defined using Data Pairs, then you should ensure that all specified deflection values are zero or positive.
•Use the *PIP SECTION keyword to identify which pipe sections are contained within which. Pipe-in-pipe section data is used in the calculation of buoyancy and hydrodynamic forces. If you are defining a pipe-on-pipe configuration, then you will not require the *PIP SECTION keyword. If you are defining a pipe-in-pipe bundle, then some pipes may act as both inner and outer sections for other pipes.
•Use the *PIP CONNECTION keyword to define pipe-in-pipe connections between nodes on the primary and secondary pipes. Connections govern the physical interaction between the pipes. Recommended practice is to designate the larger/stronger pipe as the primary pipe, and the smaller/dependent pipe as the secondary pipe. The primary elements are used to determine the orientation vectors of the stiffness connections between the connected pipes, and it is important that these vectors remain perpendicular to the overall pipe geometry in so far as possible. Designating the smaller/dependent pipe as the primary pipe is not recommended, as the consistency of the orientation vectors could be compromised due to its flexibility.
•If you are expecting little or no relative sliding between the pipes in the axial direction, standard connections are the recommended option. They are computationally efficient as each pair of connected primary and secondary nodes remain connected throughout the entire simulation and the model is effectively fixed from the outset.
•If the primary and secondary pipes share a common finite element mesh, then it is very straightforward to generate all the required standard connections using the GEN=Primary Nodes, GEN=Secondary Nodes input format under the *PIP CONNECTION keyword. In practice however, this is rarely the case so this approach is typically suitable for very simple models only.
•For models of any significant complexity, the mesh densities on the primary and secondary pipes will vary, both in terms of the overall number of nodes, and the distribution of these nodes along the pipe lengths. So identifying all the required one-to-one connections as suggested in the previous point may be time consuming and tedious, and simply unfeasible in some cases.
•So even if you are not expecting any relative sliding, it can be advantageous to create a series of sliding connections to help assemble the model connectivity initially, and to subsequently designate these connections as non-sliding once the overall model configuration has been established. Sliding connections may be created using the GEN=Primary Nodes, SET=Secondary Element Set input format under the *PIP CONNECTION keyword. This means that the program will automatically determine the optimum nodal connectivity. This considerably reduces effort on your part as the software determines which primary and secondary nodes are to be connected.
•Sliding connections can also be very useful in situations where the meshes are consistent, but where significant axial motion occurs during an initial alignment stage. For example, when setting up a landing string model, the initial set-down of the drill string within the marine riser can make it very difficult to manually identify the optimal set of pipe-in-pipe connections in advance of the initial static analysis. From a dynamic perspective, if relative sliding is not anticipated, the connections can be designated as non-sliding subsequently.
•Assuming that relative sliding is not anticipated from a dynamic perspective, you should ensure to designate the connections as non-sliding prior to any dynamic simulations. This is achieved via the inclusion of the *NO PIP SLIDING keyword. This means that the connections are effectively treated as standard rather than sliding from that point onwards. This eliminates any overhead associated with the monitoring of relative nodal locations over time, and can possibly provide enhanced numerical stability as the model connectivity remains consistent throughout the entire simulation. Note that you must explicitly specify the *NO PIP SLIDING keyword in every dynamic simulation. If you perform dynamic continuation stages, the keyword must be included in any restart keyword files also.
•Finally, and this may already be obvious, if you are genuinely expecting relative sliding between the primary and secondary pipes, you should define sliding connections as discussed above, and disregard any comments relating to the reassignment of the connections as non-sliding. Sliding connections are ideal for situations where continuous realignment of the pipe-in-pipe connections is required, for example in the case of a J-Tube Pull-In.
•Strictly speaking, it is not necessary to have finite element mesh alignment between the primary and secondary pipes. The contact stiffness at each pipe-in-pipe connection acts in a direction which is perpendicular to the Primary Element, so in theory the contact model should be independent of any axial separation which exists between connected nodes. However in practice, having a reasonably well aligned model is generally recommended, and is actually necessary for models which incorporate significant variations in local curvature.
•Line mesh generation is performed individually for each line, independently of all other lines in the model. So if you are using the *LINES keyword to construct your model, there is no automatic way to enforce mesh consistency between the primary and secondary pipes. If you feel this is essential to the success of your model, you could include additional sub-sections on one or both pipes, even if the structural properties of these sub-sections are identical to adjacent sub-sections, in order to replicate the same finite element mesh across both pipes. Although possible, this may be quite tedious to do in practice, and it is likely to add considerable effort to your model construction phase. Furthermore, it would not necessarily ensure mesh alignment in models where relative axial motion occurs during an initial alignment stage (e.g. initial set-down of a drill string within a marine riser). So it is mentioned here for completeness only.
•By default, drag forces and hydrodynamic inertia on inner pipe-in-pipe elements are modelled as mass and damping terms on the left hand side of the equations of motion, capturing the required coupling between the outer node’s velocity/acceleration and the inner node loading. This necessitates the existence of suitable pipe-in-pipe connections in the global connectivity matrix. In situations where there is no user-defined connection guaranteed to exist between an inner node and the outer pipe, the software automatically inserts a token connection of zero stiffness where required to ensure that hydrodynamic loading on the inner node can be captured. This may lead to the creation of a large number of additional connections, which can have a negative impact on run-time performance. This approach may be viewed as overly conservative by some software users, who may instead opt to suppress the creation of the additional connections via the *PIP SECTION keyword (AUTO_CREATE option). Before you choose this option, you are advised to carefully read the article on Additional Connections to Support Inner Pipe Hydrodynamics and become fully aware of its potential implications.
•Where you are using linear connections (e.g. to model centralisers), the linear contact stiffness is defined under the *PIP CONNECTION keyword so no further user input is required.
•In regions where the connected pipes are free to move radially relative to one another, a non-linear contact relationship should be defined under the *PIP STIFFNESS keyword. Recommended procedure is to use the Power-Law approach which ensures a gradual transition between regions of low (i.e. free movement zone) and high stiffness (i.e. wall-to-wall contact) and tends to aid solution robustness. Using this approach, the instantaneous contact stiffness is derived from a power-law equation which is governed by the relative spacing between the pipes in the lateral direction, and some user-defined coefficients such as a maximum contact force and a power exponent. As this is a crucial aspect of pipe-in-pipe modelling, you are advised to read the guidance regarding contact force and exponent terms.
oFor pipe-in-pipe models, you should use the CONFIGURATION=PIP option under the *PIP STIFFNESS keyword.
oFor pipe-on-pipe models, you should use the CONFIGURATION=POP option under the *PIP STIFFNESS keyword.
•In situations where the pipes are rigidly connected to each other, via a bulkhead for example, you will need to create a rigid constraint.
oFor pipe-in-pipe models, you should use the *EQUIVALENT keyword to specify that the inner and outer nodes are modelled a single equivalent node.
oFor pipe-on-pipe models, you should use the *ELEMENT keyword to insert a rigid massless element between the primary and secondary nodes.
•Given the complexity associated with pipe-in-pipe modelling - as reflected by the amount of user documentation on this topic - you are encouraged to inspect your model in some detail to ensure that it is operating as expected and meets your requirements. You can insert the *PRINT keyword (sub-entry OUTPUT=PIP CONNECTIONS) at any simulation stage to request additional information to be printed to the main output file. This facilitates a detailed inspection of the pipe-in-pipe configuration at any point during the simulation, and provides greater transparency regarding the internal workings of the software. Some sample information is shown below.
*** ADDITIONAL PRINTED OUTPUT ***
---------------------------------
Pipe-in-Pipe Connections:
Number Type Primary Node Secondary Node Status Primary Element Secondary Element Perpendicular Vector
X Y Z
--------------------------------------------------------------------------------------------------------------------------------------------
1 Sliding 1033 1002 Active 1033 1001 0.853 -0.522 0.000
2 Sliding 1034 1004 Active 1034 1003 0.824 -0.566 0.000
3 Sliding 1035 1005 Active 1035 1004 0.793 -0.609 0.000
4 Sliding 1036 1006 Active 1036 1006 0.760 -0.649 0.000
5 Sliding 1037 1008 Active 1037 1008 0.725 -0.688 0.000
To gain further insight and a complete understanding of the internal operation of the pipe-in-pipe modelling algorithms in Flexcom, you are encouraged to read these related articles also...
•Pipe-in-Pipe Sections describes how one pipe is contained within another, and explains the implications of this for buoyancy and hydrodynamic forces.
•Standard Connections outlines the operation of the standard pipe-in-pipe contact model at a high level.
•Sliding Connections explains the additional functionality offered by sliding connections, and suggests scenarios for which it is appropriate.
•Contact Modelling discusses the operation of the pipe-in-pipe contact modelling algorithm in detail.
•Hydrodynamic Forces outlines the main fluid forces modelled by Flexcom (including buoyancy, hydrodynamic and internal fluid) and how these are affected by the presence of pipe-in-pipe configurations.
•Cable Bundles. If you are defining pipe-in-pipe connections in a model which includes connections along a curved section, you need to ensure that both pipes adopt a consistent profile initially. Consider the case of a steel catenary riser which has an inner tubing enclosed within it. If you define the geometry of the inner and outer pipes separately via the *LINES or *CABLE keywords, then the solutions from the Cable Pre-Static Step for each pipe will be independent. As the properties of the riser and tubing will be very different, the cable solutions will naturally be quite different also. Note that the cable pre-static solution is based solely on apparent weight and axial stiffness, and does not take account of any pipe-in-pipe connections. The cable pre-static solution is used as a first approximation to the full finite element solution, and the pipe-in-pipe connections are initialised on that basis also. This means that any initial deviations of the inner pipe away from the centreline of the outer pipe will be maintained throughout the entire duration of the analysis, which is probably an undesirable effect. To cater for such circumstances, you can use the *CABLE BUNDLE keyword to specify that two or more cables are to be grouped together within a single bundle for the purposes of the cable pre-static step only. This means that internally, all cables within a bundle share common properties for the purposes of the cable computations, ensuring that each cable adopts a similar profile before the full finite element solution initiates. Note that if you are using the *LINES PIP keyword to set up your model, then you do not need to concern yourself with the issue of cable bundles, as it is handled automatically by the software.