## Time domain models |

There are four time domain VIV models, two being wake oscillator models and two being vortex tracking models.

In all the time domain models, the vortex force applied in the static analysis is the standard Morison drag force. Then, during the build-up period of the simulation, the ramping function is used to smoothly change to the vortex force given by the VIV model.

Note: | This ramping is only applied for the components of vortex force which are calculated by the VIV model. For example, the wake oscillator models only provide transverse vortex force. So, for the wake oscillators, the ramping is done for the transverse component of force, but the inline component of force is calculated using the standard Morison drag formulation. |

The data described below are common to all the time domain models.

For all the time domain VIV models, it is important that the model-wide outer time step (on the general data form) is small compared with the Strouhal period. The Strouhal period $T\urm{s}$ is defined as $T\urm{s} = d\urm{n}/(St\,v\urm{n})$, where $d\urm{n}$ is line diameter, $St$ is Strouhal number and $v\urm{n}$ is the normal component of relative flow velocity.

With a Strouhal number of 0.2, the Strouhal period is given by $5\,d\urm{n}/v\urm{n}$. The outer time step needs to be a small fraction of this Strouhal period, the precise fraction to use depending on the VIV model, as follows.

The wake oscillator calculations are done every outer time step, and experience so far suggests that the integration of the wake oscillator loses accuracy if this time step is greater than about 1/200th of the Strouhal period. At the start of the simulation, OrcaFlex checks and warns if the outer time step exceeds this limit at any node on lines that use a wake oscillator. Note that this check is against the Strouhal period for the flow velocity that applies in the static analysis, so it does not take into account changes in Strouhal period during the simulation.

The outer time step determines how often the fluid forces on the line are updated. The vortex tracking (1) model performs its calculations using its own variable time step (not to be confused with the more general, and irrelevant here, variable time step for implicit integration). The calculations done in this vortex-tracking time step are typically much more time-consuming than the all the other model calculations, so the model outer time step does not usually have much effect on the overall simulation speed. We therefore recommend that the outer time step is set to a very small value, preferably a lot less than the vortex tracking time step, giving the line a chance to react quickly to changes in fluid force.

The time step used by the vortex tracking (2) model is the same as the outer time step. It should therefore be small enough to discretise the VIV sufficiently finely, but if it is too small then a lot of vortices must be tracked and this significantly slows the model. Based on our experience so far, we recommend an outer time step of around 1/100th to 1/200th of the Strouhal period.

Note: | The automated recommended time step feature in OrcaFlex implements the above recommendation for the wake oscillator models but not for the vortex tracking models. |

OrcaFlex uses a digital filter, with this filter cut-off period, to separate the mean motion of the node from the VIV motion. This is required, for instance, by the wake oscillator models to avoid VIV motion feeding back into the velocity used in the wake oscillator model: the filter selects only the non-VIV motion of the node to contribute to VIV.

In more detail, the node velocity vector is filtered and the resulting *non-VIV velocity* is subtracted from the fluid velocity to obtain a *non-VIV relative velocity* vector. Then,

- for the wake oscillator models, the normal component of this non-VIV relative velocity vector is the velocity input to the wake oscillator model
- for all the time domain models, the inline and transverse directions are based on the non-VIV relative velocity vector
- the node
*position*vector is also filtered and the resulting*non-VIV position*is used in calculating the transverse VIV offset - for the Milan wake oscillator only, this non-VIV position is used for the node mean position

In VIV analysis, we use the filter to attenuate motion whose period is *below* the **filter period**. So a filter period of zero gives an all-pass filter – undesirable, since it allows VIV motion to feed back into the wake oscillator models and into the definitions of the inline and transverse directions. At the other extreme, a filter period of infinity gives a no-pass filter, which filters out all oscillatory motion of the line, leaving only any non-zero starting velocity.

The filter cutoff achieved is not very sharp so, in practice, the filter period should be set to be significantly above the period of any expected VIV (preferably by a factor of 10 or more). However it should also be significantly below (again by a factor of 10 or more) the period of any line motion (e.g. due to towing or vessel motion) that you want to contribute to VIV.

For simple cases where VIV is excited only by fluid flow and not by line motion, the filter period can be set to a large value that is at least 10 times the period of any expected VIV. For cases where line motion contributes to VIV it might be harder to achieve these factors of 10, in which case it will be necessary to compromise by setting the filter period to a value about half way between the two periods.

Warning: | Note also that with the Milan wake oscillator, if you set the filter period to infinity or a very high value, then the node mean position used by the wake oscillator will remain at the node's starting position found by the static analysis. In that case it is important that the line uses full statics, since otherwise that starting position might not be a sensible mean position for the Milan wake oscillator model to use. |

The following data can be set for each section of the line. A node at the junction between two sections uses the data for the higher numbered section.

The VIV diameter specifies the diameter used by the VIV model. Separate values can be specified for each section. The value specified is used for all nodes in that section. For a node at the intersection of two sections the VIV diameter of the following section is used. The VIV Diameter can be set to '~', which is taken to mean 'same as the section normal drag diameter'.

You can control which sections of the line the VIV model is applied to. A time domain VIV model analyses a single point on the line: OrcaFlex must therefore create one instance of the VIV model for each node in each of the enabled sections.

You can use this switch to disable VIV modelling in regions of the line where you think VIV excitation is not significant, for instance

- if the normal component of flow velocity is not significant, or the incidence angle is near to being tangential
- if there are VIV suppression devices (e.g. strakes, fairings) and you believe they will be effective

The vortex tracking model, in particular, is computationally intensive, so you may well speed up your simulation by disabling VIV modelling where possible in this way.

Only available for the wake oscillator models. The inline component of drag is multiplied by this value. The data can be specified as a variable data item which varies with transverse A/D, that is the amplitude of transverse oscillation divided by the VIV diameter.

This is not available for the vortex tracking models since they already include the effect of inline drag amplification.

These factors allow you to scale the inline and transverse components of the vortex force. Set them both to 1 to use the vortex force predicted by the VIV model, without adjustment.

If VIV suppression devices (e.g. strakes, fairings, shrouds) are fitted to a section of the line then you could allow for their VIV-reduction effect by setting the transverse force factor to a value less than 1. The device is also likely to affect the inline drag force, so you might also want to allow for this by adjusting the inline force factor. See Barltrop and Adams page 372 for more on this topic.

The inline force factor is not available for wake oscillator models, instead you should use the inline drag amplification factor.

Note: | The transverse force generated by the Milan wake oscillator model is not the whole of the transverse force, since the Milan model requires the transverse component of standard drag force to be added to give the total transverse force. The transverse vortex force factor is only applied to the force generated by the model, not to the transverse component of the standard drag force. |

The time domain VIV models (wake oscillator and vortex tracking) make no allowance for surface-piercing or seabed contact effects. OrcaFlex therefore handles these effects as follows:

- If a node comes completely out of the water, or comes into contact with the seabed, then the time domain wake model is reset. For the wake oscillator models this means that the wake degree of freedom is reset to zero; for the vortex tracking model all existing vortices are removed. If the node later comes back into the water, or breaks contact with the seabed, then the model starts again from that reset state.
- If the node is partially submerged (i.e. the length of line represented by the node is surface-piercing) then the time domain wake model continues to run but the forces it applies to the node are scaled by the node's proportion wet.

For the time domain VIV models, OrcaFlex calculates the following directions:

**axial**: the local tangential direction, given by the node's local z-direction**transverse**: normal to the axial direction and normal to the non-VIV relative velocity vector**inline**: normal to the axial and transverse directions, and therefore normal to the line axis and in the plane defined by that axis and the relative flow direction. It is the direction of the normal component of the drag force (assuming $\C{Dx} = \C{Dy}$)

These directions are used for three purposes:

- The velocity input to the wake oscillator models is the inline component of the non-VIV relative velocity.
- The transverse displacement input into the Milan wake oscillator model is the transverse component of the node position relative to its non-VIV node position.
- The inline and transverse components of the vortex force are available as results.