Is the "Low-Frequency Wave Drift Force Spectral Density" provided by Slowsim defined relative to a frequency range (zero,infinity) or, as is more common in engineering vibration literature, to (-infinity,infinity)?

Slowsim, and the rest of the SeaSoft applications, use a "non-negative frequency" convention. This is because the power spectral density of irregular waves has historically been based on a positive frequency interval (zero,infinity). This is an unfortunate break with vibration analysis conventions where the frequency baseline, as you have noted, is usually taken to be (-infinity,infinity).

One important consequence of this difference in convention is that formulae containing power spectral densities and taken from vibration literature may need to be modified by a factor of two. For example, the important and widely-used expression for the variance of a lightly damped second order oscillator excited by a broad-banded acceleration spectrum Sa(w) is

        variance = pi*Sa(w)/(2*c*w^3).

Here w is the undamped oscillator natural frequency (in radians/second) and c is the system damping constant (reduced to a dimensionless form such that damping in "percent of critical" = 100*c). This formulation assumes that the acceleration spectrum Sa(w) is defined for w in the range (-infinity,infinity). (Ref: Random Vibration in Mechanical Systems, Crandall and Mark, Academic Press, 1963, pp 76.)

To use this formula with a "one-sided" SeaSoft-type frequency convention for which the spectral density is reported as G(w), we must write

        variance = pi*G(w)/(4*c*w^3),

where G(w) is related to Sa(w) by:

        G(w) = 0        (-infinity < w < zero)
        G(w) = 2*Sa(w)  (zero < w < infinity).

Note 1: This definition of G insures that the total input "energy", defined as the integral over all frequencies of G(w), is the same as the integral over all frequencies of Sa(w), which is symmetric about w=0.

Note 2: The variance formula quoted above from the Crandall and Mark volume is to be used with an *acceleration* spectrum Sa(w). In ocean engineering one more often works with a *force* spectrum Sf(w), which is related to the acceleration spectrum Sa(w) by Sf(w) = Sa(w)*m^2, where m is the oscillator mass.

Why does the Z component of wave-frequency net vessel moment (DYNOUT and SNAPOUT) about the turret not vanish in SPMsim?

For wave-frequency calculations the turret is assumed locked to the vessel; the reported Z w.f. moment can be used to estimate if and how much w.f. turret rotation exists if the value of the turret "stiction" and "friction" in the given net load environment is available.

Why does the Z component of quasi-static net vessel moment about the turret not vanish (in SNAPOUT and LOWOUT) when I specify nonzero trim or heel? Doesn't equilibrium require a vanishing Z moment? In SPMsim won't the turret simply turn until the net moment vanishes?

The equilibrium search algorithm for quasi-static turret and/or vessel orientation takes place in a 3-dimensional global space (Gx,Gy,Gyaw). Therefore the condition of zero net turret moment or (vessel moment for Moorsim) relates to the global Gz-direction. In the global system the net moment will indeed vanish as indicated in LOWOUT. When the vessel Vz direction differs from Global Gz (as it does if the deck is not perfectly level), a small nonzero Vz moment appears when net moments are rotated into the vessel deck-vertical system. To fix this problem would require doing a much more complex equilibrium search which would simply not be practical. The moments reported in SNAPOUT are vessel-relative only and reflect this transformation problem in the presence of nonzero trim or heel. Note that this transformation to deck-vertical coordinates affects the reported wave-frequency forces and moments as well.

I have a USERRAOS file with [minimum,maximum] frequencies of [.3142, 1.571] corresponding to [maximum,minimum] periods of [20,4] seconds. My period array is in 1 second intervals from 4 to 20 seconds. I am getting a warning "requested period outside user RAO range". Why?

The [minimum,maximum] frequencies must be slightly [smaller,larger] than the frequencies corresponding to the [maximum,minimum] periods in your array because of possible floating point roundoff errors. For example, make your [minimum,maximum] frequencies [.31,1.6] to eliminate the warning. These same considerations apply to user-supplied DRFTCOFS and WAVSPEC files.

Other user-specified input files that relate only to low-frequency dynamics, WINDSPEC and CRNTSPEC in particular, have a similar restriction. You should always use [minimum,maximum] frequencies which generously bound all low-frequency modes of interest. To eliminate the chance of runtime warnings, we recommend limiting periods of 12 seconds and infinity, corresponding to [minimum,maximum] frequency values of [0.,0.5].

In SPMsim, when I change the initial vessel orientation ("Vessel heading in quiescent conditions"), the program reports that the initial condition is not an equilibrium condition. Shouldn't the vessel rotate freely about the turret?

The fairlead coordinates are always given in the Vessel coordinate system; if a physical rotation of the vessel about the turret centroid is made, this will change the locations of the fairleads (which lie at some distance from the turret centroid) in the vessel system.

To achieve the effect of rotating the vessel without moving the fairleads or anchors, you must also simultaneously rotate the fairlead positions (in the opposite direction and *about the turret center*) so that afterwards they are at the same global position as before the vessel rotation. This can be done rather easily in a three-step operation using automated procedures supported by the SPMsim editor: (1) translate all fairlead coordinates so that the turret center is at (Vx,Vy) = (0,0); (2) Rotate all coordinates by the same angle as the desired vessel rotation (but in the opposite direction); (3) Translate the center of the turret back to its original Vx location.

I sometimes get one or both of the following peculiar warning messages during execution:

 >>> Warning: KCAT, KCATO differ appreciably in FOBLQ (multiple occurrences?)
 >>> Warning: Singular SIGCQ (multiple occurrences?) detected in FOBLQ.

What to they mean? Are they important?

These warnings result from internal consistency checks that occur when the "large-amplitude nonlinear model for w.f. loads" flag is set to "Yes". They are generally unimportant and usually occur when the large-amplitude model is gratuitous. The warnings can be eliminated by setting the "large-amplitude nonlinear model for w.f. loads" flag to "No".

However, any time these warnings occur, it is recommended that at least one comparison between the results from the two algorithms be carried out to guard against heretofore unencountered problems with the wave-frequency line load model. This is particularly important for unconventional mooring leg designs containing buoys, synthetic elements or user-specified static properties.

I am confused about the definition of the direction of the Low-Frequency surge variations as reported in LOWOUT Section V. Is it in the direction of the equilibrium offset, or in the direction of the mean environmental force vector? These are not necessarily the same.

Formally speaking, the direction of the Low-Frequency surge variation is in the direction of the mean offset vector, not the mean force vector. The difference in these directions in any mooring system with at least a three-fold azimuthal symmetry should be *very* slight and well within the overall level of precision of the simulation; in fact, in the limit of small vessel offsets from the zero environment position, this difference is precisely zero.

The damping conversion given by SeaSoft is in the units (m.ton)/(m/s). The SI unit is (kg/s). Am I correct in assuming that the m.ton in your formula is a force? How can I convert your damping number to the SI unit?

The units of a damping constant C are force/velocity (since the damping term in Newton's force balance is C*dx/dt) which reduces to mass/time; a "m.ton" (metric ton) is a unit of force equal to the *weight*, on earth, of a 1000 kilogram mass (about one cubic meter of water). One m.ton is therefore approximately equal to 9800 Newtons (= m*g with m = 1000 kg and g = 9.8 m/s^2). To convert the damping constant from (m.ton)/(m/s) to kg/s, multiply the former by 9800.

I want to disable heading control and in order to do so I set the torsional spring stiffness for heading control to zero. It seems that the answers I get are different from the case without any heading control. Why is this?

The problem is that you have specified a heading-control target but not provided any DP torque to produce it (the torsional spring constant is zero).

The only way a heading-control request can be satisfied with a small or zero torsional spring constant is if the requested heading target is exactly the heading that would exist without any DP control whatever. If you want to disable DP control, this should be accomplished by turning the DP flag off, since a heading target must always be supplied when heading control is requested.

I am running CALMsim and for some reason I am not getting an XCLDAT.stxt file. The editor asks me if I want one and lets me specify the units but there is no file created. I'd like to use the file to estimate the spectral energy of the hawser force.

So sorry, but XCLDAT.stxt it isn't yet implemented for CALMsim.

Note that you can achieve most, if not all, of what you need by hand: use the hawser load variance (RMS^2) and a reasonable bandwidth (depending on both the low- and wave-frequency hawser variances). So, if the hawser RMS load is all LF, use a bandwidth constructed from the low-frequency (LF) damping & the appropriate LF period. If the hawser load is all wave-frequency (WF), use the wave spectrum or vessel surge bandwidth. If it is a mix, construct an appropriately weighted bandwidth that reflects the relative contributions of the LF & WF components. That is, treat the WF and LF contributions as independent.

I have noticed a recurring discrepancy in LOWOUT load values between the "line load snapshots" and the "maximum" (or minimum) storm extreme line loads in crossed conditions. In some cases, the "snapshot" load in a particular line is *greater* than the corresponding "maximum" low-frequency load in the adjacent table. Similarly, the smallest "snapshot" loads are sometimes smaller than the corresponding "minimum" load for the same line. Shouldn't the "maximum" and "minimum" loads in LOWOUT always bound the corresponding "snapshot" loads?

This is certainly the intent of the designations. Unfortunately, in other than aligned conditions, the calculation of "maximum" and "minimum" values are less than perfect, as are the determinations of the "turnaround" points selected for load evaluation and display in LOWOUT. This causes an unavoidable overlap between the results of the two types of calculations required which becomes steadily more noticeable as conditions become more severely crossed.

In aligned conditions, your observation that the "maximum" and "minimum" loads should always bound the snapshot values is correct. In fact, in aligned conditions, the "maximum net mooring loads snapshot" line loads and the "maximum" line loads for the most loaded lines subset will match exactly, as will the "minimum" line loads and the least loaded subset in the "minimum net mooring loads snapshot".

However, in crossed conditions the situation is not so simple. In that case, neither calculation (snapshot or maximum/minimum) is rigorously unique as all three degrees of freedom (as opposed to a single degree of freedom in the aligned case) must be combined for the calculations.

See also the related question below regarding load values in SNAPOUT and RANOUT.

I noticed that the SNAPOUT peak line loads are sometimes slightly smaller than the corresponding RANOUT peak line loads. Shouldn't the SNAPOUT loads be the same, or at least always greater than the RANOUT values?

There should be no differences between RANOUT and SNAPOUT loads for the most-loaded-line(s) in "aligned-environment" conditions where the vessel is directed into the environment. Differences can arise, however, in non-aligned *crossed* conditions, with the potential discrepancies becoming larger with the amount of low-frequency motion reported for the "high-frequency sway-yaw mode". The RANOUT and SNAPOUT load calculation algorithms differ in a fundamental way and this difference is the cause of the apparent discrepancy.

In aligned conditions, vessel "turnaround" points (for SNAPOUT) are well-defined since the low-frequency motion is confined to a single (surge) degree of freedom. In this case, SNAPOUT and RANOUT should agree as both compute the wave-frequency fairlead motions for the most loaded line about the same low-frequency fairlead-anchor offset.

However, in crossed conditions, the situation is murky since the "turnaround" point is no longer well-defined. Out of an infinite set of possible turnaround points, we *chose* to report loads in SNAPOUT at a "turnaround" point associated with the extreme surge degree of freedom offset and a "characteristic" vessel yaw angle. Note that this is analogous to the API "Peak Low-frequency, Significant wave-frequency" procedure for extreme mooring line load estimations. This can result in a slight underestimate of the most loaded line load since the energy in the yaw modes may be underestimated by this procedure. This is a shortcoming that we will try to address in a future software release.

The crossed condition situation in RANOUT is less arbitrary, since if low-frequency degrees of freedom are treated as uncorrelated variables (a whole other bag of worms, of course), you can do a statistical treatment, valid for each line, that combines *all* the low-frequency DOFs, rather than effectively "freezing" one of them (as we currently do in SNAPOUT). This will usually produce a most-loaded-line load *greater* than that given in SNAPOUT since more extreme yaw motions may be represented by this procedure.

There will always be a difference in the way SNAPOUT and RANOUT loads are computed, one doing a purely statistical synthesis of wave-frequency dynamics averaged over the low-frequency phase space motions of the vessel (RANOUT) and the other a wave-frequency analysis taken at a single point in that low-frequency phase space (SNAPOUT).

When modeling a tanker, I use a standard tanker from the "On Line Tanker Model". The tanker property screen mentions "C. Length (LPP)". When transferred to the simulation editor input stream, the same value now occurs in the field called "Length at waterline". Which of these definitions is the correct one?

In the SeaSoft simulations, there is no differentiation between Lpp and LWL. The Lpp from the database is simply used as the waterline length in the simulation. The difference between Lpp and LWL is negligibly small for our purposes.

How is the turret position in SPMsim defined? Relative to the longitudinal center of gravity (LCG)? To the waterplane centroid? To midships ( = Lpp/2)?

We are in a rather gray area here. For SeaSoft simulation purposes, the various longitudinal vessel "centers" are all equivalent. That is, the center of gravity (LCG) is assumed to be at the halfway point between perpendiculars, and at the centroid of the waterplane area, and at the plan-view centroid of the "equivalent box", and...

Of course, all these points are *not* in fact the same for real vessels; however they are close enough that the *huge* simplifications arising from assuming their equivalence is worth the small errors introduced in the various parameters that depend on them (wind, wave and current moments, principally). In unusual circumstances where differences in these "midship locations" seem too large to comfortably ignore, the two most important points are the LCG and the waterplane centroid; the SeaSoft "vessel centroid" can safely be taken to lie midway between these two points.

What is the recommended method for extracting extreme vessel motions including both low- and wave-frequency contributions? I can find the Low-Frequency extreme motions for the vessel in LOWOUT, but I don't know how to extract the combined low+high frequency extreme motions.

The locus of extreme low-frequency mooring centroid positions can be characterized, at least qualitatively, by a closed quasi-elliptical curve in the waterplane. The major axis of the ellipse is defined by the two vessel turnaround "snapshot" positions given in LOWOUT. The minor axis of the ellipse can be estimated by combining the motions transverse to the major axis arising from the two sway-yaw modes (combined as uncorrelated variables) with the vessel at its mean surge offset. Current versions of LOWOUT now characterize the locus of extreme centroid locations, as well as the locus of the "characteristic" (one- or two-sigma variation) locations

Wave-frequency vessel motions are independent of vessel position (but not independent of orientation), so the wave-frequency motions corresponding to the mean position can be used to establish the width of the w.f. band of motions at each point around the elliptical locus curve(s). A statistical summary of all low- and wave-frequency motions (and their combination) is now available in the XCLDAT.stxt output file for SPMsim, Moorsim, TLPsim and Sparsim.

In most of our model tests the wind force is calibrated using parallel conditions. We can produce the specified force in SPMsim for a given head-on wind area using the enhancement factor. For a cross condition however, we have a more difficult problem since we now have 2 degrees of freedom and still only 1 tuning factor (if beam area is also a given). What is the best simulation procedure?

We assume from your question that in addition to the head-on calibration you are also calibrating the wind in a beam-on or crossed condition, with a non-zero tanker angle relative to the wind, and measuring the associated restraining moment in addition to Fx, Fy forces.

If you are using the SeaSoft "barge" model, you have five adjustable variables (x and y wind areas and area centroids plus the enhancement factor). With these five variables, you can match up to 5 calibration values (for example, a head-on force and zero moment in aligned orientation, and an x and y force and z moment at a single oblique calibration angle comprises five calibration numbers that can evidently be used to fix the five adjustable variables).

If you wish to use the built-in OCIMF tanker coefficients, you have only three variables available (enhancement factor and x and y area) and can therefore match only three calibration values (for example, head-on wind force and beam-on wind force and moment).

An alternative method with more flexibility (at the expense of more effort): Prepare a custom set of wind coefficients and do a simulation with "user specified" wind force coefficients (either binary LOWDAT-style or text-based WINDCOFS.txt style). For example, you could print out the SeaSoft version of the OCIMF wind data for your tanker (using Slowsim), put the table of coefficients in a spreadsheet program and multiply the Fx, Fy, Mz coefficients by constant or angle-dependent factors of your choosing. This method will allow you in principal to match any (Fx,Fy,Mz) value at any vessel-relative wind angle. Be careful to review the documentation carefully before undertaking this method; In particular, user coefficients are defined relative to the vessel midships and not the turret.

When I turn on wave spreading and the "use spectral estimates for RMS loads" flag is selected, I find a rather large difference in the reported RMS loads from the (otherwise identical) unspread case. Why is this?

The RMS load calculation when spread seas and the "RMS spectral load" option is selected appears free of algorithmic errors. This was tested by forcing all vessel RAOs to be frequency-independent and the line load RAOs for each wave approach angle to be the same (but still frequency-dependent), thereby mimicking a linear system (to eliminate the complication of the true nonlinear transfer function between fairlead motions and line loads). When this is done, the spread and unspread calculations give the same value in spite of the fact that one represents a sum over many different wave headings and frequencies with different weights for different angles and the other a calculation using a single wave direction.

Therefore, when real vessel and line load RAOs are used rather than the frequency-independent ones used for testing, the differences between spread and unspread "RMS spectral load" values reflect the underlying nonlinearity of the line load model bumping into the linear procedure used in the "RMS spectral load" evaluation. Generally speaking, it is not hard to see why the use of the "RMS spectral load" flag gives smaller RMS loads in spread versus unspread seas; this is because, all other things being equal, the linearization means that the effective line load RAOs for the spread case are smaller than for the unspread case (since they use effective wave heights/fairlead motions associated with only a fraction of the total wave energy and since the nonlinearity generally produces more-than-proportionate load increases for a given increase in fairlead motion). You can see this by increasing the number of angular wedges for the spread sea case with the "RMS spectral load" flag set; the RMS values grow ever smaller as the number of wedges increases. This is simply an artifact of the linearization. It means that if you are going to use the "RMS spectral load" option with spreading, you may want to use the smallest justifiable number of wedges (4 or 6, perhaps). Judgment is clearly in order here.

The "RMS spectral load" procedure has been slightly problematic from the outset. Still, it does serve to protect against the one condition it was designed for: namely, cases in which the RMS line load response at the single frequency (associated with the peak of the fairlead tangential velocity response spectrum) used for the "original" RMS load calculation is anomalously small.

If the RMS value is important, and you must run spread seas, you should run the simulation both ways to reduce the possibility of understating the RMS values. We are hard up against a fundamental limitation of the frequency-domain approach here...

The quadratic roll damping estimates in Shipsim seem to be rather insensitive to bilge keel particulars. Can you explain this?

In *early* versions of Shipsim, quadratic roll damping for vessels with bilge keels was computed, regardless of the keel details (keel length, width, etc.), as if the vessel had perfectly square bilges (i.e., without bilge keels and with zero bilge radius). The physical basis for this early treatment is that to permit drydocking, bilge keels normally do not project beyond the planes formed by extension of the bottom and side vessel surfaces; that is, the outboard edge of an "optimal" bilge keel lies just inside the (imaginary) location of the corner of a square (zero-radius) bilge. This prevents damage to the bilge keels during drydocking. As a result, the large-scale potential flow around the bilges during rolling (and the associated square-law damping associated with eddy-like viscous disruptions of this flow) is qualitatively not too different for a vessel with bilge keels and one with a perfectly rectangular underwater cross-section. The result of this qualitative similarity is that SeaSoft's quadratic roll damping is relatively insensitive to bilge keel particulars.

When I compare the results of a simulation with no current to those of a simulation identical in every way except that the current is on but has zero current speed, I get different simulation results. Why is this?

The correct way to eliminate the effects of current, wind, wave or swell is to turn "off" the appropriate flag for that environmental type. Setting the strength of the environment to zero (zero wind speed, current speed, wave height, etc.) will not produce identical output files and, more importantly, is not guaranteed to produce identical numerical results since the internal tests for the "environment off" condition involve only the environment flag and not the value and thus different paths through the code apply to the two cases (i.e., flag off versus flag on and zero value). In some cases, a zero environment can produce "abnormal termination" (a euphemism for simulation crash). An environment turned off properly (using the appropriate flag) should never cause an abnormal termination.

This general rule applies to all input variables that are controlled in this way by both a flag and a value; for example externally applied forces and dynamic positioning variables.

I have noticed that when I specify the natural roll period and damping that the wave-frequency vessel RAOs no longer depend on wave height as they do when I let the simulation estimate the roll period and damping. Why is this?

All simulations ultimately analyze wave-frequency motions of any degree of freedom as if the vessel was a linear second-order oscillator in that degree of freedom. Nonlinear effects, such as quadratic roll damping in Shipsim or quadratic heave, pitch and roll damping in Semisim or Discsim, are accommodated by either an equivalent linearization or an iterative solution to a nonlinear oscillator model. In either event, when you *specify* natural period and damping for any degree of freedom, the analysis defaults to that of a *linear* oscillator with the specified period and linear damping; hence the RAOs will lose the wave height dependence characteristic of a nonlinear oscillator. It is not possible, in the SeaSoft treatment, to combine user-specification of damping and period with a nonlinear oscillator model.

I am comparing output for two configurations of a moored CALM buoy produced using Moorsim's "mooring feedback" feature. I want to see how the buoy RAOs vary with a change in the fairlead coordinate radii; aside from the fairlead radii, my two data files are identical. In addition, I am hardwiring the period and damping for all six degrees of freedom in this system rather than using simulation estimates for these quantities; therefore all periods and damping are identical in the two cases. The *fairlead* motion RAOs differ (as expected, since the fairlead locations in the two cases differ). It also seems reasonable to expect a change in buoy RAOs due to the differing forces and moments from mooring feedback in the two cases, but the simulation predicts identical RAOs. Why is this?

See the answer to the question above; the same principles apply to the "mooring feedback" condition. Once both period and damping for a particular degree of freedom are set, the simulation defaults to a linear oscillator model for that degree of freedom using the specified period and damping. Therefore the vessel RAOs will be independent of everything else; RAOs *inferred* from the underlying six vessel RAOs (such as the fairlead motion RAOs) will differ if the locations associated with those RAOs differ, as in this case.

I have noticed that the mean and variable wave-drift forces acting on a vessel vary with current, usually becoming larger with increasing current speed. Why is this?

Waves running parallel to an underlying mean current possess, by virtue of that current, greater momentum density than waves of the same wave length and height in the absence of current. By way of analogy, the earth-relative momentum of a bullet fired forward from a moving train is greater than that of the same bullet fired from a platform at the (earth-fixed) train station; when deflected by a solid object, the momentum difference in these two instances results in different forces acting on the deflecting object.

In SPMsim I have a highly asymmetric mooring layout and have noticed some curious behavior: a co-linear environment towards any direction but 180 results in non-zero low-frequency sway-yaw motions. (The 0-180 degree line represents a line of symmetry of the plan-view mooring layout.) Shouldn't the sway-yaw modes always disappear in an aligned environment if the mean vessel orientation is parallel the environment, as it will usually be for a single-point-mooring system?

The development of sway-yaw motions in aligned conditions can be produced by a misalignment of the mean offset direction with the mean vessel heading. This can occur when the mooring layout lacks sufficient symmetry and causes the "surge" motions (which align with the turret offset vector) to produce sway/yaw forces/moments and a coupling to the sway-yaw modes. When the environmental direction is along a mooring system line of symmetry, the offset direction is aligned with the vessel orientation and this coupling disappears, eliminating the sway-yaw excitation.

In Catsim I am working on "continuous equilibrium" offsets of a moored vessel subject to various external forces and moments. I am unsure of the vessel point to which the reported "continuous equilibrium" offsets (Gx,Gy,Gz) apply. Is it the vessel center of gravity, or the centroid of the fairleads or yet some other point? The output documentation does not make this clear.

In earlier versions of Catsim, the point to which the offsets apply was not specified in the output. In all versions, the (Gx,Gy,Gz) offsets are reported at the vessel center of gravity.

When using Catsim's "continuous equilibrium" offset option, the meaning of "Roll", "Pitch" and "Yaw" are clear when these are small angles. What is the meaning of these quantities when the angles are not small?

For small angles, Roll, Pitch and Yaw are defined conventionally as right-hand-rule rotations about the vessel-fixed Vx, Vy and Vz axes, respectively. For large angles, the definitions are more complex and unintuitive as a result of the non-commutativity of large angular displacements (in the language of group theory, angular displacements are commutative in the small-angle limit). We have chosen a large-angle representation that is analogous to the representation for the small-angle case. In particular there is no direct correspondence between the canonical Eulerian rigid-body rotation angles and the Catsim-reported (Roll,Pitch,Yaw) values.

To clarify, first define a vessel-fixed coordinate system with coordinate unit vectors (Vx,Vy,Vz) as usual (x forward, y to port, z vertical). This vessel system, in the zero-offset "equilibrium" configuration (i.e., before external forces or moments are applied), coincides with our "Global" coordinate system. Then the reported (Gx,Gy,Gz,Roll,Pitch,Yaw) displacement is to be interpreted as follows:

1. (Gx,Gy,Gz) represents a rectilinear translation of the c.g. in the Global coordinate system.

2. The "Pitch" angle is defined as *minus* the ARCSIN of the Vx unit vector projection on the global vertical axis (Gz).

3. The "Roll" angle is defined as the ARCSIN of the Vy unit vector projection on the global vertical axis (Gz).

4. The "Yaw" angle is defined as the ARCSIN of the Vx unit vector projection on the global Gy axis.

While experimenting with Shipsim/SPMsim's "vessel speed" capability, I ran the following test: 1) I ran Shipsim with nonzero vessel speed and output RAOs (in deg/deg format). 2) I converted these RAOs to a user-specified USRRAOS file and re-ran the simulation with zero vessel speed using these new user-specified RAOs. When I compared the output RAOs (from the run with user-specified RAOs) to the *original* RAOs calculated with nonzero vessel speed, the RAOs were the same when compared in degrees/degree format (as expected) but they were different when comparing in degrees/meter format. Is this a bug in the simulation? Shouldn't the RAOs be the same regardless of the output format (degrees/degree or degrees/meter)?

The d/d and d/m RAOs *cannot* simultaneously match between two simulations which differ in vessel speed since the conversion factor between these two RAOs involves the wave slope and for a given frequency the wave slope is different with and without the Doppler shift associated with nonzero vessel speed. Since the USRRAOS file requires degrees/degree input format, this is the form that matches your degrees/degree output. Converting to degrees/meter from degrees/degree will produce different RAOs for the two different speed values.

How does SeaSoft treat the effect of current on waves? In the presence of a current, are the specified wave periods relative to the fixed vessel or to a stationary fluid?

The specified period array serves several functions; however, its primary purpose is to provide a numerical grid upon which to evaluate irregular wave spectral integrations. Requested irregular wave spectra are represented internally in such a way that a wave probe stationary with respect to the vessel would "see" the requested spectral properties, including peak period, significant height and wave energy frequency distribution. In this sense, the period array can be considered "vessel-centric" (as opposed to "fluid-centric"). This "vessel-centric" consideration also applies to other wave periods, such as swell significant period.

I notice that when a nonzero vessel speed has been specified, the period array appearing in RAO output tables is labeled "encounter period" and is different than the user-specified period array. What is going on here?

For computational convenience, vessel RAOs are evaluated internally for *wavelengths in still water* corresponding to the user-specified array of wave periods. When there is relative motion of the ship and fluid due to a vessel speed specification, these wavelengths are associated with vessel-relative wave periods different from those input by the user due to the motion-associated Doppler shift. It would possibly be less confusing if the user were asked to specify a *wavelength* array rather than a *period* array since this would be the same with or without vessel-fluid relative motion. However, for historical reasons and for reasons of convenience, wave period specification has retained the central input role.

The "encounter periods" given in the output stream are those periods which would be observed from a vessel moving as requested into regular waves of the user-specified wavelengths (albeit *indirectly* user-specified; see above); vessel RAOs are still ultimately evaluated at the user-specified periods (by suitable interpolation on the "encounter period" array) for the purpose of irregular wave spectral integrations. It would perhaps be less confusing if the internal "encounter period" RAOs were interpolated and output at *user-specified* periods rather than *Doppler-shifted* periods; this procedure may in fact be adopted in a future version of the software.

I am confused by the differing treatment of current and vessel motion by SeaSoft. Shouldn't a vessel moving at 5 knots into a stationary fluid be equivalent to a stationary vessel in a 5 knot current?

This is a very subtle and important point. The quick answer to your question is yes. However, for computational convenience and for historical reasons, vessel speed in the SeaSoft simulations effects *only* the wave-frequency response of the vessel and current effects *only* static and low-frequency forces and motions.

One important point: Any irregular wave specification (peak period and spectral shape in particular) is referred to a vessel-fixed frame (that is, the internally produced spectrum replicates that which would be measured by an imaginary wave probe stationary relative to the vessel); this is a consequence of wave-basin testing practice in which the wave spectrum is usually measured by just such a probe. This situation persists in the presence of a mean current, or vessel speed, or both.

In wave-frequency-only simulations (Shipsim, Semisim, etc.), one cannot specify a separate current. In order to obtain RAOs that would be realized in a wave-basin test with an underlying current, you need to impose a vessel speed which is equal and opposite in direction to the desired current.

In comprehensive simulations (SPMsim, Moorsim, CALMsim, etc.) you may specify *independently* both a current and a vessel speed. The current will be used in the calculation of static current forces and moments and in the modification of wave drift forces. The vessel speed will be used, if specified, for vessel wave-frequency RAOs. Should you wish the RAOs to be corrected for the applied current, you must request *both* the current *and* a vessel speed equal and oppositely directed to the current.

I am preparing a RAOs file for use in SPMsim and noticed that the example given in the manual depicts a monotonically decreasing frequency array (i.e., the first row in the RAO information table is associated with the largest frequency value). Can the frequency array also accommodate monotonically increasing frequencies?

The only requirement is that the frequency array be monotonic. It may be either increasing or decreasing.

I only have access to zero-speed RAOs to use in a USERRAOS file for SPMsim. I want to use the built-in "vessel speed" capability to correct my zero-speed RAOs for vessel motion, however when I attempt to specify a vessel speed value, the program issues a "fatal error" warning preventing execution. Why can't I specify a vessel speed with user RAOs?

When user RAOs substitute for internally-computed RAOs, all responsibility for the correct specification of the RAOs rests with the user, including the effects of vessel speed on the RAOs. Presently, it is not possible to supply zero-speed user RAOs and have the simulation provide a vessel speed correction.

The built-in yaw wave drift coefficients for semisubmersibles appear to be identically zero at all wave periods. Why is this?

Because of the high degree of azimuthal symmetry of semisubmersibles, wave drift yaw moments are very small and highly dependent on vessel specifics; it is therefore impossible to produce a "typical" or "average" set of yaw coefficients that will meaningfully apply to all semisubmersibles. This is in contrast to the surge and sway drift forces, which depend principally on the net column waterline lengths. We have therefore set the built-in yaw coefficients exactly to zero. If you need more complicated characteristics, with non-zero yaw coefficients, you will need to create your own and provide them in a DRFTCOFS.txt file. Note that it is entirely possible to "mix and match" built-in and user-specified coefficients, so that you could use built-in coefficients for surge and sway and supply your own for yaw.

I am not sure what member length I should use for water piercing members. Should the member be terminated at the waterline, or will the simulation "find" the waterline automatically on water-piercing members and compute the hydrostatics accordingly, in which case I can use any length whatever for water-piercing members.

The internal hydrostatics routines "find" the waterline on all water-piercing members and only use the submerged portions in the hydrostatics calculations. Therefore, provided you specify a length large enough to represent a surface-piercing member, you should be OK.

Note, however, that some simulations (Sparsim and TLPsim in particular) simulate vessel pulldown in response to mean offsetting forces. For these simulations, you will need to provide piercing-member lengths which are sufficient to prevent member top immersion in the most extreme possible offset/pulldown configuration, otherwise the simulation will cough up a hairball and issue an informational warning.

I wish to implement a "hollow column" in Semisim or Sparsim; that is, a central column with a substantial moonpool, so that the waterplane area of this column is annular rather than circular. What is the best way to simulate this configuration?

A moonpool will normally not have a significant effect on vessel dynamics for a semi or a drillship because the volume and waterplane area of the pool will be negligible compared to the displacement and waterplane area of the vessel. In unusual cases, or for academic purposes, various corrections for the moonpool can be made, although these are necessarily somewhat approximate as a result of complex hydrodynamics near the moonpool bottom and the natural heave resonance of the moonpool fluid itself, among other things.

The fundamental physical consideration is that the water in the moon pool moves with the vessel for all but vertical motions (i.e., heave for a centrally located moonpool). Thus the moonpool fluid can be considered "frozen", i.e., to be a part of the vessel for all but vertical motions.

The most sensible (and most easily implemented) solution is to model the vessel as if the moonpool fluid were frozen solid, including the moonpool water in all vessel mass and hydrostatic properties *except* the total vessel water plane area (i.e., include the frozen fluid in kg, kb, km, gyradii and displacement values).

Then, if Amp is the moonpool waterplane area and AWPv is total waterplane area for the "frozen moonpool" vessel, you would use (AWPv - Amp) for the "Vessel water plane area" parameter on the "Vessel Hydrostatic Characteristics" editor page. The full plan-view column area (including the moonpool area) should be used for the column specification.

The only downside to this procedure is that the program will issue a hydrostatics warning that the "simulation estimate" for the water plane area differs from the user-specified area. This warning can be ignored; the user-specified water plane area will be used to determine the natural period of heave.

Occasionally, when using the "continuous equilibrium" feature of Catsim on a simple horizontal forcing offset sequence, at large force values the program returns bizarre results, including for example a large yaw offset when a pure surge force sequence is applied along a line of mooring symmetry. At other times, it seems unable to find an equilibrium, again usually for large offsets, in this simple, symmetrical situation. What causes these problems? Are these two situations related? How can an asymmetrical equilibrium result be correct in light of the symmetrical configuration?

One situation commonly exhibits this behavior: When the point of application of the forces in the force sequence is at the center of the mooring pattern (e.g., the centroid of a CALM buoy). In such a situation, there can in fact exist several static equilibrium points for each force, including the obvious "zero yaw" solution suggested by symmetry. This condition also can create various numerical stability problems in the search for equilibria. Catsim does not do a global search for all equilibrium points, but simply reports the first one it finds. Sometimes, particularly at large force values, it casts too wide a net in its search and first finds an unexpected (and unwanted) equilibrium point. In other cases, these extraneous equilibria may be rather shallow so as to cause convergence problems. To circumvent this class of problem, you can "help" Catsim find the desired symmetric equilibrium point by moving the force application point slightly away from the mooring centroid (along the axis of symmetry in the direction of the applied force). Even a very small shift (like .01 ft or .01 meter) will usually suffice. You may need to experiment. Other possible solutions to equilibrium determination failures include a change in any nonessential numerical values, such as the offset increment or a change in the vertical interpolation layer spacing. Such changes cause a slightly different test net to be prepared, and will sometimes alleviate numerical convergence problems. When Catsim completes execution without error notification, you are assured that it has returned only valid equilibrium states, so once you find a "zero yaw" solution at all force sequence points, you will have your desired symmetric solution.

Occasionally, when using the "continuous equilibrium" feature of Catsim on a simple horizontal forcing offset sequence, at larger force values the program reports something like the following:

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 >>> Warning: A vertical translation of amount 41.15
              plus a rotation of amount 33.25 degrees about direction
              (0.,1.,0.) has carried fairlead number 1 outside
              the bounds of the specified vertical interpolation span.
              This may lead to interpolation errors. Consider increasing
              the vertical interpolation span.

 Enter "A" to abort or press [return] to continue:
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

What is the meaning of this? Why has what is essentially a horizontal offset sequence gone so far away from the waterplane? If I hit <return>, usually the program completes without further messages.

This message can always be ignored *if* the ultimate offsets reported by Catsim lie inside its assigned interpolation range, both vertically and horizontally. Occasionally, during the search for equilibria, the program casts too wide a "net" in its search for equilibrium points and will try to evaluate mooring loads at a vessel location/orientation that goes well beyond the range of the actual ultimate equilibrium points.

On the other hand, if the program actually reports offset points that lie outside your interpolation table bounds, you should broaden the range of interpolation.

I am puzzled by the treatment of trim and heel in the simulations. In Catsim, for example, if I set up a simple symmetric moor, say six identical lines at 60 degree azimuthal intervals, and compare a benchmark zero trim/heel case with one identical in all respects except the imposition of a small trim or heel, the anchor distances reported for the two cases are different. What is going on here?

Trim and heel are problematic for many reasons; they complicate immensely the internal calculations, provide very little in the way of enlightenment and produce lots of confusion and problems of interpretation. So the best advice I can give is to avoid them whenever possible. That being said, the simulation begins a trim/heel calculation by creating an internal "bookkeeping" coordinate system, one fixed to the vessel but aligned with the waterplane rather than the deck. The fairleads are resolved into this new system prior to interpolation table calculation. Since the fairleads have different vertical positions before and after a trim/heel application, the anchor distances needed to produce a particular pretension value or angle depend on the trim/heel angles. If you want to evaluate mooring loads with fixed anchors, the way to do this is to use the oblique rotational offset feature in Catsim. Alternatively, for small angles, you can run the zero trim/heel case, obtain the anchor distances associated with this condition, and re-run your nonzero trim/heel problem using these anchor distances to determine your pretension condition, rather than a pretension angle or value. [Note: this procedure works without further "distance tweaking" only for very small angles in which there is no significant geometrical change in the horizontal distance-to-anchor. A trim of 1 degree on a 700-foot long vessel produces a negligible relative shift of 350*(1-cos(1)) = 0.05 feet but the same calculation for a trim of 5 degrees shows a difference of 1.3 feet, which is no longer ignorable.]

I do not understand the difference between the "Global" and "Vessel" stiffness matrix variants in Catsim. Could you explain the differences?

The stiffness matrix documents the *changes* in forces and moments experienced by a moored structure as each of its six degrees of freedom are varied independently and incrementally about some starting point in its six-dimensional configuration space.

In the "Global" variant, the incremental virtual translations and rotations required to define this matrix take place in the "Global" earth-fixed coordinate system, whose x-axis points to global North and whose x-y plane parallels the waterplane. The force and moment variations resulting from these incremental variations are also reported in this global system. Thus, a rotation about the global x-axis will generally not have any relationship to the vessel roll degree of freedom, but will depend on the instantaneous vessel orientation. The "Global" matrix formulation is useful in implementing an earth-bound equation-of-motion model.

In the "Vessel" variant, incremental motions take place in a vessel-bound coordinate system with the x-y plane parallel to the instantaneous deck (x-axis forward) and z perpendicular to the deck. Again, both the 6 DOF virtual coordinate variations and the resulting force and moment variations are reported relative to this body-fixed system. In this system, rotations about x, y and z correspond directly to vessel roll, pitch and yaw motions, respectively. The "Vessel" matrix formulation is useful in implementing the body-fixed "Euler Equations" for rigid body motions.

I have noticed that at some places in the output, for example in RANOUT, you refer to variable load values with a "(+)" modifier. Example: In RANOUT table XI is the column label "Low-frequency Contribution (+)". What does this modifier refer to?

Because of the many nonlinearities in offshore mooring systems (which affect both wave- and low-frequency dynamical behavior), oscillatory variables such as line tensions have different excursions from their mean values on the plus and minus sides of the mean. That is, the nonlinearity prevents any sort of plus/minus symmetry that one would obtain in a linear or sinusoidal-type process. Because the nonlinearities generally make the "plus" side excursions from the mean larger than the "minus" side excursions for mooring loads, and since it is large loads rather than small loads that are of the greatest design concern, we have chosen to display only the "plus" side variability in many circumstances. This is the significance of the "(+)" modifier at various places in the output stream.

In RANOUT it seems to always be the case that the reported "Fairlead Maximum Tension" in the "Storm-Extreme Line Loads" table is equal to the "Mean" plus "Low-frequency Contribution (+)" plus "Wave-frequency Contribution (+)" which occur in the table immediately following ("Estimated Storm-Extreme Line Load VARIATIONS"). The same can not always be said for the anchor loads. Why?

This circumstance arises when you have a nonzero friction coefficient. This is because the amount of friction-related load reduction at the anchor naturally depends upon the amount of line lying on the bottom; thus, the quoted "Mean" load is associated with a different (generally larger) friction correction than the "Maximum" load. The load "variations" given in the tables are uncorrected for friction, which correction is applied as a final step just before output of the "Maximum". "Minimum", or "Mean" line load values. (Friction corrections for line load *variations* have not been offered because their usefulness questionable and because this would require separate variations to be quoted for fairlead and anchor, complicating both the display and interpretation of the summary tables.)

Generally speaking, a nonzero friction coefficient is not particularly useful from the standpoint of understanding the important ingredients in the anchor load analyses. In the most loaded lines, which are generally by far the most important to a design analysis, friction rarely plays a significant role since it is generally small in those lines and its omission is always slightly conservative (since its omission leads to somewhat larger anchor loads). Friction plays no role whatsoever in the current SeaSoft estimates of wave-frequency fairlead loads, although there is in principle a theoretical increase in effective stiffness in each line from the "frozen" section lying on the bottom which is ignored in the SeaSoft analysis. Again, this stiffness increase is far smaller in the important "most loaded" legs since they have the least amount of bottom-resident line. It is for this reason that an adjustment for this friction-related stiffening has not been incorporated into the simulations.

In RANOUT's "one page per line" output (titled "X. Wave-Frequency Motion/Load Statistical Summaries"), the "Maximum Fairlead Tensions" always agree with the values produced in the summary table ("XII. Estimated Storm Extreme Line Loads") near the end of RANOUT. However, the corresponding "Wave-Frequency Characteristic Motions/Loads Summary" in section X does not agree with the corresponding entries in the tabular summaries ("XI. Estimated Characteristic Line Loads"). What is the reason for this difference?

The sections titled "X. Wave-Frequency Motion/Load Statistical Summaries" relate to pure wave-frequency statistical information when the fairlead is at a user-controlled low-frequency offset point. These are the one- (or two-) sigma and extreme low-frequency offset points, depending on user specification. The corresponding entries in the table of section XI is a statistical composite in which the square root of the sum of squares of the low- and wave-frequency variations is added to the mean value to produce the quoted maximum/minimum characteristic line loads. The two different reporting methods are intended to help in the assessment of the relative importance of the low- and wave- frequency components to the total line loads. Furthermore, when a nonzero value has been set for the bottom friction coefficient, the frictional effects (which impact reported anchor loads) are handled differently in the two styles of presentation. In section X the anchor load reduction is computed using the amount of line lying on the ground at the appropriate low-frequency offset point; in sections XI and XII, the anchor load reduction is computed using the amount of grounded line associated with the static catenary which has the same *total* fairlead line tension; that is, mean plus low- plus wave-frequency contribution. See the friction discussion in the previous FAQ item for additional detail.

I have noticed that SeaSoft's "Ensemble Scatter" estimates (as displayed, for example, in section "XII(b) Extreme Load Ensemble Scatter Estimates") always appear to be related by

    Most Probable Extreme (MPE) < "Mean Extreme" < MPE + Standard Deviation

This strikes me as curious; is this always the case? If so, why?

Yes. This is a property of the probability density function of extreme values used in the SeaSoft simulations. This property is a consequence of the assumptions (1) that the crossings of "near extreme" levels (of loads, motions, or whatever) are infrequent and that the statistics of these crossings can therefore be adequately described by a Poisson distribution and (2) that the underlying wave-frequency excitation process (that is, the water surface elevation) is Gaussian. Strictly speaking, these assumptions fail to represent with mathematical rigor the processes of direct interest. Nonetheless, this model provides an extremely powerful and easily implemented way to approximately estimate the extremes and their variability.

In this regard, one very important fact should be kept in mind: with respect to mooring loads, SeaSoft's output stream is mislabeled for reasons of presentation simplicity. What is quoted as the "Most Probable Extreme Load" is in fact more accurately described as "the load associated with the Most Probable Extreme Fairlead Motion". These are obviously not formally equivalent; furthermore, this comment applies to the "mean extremes" and "standard deviation of extremes" as well as the most probable extremes. This treatment is consistent with the handling of other system loads, such as the characteristic "one sigma" and "two sigma" loads which, as thoroughly discussed in the manuals, are *not* what one would obtain from a time history of the relevant load, but rather the load variation associated with the one or two sigma values of the relevant fairlead position variable. The reason for this treatment of loads is that the statistics of vessel motions, both wave- and low-frequency, is in most circumstances considerably simpler than that of the loads, which are related to the motions in a strongly nonlinear and frequency-dependent manner.

I am unsure how the "surge" direction is defined in CALMsim. I am aware that in SPMsim, it is the direction of the mean turret offset from its quiescent equilibrium position. In CALMsim is this direction the buoy offset direction, the Tanker fairlead offset position, or something else?

In CALMsim, the "surge" direction lies in the vertical plane which passes through the *quiescent* buoy centroid and the tanker bow hawser attachment point at its *environmentally-determined* equilibrium point. For symmetrical mooring layouts, the buoy centroid will also fall in or very near this plane and even for severely asymmetrical mooring systems, the equilibrium buoy centroid should rarely lie far from this plane. Therefore, for most practical situations, the two directions can be considered the same.

I am getting one or the other of the following warnings from recently created CALMsim data files:

 >>> Possible System energy-offset synchronization error: Absolute error = .7 ft
 >>> Possible Buoy energy-offset synchronization error: Absolute error = .1 ft

What do these mean? Do I have a problem here, or can they be safely ignored?

These warnings are generated during a routine internal cross-check used to flag possible computational problems. The system potential energy minimum (at the environmental equilibrium) should correspond to a configuration of zero net system force and moment. The energy minimum and force/moment zeros result from completely independent calculations and can therefore be used as a consistency check. In asymmetric moors, when the "surge" direction does not lie in the same plane as the mean buoy offset, the energy minimum calculation is approximate and may not exactly replicate the force/moment zero-finding result. (See also the preceding question.)

This check is also applied in SPMsim, and although the likelihood of a "synchronization error" in that case is much smaller because of its simpler configuration, it may arise in a sufficiently asymmetric mooring layout.

Provided the "Absolute Error" quoted is reasonably small (say, less than a percent or two of the associated mean offset values) this warning can probably be ignored.

I am wondering about the achieved precision of the stiffness matrix output in Catsim. Many of the matrix elements appear to be zero within floating point precision, but others appear to be nonzero and, for example, do not match their symmetric counterparts when using the "symmetrized matrix" option. This is particularly noticeable in the "moment-vs-angle" 3x3 submatrix. Could you comment on this? How can I separate meaningful values from the numerical noise?

Numerical precision issues limit the accuracy of the finite-difference differentiations required for the stiffness matrix calculation. These calculations should ideally be carried out in double precision but are not at present due to compatibility requirements between certain interfacing code modules. Stiffness matrix elements are "noisy" due to this precision problem.

The off-diagonal terms in the moment-vs-angle 3x3 submatrix are the worst offenders. This is because they comprise a sum over all fairleads of up to four products (per fairlead) of the type Rx*Ry*dFz/dz, Ry*Rz*dFz/dx, etc., where for example Rx is the x fairlead coordinate and Fz the vertical force at the fairlead. That is, each individual contribution involves the square of a fairlead distance. For typical applications, these distances can be well in excess of one hundred feet (or meters). The off-diagonal terms therefore require adding multiple floating-point numbers (per fairlead) of size 10^4 to 10^5 over all fairleads. Symmetry requirements dictate that this sum be zero in many cases. Because individual terms in the sum are large, the cumulative numerical "noise" can be very high.

Stiffness matrix elements can be divided logically into three groups: the moment-vs-angle (MvA) 3x3 submatrix, the force-vs-offset (FvO) 3x3 submatrix, and "all the others", which comprise cross terms involving [forces and angles] or [moments and offsets]. Each of these subsets has its own characteristic "size scale", set ultimately by the number of factors of fairlead distance (Rx, Ry, etc.) occurring in each. The FvO terms are the smallest (containing only fairlead distances to the zero power), the MvA terms the largest (containing fairlead distances to the second power) and the "others" are intermediate in size (containing fairlead distances to the first power). The size scale for the MvA and FvO submatrices is set by the largest diagonal element of the respective submatrix; for the "other" subset, the appropriate scale is the square root of the product of the MvA and FvO scales. (See the example below for additional clarification.)

The following "rule of thumb" discussion can help you judge which matrix elements are noise and which are not:

Since a single precision IEEE floating point number has only about 6 significant decimal digits, and since each displayed matrix element suffers numerous roundoff, processing and rotation-related trigonometric insults before being output, something like two of these IEEE significant digits will generally be lost. Therefore, any matrix value less than about 1.E-4 times the relevant "scale" value in the *Raw* Mooring Stiffness Matrix (as opposed to the *Symmetric* representation) is probably noise.

Thus, in the sample below taken from a 650 foot-long Spar, any off-diagonal value in the MvA 3x3 submatrix less in magnitude than about .1E+03 is probably noise and may well be exactly zero since the largest diagonal value in the "Raw Stiffness" MvA submatrix is about .1E+07.

In the FvO submatrix, corresponding "scale" and "noise" values are roughly .7E+01 and .7E-03, respectively.

In the "other" sub-region, corresponding "scale" and "noise" values are about .3E+04 (derived from sqrt[(.7E+01)*(.1E+07)]; see comments above) and .3E+00, respectively.

These "noise" values apply to both "Raw" and "Symmetrized" versions of the matrix, even though the "Symmetrized" matrix always comprises smaller elements. In most practical cases, there will be only a few "non-zero" off-diagonal values found in either representation of the stiffness matrix.

(Aren't you glad you asked this question?)

     >>> Raw Mooring Stiffness matrix in earth-bound system (Gx, Gy, Gz)

| dFx/dx dFy/dx dFz/dx dMx/dx dMy/dx dMz/dx | | dFx/dy dFy/dy dFz/dy dMx/dy dMy/dy dMz/dy | | dFx/dz dFy/dz dFz/dz dMx/dz dMy/dz dMz/dz | | dFx/dPx dFy/dPx dFz/dPx dMx/dPx dMy/dPx dMz/dPx | | dFx/dPy dFy/dPy dFz/dPy dMx/dPy dMy/dPy dMz/dPy | | dFx/dPz dFy/dPz dFz/dPz dMx/dPz dMy/dPz dMz/dPz |

----------------------------------------------------------------------------- Column => 1 2 3 4 5 6 ----------------------------------------------------------------------------- Row | Offset Value = 20.00 ft v

1 -.4965E+01 -.3052E-03 -.6348E+00 0.0000E+00 0.7255E+04 0.2480E-03 2 0.6866E-03 -.5683E+01 0.2441E-02 -.7283E+04 -.4639E-01 0.1099E+03 3 -.6242E+00 0.1526E-03 -.7468E+01 0.1221E-02 -.6902E+02 -.7629E-04 4 -.1530E-01 -.4243E+03 0.2798E+00 -.9725E+06 0.1259E+01 0.1324E+05 5 0.3727E+03 -.1749E-01 0.4224E+02 0.1259E+01 -.9707E+06 -.9562E-02 6 -.2186E-02 -.4371E-01 -.1399E+00 0.5085E+04 -.1399E+01 -.2312E+06

>>> Symmetrized Stiffness matrix in earth-bound system (Gx, Gy, Gz)

----------------------------------------------------------------------------- Column => 1 2 3 4 5 6 ----------------------------------------------------------------------------- Row | Offset Value = 20.00 ft v

1 -.4965E+01 -.3052E-03 -.6348E+00 0.0000E+00 0.3881E+03 0.6485E-04 2 0.6866E-03 -.5683E+01 0.2441E-02 -.4157E+03 -.4639E-01 -.4628E-01 3 -.6242E+00 0.1526E-03 -.7468E+01 0.1404E-02 0.4088E+02 -.7629E-04 4 -.1530E-01 -.4243E+03 0.2798E+00 -.3430E+05 0.1259E+01 0.5421E+02 5 0.3727E+03 -.1749E-01 0.4224E+02 0.1262E+01 -.3231E+05 -.1750E-02 6 -.2186E-02 -.4371E-01 -.1399E+00 0.5797E+02 -.1403E+01 -.2751E+04

I am curious about the "SeaSoft" extreme load algorithm you call the "SeaSoft significant Low; maximum High" algorithm. How does this differ from the A.P.I. algorithm of the same name?

From the relevant on-line help item:

The SeaSoft "n-sigma LF, peak HF" algorithm, like the "API n-sigma LF, peak HF algorithm", assumes vessel wave-frequency motions occur at the "n-sigma" low- frequency offset point, where n is 1 or 2 according to user specification. Storm extreme line load estimates are then produced by combining the peak wave-frequency load estimates with the PEAK low-frequency loads according to a simplified statistical algorithm. The SeaSoft method will produce larger load estimates in the most loaded line than the API method; either will usually produce "most loaded line" peak loads intermediate between the "lower" and "upper" bound algorithms.

I was getting strange results for the hawser load in a particular batch-processed CALMDAT file. Finally I discovered that the RAO's for Surge and Pitch at 2 seconds are reported as "INF"; this was evidently causing the hawser load problem. What causes this behavior?

This is a fairly common occurrence as you push the short period limit ever lower.

Because of the ubiquitous exponentials in wave analyses, it has proven impractical to trap in the code for all possible numerical overflow and underflow conditions (after installing many such traps, we finally gave up; some of the remaining problematic calculations are in numerically intensive portions of the code and installing traps could seriously erode performance).

If you consider the number of 2 second wavelengths required to span a 300 meter foot-long vessel (about 50), you can see how very short waves, when processed in exponentials, can cause numerical exceptions.

Different compilers and floating point units handle over/underflow differently. One "old" Motorola 68k compiler (by Absoft) terminated execution on these exceptions so that one would know when they were happening. Some more recent compilers just chug along, carrying INF's ("INFinities", generated via division by zero) and NAN's ("Not A Number" usually generated by functionally processing an INF), on and on through layers of subsequent calculations to appear finally in the output stream.

In short, there is not much we can do about this. As a general rule, waves with periods less than 4 seconds have little effect on design loads or motions. In our own analyses, we usually use a 4 second period as a lower bound, although for offshore-sized vessels (100 meters or greater) you would most likely be safe with a 3 second minimum period. Since the exponentials involved contain the number of wavelengths spanning the various simulation lengths (vessel length, beam, draft, hawser length, etc.) smaller vessels will evidently tolerate smaller minimum periods without producing over/underflow events.

When running CALMsim (and, less frequently, SPMsim) repetitively in a batch-processing mode, I have at times seen the simulation fail to complete, exiting with the following error message:

        >>> Nonzero IER = 2 in NLNCOR; [RETURN] to continue

What is going on here?

In general terms, this message usually indicates that the estimated low-frequency vessel "upstream" motions (i.e., motions into the mean environment, or "Variations that REDUCE mean environmental offset" in LOWOUT) are so large that the nonlinear energy-offset algorithms fail. This can happen when the following conditions are met:

1. The "bowl" of the energy minimum is very flat near the quiescent equilibrium point (always the case with CALMsim; true for SPMsim whenever the mooring system is very soft at small offsets).

2. The environmental *mean* force is small due to a cancellation of large non-co-linear environmental contributions (from wind, wave, swell and/or current).

3. The *variable* low-frequency forcing is substantial (this will normally be dominated by waves and/or swell).

When all these conditions are met, vessel motions will not be confined to a relatively small region about the environmentally-determined equilibrium, as required by the SeaSoft simulations. Rather, the vessel can be expected to "wander" aimlessly, without exhibiting well-defined normal mode excitations. These large-amplitude excursions would require a nonlinear time-domain analysis to characterize with complete generality.

Tip: Usually, a small aft thruster force applied to the tanker will provide enough stability to limit the amplitude of low-frequency excursions and permit the simulation to carry on to completion. For sufficiently small thruster forces, the predicted loads should be at least qualitatively meaningful. In adopting this strategy, you should experiment with the magnitude of the thruster force and use the minimum value that still permits the simulation to run to completion.

I have noticed a text file named "MORUPWRN" (or VESUPWRN, or SLMUPWRN, etc.) in my Moorsim (or Shipsim, or SALMsim, etc.) working directory. It appears to contain some sort of warning information. What is this all about?

Anytime you open a data file which produces startup warnings immediately following a "M"odify or "E"xecute in the opening splash window (which contains the "Welcome to Shipsim", etc. salutation), the warning messages are sent to both the screen and the appropriate ???UPWRN file to produce a hardcopy record of the messages. These warnings are of many kinds. For example, they alert you to a change in version number between the application that created the data file and the application used to open it; they alert you to a data file that was produced in another simulation; they may include information on data file structural changes between the creating version and the executing version. The ???UPWRN files are not erased until they are overwritten by the next occurrence of a similar warning message scenario, so most working directories will have an old one lying around unless you consciously find and delete it after its creation. They exist only for circumstances in which you are too quick and tricky with the [return] key and wonder, "gee, I wish I knew what those messages that flashed by at startup were all about...".

When I change simulation units from "English" to "metric", I see some numerical values change (like the indicated water density), but not others. Shouldn't changing the simulation units change all numeric values?

The "change of units" selection item on the first page of all editors supports two options: (1) The limited change you note in your question, which is designed primarily to switch units during the Creation of a wholly new data file, and (2) a comprehensive conversion utility that can be used to convert an entire data file's units from metric to English or vice versa. See the online help for details.

When running Shipsim, I receive error messages of the type:

 >>> Suspicious equivalent box; check data file and retry

What is the meaning of this?

One of the more difficult problems for Shipsim is obtaining an internally consistent set of hydrostatic data. Shipsim builds its "equivalent box" using the supplied displacement, longitudinal and transverse metacentric heights (KML and KMT). It cross checks the estimated box dimensions against various other supplied data such as the waterplane area. If Shipsim finds an unreasonably large discrepancy between, for example, the supplied waterplane area and the equivalent box Beam*Length, it issues this warning.

Usually, the cause of the problem is physically questionable values of either KML or KMT or both, which for a variety of reasons are often estimated incorrectly in a "first look" at a new vessel.

You might consider using the built-in "tanker database" with your desired ship displacement in order to get an idea of reasonable and internally consistent values for KML, KMT and waterplane area (and, for that matter, other variables such as KB, KG, gyradii, etc.). Using this information as guidance, you should be able to arrive at physically reasonable values for any problematic input variables.

If I allow the simulation to compute a vessel pitch damping on an initial run, then re-run exactly the same simulation with no changes other than specifying the pitch damping percentage which was output in the initial run, the reported pitch RAOs and significant pitch from the second are noticeably different. Since the reported pitch period and damping are the same, why do the motions differ?

The reason is that the internal pitch damping model is frequency dependent. The reported damping at pitch resonance of course applies only to motions at the natural pitch period; motions at other wave periods are associated with other internal damping values, which fact can only be inferred by looking closely at the RAOs.

Since resonant damping (at least for pitch and heave) is generally higher than the frequency-dependent pitch damping at longer and shorter periods (which damping, for example, goes to zero in the long- and short- period limits), a user-supplied damping value as a rule produces larger effective damping (and lower motions) when averaged over the wave spectrum.

With user-supplied damping, there is no frequency dependence; the supplied value remains equally effective in reducing motion even in the long- and short- wave limits.

You might have noticed, in particular, that the pitch RAOs for each of your paired set of runs were slightly different at all periods except one: the period closest to pitch resonance, where they are *identical*. This brings up another subtle point: the reported pitch damping is not actually the damping at pitch resonance, but the damping at the period whose value in the selected set of periods is *closest* to the pitch resonance period. This could be an issue if your period grid was very coarse and the frequency dependence was strong...

These comments apply to heave and roll, as well.

I am having difficulty setting the tendon length in TLPsim. Because the tendons are so stiff, *very* small changes in length correspond to *large* changes in top tension. Getting the tension, length and distance-to-anchor (presumably, zero) correct is therefore problematic. What should I do?

This is what we recommend:

1. Set the "Mean line profile determined by" on editor page 2 to "line tension" and set the line tension array for the tendons to the desired tension value(s).

2. Let the *editor* choose a length that will produce the desired top tension. This is done by using item 21 ("HELP for subline physical property estimates") on the tendon specification page and item 5 on the subsequent Subpage ("Fairlead subline length for specified tautwire tension"). This will compute the unstretched length of tendon required to obtain the requested top tension.

3. Return to page 2 and reset the "Mean line profile determined by" to either horizontal tension component or distance to anchor. For tendons each of these would be exactly zero since they are vertical at quiescent equilibrium. You may also, if you wish, use "Fairlead Line Angle" and set the tendon angle values to 90.

Item 3 is not actually absolutely necessary, but it prevents some runtime warnings that arise from difficulties in handling vertical members and give more cosmetically satisfying output.

I understand how to handle vertical mooring lines (such as TLP tendons, described in another FAQ) but this requires setting the "distance to anchor" or "horizontal tension" values to zero. What if I have a mixture of lines, such as normal catenary risers or flow lines in addition to the vertical tendons?

In this case, the recommended procedure is a bit more complex than for tendons alone, and depends slightly on how you wish to specify the mean line profile in the non-vertical (catenary) lines. The most common (and most problematic) situation is when you wish to specify top tension values for all lines. In that case:

1. Set the "Mean line profile determined by" on editor page 2 to "line tension" and set the line tension array for all lines, including tendons, to the desired tension value(s).

2. Let the *editor* choose a length that will produce the desired tendon top tensions. This is done by using item 21 ("HELP for subline physical property estimates") on the tendon specification page and item 5 on the subsequent Subpage ("Fairlead subline length for specified tautwire tension"). This will compute the unstretched length of tendon required to obtain the requested top tension.

3. Run the simulation and get the estimated horizontal tension components, distances to anchor or fairlead line angles for all the non-vertical lines (in MEANOUT).

4. Re-enter the editor, return to page 2 above and reset the "Mean line profile determined by" to distance to anchor, horizontal tension component or fairlead line angle. For the vertical members (tendons) use zero or 90, as appropriate.

Items 3 & 4 are not actually necessary, but they prevent some runtime warnings that arise out of difficulties in handling vertical members and give more cosmetically satisfying output.

Note: In the case where the mean line profile is to be determined by fairlead line angle, the intermediate simulation run is unnecessary. In that case, after determining the proper tendon lengths in item 2 above, return to page two, reset the "Mean line profile determined by" to fairlead line angle, and input the desired angles for all lines. For the vertical members, the specified angle should be 90.

In Sparsim, I need to simulate three line types: (1) conventional high-tension mooring lines; (2) catenary-style risers; (3) constant-tensioned vertical risers. How is this best accomplished?

The mooring lines and catenary-style risers can be simply treated as two conventional mooring line "types".

The constant-tension risers are tricky, especially since they are vertical at the zero-environment equilibrium. It is generally adequate for simulation purposes to lump all the vertical constant-tension risers into a single vertical line, although this is not a requirement.

Here is one way these lines can be handled:

1. Specify as many elements as necessary to simulate the weight/unit length distribution along the riser (usually this won't make any noticeable difference; the only important simulation parameter for these line types is the riser axial tension at the keel entry point).

2. Set the "Mean line profile determined by" on editor page 2 to "line tension" and fill in the line tension arrays for all mooring lines and risers.

3. Make the vertical riser(s) *extremely* compliant (something like 1,000 times as compliant as an "equivalent" wire rope; the actual compliance value is unimportant so long as it is large enough to prevent significant riser tension oscillations during vessel motion).

4. Rather than specify a length, let the *editor* choose a length that will produce the desired top tension. This is done by using item 21 ("HELP for subline physical property estimates") on the Tensioned Riser specification page and item 5 on the subsequent Subpage ("Fairlead subline length for specified tautwire tension"). This will compute the unstretched length of riser required to obtain the requested top tension when the riser top is "pulled up" to the keel level in the face of the specified large compliance value.

5. Run the simulation and get the estimated horizontal tension components or distances to anchor for all the other mooring lines (in MEANOUT).

6. Re-enter the editor, return to page 2 and reset the "Mean line profile determined by" to either horizontal tension component or distance to anchor. For the tensioned riser each of these would be exactly zero if it is vertical.

Items 5 & 6 are not actually necessary, but they prevent some runtime warnings that arise out of difficulties in handling vertical members and give more cosmetically satisfying output; these extra steps may help reduce confusion.

This method simulates completely the constant-tension aspect of these risers since the high compliance insures that the top tension is roughly independent of vessel motion (we are treating the riser like a highly stretched rubber band). Since the only important physical parameter is the riser axial tension at the keel entry point, this "elastic riser" model works perfectly in the estimation of pitch/roll/surge/sway periods, which is the only measurable influence on vessel and mooring dynamics in practical situations.

How is "The Maximum Loads turnaround" point quoted in LOWOUT.stxt and SNAPOUT.stxt derived from the underlying surge, sway and yaw amplitudes? Doesn't this require some kind of statistical processing?

Yes, you are correct; there are statistical assumptions hidden in these quoted "snapshot" offset point estimates. Without a vastly more rigorous and comprehensive probabilistic treatment than is justified for the purposes of these estimates, some reasonable approximations must be made. This gets muddy, so put on your boots...

For ** Moorsim, Sparsim and TLPsim **, in which the underlying low-frequency normal modes are adequately represented by pure surge, sway and yaw about equilibrium, the statistical synthesis of "snapshot" points is accomplished as follows:

Surge and sway are assumed to be highly correlated. In this case these two lateral degrees of freedom are analogous to those of a simple centrally-restrained mechanical oscillator (a mass with x- and y- restoring springs of comparable stiffness) whose surge and sway natural periods are comparable. The excitation of such an oscillator has a high degree of correlation between the surge and sway degrees of freedom; in the limit that the surge and sway stiffnesses are equal, the correlation becomes perfect and the motion is most conveniently described not as surge and sway of the center of gravity about equilibrium, but rather as the instantaneous radial coordinate and azimuthal direction of the c.g. from the equilibrium point. In this case surge and sway are simply the cosine and sine of the azimuthal angle (the "phase") times the radial coordinate and hence are 100% correlated by definition. Under these conditions, the quoted RMS and peak vessel offset points follow directly from simple vectorial addition of the underlying surge and sway values. Yaw is treated as uncorrelated with surge/sway and the snapshot positions are given at an instant in which the yaw coordinate has its mean, or equilibrium, value.

For ** SPMsim, CALMsim, SALMsim and Towsim **, in which the underlying low-frequency normal modes comprise the "surge" mode in combination with the two coupled "sway-yaw" modes described in the various manuals, the situation is not quite as tidy, since the correlation of the underlying normal modes is usually nonexistent. In this case, the evaluation of "snapshot" points is accomplished as follows:

The "surge" degree of freedom is assumed to be the dominant contributor to low frequency mooring loads and therefore takes center stage in the proceedings. Surge is in quotes here because, as described in the manuals, the "surge" degree of freedom comprises motions of the mooring center which are not in general aligned with the vessel centerline.

The low-frequency sway-yaw mode, whose oscillation center is generally near the mooring attachment center (tanker turret location or hawser or towline attachment point, all of which will be identified in the following as the "turret location" for brevity) is assumed to contribute nothing to these loads and is ignored, both in load calculations and in computing the various "snapshot" locations.

The high sway-yaw mode, whose oscillation center is generally near the vessel center of gravity, can result in substantial motion of the mooring attachment point and cannot be ignored. If the environment is such that the vessel centerline and the turret offset from quiescent equilibrium are substantially misaligned, the high sway-yaw mode produces turret motions in the turret offset plane (which is the plane of the "surge" motions and is referred to here as the "surge plane"), thereby adding to the motions produced by the dominant "surge" degree of freedom. These two components of motion in the surge plane (surge and high sway-yaw) comprise statistically uncorrelated contributions to low-frequency motions of the turret which are directly reflected in low-frequency mooring load variations.

Since the surge and high sway-yaw contributions are uncorrelated, the RMS snapshot points and loads are computed from the square root of the sum of the squares of the two uncorrelated contributions (i.e., "surge" mode and the component of high sway-yaw lying in the surge plane). The snapshot points are given in the surge plane; that is, motions perpendicular to the surge plane are ignored in this calculation.

The snapshot points associated with peak (as opposed to RMS) motions are more problematic: because a considerably more comprehensive probabilistic analysis requiring a greatly expanded computational load would be necessary to completely characterize the statistical relationships between the contributing components, we have resorted to a useful, if simplistic, approximation in arriving at our peak load and offset point estimates. Specifically, the peak loads snapshot point is defined as that point <<lying in the surge plane>> determined by the sum of motion from the "surge" mode plus *twice* the RMS contribution from the component of the high sway-yaw mode lying in the surge plane. This procedure mimics, at least superficially, the API "Peak low-frequency, two-sigma high frequency" rule for estimating a peak net load from its low-frequency and wave-frequency components.

Wave-frequency seakeeping simulations such as Shipsim output only "significant" values for 6 degree of freedom motion variables such as wave-frequency heave, surge or pitch. How can I obtain the "maximum" values?

Wave-frequency motion/velocity/acceleration peak values can be assumed to conform to a Raleigh distribution (this is not the case for loads or for low-frequency motions).

Therefore, "significant" single-amplitude values are just twice the RMS values and the "maximum single-amplitude values (most probable extreme value in a series of N wave cycles) is

 (RMS_value)*sqrt(2*ln(N)).

So, in 1000 wave cycles, a significant single-amplitude heave of 5 m has a most probable single-amplitude maximum value of

 (5/2)*sqrt(2*ln(1000)) = 9.3 m

You should use the spectrum peak period and desired duration in computing the value of N. Very often, a "generic" value of 1000 cycles is used (from whence is derived the famous factor 1.86 = .5*sqrt(2*ln(1000)); this represents about 3 hours worth of 11 second waves).

I understand how to obtain maximum value estimates for pure wave-frequency motion variables such as heave or pitch of a freely floating vessel. How do I obtain the "maximum" values for variables, such as surge, for a moored vessel whose surge comprises both wave- and low-frequency components?

Estimating a maximum value which has *both* a wave-frequency (w.f.) and low-frequency (l.f.) component, like the surge of a moored vessel in waves, is more complicated than the wave-frequency calculation and cannot be done rigorously using only output from the SeaSoft simulations, although it is easy to arrive at a rigorous upper bound.

For an upper bound, simply add the maximum l.f. value (from LOWOUT) and maximum w.f. value (as discussed elsewhere) together.

Other estimates, such as the lower bound, involve a certain among of engineering judgment; our recommendation is to find the largest maximum motion contribution (l.f. or w.f., depending on circumstances) and add to that maximum the RMS of the remaining contribution to obtain a lower bound for the maximum combined motion.

Usually, the maximum motion contributions are l.f., (almost always the case in deep water), and in such cases a suitable lower bound rule would be: add the maximum l.f. (from LOWOUT) and RMS w.f. (as discussed above) values together.

An intermediate approach that many users advocate in order to produce a *single* numerical estimate for a combined maximum value (rather than separately computing both upper and lower bounds) is to add the *maximum* l.f. value to the *significant* w.f. value (at least in cases for which l.f. motions dominate).

Moorsim (as well as other "comprehensive" simulations) has the capability of calculating the low frequency response due to a fluctuating wind and/or current using by specifying a speed variation "spectral density value". I am confused by this term (using English units this quantity appears as ft^2/sec). What does the current speed variation spectral density value mean? Shouldn't it be of the form S(w), where the units are (ft/sec)^2/(rad/sec) and w is the frequency in rad/sec? Can you clarify?

You are quite correct. The units of a speed spectral density are

    [speed squared]/[radians/second]

We often write, for brevity,

    [(ft/sec)^2/(rad/sec)]  --> [ft^2/sec]

because "radians" are formally dimensionless.

The simulations request either (1) a single number S(Wn), where Wn is the natural surge period of the system, or (2) a flow speed spectral file (i.e., CRNTSPEC.txt or WINDSPEC.txt) with spectral values across a range of low-frequency spectral points. The latter option can be used to ensure that different spectral values are used for each of the three low-frequency modal periods (such as the surge and coupled sway-yaw normal modes for SPMsim).

There is very little oceanographic data available on current speed spectra. Could you provide some guidance on how to estimate these? Similarly, is there any way to estimate current spectral densities from wave basin data when only the RMS current values are reported?

This is pretty treacherous stuff and quite dependent on the physical circumstances producing the current fluctuations. You should always try to get measurements for these spectral values, but it is useful to see how the spectral values are related to the underlying physical quantities. To get your thinking started, consider the following crude but interesting physical model:

One common source of current variation is the formation of eddies due to a mean current flowing past an irregular boundary (for example, think of an along-shore current flowing down a rough coastline). Here, there will be eddies of all sizes, corresponding to the infinity of roughness scales present in a natural coastline (which roughness forms a "fractal continuum" of size scales). The mean speed of eddy transport is the mean current speed. The mean speed of the circulating current within the eddy, viewed in a frame co-moving with the center of that eddy, is also comparable to the mean current speed.

This is a situation which should produce, at any point in the near-shore eddy field, a pretty reasonable (if imperfect) "white spectrum" of current variation with time (arising from the large range of eddy sizes flowing past a point fixed in space). Higher frequency components are produced by the smaller eddys, and lower frequency components by larger eddies.

Now, very high frequency components are of no practical interest since they produce no useful dynamic effects on large systems; rather, the frequency components of interest lie in a band between, say, 0.0 and 2*Wn where Wn is the natural frequency of our lightly damped mooring system. (A 400 second natural surge period in the moor means Wn = 2pi/400 = .016 radians/second.)

We can now construct a rectangular current speed spectrum on the frequency interval (0,2Wn) using the following crude "order of magnitude" argument:

If the mean current speed is V, then from the "eddy" nature of the current variations we would expect the RMS current (Vrms) also to be of order V. Since the spectral variance (the integral over frequency of the current speed spectrum) is by definition the square of the RMS fluctuation, we can obtain an order of magnitude estimate for the current speed spectral value by equating (Vrms)^2 to the variance Sc*2*Wn of our rectangular spectrum, producing the spectral density estimate

 Sc = (Vrms)^2/(2*Wn)

For a 1 m/second mean current and the Wn estimate above, this produces a current spectrum value at surge resonance of

 Sc = 31 m^2/sec.

In the wave basin scenario, a similar approach can be taken to obtain a crude estimate of an "equivalent" rectangular current spectrum, although it should be said up front that there is no excuse for doing this kind of estimate because if the RMS current has been measured, then the current time history was clearly available and a spectral analysis of that history is obviously superior to any order-of-magnitude estimate we can cobble together.

That said, since the RMS value of the current fluctuations are known, we only need to estimate the "bandwidth" 2*Wn in the formula above to be used in the wave basin environment. This can be done using the mean current speed V and a characteristic minimum length scale of the basin current production system (including vanes, thrusters, jets, basin geometry, etc.). Typically, this length scale is an order of magnitude smaller than the basin size (e.g., about 1/10 to 1/20 of the basin width). In prototype scale the basin is perhaps 10-20 times wider than the tested objects, so a reasonable length scale is the prototype width of the tested object. For an FPSO this might be 50-100 meters. In a 1 m/sec mean current, a 100m length scale translates to a frequency of about .01 hz or a circular frequency of about .0015 rad/sec. For an RMS current measurement of .1 m/s, the formula above (with Vrms = .1 m/s and 2*Wn = .003) gives:

 Sc = 3 m^2/sec.

You say that the various mooring systems may be approximately represented by narrow-banded processes when computing low-frequency responses from variable wind, waves and current. For lightly damped systems this should definitely yield good results. However, in Gulf of Mexico loop current cases, where the damping due to current might be 30 - 40 percent of critical, wouldn't this approximation be invalid?

Your analysis is basically correct. Our treatment is formally limited to systems with a narrow-banded response (or, equivalently, to lightly damped systems) in cases that the excitation spectrum is *not* "white". However, most current spectra will in fact be quite flat near the long periods of interest. Furthermore, it is an interesting (and little-known) fact that SeaSoft's narrow-banded analytical result is exact, *regardless of damping level*, provided that the excitation spectrum is "white", i.e. the same for all frequencies. Since most current spectra will usually exhibit a reasonably white spectrum across the frequencies of importance, the SeaSoft approximation is far, far better than you might expect.

The upshot is that I wouldn't worry about the "narrow-band" approximation, especially in light of the many other limitations to the analysis.

I would like to be able to do a static mooring analysis for a single point moored vessel attached to a hawser. By this I mean a single line (the hawser) connecting the vessel to an earth-fixed endpoint, such as a dock or a permanent offshore platform. Catsim has the property of selecting whether we want a hawser or not, but I cannot figure out how to use it. How should I proceed with Catsim?

The Catsim feature is specific to calm-hawser systems where the calm buoy has its own set of mooring lines and the tanker is attached by an additional line (the hawser) to the buoy.

For a single mooring line to a fixed terminal as you have described, that option is not relevant. Just use Catsim with a one-line system.

I would like to do a dynamical analysis of a vessel attached by a single line (a hawser) to an earth-fixed endpoint, such as a dock or permanent offshore platform. How do I simulate the placement of the "anchor", which is above the waterline in my case.

Simulate a single-line system and tell the program that the bottom is "transparent" to the line. Then, set the anchor "depth" so that the terminal end of the hawser is at the correct vertical location. That is, for a terminal mooring point on a dock 10 feet *above* the water surface, the anchor "depth" would be -10 feet (i.e., negative numbers for points above the waterline).

I have attempted to reproduce from scratch (1) the fairlead-anchor separations for RMS and extreme low-frequency line loads, and (2) the "snapshot" vessel positions given in LOWOUT by Moorsim. I have so far been unable to understand how these are computed. Can you discuss this further?

In Moorsim, the vessel surge sway and yaw degrees of freedom are treated as the normal modes of the system. This is not always rigorously the case, although it is usually "close enough" for spread-moored vessels of all types. Note that this circumstance (i.e., surge, sway and yaw being normal modes) does *not* require azimuthal symmetry of either the restoration (mooring) matrix or mass matrix. It does however require that the mooring and mass matrix be diagonal when resolved with (surge,sway,yaw) as normal coordinates. This is, as they say, "usually the case" (except, when it isn't :-). So the normal mode summaries in LOWOUT are unequivocal, applying as they do directly to the identified normal mode.

A correlation question arises when you need to *combine* the three degrees of freedom to establish either individual fairlead locations (for individual line load estimates) or vessel centroid locations (for vessel snapshot estimates). In order to provide estimates for vessel centroid motions and line load variations, Moorsim currently assumes that the surge & sway are 100% correlated and that the LF motion arises predominantly from a single excitation (usually, waves). It further assumes that yaw is totally *uncorrelated* with surge and sway. This means that for oblique excitations, such as those at a 45 degree angle, the resulting motion is assumed to be an approximately linear oscillation along the line of action of the exciting force. This simplified picture is clearly compromised by a strong mass and/or mooring asymmetry coupled with an oblique excitation direction.

Moorsim's combination method is (more-or-less) rigorously valid in the limits of:

(1) purely head-on excitation

(2) purely beam-on excitation

(3) arbitrary excitation directions provided the vessel has azimuthal mooring and mass symmetry (or, more generally, if slightly less rigorously, azimuthal natural period symmetry, meaning that the surge and sway natural periods are the same).

To the extent that at least one of these three conditions is *not* satisfied, the combination process employed by Moorsim can be viewed as a "smooth matching algorithm" that "interpolates" between the situations in which it is rigorous to approximately deal with those in which it is not. Errors thus introduced are probably tolerable, but this has not been quantified.

Some additional specifics of the combining algorithms:

>>> RMS line load levels:

RMS levels of all motions are estimated as the square root of the sum of squares of the various contributions.

>>> Peak line load levels:

When evaluating "extreme" LF fairlead excursions for the maximum line load tables in LOWOUT, Moorsim uses an API-type synthesis: The maximum fairlead excursion estimate is taken as the maximum excursion produced by the (correlated) surge and sway motion, enhanced by the "two sigma" motion associated with the (uncorrelated) yaw DOF. This is a non-rigorous treatment whose main asset is that it is subjectively inoffensive and probably can't produce a horribly bad estimate under any reasonable circumstance.

When evaluating vessel position for the snapshot evaluations, the mean yaw angle is used.

I have attempted to reproduce from scratch (1) the fairlead-anchor separations for RMS and extreme low-frequency line loads, and (2) the "snapshot" vessel positions given in LOWOUT by SPMsim. I have so far been unable to understand how these are computed. Can you discuss this further?

In SPMsim, the normal modes of oscillation of the system are called "surge", "high-frequency sway-yaw" and "low-frequency sway-yaw". You should review the physical nature of these normal modes (in the Moorsim/SPMsim manual).

A correlation question arises when you need to *combine* the three normal modes to establish either individual fairlead locations (for individual line load estimates) or vessel mooring centroid locations (for vessel snapshot estimates).

In order to provide estimates for mooring centroid motions and line load variations, SPMsim assumes that only the surge and high sway-yaw modes contribute to fairlead motions. This is discussed in the manual, but basically, for most turret installations with turret near the bow, the low sway-yaw mode comprises yawing motions about a point near the turret, which motions produce very little fairlead motion, at least when compared to the other two normal mode contributions. High sway-yaw comprises yawing motions about a point close to the c.g., which produces substantial lateral motions of the fairleads on a bow-mounted turret. SPMsim further assumes that the sway-yaw modes yaw are totally *uncorrelated* with surge.

Some additional specifics of the combining algorithms:

>>> RMS line load levels:

RMS levels of all motions are estimated as the square root of the sum of squares of the surge and high sway-yaw contributions.

>>> Peak line load levels:

When evaluating "extreme" LF fairlead excursions for the maximum line load tables in LOWOUT, SPMsim uses an API-type synthesis: The maximum fairlead excursion estimate is taken as the maximum excursion produced by the surge mode, plus the "two sigma" motion associated with the (uncorrelated) high sway-yaw mode. This is a non-rigorous treatment whose main asset is that it is subjectively inoffensive and probably can't produce a horribly bad estimate under any reasonable circumstance.

When quoting mooring centroid locations for "snapshot" conditions, the yaw angle used is, again, the "two sigma" high sway-yaw value taken in the most *unfavorable* (i.e., away from quiescent mean) direction.

Does the line drag calculation (i.e., drag due to a mean current profile) include a contribution for line lying on the bottom? Lines perpendicular to the current near a frictionless bottom would "sag" horizontally in the direction of the local current.

No. The drag force acting on lines is assumed to terminate at the touchdown point. This is the only reasonable choice for several reasons, principal of which is that real bottoms are rough (and/or the line is buried in mud or sand) and the mean current acting on bottom-resident line is certain to be negligibly small.

What is the most efficient way to begin a simulation of a new vessel or mooring system. For example, I want to do a complete work-up of a semisubmersible and develop a mooring system for the same vessel.

You are probably best served building your project in phases, especially for more complex vessels like semisubmersibles.

First, troubleshoot the vessel physical properties (using Semisim in your example, otherwise use Shipsim for shipshapes or Discsim for buoys).

Assuming you are working with Semisim and Moorsim, you would work on your SEMIDAT file until you have a clean execution from Semisim for one of your target wave environments. Then copy that SEMIDAT file into your Moorsim directory and fire up the Moorsim editor. Go to the last page (type "L" at any 'Enter Number of Selection' prompt) and select "Import Vessel and environment data from an external file"; at the ensuing prompt, type "SEMIDAT" (without quotes) and press return. The (already debugged) vessel data and environment data will be copied into the MOORDAT editor.

You can now begin to build and troubleshoot the mooring system. Be sure to save your work occasionally (do a "L" to go to last page and from there a "1" to save the datafile and exit; then restart the Moorsim editor and resume work).

Using Shipsim, I am trying to analyze the risk of green water impinging the deck by using the "Relative Motion" option to study the relative motion between the deck and the nearby water surface. However I am not sure I understand the meaning of the output "SIGNIFICANT SINGLE AMP. RELATIVE MOTION" variable in RANOUT. Could you clarify it's meaning, in particular how to infer the occurrence likelihood of green water on deck from these values?

The "relative motion" data is a bit confusing, particularly so because the nomenclature changed at SeaSoft version 5.0. We no longer refer to this variable as the "air gap" because it now applies to horizontal as well as vertical motions; therefore we call it "relative motion", although for your purpose (green water) there is no distinction since only the vertical motion of a point on the water surface pertains to your question.

An amplitude of 2 meters significant for the "Z component" of the relative motion at a point on the vessel means that the vertical distance between that point and the water surface has an RMS variation of 1 meter (1/2 the significant value) about the mean value.

Example: The vessel point in question lies 4 meters above the waterline in still water conditions. Shipsim reports a single amplitude relative vertical motion for this point of 2 meters. The most probable peak relative motion in 1000 wave cycles would then be 1.86*2 = 3.7 meters. Since the mean separation (i.e., the still water vertical separation) was 4 meters, the peak relative wave event would not quite reach the point in question since 4 > 3.7. This calculation establishes the expected level of "green water".

The same considerations apply to horizontal relative motions, except that there the "mean separation" value for X and Y will usually be zero.

One warning however: Shipsim does not take into account the increased amplitude of the waves near the ship due to the reflected wave component. Therefore, the relative motions reported will always be slightly underestimated (although typically only by a few percent for waves approaching the bow; more in near-beam sea conditions where the reflected wave amplitude will be larger).

When I use a DRFTCOFS file produced by WAMIT (or other standard diffraction analysis) in a waves-only FPSO turret simulation, I usually find that the vessel aligns itself with the waves, as I would expect intuitively. However, when using SeaSoft's built-in drift coefficients, I always seem to get a small but nonzero equilibrium angle for the vessel in waves. Can you explain this experience?

For this discussion, call the wave attack angle Theta, with Theta = 0 for bow-on waves.

In the absence of a mean current, it can be shown that for very small wave angles of attack, the functional dependence on Theta of the transverse mean drift force (Fy) for a conventional wedge-shaped forward waterline shape (such as an FPSO tanker) in long-crested waves looks like:

       sin(Theta)*|sin(Theta)|

which approximates in the very small angle limit to:

       Theta*|Theta|.

(Vertical bars denote absolute values.) Therefore, if your DRFTCOFS angular grid is too coarse, *linear* interpolations on Fy (such as those used in SeaSoft's DRFTCOFS processing algorithms) can misrepresent the functional behavior of Fy near a Theta of 0 or 180 (bow-on or stern-on waves) since Fy is in fact quadratic in Theta there.

The upshot is that the Fy contribution to the net turret moment (which contribution is *stabilizing* and attempts to align the vessel with the waves) gets overestimated for Theta near zero when a coarse DRFTCOFS grid is provided to the simulation (since linear interpolation always produces a *linear* Theta dependence, rather than the correct Theta*|Theta| dependence; further, Theta > Theta*|Theta| in the small Theta limit). This causes the Fy contribution to (erroneously) overwhelm the (*destabilizing*) Mz contribution, causing the vessel to align with the wave vector when it should not.

In fact, for waves-only conditions in the short-wave (or "geometrical optics" limit), it can be shown that there is *always* a theoretical nonzero equilibrium angle for wedge-shaped bow forms. This is because Mz is proportional to Sin(Theta) near zero, so the *destabilizing* effect of My *always* overwhelms the stabilizing effect of Fy for sufficiently small attack angle, thereby producing a nonzero alignment angle. (Obviously, for turrets *very* far forward of cg, this equilibrium angle will be so small as to be of only theoretical interest.) To capture these small-angle equilibria, which are in fact quite important (and observable) for turret and vessel parameters relevant to real-life FPSO designs, the DRFTCOFS files should incorporate a tight angle grid near 0 and 180 (like 0, .25, .5, 1, 2, 3, 4, 6, 8, 10, 15, 20, 30, etc.) in order to properly predict the small-angle equilibrium that always occurs in waves-only environments.

Note that SeaSoft's built-in coefficients are analytically formulated (i.e., do not use linear interpolation) and are therefore not subject to this interpolation issue, which is why they always exhibit a vessel heading slightly misaligned with the wave vector of the incident waves.

When I set the "Number of lines for dynamic evaluation" to zero on the "Dynamics-Related Mooring Information" page, I expected the wave-frequency dynamic motions of and loads on the lines to be eliminated. But LOWOUT shows the same value for wave frequency line damping when *no* lines are selected for dynamics as when *all* lines are selected for dynamics. Can you explain this?

The "Number of lines for dynamic evaluation" only applies to the *output stream* of (1) line load RAOs (DYNOUT.stxt) and (2) statistical summaries (RANOUT.stxt, XCLDAT.stxt). Line load damping, net vessel mooring loads, etc., are *always* computed using all lines *unless* you exclude them using the "broken line" database. The "Number of lines for dynamic evaluation" item is only used to "hide" unwanted output; it has no effect on what is actually computed internally.

If you want to eliminate line damping without "breaking" the line, about all you can do is set the target line(s) drag coefficient to zero.

In other simulations I have seen, one can specify values for the tangential drag coefficients for moorings and risers. This option seems to not be available in SeaSoft offerings. Why?

We have looked at this carefully and concluded that the effects of tangential drag lie "in the noise" and have therefore elected to ignore them entirely.

On a related issue, there is a lot of nonsense in this industry regarding the magnitudes of these tangential drag coefficients. We have seen values as high as .65 given for inline drag of moorings based on line wetted areas. This is absurd. Whoever wrote these specs has no idea what (s)he is talking about, as even a casual inspection of an authority such as Hoerner's "Fluid Dynamic Drag" will verify.

I am puzzled by the "Variations that <<INCREASE>> mean environmental offset" in LOWOUT relating to the "low sway-yaw mode" for SPMsim. To what vessel point do these dimensional quantities relate? The turret? Midships?

In SPMsim all dimensional "sway" (a.k.a. "low sway-yaw mode") values are evaluated at "midships". None of the distance values apply to the turret.

The "Total at midship" item just gives the statistical "sum" (defined as the sum of squares, of course) of all the environmental contributions.

In SPMsim there seems to be no output of the *angular* values for low sway-yaw mode amplitudes caused by wind alone (or current alone, etc.) as there is for the "sway" offset at midships discussed above. Why is this?

For the low sway-yaw mode, linear and angular values are simply proportional to each other; they are just two ways of representing the same quantity. Since the *total* low sway-yaw amplitude is given both in degrees of yaw and feet (or meters) of midship offset, any component angular contribution (wind, for example) can be obtained by simply maintaining the proportionality ratio demonstrated by the "totals" and applying that ratio to the wind "offset" to obtain a wind "angle" value.

I want to eliminate the contribution from low frequency system damping arising from wave frequency line dynamics. I can set the line CD values to zero, but this also eliminates the mean current loads on the lines. Is there any way to eliminate the WF line damping without also killing the mean current load on the lines?

Two ideas here:

You can run the simulation to get the full low-frequency modal damping estimates, then subtract out the indicated unwanted line-dynamic contribution, and finally "hardwire" the low-frequency damping to the resulting value in a subsequent simulation run. This will cause some degradation because certain nonlinear modifications, such as square law hull damping calculations, are skipped when you hardwire damping values. (Note: A related issue, the effects of hardwired damping on wave-frequency roll performance, is also discussed elsewhere in the FAQ).

Another method that is a bit more cumbersome, but is perhaps formally more satisfying as it does not bypass the nonlinear response issues mentioned above:

1. Run with normal line CDs; record current damping (hull + lines) and current forces due to lines.

2. Run with line CDs set to zero; record the current damping (which would then be from hull-related forces only).

3. Run (2) again, but apply the line current force as an external force on the moorings; you can at the same time specify the damping amount due to current forces on lines derived from (1) & (2) above.

I notice that Sparsim allows input for "Head-on and Beam-on Centroid from Keel" distances for both wind and current effective drag areas. But other modules such as SPMsim and Moorsim do not have this option. Can you explain?

This parameter isn't relevant except for low-frequency and quasi-static pitch and roll estimates, which are pretty insignificant for ships and semis. This feature may at some point be implemented for semisubmersibles, for which, arguably, it could be detectable in real life.

What current force model do you recommend for a semi? I noticed "SeaSoft Barge" was used in one sample semi mooring problem. But Cylindrical Vessel was used in a SeaSoft TLP benchmark. What do you think would be the most suitable model for Semi?

Historically we used the "barge" model for semis, simply because it seemed most reasonable to us. However, it is obvious from the underwater form of Spars and TLPs that the "cylindrical" model would probably be superior for these vessels since the barge model is *not* azimuthally symmetric (it implies, for example, a 1.414 times greater current force for current from 45 degrees than for bow-on or beam-on currents incident on a vessel such as a square-planform spar with equal "beam" and "length").

Semis are more problematic because of their very substantial and asymmetric pontoon profiles. However, we expect that semis may *also* best served by the "cylindrical" model provided meaningful beam-on and head-on current areas are provided. You should study the on-line help for the "cylindrical" model to be sure you understand how it works. It would probably be more accurate to call it the "elliptical" model since Fx(0 deg) is not necessarily equal to Fy(90 deg).

Note that you can always "build your own" coefficients using CRNTCOFS.txt and WINDCOFS.txt files should you have theoretical estimates or measurements you wish to adopt.

In the final analysis, the choice is pretty much a judgment call since the physically important quantities are not the coefficients but the forces (coefficient times the relevant scale area times the squared speeds). The *best* choice is always an *empirical* representation of the forces, preferably from measurements.

I ran a few cases of the SPAR model in Slowsim and noticed the force coefficients are different for different environment headings. Since the SPAR is cylindrical, the wind or current force coefficient should be the same regardless of the environment headings. Could you clarify and confirm this?

You have probably selected the "SeaSoft Barge" for your wind and current force model, which is not azimuthally symmetric, as you note. You can select instead the "Cylindrically symmetric" wind or current force model, which will do as you expect, or you can specify the wind coefficients directly using a WINDCOFS and CRNTCOFS files.

I've been using Moorsim to analyze a moored semi, and SPMsim to analyze an FPSO. Changing the mooring and riser tensions has no effect on the "Z Displacement" output in MEANOUT.stxt. Where is the "pulldown" effect as we see for spars (in Sparsim) and TLPs (in TLPsim)?

Moorsim (and SPMsim, and CALMsim, and Towsim) assume that the vessel is so large that vertical mooring forces can be ignored with regard to vessel pulldown. This is normally an abundantly generous assumption. The "pulldown" calculation could arguably be extended to Moorsim, especially for semis, but this has not been done; it is rather computationally intensive and adds little of value to the simulation, other than the quasi-static pulldown amounts themselves, which can be obtained by other means (e.g., using the "continuous equilibrium" feature of Catsim).

What does this warning mean and how can I get rid of it? ++> Warning: Mixed "legacy" status flags detected for wave-current, wave dissipation and wave reflection peak load models; this is not generally recommended...

In general this message means you (1) have selected a "2001" wave drift/drag model (tanker or semi most likely) but have invoked one or more of the "legacy" version 5 flags, or (2) have selected a "legacy" tanker/semi with "legacy" flags disabled. The "legacy" flags involved are most likely found amongst these:

  Use "Legacy" current-wave drift force interaction model ... No
  Use "Legacy" peak low-frequency motion and loads model .... No
  Exclude wave absorption damping and excitation ............ No

It looks like Sparsim does not allow multiple wave headings for computing RAOs like Semisim/Shipsim does. Did I miss an option somewhere to make the "Number of wave headings" selection disappear?

Sparsim, like Moorsim, CALMsim, SPMsim, TLPsim, and Towsim, is a wave-basin simulator. You get one environment per run.

If you want *only* wave-frequency RAOs at many headings, etc., as in Shipsim, Semisim and Discsim, you need only import the SPARDAT file (SPARDAT => SEMIDAT) into Semisim and work from there. Similarly for Moorsim/Shipsim, etc.

I notice the wind and current force coefficients required for input to Moorsim, etc., are dimensionless. The data I have are in units of force/velocity^2. What would be the easiest way to input these coefficients without having to figure out the windage area and drag area for all headings in order to convert back into dimensionless coefficients.

You only need the head-on and beam-on wind/current areas to convert to dimensionless units. Look at the on-line help for the "user-supplied WINDCOFS.txt & CRNTCOFS.txt options.

I have no idea how many "interpolation layers" I should use when the simulation recommends the use of "Large-amplitude nonlinear model for w.f. loads". Should I use the maximum possible number?

This is a very subjective matter. You are always safest using the maximum allowable number of layers, but the trade-off is that simulation times increase somewhat and the interpolation output table can become inconveniently large.

For most SPMsim/Moorsim applications, you seldom actually need more than three layers with just enough total layer depth to span the vertical range expected to be swept out by the most vigorously moving fairlead.

Sparsim and TLPsim require more layers in general. In any case, you should err on the side of too many, rather than too few layers. If you have lots of runs to do, you can experiment, beginning with the maximum number of available layers and reduce the number (say, by 25% at each step) until (1) the simulation protests or (2) you detect an appreciable deviation of the output values of interest from your "benchmark" max-layer-number results.

For Semisim member specifications, I am confused by your use of "member dimensions" in the member coordinate system. In your definition, the member coordinate system origin is at member centroid. In that case Mx, My and Mz should all be half of the full dimensions for a symmetrical section. But full dimensions were used in the Semisim manual examples. Please clarify.

The member quantities to which you refer are "dimensions", not "surface coordinates".

In this context the "Member Dimension Mx" of a circular member (whose axis lies along Mz by definition) refers to the *diameter* of the cylinder along the Mx axis, as indicated in the examples, and not one-half the diameter.

Coordinates are only used to specify the endpoints of members, never the dimensional information.

I do not understand the "acceleration" output values in Shipsim; I think that the reported Az (vertical to the deck) is too small. For example, if the vessel heels 10 degrees, the inclination due to roll produces an Az component of 1g x cos(10deg) = 0.985g. In addition, there should be an additional motion due to heave acceleration. Therefore, Az should be even larger than 0.985g. But SeaSoft always outputs much smaller values. Please clarify.

The easiest way to think about this is via an "accelerometer" model. Attach an accelerometer to the deck. Call its output values (Ax,Ay,Az), with z deck-vertical and x forward along the centerline as usual. Calibrate the accelerometer to read (Ax,Ay,Az) = (0,0,0) on a level, stationary vessel, just as you would do in a wave basin or on a real vessel. If the vessel heels statically 10 degrees, the accelerometer will read:

    Ax = 0
    Ay = 9.8*sin(10) = 1.7 m/s^2

The z component is more problematic; its reading is

    Az = 9.8*(1-cos(10))

This is *second order* in the small inclination and is therefore not included in Shipsim's "linear" analysis (which only reports first order quantities, be they motions, accelerations, or whatever). Therefore, the Az values reported by Shipsim arise only from the second derivative of the deck-vertical motion; there is no gravity contribution (since that contribution would be of second order in the motion variables).

On the other hand, the gravitational Ax, Ay contributions are *first order* in the angle and therefore are included in Shipsim's reported accelerations.

To summarize: Shipsim adds the acceleration values at the specified point (i.e., the second derivatives of the displacements) to the inclination-derived gravity contributions. Ax and Ay therefore contain gravitational contributions arising from the instantaneous roll and pitch inclination angles. The Shipsim value for Az is simply the (first order) second derivative of the deck-vertical displacement, and lacks any second order gravitational correction.

Is it possible to use Semisim to get "batch" wave-frequency RAOs for a TLP? There seems to be no mechanism for simulating the effects of the tendons or risers.

You can accomplish this from a TLPDAT starting point as follows:

* Import a TLPDAT file into Semisim (TLPDAT -> SEMIDAT)

* Apply the desired (tendon + riser) tension using the "phantom mass" option.

* Hardwire the heave, pitch and roll periods and damping using the estimates from TLPsim or from another source.

This gives a very satisfactory W.F. dynamic TLP model. The periods have to be hardwired because at this time there is no way to specify the tendon elastic properties in Semisim.

Note that TLP resonant damping is very problematic; attempts to estimate this damping are notoriously treacherous. The best source of information, if you can get it, is a real-life, full-scale estimate based on the *measured* RMS motion spectrum of an existing offshore platform in *measured* wave conditions. Lacking that, you are probably better off applying a "reasonable guesstimate" (a probable range is 5% to 20%).

What is the purpose of the "Utilize ONLY square law driving forces" option in Semisim, TLPsim and Sparsim?

The details of TLP performance can be sensitive to the square-law loading from the orbital motion of water particles in waves. Many issues complicate the simulation of this process, including:

* wave amplitude relative to member size (the "Keulegan-Carpenter" number)

* the effective Reynolds number (usually quantified in oscillatory environments by another dimensionless viscosity variable called "beta")

* member shape (For example, smoothly rounded members can have extremely different "drag" properties in oscillatory flow than rectangular members with sharp corners. This circumstance is quite different from uniform flow, in which the drag coefficients of square and round profiles are not radically different.)

* member roughness

* many current effects, including:

(1) member local flow environment (e.g., is the member of interest in the turbulent down-current wake of another member or in a pristine uniform flow field uncontaminated by upstream structures)

(2) current turbulence

The purpose of the "Utilize ONLY square law driving forces" option is to isolate that portion of TLP wave forcing deriving from square-law effects from those associated with inertial or hydrostatic contributions (the so-called "Froude-Krylov", or "F-K" contributions) or first-order wave radiation damping contributions.

Note that the inverse can also be accomplished: F-K forcings can be isolated by elimination of square-law drag effects by using the "Resonant damping only; no square-law driving forces" option.

What is the reason for the large number (29) of interpolation layers in TLPsim's default "interpolation layer" specification. Is this really necessary?

Tendon interpolation tables are *very, very* sensitive to small vertical displacements due to the extreme stiffness of these structural members. TLPsim utilizes the same "catenary-elastic" load evaluation engine as the other SeaSoft simulations, although it needs to be used with greater care because of the extreme stiffness of the system.

In Catsim's "continuous equilibrium" offsets for a TLP-type mooring, the most loaded line tension value seems to jump around randomly as the offsetting force increases. This looks to be incorrect. What is going on?

As you might imagine, for a very taut member such as a TLP tendon, the interpolation routines are rather sensitive to the interpolation table spacings. Your faulty output stream should have been forewarned by one or more runtime alerts regarding the insufficiency of one or more interpolation grids.

The interpolation arrays are two-dimensional, with a vertical "layered" structure and, within each layer, a conventional catenary-type force-versus-offset substructure. The vertical interpolation step size is controlled by the number of layers, the total vertical span, and the "TLP-style interpolation table" flag on penultimate output specification screen.

The interpolation step size within a layer is set by the number of interpolation points and the (maximum, minimum) horizontal loads specified on the first "mooring definition" page.

For a TLP or other extremely taut system, you should strive to make these interpolation steps as small as physically possible; you should therefore begin by using the maximum permissible number of vertical layers and horizontal interpolation points if you have not already done so.

For "continuous equilibrium offsets", you may occasionally want to make a couple of runs to obtain optimum interpolation step sizes since you will not generally know in advance what the maximum vertical or horizontal excursions will be. However, by running Catsim a couple of times, you should be able to deduce a vertical layer thickness and a range of horizontal loads that eliminate your problematic tension values. Always do your best to eliminate any runtime warnings regarding the insufficiency of your interpolation ranges. Once you obtain an input stream that runs without warnings and produces "smooth" output results, you have achieved Nirvana and will be blessed in the afterlife.

In my deepwater simulations, I seldom if ever see much difference between simulation results for the "SeaSoft Upper Bound Algorithm" and some of the other options (for example, the "API 2-sigma Low Frequency, maximum wave-frequency" algorithm). Why don't you just eliminate some of these options since they all give nearly the same result, within measurement and other engineering uncertainties?

These various options produce the greatest difference in shallow water simulations, where the mooring nonlinearities are more pronounced. Deep water, for purely geometrical reasons, tends to produce fairly linear mooring offset curves, at least for the design quasi-static offset amplitudes. For those situations, it is true that the various line load algorithms produce similar simulation results. We recommend the "Upper bound" algorithm in these circumstances; it will generally (but not always) produce slightly higher loads and therefore constitutes the most conservative approach from an engineering standpoint.

I want to simulate a nonzero wind (or current) moment on a symmetric vessel in a head-on mean flow. What is the best way to accomplish this? (Normally, of course, there would be no moment in such a symmetric situation.)

You have several options. Your choice will depend upon precisely what it is you wish to accomplish. Some considerations:

Do you want the same mean moment to be applied regardless of vessel orientation? Or do you want the mean moment to vanish (and, perhaps, change sign) at some relative vessel-flow angle?

Do you want a variable moment to be associated with the mean moment so as to produce a low-frequency yaw excitation? If so, do you want that variable moment to be dependent on the specified wind velocity spectrum, or independent of any specified flow variability?

Is your mean moment actually the result of a square-law load on an asymmetric appendage (such as a heliport), or is it a "mystery" moment inferred from a wave-basin-observed mean yaw angle in the presence of a head-on wind field flowing past a perfectly symmetric model? In the latter case, the moment is the result of a (possibly undocumented) flow asymmetry of some sort, or the vessel-flow system simply has no stable equilibrium with vessel heading exactly into the flow field.

We will restrict the discussion to a wind-only example for simplicity; identical considerations apply to current-only, or wind *and* current configurations.

1. If the nonzero mean moment is due, for example, to a subtle asymmetry in the vessel that will produce a variable moment in a fluctuating flow field (i.e., in the presence of a wind spectrum), then you can create a WINDCOFS.txt file with a suitable nonzero value at zero flow attack angle (i.e., head-on mean flow). This coefficient will then automatically produce a variable moment whenever a wind spectrum is applied.

2. One of the built-in wind models (such as the "barge", or "cylindrical" models) can be used with a nonzero head-on area centroid. This too will produce a nonzero mean moment and a nonzero moment variation leading to yaw oscillations in a variable flow field.

3. You may apply the mean moment (and specify an unrelated and independent moment variability, if necessary) using the comprehensive "External Force/Moment Specification" capabilities. In this case, the mean moment will not depend on vessel orientation, and you have complete control on the level of moment variability used by the program (including no variability at all despite the presence of a fluctuating flow velocity).

I notice that the RMS surge, sway and yaw motions quoted in LOWOUT's "normal mode" pages for TLPsim are generally smaller than those given in XCLDAT. Why aren't they the same in the two output files?

The "normal mode page" values given in LOWOUT are approximate; they treat the TLP as a simple linear 2-D spring-mass system in the waterplane oscillating about its equilibrium offset. This calculation neglects pulldown and surge-sway-yaw coupling. The calculation in XCLDAT, like the "snapshot load" table at the end of LOWOUT is more rigorous; both these representations take pulldown and coupling into effect. This generally results in less motion (smaller RMS values) than the less quantitative estimates reported on the "normal mode" pages.

Is there a downside to using the "large-amplitude nonlinear model for w.f. loads" in very deep water where the amplitudes of vessel motion are always negligible compared to the water depth?

Yes, the "large-amplitude" nonlinear model can become problematic in very deep water. It is best to turn this option off unless alerted by the simulation that the water depth may be too shallow for the linearized model. Still, it never hurts to run both, if possible, and see if any quantities of interest to you change significantly.

How is the pitch/roll moment for spars and TLPs related to the vertical current centroid and current areas specified for these vessel types? Shouldn't the current profile and the vessel particulars completely define these quantities? So why specify them at all?

Your statement is really true for all vessel types. However, for many reasons we consider it safer to let the user specify the current forces and moments with a few simple parameters. Here is how they are used:

(a) An "average" squared current (v^2) is computed using the specified current profile with depth. This is not weighted with variable vessel beam (as you might have with an "hourglass" spar, for example, or with the complex pontoon/column profiles of a semisubmersible), but assumes an average, constant beam whose value equals the specified current area divided by the specified vessel draft.

(b) The current coefficient angular dependence is determined from the user-specified model.

(c) The net force is computed from the product of the specified area times the average current (a) above, times the current coefficient (b) above, and, of course, the appropriate constants.

(d) The pitch/roll moments for spars and TLPs are derived from the user-specified Z centroids times the net force computed in (c) above.

This gives the user the ability to get exactly what they want, rather than having the program do what it thinks they want and getting it wrong.

I wonder about the documentation for the mooring stiffness matrix in the Catsim OFFSETS.stxt file. An example:

     >>> Raw Mooring Stiffness matrix in earth-bound system (Gx, Gy, Gz)

              | dFx/dx  dFy/dx  dFz/dx  dMx/dx  dMy/dx  dMz/dx  |
              | dFx/dy  dFy/dy  dFz/dy  dMx/dy  dMy/dy  dMz/dy  |
              | dFx/dz  dFy/dz  dFz/dz  dMx/dz  dMy/dz  dMz/dz  |
              | dFx/dPx dFy/dPx dFz/dPx dMx/dPx dMy/dPx dMz/dPx |
              | dFx/dPy dFy/dPy dFz/dPy dMx/dPy dMy/dPy dMz/dPy |
              | dFx/dPz dFy/dPz dFz/dPz dMx/dPz dMy/dPz dMz/dPz |

It seems contrary to the usual engineering tradition of "first index for rows, second index for columns". Is the documentation in error (or are you simply contrary)?

We are simply being contrary. Seriously, there is probably an obscure historical reason for this, but we have forgotten it. The documentation accurately reflects the related output tables.

I am confused about the use of the "Peak Factor Multiplier" in the "Auxiliary External Forcing" option. For example, in Sparsim when I attempt to simulate a sinusoidal vortex induced vibration (VIV), which "sway" motions are produced at right angles to a steady current, I specify a Peak Factor Multiplier of sqrt(2) = 1.414 as suggested in the on-line help. Although there are no other environmental excitations in this "sway" direction, the ratio of the RMS to peak values reported in LOWOUT for the sway degree of freedom are not exactly 1.414, but seem to always be somewhat less. Why is this?

You have evidently asked for a rather large VIV excitation, or else your mooring system is unusually nonlinear. It is true that the requested "Peak Factor Multiplier" in this case will always be somewhat larger than the reported peak factor ratio, although in the limit of small oscillations and/or linear mooring system the difference should be utterly negligible.

The concept of a "Peak Factor" relates to linear systems; to the extent that the mooring system is measurably nonlinear, the requested and achieved Peak Factor Multiplier will differ slightly (with the requested always being larger than the achieved) as a result of those mooring nonlinearities.

Regarding the estimated tensions at the anchor: In many SPMsim simulations (also Moorsim, Sparsim, CALMsim), the wave-frequency component of tension is noticeably higher at the anchor than at the fairlead. What is the explanation for this?

Wave frequency load contributions arising from fairlead motions are often greater at the anchor than at the fairlead because of longitudinal strain waves in the line associated with the fairlead oscillation. For this kind of strain wave, the anchor is a fixed point (or displacement wave node, or strain wave anti-node), while the fairlead is a displacement anti-node (or strain wave node). (Recall that the strain is proportional to the spatial derivative of the material displacement along the line tangent.)

For example, a uniform line whose fairlead oscillates at a frequency which produces a longitudinal strain wave with exactly 1/4 wave length between the fairlead and anchor, the anchor load will be *twice* what you might expect from static considerations, while the fairlead load will drop to zero. This becomes very noticeable in deep water. You can explore this behavior using the "line extension" option to see how a constant fairlead motion amplitude affects the fairlead and anchor loads as a function of frequency. In general, you should see the anchor loads rise, and fairlead loads drop, as you increase the frequency of motion from very small values (very long periods).

I have noticed that the "select alternate equilibrium" flag in SPMsim can produce some rather unusual results with exceptionally high forces. What is going on here?

From the on-line help for this flag:

In some circumstances there exist two or more stable equilibrium vessel positions and orientations in the specified environment. These circumstances fall into two categories: (1) situations with crossed environmental conditions in which one of the stable equilibrium points is much more stable than the other(s) and (2) situations such as a tanker moored in a current-only or waves-only environment in which there are generally exactly *two* equally stable equilibria. In the first case, the simulation generally seeks and uses the most stable equilibrium. In the second case, with two physically equivalent equilibria, it has no way to choose one over the other and in fact just selects the first one it finds. Setting this flag will force the simulation to select an alternate equilibrium point. This is useful, for example, when simulating the equilibrium actually obtained in a model-test setup.

When there exists a weak secondary equilibrium, SPMsim will find it if you so instruct it with this flag. The secondary equilibrium will either be of virtually no interest because of its marginal stability (this is the situation you allude to which will generally show very high loads), or it will be an "equivalent" equilibrium (one of two physically equivalent equilibria which the simulation has no method of choosing between). The purpose of this flag is to permit you to access such second equivalent equilibria; it is of no real value when the second equilibrium is grossly unfavorable and physically highly improbable, as in your case.

I have noticed that waves and variable current (or wind) produce qualitatively different low-frequency peak oscillation behavior. For example: In SPMsim if, in the absence of wind or waves, I simulate a strong current whose magnitude and spectrum is chosen to produce the same mean force and same RMS surge as a companion simulation using waves alone, the predicted "most probable peak" low-frequency motions for the two simulations are quite different. In particular, the predicted plus-side peak oscillation in the case of waves is generally *larger* than the minus-side peak oscillation, while the opposite holds true in the case of current. Can you explain this discrepancy?

The apparent discrepancy in response arises from two competing effects: (1) system nonlinearities and (2) differing statistical properties of the two fluctuating driving forces (i.e., variable wave drift force and variable current speed).

Even if the wave height and current speed are chosen to produce the same mean force, and the current spectrum is chosen to produce the same RMS surge amplitude as in waves, the extreme value statistics for vessel motions will depend on the statistics of the forces. Current fluctuations are assumed internally to be (approximately) Gaussian about their mean value, while the wave drift force variations are non-Gaussian (the latter are closely represented by a simple exponential distribution, as contrasted with a Gaussian distribution). The most fundamental consequence of the non-Gaussian nature of the wave drift forces is an asymmetry in the peak oscillations that, even in a *linear* system, produces larger peak amplitudes in the direction of the mean offset than in the direction opposite to the mean offset.

Further, the nonlinearity of the mooring system produces an asymmetry in peak oscillations which favors smaller peak amplitudes in the direction of the mean offset than in the direction *opposite* to the mean offset.

These two competing effects can produce the discrepancy you have noted. Generally, the mooring nonlinearity-based asymmetry dominates wind and current-driven oscillations (which would be *symmetric* for a linear mooring system), while the non-Gaussian asymmetry generally dominates wave-driven oscillations.

I am befuddled by the various line load reporting options. There appear to be a boatload of these, depending on the various choices for the "line peak load algorithm" and the "RMS reporting option":

       API 1-sigma LF, peak HF
       API 2-sigma LF, peak HF
       API peak LF, 1-sigma HF
       API peak LF, 2-sigma HF
       Upper Bound with 1-sigma reports
       Upper Bound with 2-sigma reports
       Lower Bound with 1-sigma reports
       Lower Bound with 2-sigma reports
       SeaSoft 1-sigma LF, peak HF
       SeaSoft 2-sigma LF, peak HF

What is it with all of these? How are they different? What should I use?

You're absolutely right. This is confusing as hell. The variety has grown over time with user requests and the possible combinations, and their effects on the output stream are nearly incomprehensible, even to us.

It is important to realize that the "one-two sigma" flag option has *no* effect on reported vessel motions (either low-frequency or wave-frequency), but only the reported loads.

As for guidance, as a general rule, relatively inexperienced users should use the Upper Bound Algorithm, which usually produces conservative load estimates and will help keep you out of underestimation problems, which can clearly be problematic from a design standpoint. Use either the 1- or 2-sigma flag, depending on your preference or needs; typically designers use the 1- sigma flag when they are targeting fatigue issues, and the 2-sigma flag in other circumstances.

I noticed recently when using the "Full square-law driving force calculation" option in Sparsim that the effective heave damping appears to be *very* small (i.e., SEMIRAO reports a very large heave resonant peak). This SEMIRAO heave resonance peak is definitely not consistent with the heave damping value quoted in SEMISIM. What gives with that?

You are quite right. When the "Full square-law driving force calculation" option is in effect, the *axial* damping contribution of semisubmersible-type members is ignored. That is, it is set to zero internally for member-relative fluid velocities parallel to the "member" axis (the "Mz" axis). This is because the algorithms were designed for long slender members whose axial drag is very small and not generally meaningful or easily computable. Transverse drag is fully accommodated regardless of member orientation relative to the wave field flows. A spar, of course, is basically a single member whose heave direction coincides with the member axis. Hence there is no internal heave damping for the "Full square-law" option.

For example, you can see this if you look at the phase of the Sparsim "Full square-law" heave RAOs: They all have phases of 0 or 180 degrees; i.e., they have no out-of-phase damping component.

The large heave RAO at resonance you found with the "Full square-law" option reflects, essentially, zero resonant heave damping despite the quoted non-zero value in SEMISUM, which value only applies to the *other* options and is printed out for the "Full square-law" option only as an additional point of information.

For Sparsim, you should therefore avoid the "Full square-law" damping option altogether until such time as this matter is revisited and corrected to eliminate the confusion. The issue is actually pretty moot since there is virtually no resonant excitation of heave for large conventional caisson spars because of their long natural periods.

In SPMsim, when I specify a trim or heel, this warning message is issued at runtime:

 ++> Notice: A nonzero trim or heel angle requires adjustment of fairlead
             locations and a separate interpolation table to be evaluated
             for each mooring line. No changes will be made to the input
             file BUT line TYPE assignments in the output stream may differ
             from input line type assignments.

What is the meaning of this?

The purpose of this note is simply is to explain, briefly, why the simulation is producing a separate interpolation table for *every* mooring line, rather than the usual reduced set (which comprises one table for each line *type*, typically comprising many individual lines). You can ignore the message. However, see comments elsewhere in the FAQ on the problematic nature of trim/heel adjustments and our general recommendation to avoid them whenever possible.

The vessel deadweight used in the editor "Help for Tanker-Type Physical Characteristics" Subpage does not seem to be retained from one execution to the next, although it is retained on repeated entries into the tanker help Subpage during a single simulation invocation. For example, if (1) I set the deadweight at 50,000 tonnes in the "Tanker Help" facility Subpage in SPMsim, and (2) I then change the vessel deadweight to, say, 60,000 tonnes on the "Low-Frequency Dynamics Characteristics" page, and (3) then re-enter the "Tanker Help" Subpage, I see the 50,000 I originally input there, not the later 60,000 value. However if I save my datafile changes, quit and re-start the editor and re-enter the "Help for Tanker-Type Physical Characteristics" Subpage, the deadweight is no longer 50,000 tonnes, but has been changed to a number close to the 60,000 I specified on the "Low-Frequency Dynamics Characteristics" page. What is the reason for these inconsistencies?

First note that this behavior is common to all "comprehensive" simulations for which static or low-frequency vessel environmental forcings apply, including Moorsim, Towsim and CALMsim.

The "Tanker Help" facility utilizes local variables for it's operation (as opposed variables saved in the SPMDAT data file ), and it initializes these variables on the first entry to the "Help" routine during a particular simulation session. The initialization is keyed to the datafile displacement value displayed on the "Low-Frequency Dynamics Characteristics" editor page. These local variables are retained during an editing session but are lost when the editor is exited for any reason. The physical values displayed in the "Tanker Help" facility are not passed to the datafile outside that facility unless specifically requested by the user (for example, by exiting the Help facility with the "Z" option, which passes *all* displayed physical variables out to the datafile.)

How should I treat the water in the moonpool and in the so-called "soft tanks" commonly used in the design of caisson-type spars?

It is usually best (and simplest) to include all the water in the moonpool, "soft tanks" and "hard tanks" in the vessel hydrostatic and mass distribution quantities, including KB, KM, Displacement (hydrostatics) and KG, Gyradii (mass distribution). Note, however, that only water which will clearly move with the vessel during its oscillations should be included; water inside a very open truss structure should therefore *not* be so included.

The lone exception to this rule is the waterplane area, which should reflect the "tons per inch"-type hydrostatic resistance due to incremental vessel immersion (i.e., it should exclude any contribution from the moonpool, which is clearly not a part of the waterplane area). This will result in the correct estimation of heave periods and offset-versus-pulldown characteristics. (Note that it is perfectly reasonable to treat the KM's in a manner similar to the waterplane area; that is, to exclude the moonpool contribution to the righting moment variables since the moonpool is a "free surface". This is generally not worth the effort because the waterplane moment of inertia contribution arising from the moonpool free surface is so utterly negligible in most cases compared to the full vessel water plane MOI.)

If any "hard" or "soft" tanks have free surfaces, the free surface effects can be accommodated in the usual way by suitable reduction of the KG.

As indicated above, this procedure assumes that water included in the hydrostatic values is more-or-less completely entrained. This can be a gray area in some circumstances; for example, water in a moon pool is *not* entrained with regard to heaving or yawing motions (although it is, mostly, with respect to the other degrees of freedom). The vertical motion of water in the moonpool is generally not important in effecting overall vessel motions (other than the hydrostatics discussed above) and we recommend ignoring it.

In most circumstances, errors introduced by this simplifying procedure will be small and tolerable. The alternative to the simple approach includes analysis of (sometimes complex) dynamical subsystems (such as the water column in the moonpool) and its coupling to heave, in particular, through obstructions within, or partial blockages of, the moonpool.

So, for most caisson spars, the following simple procedure will produce generously sufficient accuracy:

* Set the simulation "KB" to the KB of the enclosing wetted volume. (Unless the spar has "shoulders" or other irregularities, this is simply one-half of the non-truss column length of the spar; if the spar is uniform in horizontal section and lacks submerged truss sections, this is simply the half-draft.)

* Compute the simulation displacement by adding the dry structure to the entrained water.

* Compute the simulation KG by straightforward combination of the dry structure mass/KG and the entrained water mass/KG.

* Compute the simulation KM from the true waterplane moment of inertia (i.e., excluding any moonpool contribution), the KB and the displacement volume.

* Set the simulation water plane area to the true waterplane area (i.e., excluding any moonpool contribution)

* Include the entrained water in all gyradii calculations (except, possibly, yaw, for which DOF the entrained water may not always be carried with the vessel; the yaw gyradii will obviously be problematic in some circumstances but yaw is also generally of relatively little concern).

* If simulating a model test in which the hydrostatics are separately and independently measured, be sure that the small-angle righting moment

    =  (KM-KG)*Displacement

as computed above matches that obtained in the tests.

I want to be able to resolve the motion of an arbitrary point (e.g., a mooring fairleader) as the vessel undergoes a cg shift and orientation adjustment during "continuous equilibrium" offsets in Catsim. Since the vessel cg offsets are given in the global (Gx,Gy,Gz) coordinate system, and since roll, pitch and yaw are usually referred to a vessel-fixed coordinate system, how can I combine this information to comprehensively determine the location of any vessel point given the (x,y,z) and (roll,pitch,yaw) information from Catsim?

For very small angles of pitch, roll, and yaw (referred to as "P", "R", "Y" below), the fairlead motions you desire can be computed to an reasonable approximation using standard "small angle" rules:

A small-angle "rotation vector" (call it Rvec) is defined which has body-fixed (Vx,Vy,Vz) components (R,P,Y), where P, etc. are expressed in radians. If the target body coordinate 3-vector is called Fvec, it transforms according to

              Fvec  => Fvec - Rvec*Fvec.

Here "*" designates the vector product (or cross product) between the two three-vectors Rvec and Fvec.

For "large" (i.e., non-infinitesimal) values of (P,R,Y), the correct transformation is cumbersome; understanding and correctly implementing it requires arcane transformation tools that are typically addressed in postgraduate rigid-body dynamics courses and textbooks.

For those in need of a general large-angle solution, a spreadsheet is available from SeaSoft to implement a finite-angle transformation based on the Catsim output roll, pitch and yaw variables.

+++ Expanded Large-Angle Discussion

The "roll, pitch, yaw" values as reported in Catsim's "continuous equilibrium" output pages are derived from the orientation of a CG centered, vessel-bound (Vx,Vy,Vz) unit vector triad relative to a globally oriented unit vector triad (Gx,Gy,Gz). As always, the (Vx,Vy,Vz) triad obeys the "right-hand-rule" with: Vx forward (surge); Vy to port (sway); Vz deck-vertical (yaw). Infinitesimal roll, pitch and yaw rotations are by definition associated with pure rotations about the instantaneous Vx, Vy and Vz body axes, respectively.

For large angular offsets, "roll, pitch, and yaw" become ill-defined and the terms lack rigorous meaning. Formally decoding these quantities into coordinate displacements for rotated body points (e.g., mooring fairleads) requires invocation of 3x3 rotation matrices. Those who have studied the Eulerian angles often used to describe rotating solid bodies may wish to review those concepts in a graduate-level dynamics textbook.

Since in most cases vessel rotations are small, the order of application of roll/pitch/yaw deviations in determining vessel-bound fairlead displacements does not matter (in the language of group theory, "infinitesimal rotations commute") and the extraction of rigid-body-fixed point displacements is simple; for large angular offsets (greater than a few degrees) the determination of displacements is much more complicated. However, it is still the case that the complete specification of vessel orientation depends on only three independent angular variables. The SeaSoft finite angle convention uses three large-angle variables (called "roll", "pitch" and "yaw") which tend, in the small angle limit, to the conventional small-angle nautical definitions, to wit angular rotations about the surge (Vx), sway (Vy) and yaw (Vz) body axes, respectively.

Note that the three independent SeaSoft angles can be converted into a set of equivalent independent "Eulerian Angles" (usually referred to as "phi", "theta" and "psi"); the process is straightforward, but startlingly ugly. There is very little standardization in the definition of the Eulerian angles, so we won't attempt to supply definitions here.

Catsim's output stream was created to provide a physically intuitive description of the vessel position and orientation, and was not optimized for carrying out point transformations. That said, it is certainly possible to accomplish the requested goal even for large angles. To do this, you must first form the matrix of the direction cosines for the transformation from (Vx,Vy,Vz) to (Gx,Gy,Gz) discussed above. For this purpose, the notation V1=Vx, V2=Vy, V3=Vz, etc., is adopted (i.e., replace [x,y,z] indices with [1,2,3]).

The direction cosines are nine quantities A(i,j) with i,j each varying from 1 to 3; each A(i,j) value is the cosine of the angle between the unit vectors Vi and Gj (equivalently, A(i,j) is the dot product of Vi and Gj):

       A(i,j) = cos(Vi,Gj).

In the language of transformation theory, the matrix A is "orthogonal" and its determinant is unity.

Assume one wishes to determine the global location of a vessel-fixed point with vessel-bound coordinates Vp(i) after transformation via a Catsim-reported global cg offset of X(i) = [X,Y,Z] and roll, pitch, yaw orientation angles of (R,P,Y). The recipe is:

       Gp(i) = X(i) + {A(i,j)}*{Vp(i)}

Here the {}*{} operation is a matrix multiplication of a 3x3 square matrix (A) and a 1x3 column matrix (Vp). The A(i,j) matrix is structured such that

       (i,j) = (row,column).

Three of the nine components (the direction cosines) of the A matrix are simple and we offer them to give insight into our choice of (P,Y,R) as our independent angular variables:

       A(1,2) = - A(2,1) = + sin(P)
       A(1,3) = - A(3,1) = - sin(Y)
       A(2,3) = - A(3,2) = - sin(R).

Unfortunately, the remaining 6 components are quite complicated and we will not attempt to display them here. A spreadsheet utility to actually carry out large-angle transformations is available on request from SeaSoft.

Note: The use of the sine function above (for the direction *cosines*) is not a misprint.

I am puzzled about the meaning of the "phase" of net vessel loads quoted in SNAPOUT. I usually associate "phase" with an RAO of some sort, yet the data given in SNAPOUT relates to line and vessel load responses to irregular waves and swell. So exactly what does the "phase" of net vessel loads mean in SNAPOUT?

The "phase" estimates in SNAPOUT are provided to give some idea of the timing of net vessel *wave-frequency* loads relative to the underlying waves in a specified environment. This is a very qualitative assessment, as we will discuss further below. The basic idea is that even in fairly broad-banded underlying waves (like waves with a Pierson-Moskowitz spectral signature), individual line loads and net vessel loads are quite narrow-banded (because of the mechanical filtering of short waves by the relatively large vessel and the existence of the vessel heave, pitch and roll resonances). It is therefore useful for limited purposes to treat net vessel loads as a narrow-band process and relate the timing of the vessel load peaks to the arrival of crests of the underlying waves at the vessel centroid. This treatment, to be even qualitatively valid, requires that the underlying wave field comprise a simple, well-defined spectrum with a prominent spectral peak and associated peak period. For more complex excitations, such as wind waves crossed with an independent swell, the definition of a vessel "phase" is highly compromised except in special circumstances, such as a wind wave spectrum and crossed swell spectrum with nearly equal significant wave heights.

>>> Individual line phases

Since mooring loads are in general so nonlinear, it isn't really meaningful to talk of an "RAO", or to associate a "phase" with either individual line or net vessel loads. However, since line loads in regular seas are at least periodic, a "quasi-phase" can be defined by the timing of the (periodic) peak loads, relative to wave crests, in a regular wave field. This is what the "phases" in DYNOUT are all about.

>>> Net vessel load phases in a long-crested narrow-banded wave field

To estimate "net vessel" wave frequency load phases in a regular wave field (such as quoted in DYNOUT), the problem is complicated by the fact that the peak loads in the various lines occur in general at different times; if line loads were sinusoidal this would be no problem since they could simply be superposed to obtain net loads.

In order to obtain qualitative net load timing information in DYNOUT and SNAPOUT, we treat the individual line loads as if they *were* sinusoidal, and add them up to obtain net vessel load data, whose "amplitude" and "phase" therefore have the same qualitative significance as for individual lines (i.e. the "phase" approximates the timing of the peak positive net load event relative to wave crest passage of the vessel centroid). This procedure is probably not too bad for a single long-crested wave field (i.e. irregular waves *or* swell) since the vast majority of the net vessel load almost usually comes from just a few lines whose peak loads are in fact nearly in phase, at least for the nice narrow-banded fairlead motions produced by virtually all long-crested wave trains with a single prominent spectral peak period.

>>> Net vessel load phases in multiple wave fields

In the presence of two or more wave fields (e.g., "wind", and "swell") with differing peak periods, directions, etc., things get murkier still. In fact, since there are now multiple distinct wave fields, the concept of the "phase" of the vessel response is pretty much meaningless, except in very specific circumstances (such as if two wave systems contribute equally to the composite fairlead motions). Similarly, even the "amplitude" of the net vessel loads cannot be meaningfully determined except in special circumstances. So you should use the SNAPOUT data with extreme caution in the presence of two underlying wave fields. (The data in RANOUT, by contrast, always applies to a single, long-crested regular wave component and is therefore not compromised by multiple wave fields.)

For want of a better procedure, we handle the "two wave field" situation in SNAPOUT as follows:

The starting point for each line is the fairlead tangential motion spectrum, which contains contributions from all underlying wave fields (including multidirectional seas, if specified). A "characteristic period" for each fairlead is derived from the ratio of the RMS tangential velocity to the RMS tangential motion, which for a narrow banded process is very near the spectral peak period. Note that with *two* underlying spectral components (e.g., wind waves and swell), the meaning of this period is not as clean as it is with a single underlying wave system; the fairlead spectrum could well be strongly double-peaked so the procedure of treating the excitation as a regular wave of the appropriate period and amplitude, as we do in the case of a single underlying wave field, is somewhat compromised.

Note that there is really not a fundamental problem if all you want is the individual line loads, since they depend principally on the amplitude and characteristic period of fairlead motion, which is unambiguously known (derived from the fairlead motion spectrum).

The problem comes in assigning a "phase" to the fairlead tangential motion in the more complex multi-wave environment, and then in summing the contributions to obtain net vessel loads from the individual fairlead information and assigning a "phase" to the composite vessel loads.

In order to make minimal progress on this front in the comprehensive simulations, we have *assigned* each fairlead peak load phase to be that associated with the fairlead response to the *largest* underlying wave train. Thus, if one or the other of (wind waves, swell) strongly predominate, this procedure should produce pretty good results. When the two underlying wave systems are of roughly equal energy (or SWH) and widely differing directions, the procedure becomes problematic.

This is a fundamental limitation of the nonlinear frequency domain approach. I suppose a formal treatment of all lines as linear might be satisfying, but mixing a linear approach with the very powerful nonlinear wave-frequency load model could lead to undesirable and perhaps unpredictable consequences that I can not foresee. I think that the approach taken here will give satisfactory results in most cases.

To summarize: The net wave-frequency vessel load data, amplitude and phase, (in SNAPOUT) needs to be treated with caution in the case of two underlying wave fields (i.e., wind waves and an independent swell).

I want to carry out a very large number of executions of Moorsim, the only difference between individual runs is the wave direction. Can SeaSoft's offerings be run in "Batch" mode, for example overnight?

Yes; in one case, a user ran and processed output from nearly 100,000 full SPMsim simulations overnight. To do this, you need to run the software from a command line environment (e.g., a shell window (bash, ksh, etc.) in Unix/Linux/Macintosh, or a so-called "console" or "DOS" window in Microsoft Windows). You then create a text file with the commands you wish to execute within the editor. The specific syntax will vary between the various systems, but it is always trivial to set up if you are familiar with console operations. For example, the following line in a "DOS" window will execute SPMsim using the commands found in DO_IT.txt:

      SPMsim < DO_IT.txt.

DO_IT.txt might contain the following 4 lines of text:

      M
      J3
      1
      100
      L
      4

This would cause SPMsim to open the SPMDAT file in the current directory for modification ("M"), jump to page 3 ("J3"), select item 1 for modification ("1"), enter the value 100 for the variable attached to item 1, jump to the last page ("L") and execute SPMsim in "silent" mode ("4"), which will result in no output being sent to the console. You may want to read the online help for the "silent execution" mode to learn more about how that works.

I have several thousand cases to run for a comprehensive mooring system review in Moorsim. When I set up Moorsim for batch running, I can't find a way to eliminate the occasional unanticipated console requests for user intervention, say when an error condition occurs. How can I carry out batch runs without knowing what possible error conditions might develop?

This is what the so-called "silent mode" option is for. See item "4" on the last editor page of any simulation and read the associated online help. If serious enough error conditions are encountered, that instance of execution will terminate, but it will not affect other batch jobs.

This feature, of course, cannot be accessed directly using the website software version; you would need to have an unrestricted local copy of the relevant SeaSoft title.

Is there any way in which I can get the zero up-crossing periods for accelerations at a point on the vessel using Shipsim?

Sorry, no formal way I can think of, short of modifying the code to provide these quantities.

However, note that the zero up-cross period for a "well-behaved" acceleration trace, which we (almost) always have in ocean engineering applications, is just "a little smaller" than that of the predominant displacement contribution (e.g., the average of the heave and pitch up-cross periods for a point on the bow or stern). This difference is proportional to the square of the bandwidth of the process (which goes to zero for a purely sinusoidal signal), so it is quite a modest shift for any reasonably narrow-banded process. In most practical circumstances, then, you will not be far off by using the reported displacement-based up-cross period for accelerations and velocities as well. Note that since a typical dimensionless bandwidth (spectral width divided by center frequency) in these applications would likely be 0.2 or less, the correction to the up-cross period would be .04 (4%) or less; that is, the acceleration up-cross period would be less than 4% shorter than the displacement up-cross period.

Interesting sidebar: Remember that higher derivatives (like velocities or accelerations) are "noisy" (in the signal-processing sense) and will therefore be more uncertain than motions; in fact, the zero up-cross period for the vertical acceleration history of a water-surface point moving in accordance with any of the common wave spectra (Pierson-Moskowitz, JONSWAP, etc.) is actually not even computable due to non-convergence of the required spectral integrals (proof left to the interested student :). This theoretical peculiarity would not however apply to the motions of an extended body such as a ship, for which convergence is achieved by spatial averaging over the lateral body dimensions, and for which the zero up-cross periods of displacement, velocity and acceleration will be very close to one another.

When I run Moorsim in very shallow water (water depth/draft around 1.04), I am seeing the message:

    ++> Warning: A water depth/draft parameter lies outside valid range

What is the cause of this and how can I eliminate it?

You have selected one of the "OCIMF" current force models for your vessel and your water depth/draft parameter has fallen outside the limits for which the OCIMF data is valid. The message can therefore occur in any of the comprehensive simulations (SPMsim, CALMsim, etc.)

For example, when using the "OCIMF '91" data, this message is issued when a full load draft is greater than .95* water depth (Note: The OCIMF data uses full load draft as a parameter even for ballasted cases).

The simulations will do the best they can, by linear extrapolation of the OCIMF data outside the valid range in this case, but you should be aware you are using, in essence, untested current coefficients in that case.

I have noticed when comparing the current loads on lines and risers produced by SPMsim against the identical mooring and riser complement from another software package we use, that SPMsim's values are almost always substantially greater, often being nearly twice as large. Have you analyzed these differences?

We have, and we are confident of our approach to modelling these forces. A complete discussion of this would require a full-blown research paper, but the problem appears to be that every other software package in this industry uses a model for the current loads on slender members that was proposed during the early development of aerodynamic theory; this model has been known for over 50 years to be inappropriate for the Reynolds numbers and flow parameters characterizing moorings and risers, in either the ocean or the model basin. It seems unbelievable, but there you have it; you heard it here first...

Do you account for the difference in "phase" between the various forcing components that comprise the low frequency excitations in producing your peak value estimates? In other words, the most probable peak wind-wave group may not coincide with the most probable peak swell wave group and the the most probable peak low frequency wind gust.

The correct strategy for combining peak events with multiple independent inputs is reasonably well established in communication theory, although the nonlinearity of the underlying processes muddies the water somewhat.

We assume that all components (waves, swell, current fluctuations, wind fluctuations, etc.) are be statistically independent, so there is a small probability, for example, that the extreme wave event will overlap with the extreme swell event and that will produce an extreme response that will be very far out on the extreme distribution tail, much greater than the "most probable" peak response that is given by SPMsim.

You can estimate the probability of overlap to get a feeling for how likely such an event might be: If the extreme wave and swell groups are roughly a minute in duration (4-6 wave cycles), then the probability of overlap in a 3 hour storm is something like 1 in 180. Small, but certainly not infinitesimal.

Also interesting: In the case where swell and waves are in opposition (i.e. come from opposite directions towards the vessel), the (unlikely) overlap of extreme groups at the vessel location would actually result in a *reduction* in the peak responses from what would occur if the groups did not overlap. That is, an improbable coincidence of wave and swell peak groups would result in a statistical anomaly, but SeaSoft's predicted peak factors could *overestimate*, rather than *underestimate*, the peak responses, for that test run in that case.

Of course, if the waves and swell were coming from the same quadrant, the overlap event would produce an anomalously large excitation, and SeaSoft's "most probable peak" estimates would likely be too small.

I need to evaluate the performance of a stand-alone CALM buoy (without an attached storage tanker). In particular, I believe I need to invoke "mooring feedback" to realistically determine buoy performance in waves. I see no way to do this in CALMsim. How can I accomplish this?

CALMsim can only simulate two-body systems. To analyze a standalone CALM buoy, you should use Moorsim, which will simulate mooring feedback for "Puck-shaped buoy" vessel types.

Note: To import the buoy and mooring system into Moorsim from CALMsim, you must first apply the "Swap tanker, buoy data" option on the Output Options page of CALMsim before creating the CALMDAT file, which can then be renamed MOORDAT and imported into Moorsim. (The original unaltered CALMDAT file can be retrieved, if necessary, from the associated CALMBAK file.) After importation into Moorsim, you must also eliminate the mooring line associated with the "hawser" line type.

 

SeaSoft Home