Copyright © 2017 by SeaSoft® Systems; All rights reserved

SeaSoft is a registered trademark of SeaSoft Systems

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(wo)/(2*c*wo^3).
Here wo 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(wo)/(4*c*wo^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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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. 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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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 relating to low-frequency user specified spectra, we recommend a span of periods from 12 seconds to infinity, corresponding to [minimum,maximum] frequency values of roughly [0.,0.5].
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

I am confused about the SPMsim definition of the direction of 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 in SPMsim (and in Moorsim/TLPsim/Sparsim when the "non-Legacy Normal Mode" option is in effect) 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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).
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

I am always confused as to what to use for my vessel origin of coordinates, which I use to locate fairleads, turret centroid, etc., on the vessel. The LCG? Waterplane Centroid? Midships (Lpp/2)?

You should make it a habit to use the plan-view center of gravity as your longitudinal coordinate origin. That said, errors introduced by the use of other choices (such as midships or waterplane centroid) will normally fall well within the error bounds associated with other analysis uncertainties; from an engineering perspective it is "noise", and you can use whatever you prefer.

Note: IN ALL CASES references in the documentation to "vesel centroid", "vessel CG", "LCG", "waterplane centroid", etc., are simply proxies for the user-specified plan-view origin of the vessel coordinate system used to specify fairlead locations, turret centroid, or any other point(s) on the vessel.

A related comment: Because the midships location impacts OCIMF moments computed for tankers, when using OCIMF coefficients you can and should specify any non-zero midship location relative to your coordinate origin (see the vessel hydrostatics page), so that quasi-static environmental moments produce exactly, rather than approximately, the mean yaw offsets expected when combining results from Slowsim (environmental forces & moments) and Catsim (mooring statics).
Added:     Feb 28, 2001
Modified:  Dec 1, 2016

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 vessel 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.
Added:     Feb 28, 2001
Modified:  Oct 17, 2013

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 in SPMsim.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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 our "nonlinear--compensated" frequency-domain approach here...
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.

In later versions (post version 4.0), the shipshape roll damping model was extended to more realistically accommodate bilge particulars but the underlying physics dictates that roll damping remains somewhat indifferent to bilge keel details.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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 immediately previous question; 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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. These considerations apply as well to CALMsim and Towsim.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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 admittedly 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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 in all respects?

This is a very subtle and important point. If all details in those two scenarios are properly adjusted (such as accounting for the Doppler-shifting of frequencies for waves riding atop a moving body of water but viewed in an earth-fixed frame), 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. (Note: There is another FAQ with a Slowsim-related slant.)

One caveat: In the SeaSoft simulations, regardless of current or vessel motion particulars, all input wave specifications (wave periods and spectral shape in particular) are referred to an earth-fixed reference frame, and *not* a frame co-moving with the mean flow. This is a simple nod to wave-basin measurement practices in which the wave spectrum is generally measured and reported using a basin-fixed probe.

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 for those simulations, you must 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 reflection (aka wave drift) and wave absorption (aka wave drag) forces. As in Shipsim, etc., the vessel speed in SPMsim, etc., will be used when obtaining wave-frequency vessel RAOs. Therefore, should you wish RAOs to be corrected for underlying current in SPMsim, etc., you must request *both* the current *and* a vessel speed equal and oppositely directed to that current.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

I am preparing a USERRAOS 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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. 
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.]
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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 and Towsim, 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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 Towsim, 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.
Added:     Feb 28, 2001
Modified:  Oct 17, 2013

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


Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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 always 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

I have noticed a text file named "DATUPWRN.stxt" in my Moorsim (or Shipsim, or SALMsim, etc.) that sometimes appears in my working directory. It contains 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 a DATUPWRN.stxt 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 DATUPWRN files are not erased until they are overwritten by the next occurrence of a DATUPWRN warning message, so most working directories will have an old one lying around unless you consciously find and delete it after its creation. They exist primarily for circumstances in which you are too quick with the [return] key and wonder, "gee, I wish I knew what those messages that flashed by at startup were all about...". When running datafiles produced in earlier software versions, it is sometimes helpful to archive the DATUPWRN file to provide clues later on should unexpected issues or surprises develop when reviewing the output stream.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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 "C"reation 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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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.

This process can be used for any simulation (e.g., Sparsim) that contains highly tensioned members which are vertical at quiescent equilibrium.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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?

For Moorsim, Sparsim and TLPsim, it is assumed that lateral low-frequency motions (surge and sway in "legacy" processing terminology; "High" and "Low" normal modes in the post version 5.5 terminology) from each environmental excitation are highly correlated with each other, and that yaw motions are relatively uncorrelated with the lateral (surge/sway, high/low) motions. For this situation, the statistical synthesis of "snapshot" points is accomplished as follows (note that reference to "surge" and "sway" below carries over to the post v 5.5 nomenclature by the substitution of "high" and "low" normal modes for surge and sway):

To repeat: Surge and sway (or "high" and "low") are assumed to be highly correlated with respect to each environmental excitation. The 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 & sway natural periods are comparable. The response of such an oscillator to an external variable force has a high degree of correlation between the surge/sway (hi/low) degrees of freedom; in the limit that the x & y 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, for which the underlying low-frequency normal modes comprise the "surge" mode in combination with the two coupled "sway-yaw" modes described in the relevant manual sections, 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.
Added:     Feb 28, 2001
Modified:  Oct 5, 2013

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). 
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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). 
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

Moorsim (as well as other "comprehensive" simulations) has the capability of calculating the low frequency response due to a fluctuating wind and/or current by specifying a speed variation "spectral density value". I am confused by this term (using English units this quantity appears as ft^2/sec). Shouldn't the units of this quantity be (ft/sec)^2/(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 spectral value Sv(Wn), where Sv is the speed spectrum and 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).
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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

Added:     Feb 28, 2001
Modified:  Oct 8, 2013

You say, for the "Legacy" estimation purposes (pre version 5.x), that low-frequency variables are approximated as narrow-banded processes. For lightly damped systems this should definitely yield good results. However, I sometimes see very high damping levels, sometimes even exceeding 100%; wouldn't that render this approximation invalid?

Your analysis is basically correct. Our "Legacy" 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 environmental spectra are relatively flat near the long periods of interest (i.e., near zero frequency). Furthermore, SeaSoft's Legacy narrow-banded analytical result is exact, *regardless of damping level*, provided that the excitation spectrum is perfectly "white", i.e. the same for all frequencies. Since most environmental spectra are reasonably flat (white) across the frequencies of importance, the SeaSoft Legacy approximation is far, far better than you might expect.

As of version 5.5, the newer "non-Legacy" treatment abandons the "narrow-banded" approximation altogether in favor of a complete numerical integration.

The upshot is that I wouldn't worry about the Legacy "narrow-band" approximation, especially in light of the many other limitations to the analysis.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.

Use SPMsim to 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).
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

When using the "legacy" normal mode option for lateral low-frequency motions in Moorsim, 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. I have so far been unable to understand how these are computed. Can you discuss this further?

Note: Most shortcomings of the "legacy" treatment discussed in this note are eliminated by the version 5.5+ normal mode treatment, which addresses the failings of the legacy method and should be adopted as the treatment of choice when running software versions later than 5.5. This discussion of the "legacy" method relates primarily to earlier versions of the software.

In Moorsim, when "legacy" normal mode processing has been selected, 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 often "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 issue 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 "legacy" treatment is (more-or-less) rigorously valid in the limits of:

(1) purely head-on excitation

(2) purely beam-on excitation

(3) a single variable environment (or an overwhelmingly predominant environmental contributor, usually waves), 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 nearly the same).

To the extent that not one of these three conditions is approximately satisfied, the combination process employed by the "legacy" normal mode treatment in 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 usually tolerable, but this can not be easily quantified.

Again, the shortcomings of the "legacy" treatment are mostly eliminated by the version 5.5+ normal mode treatment, which was developed to address the failings of the legacy method and should be the treatment of choice going forward.

Some additional specifics of the "legacy" combining algorithms:

>>> Low-Frequency RMS line load levels:

RMS levels of all fairlead motions are equal to the square root of the sum of squares of the various environmetal contributions (i.e., the contributions are assumed to be uncorrelated). RMS line loads are then computed based on the RMS fairlead motions as discussed elsewhere.

>>> Low-Frequency 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 (assumed perfectly correlated) surge and sway motions, 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 seriously inadequate estimate under any reasonable circumstance.

When evaluating vessel position for the snapshot evaluations, the mean yaw angle is used. 
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Feb 28, 2001
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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).
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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. (The original "air gap" terminology related to use in Semisubmersibles, of course.)

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).
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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?

The universal circumstance of a small turret-moored FPSO mean misalignment with the waves in a waves-only environment should not be surprising; it has the same wave-vessel orientation nexus as the circumstance that seagoing vessels invariably wind up beam-to the waves after losing steering control. This is due to the inherent yaw instability of shipshapes aligned with incoming waves. This instability, mathematically, results from the fact that the vertical wave-drift moment (Mz) for small angles of wave attack is destabilizing (any initially small attack angle attempts to grow with time).

To understand why your DRIFTCOFS file does not exhibit this expected behavior requires some effort. 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 (which is 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 degrees (like 0, .25, .5, 1, 2, 4, 6, 8, 10, 15, 20, 30, etc.) in order to properly predict the small-angle equilibrium that always occurs in waves-only environments.

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

With the "legacy mode" flag set 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 Legacy 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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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 FAQs).

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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 assumed to be insignificant for ships and semis. This feature may at some point be implemented for semisubmersibles, for which, arguably, it is detectable, measurable and relevant in real life as well as in model tests.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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).
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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

Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.

If you begin to add taut members to your mooring complement (top tensioned risers or whatever), you will probably want to add interpolation layers; just a heads up in case you start getting error messages. You want enough layers, and sufficiently fine layer spacing, that the taut members do not go into a slack condition during the hunt for equilibrium, when the "virtual" vessel draft variations go beyond the first interpolation layer boundary in the downwards direction.

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.
Added:     Aug 13, 2004
Modified:  Aug 28, 2010

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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, in metric units 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.
Added:     Aug 13, 2004
Modified:  Aug 28, 2010

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 weight" 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%).
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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 the penultimate output specification screen: "Net Vessel Loads & Miscellaneous Options".

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.
Added:     Aug 13, 2004
Modified:  Aug 28, 2010

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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).
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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 squared 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.
Added:     Aug 13, 2004
Modified:  Aug 28, 2010

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.
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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), in which oscillatory "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 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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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).
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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; 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.
Added:     Aug 13, 2004
Modified:  Aug 28, 2010

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.
Added:     Aug 13, 2004
Modified:  Aug 13, 2004

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*, which typically comprises 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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.)
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Mar 9, 2005

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.
Added:     Aug 13, 2004
Modified:  Aug 14, 2004

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 highly 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 always 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 DYNOUT, 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).
Added:     Aug 13, 2004
Modified:  Aug 28, 2010

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 well over 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.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.

The "silent mode" option essentially replicates the run-time characteristics of SeaSoft's web-based program suite in which interaction between user and simulation during execution is not possible.
Added:     Aug 13, 2004
Modified:  Oct 8, 2013

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.
Added:     Aug 13, 2004
Modified:  Aug 14, 2004

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. 
Added:     Aug 14, 2004
Modified:  Aug 14, 2004

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 that we are correct and everybody else is wrong. A complete discussion of this would require a full-blown research paper, but the problem appears to be that as of 2010, 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 and has been known for nearly 100 years to be inappropriate for the Reynolds numbers and flow parameters characterizing moorings and risers, in either the ocean or the model basin . I know it is seems unbelievable, but there you have it. You (probably) heard it here first...
Added:     Aug 14, 2004
Modified:  Oct 8, 2013

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 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. 
Added:     Aug 14, 2004
Modified:  Aug 28, 2010

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.
Added:     Mar 8, 2005
Modified:  Oct 8, 2013

We sometimes have to perform long term response analyses in which we analyze a large number of sea states covering, say, a 10 year time span. We then use short term (3-hr) extremes to predict the long term (100-yr) extremes. We run SeaSoft with user defined RAOs but then are tied to a fixed roll RAO. Since roll response is one of the variables of interest, we would like to find a way to vary the roll damping as a function of response amplitude, like SeaSoft does when RAOs are calculated within the simulation. Is there a way that we can modify the user-defined roll RAO "on the fly", based on the response level, or implement something that has the same effect as SeaSoft's wave-height dependent roll RAOs?

If you're scripting the applications for batch processing in these studies, perhaps you can prepare all the RAOs you need (spanning with decent granularity the desired range of wave amplitudes and directions), and copy the desired USERRAOS.txt into the execution directory before execution? If necessary, you can run the simulation twice for each case: The first time with an "average" RAO file, to determine the approximate mean vessel heading relative to the environment, and the second using that heading and your RAO database to select the optimal USERRAOS.txt file for the second and final run.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I occasionally see an error message referring to a "Null Determinant" in the context of a failure to find an equilibrium condition in Moorsim, TLPsim and Sparsim. These messages never seem to occur for SPMsim. Can you elaborate on the differences that lead to this experience?

Moorsim and the other spread-mooring-style simulations you mention use a different, and much more problematic, equilibrium finding algorithm than SPMsim (or CALMsim, or SALMsim, or Towsim).

SPMsim, CALMsim, SALMsim, and Towsim all use a simple one-degree-of-freedom search, the search variable being the vessel yaw angle (FPSO for SPMsim, barge for Towsim, Tanker for CALMsim, etc.). This search is guaranteed to find at least one equilibrium angle provided only that the net forces and moments do not vanish identically (i.e., there exists at least one external forcing agent).

Moorsim requires a three-degree-of-freedom search (surge, sway and yaw); heave, pitch and roll are assumed to remain constant during the equilibrium search in consequence of the (assumed) negligible magnitudes of mooring forces and moments compared to vessel displacement and pitch/roll moment balance.

TLPsim and Sparsim require a full six-degree-of-freedom equilibrium search because changes to mooring forces and moments are not ignorable as the vessel moves under quasi-static conditions (i.e., quasi-static pulldown versus vessel offset, and quasi-static pitch/roll angle variations with vessel offset are not ignorable).

Multi-degree-of-freedom searches are notoriously problematic, relying on a generalization of Newton's method that is not guaranteed to produce a solution in all cases. Usually, for modest environments, an equilibrium is easily found. In extreme environments there may be equilibrium-finding failures, or even the occurrence of multiple equilibria which lead to algorithmic dead ends of one kind or another. Usually, reducing the environment until an equilibrium is found and then gradually increasing the environment will help you find the maximum environment that the equilibrium-finding code can accommodate. You should submit problematic cases to SeaSoft for analysis and suggestions.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I ran a numerical experiment recently with an azimuthally-symmetric vessel and mooring layout in Moorsim. I ran a rectilinear environment from the North (environmental headings 180 degrees) and compared the output to a simulation of the same vessel and mooring layout, but with a rectilinear *quartering* environment (headings of 225 degrees). The expected surge/sway symmetry did not materialize; for example, the low-frequency RMS surge motions in the case of the Northerly environment did not equal the sum of squares of the surge and sway RMS motions in the quartering environment. Shouldn't these be identical in my two test cases?

Yes, they should, provided the mooring layout had at least an 8-fold (45 degree) rotation symmetry (so that the net mooring stiffness for offsets along the environmental direction was identical in your two simulations). Your experiment points up a deficiency in Moorsim's "legacy" handling of the low-frequency lateral normal modes (this was also a deficiency in the legacy treatments for Sparsim and TLPsim). This issue was addressed in SeaSoft version 5.5 with the following flag setting:

          "Use "Legacy" Low-Frequency surge/sway damping model .... (Yes/No)".
This should be toggled to "No" to achieve the expected symmetry in your numerical experiment. You may wish to search for several other related FAQs addressing the changes in the Moorsim/Sparsim/TLPsim low-frequency normal mode processing in version 5.5. 
Added:     Sep 4, 2010
Modified:  Aug 3, 2013

Can you comment on the most efficient method to replicate for simulation purposes the following situation in the wave basin? Because the current and wave generators can only provide current and waves in one direction, to achieve quartering conditions on our system the entire vessel and mooring must be rotated relative to the current/wave source. How is that best accomplished?

You need to keep firmly in mind the coordinate system in which each of the relevant variables is defined:

1. GLOBAL SYSTEM: Environment (wind, waves, current); fairlead departure angles; vessel headings. 2. VESSEL SYSTEM: Fairlead locations.

In the situation you describe, you would be best served, I think, by imagining the vessel to be fixed in space (vessel heading towards global North in both cases) and the basin (and current/wave generators) being rotated underneath the vessel, rather than the other way around. It really doesn't matter, though.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

The wave-frequency tendon loads in TLPsim seem unreasonable whenever the "Apply inertial correction to wave-frequency catenary loads" flag is set to "Yes". Comments?

As indicated in the textual description and help item for that flag, it is for catenaries only (usually, chain-type heavy catenaries); this item should be set to "No" for any taut-mooring applications, such as TLPsim or Sparsim or, for that matter, any taut-line system in which the mooring potential energy derives principally from line elasticity as opposed to gravitational (catenary) adjustments.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

The new (version 5.5 and later) surge-sway "Normal Mode" model in Moorsim/Sparsim/TLPsim is confusing. For example, it seems to always produce negative values for the "High Mode" mean offset and zero for the "Low Mode" mean offset in LOWOUT, regardless of the environmental angles. Aren't the "High" and "Low" modes supposed to correspond roughly to "Surge" and "Sway"? Can you clarify?

The new normal mode analysis is simply an automated, under-the-hood implementation of a procedure we have recommended for some time to be used for highly symmetric vessels, including TLPs and Spars, in "quartering" environments (i.e., when the mean offset is highly mis-aligned with *both* vessel principal [surge,sway] axes). Although interpreting the new normal mode-based information (in LOWOUT.stxt) will take getting used to, the interpretation of the most important variables (i.e., individual line loads and net global- and vessel-based loads/moments in MEANOUT.stxt, RANOUT.stxt, SNAPOUT.stxt and XCLDAT.stxt) has not changed. You are strongly urged to do a careful side-by-side comparison of the LOWOUT.stxt output files for the two cases (Legacy treatment and the improved normal mode treatment) in order to facilitate understanding of the following discussion.

This what is happens with the new analysis:

1. The equilibrium vessel position and orientation (both quiescent and with full environment) are established as usual.

2. The vessel "heading" is temporarily re-defined internally (i.e., the vessel is rotated) so as to point FROM the mean (environment-on) offset determined in (1) above TOWARDS the quiescent (environment-off) equilibrium point. The vertical plane containing the mean offset vector is the plane of motion of the highest frequency lateral normal mode, which we refer to as the "High" normal mode in the LOWOUT.stxt output stream, just as in SPMsim. The "Low" normal mode lies in the plane orthogonal to the "High" mode plane (positive direction set by the right hand rule with z vertical, as always). Note that this convention means the "High" normal mode could in principal be aligned with the vessel SWAY direction; this situation could obviously cause considerable interpretive confusion if the High mode were referred to as the "Surge" mode, as it is in SPMsim. The Yaw mode is approximately decoupled from the lateral modes so it is not affected by these considerations.

3. The vessel-based fairlead coordinates are rotated by the same angle as in (2) above (but in the opposite direction) so that the mooring legs remain in the correct vertical global plane (i.e., fairleads and anchors are located at the same global positions as before the "virtual" vessel rotation in (2)).

4. The "High Mode" equilibrium position (aka net mean vessel offset) always has a *negative* value as a consequence of our definition in (2); the "Low Mode" mean offset is evidently always zero in this scheme.

5. The low-frequency ("LF") dynamical model proceeds with the new vessel orientation, and the low-frequency normal mode damping and motion amplitudes (RMS and Peak) are computed and reported in LOWOUT. Hence, as mentioned above, the mean "Low Mode" offset will always be zero in LOWOUT, although "Low Mode" *variations* will not. For Sparsim, "High" and "Low" *angular* modes, defined analogously to the "High" and "Low" lateral modes, are similarly reported.

6. Once the low-frequency normal mode dynamics have been established, the vessel orientation and fairlead locations relative to the vessel are returned to their original values for wave-frequency analysis and all vessel-relative motions (in XCLDAT, for example) are corrected for the transformation back to vessel-bound coordinates.

7. Finally, the "High", etc., normal mode amplitudes are decomposed into the global system, and combined with the wave-frequency amplitudes to produce the RANOUT, SNAPOUT, DYNOUT and XCLDAT output stream.

The benefits: Because of the nearly universal mooring nonlinearity that exists in offshore mooring systems, the true small-amplitude lateral normal modes lie approximately parallel and perpendicular to the mean offset vector, at least for sufficiently azimuthally-symmetric systems such as Semis, Spars, buoys and TLPs. Orienting the underlying nonlinear oscillator model used for low-frequency dynamics along the normal mode axes is less analytically problematic and more computationally rigorous than artificially decomposing motions along the vessel axes (which are arbitrary in any event for vessels with perfect azimuthal symmetry). This eliminates many difficulties, in particular when evaluating damping arising from square-law processes. In most cases, the LF mooring and vessel load fluctuations, and the LF offsets, are slightly overestimated when using the legacy procedure as a result of the slight underestimation of the damping levels of the largest motions; i.e., LF motions and loads will usually, but now always, be somewhat lower using the new normal-mode model.

Some caveats: The normal mode approach is of uncertain utility for highly asymmetric vessels, such as shipshapes, at least in near-quartering conditions. (In bow-on or beam-on aligned conditions it produces identical results to the legacy vessel-aligned method.) Its use in vessel-asymmetric circumstances becomes a matter of judgement, requiring careful comparison of the two methods. Our best guess at this point is that for shipshapes the new normal mode analysis will improve simulation quality in quartering conditions. In bow-on or beam-on conditions, once again, it makes no difference.

Finally, the legacy treatment can be re-enabled via a flag in the input stream to permit evaluation of & comparisons between the two methodologies.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have noticed that the low-frequency motions and load variations in Sparsim, TLPsim and Moorsim tend to be smaller when the newer (version 5.5 and later) "normal mode" method is in play. Is this a general feature of the newer procedure?

Generally speaking, yes. There are multiple considerations at play here:

1. Because of the presence of nonlinear damping mechanisms, the overall damping levels in the newer normal mode treatment will generally be somewhat higher than with the legacy treatment. This leads to slightly smaller LF motion variations and slightly lower LF load contributions. This is also discussed in the FAQ immediately above, dealing with the theory and implementation underlying the new treatment. Also, since the WF variations will be evaluated at these slightly reduced LF offset points, you may notice a "second order" reduction in the WF loads from that mechanism as well.

2. In addition to the *damping* considerations above, mooring nonlinearities also come into play, especially when the mean environmental forcing lies along a single mooring leg or along a closely-arrayed group of legs. The strong asymmetry produced by this configuration, and the huge mooring stiffness associated with additional offsets parallel to the mean environment, can lead to smaller predictions of low-frequency motions with the newer procedure when compared to the legacy procedure. In all these cases, the newer procedure should lead to more reliable motion estimates, which will in most circumstances result in lower overall loads.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

In TLPsim, I have noticed that in quartering conditions (waves running along a plan-view diagonal, with wave-vector pointing from one column to the diametrically opposite one), the mean and low-frequency variable wave forces are not the same as in "head-on" conditions (wave vector normal to the plane containing the two wave-facing columns on the "bow" side of the vessel). I would expect these wave loads to be nearly axi-symmetric and independent of wave approach angle. Can you offer any insight?

Both wave reflection ("wave drift") and wave absorption ("wave drag") forces depend on the relative motions between the members and the local wave environment. This introduces phase considerations into the calculation. Since diagonally-opposite columns in a square array are further apart than columns on the same side of the vessel, the phase environments for the columns in the two orientations (bow-on or beam-on and quartering) differ; hence the net drift and drag forces differ slightly as well.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

In SPMsim, what are the difference between VFz and VFz+ in XCLDAT.stxt? Are these the forces acting on the turntable?

These Fz values are indeed turntable forces in SPMsim (and the total z mooring forces in comprehensive spread moor simulations: Moorsim, TLPsim, etc.), as are VFx, VFy, VFxy; likewise the moments VMx, VMy, VMxy.

FPSO Fz values are problematic for several reasons. The biggest shortcoming is that the simulation does *not* presently accommodate hydrodynamic or inertial forces acting on underhull turret structures. The missing turret force contributions include turret inertia, wave action, and hydrodynamic reactions on the turret to pitch/heave accelerations. In reality, all these neglected contributions are seen by the turret-to-vessel load transducers. These "hidden" dynamic effects have caused the painful and expensive re-design of many an underhull turret system.

Because of the "pancake" aspect of the turret, the Fx, Fy loads are mostly immune to these effects.

As a result, Fz values (and also Mx, My values) will be among the most poorly reproduced by SPMsim due to the missing forces and their phasing; (mean turret forces and low-frequency variations will not reflect this omission, but wave-frequency contributions will).

The Fz+ value is simply the net vertical force transmitted to the turret by lines & risers.

The Fz value is the Fz+ value with the quiescent environmental load (i.e., the net load at zero turret offset) taken out. (In particular, Fz = 0 in the absence of environmental forces.) You will see either Fz or Fz+ (sometimes both) in basin reports. In the Deepstar FPSO report, they only gave the Fz value, and not the Fz+.

Designers, for obvious reasons, work mostly with Fz+.

VFxy, VMxy represent the square root of [VFx(t)^2 + VFy(t)^2], [VMx(t)^2 + VMy(t)^2], respectively. Therefore they are always greater than or equal to 0.

In contrast to SPMsim, Moorsim (and Sparsim and TLPSim) forces and moments are defined in a vessel system with plan-view origin at the vessel centroid rather than the mooring centroid. The vertical location about which moments are reported is user-selectable and is not necessarily at vessel baseline (keel).
Added:     Sep 4, 2010
Modified:  Oct 17, 2013

In Semisim, the three options on page 10/item 4 produce three slightly different RAO sets with noticeably different phase angles, for example, surge in head-on waves. The "Option 1" description: "Resonant damping ONLY, no square-law driving forces", produces surge phases that seem to be only 90 or -90 degrees at all wave periods while the other options show a continuous variation of phase angle with wave period. What is the reason for this qualitative difference; is it to be expected or is it a bug? Which of the three RAO options is "best"?

This is normal. Without square-law damping, the surge/sway RAO phases for a semi with sufficient symmetry will be +/- 90 since, unlike a shipshape, the linear damping arising from vessel motions feeding outgoing wave energy is essentially nil (and is neglected in Semisim). With square-law drag in play, however, the RAO phases shift slightly from +/- 90 depending on wave period and other details.

In general, option 2 ("Full square-law driving force calculation at all wave periods") is the most defensible option since it in principal gives the most rigorous (and fully nonlinear) RAO estimate at each wave period. The downsides are (a) it takes longer to run (may be an issue for huge batch runs) and (b) it sometimes may not run at all. The latter circumstance is not common, but complicated geometries and very long or very short periods can be problematic. For that reason we typically use option 1 or 3 for most of our runs, depending on whether or not we want square-law effects, and maybe do a few final check runs using option 2 to see if it matters.

You shouldn't see much difference in rms vessel or fairlead motions between the 3 options despite the observed differences in reported RAOs.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

I am simulating a submerged calm-type buoy with its complement of mooring lines and risers using a single (fully submerged) semisubmersible member in Sparsim. I notice that the "unmoored pitch and roll periods" reported in Sparsim's SEMISUM.stxt output file differ substantially from the pitch and roll periods reported by Semisim's version of that file for the same vessel. Shouldn't these be the same?

The "unmoored pitch and roll periods" reported by Sparsim in SEMISUM.stxt are developed by eliminating the mean mooring/riser system *restoring* characteristics from the period estimates, just as they are in Semisim (which knows nothing about moorings, etc.). This leaves only hydrostatic restoring moments to provide the "effective torsion springs" counteracting angular displacements. However, the presence of the moor also indirectly influences the "effective" hydrostatic and mass distribution properties of your buoy. For example, the displacement of the submerged, moored buoy is greater than the dry weight of the buoy by the net mean vertical mooring + riser loads. These subtle mooring-related "hydrostatic" effects are unknown to Semisim, but known by Sparsim, which leads to the discrepancy you have noted. This is of no practical consequence since these values are presented only to provide a qualitative measure of the mooring contribution to the angular restoration moments relative to the hydrostatic contribution; they are not used elsewhere in the simulation. 
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have noticed a strange behavior in Sparsim and TLPsim when large Low-Frequency (LF) oscillations occur about a very small mean offset. This circumstance can be created with a small wind or current coupled with large spectral values, or by imposing suitably small external forces with large external forcing variability. In these circumstances the "Gz" pulldown values at the RMS and extreme LF vessel offsets are wildly incorrect as compared, for example, to Catsim results for the same static offset locations. When this happens, the XCLDAT and LOWOUT values for rms pulldown are also wildly different. Is this a bug?

Yes, kind of... This happens because only the mean offset, and its associated pulldown, is used in an interpolation/extrapolation scheme to predict the pulldown associated with the variations about the mean due to LF motions. When the LF motion magnitudes far exceed the mean offset magnitude, this scheme breaks down. It is not an issue for realistic environments for which the mean offset is usually larger than, or at least comparable to, the variable offsets, but it will arise when artificially concocting a small mean offset about which are imposed large LF motions.

The XCLDAT/LOWOUT differences occur because XCLDAT assumes a linear relationship between the pulldown value and the LF distance variation from the mean. Again, that's fine for smallish oscillations about a large mean offset but fails for large oscillations about a small mean offset (where the relationship is roughly quadratic, not linear). This is expected to be fixed in a future release but is not a high priority since it is not expected to occur in a realistic environment.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

I can't understand your online description for the SeaSoft swell "bandwidth parameter". Can you please expand?

You aren't alone. We don't understand what it says either. It doesn't help that the name "Gaussian" conjures thoughts of the (roughly) Gaussian distribution of water surface elevations going with *any* random sea condition. However, the "Gaussian" referred to in this FAQ simply refers to the *functional shape* of the swell spectrum, which is that of a bell-shaped Gaussian curve centered on the peak spectral frequency.

That is, our "Gaussian" swell spectrum is just a simple one-parameter Gaussian function, S_gauss[w], symmetric about the spectral peak w = wp:

        S_gauss[w] = A*EXP{-[.5*(w/wp - 1)^2]/s^2}
(It is assumed that the spectrum is narrow enough, which is to say "s" is small enough, that the nonzero spectral value at w = 0 is negligibly small.)

Here A is a normalization factor that produces the required Significant Wave Height, wp is the peak frequency, and s is the (dimensionless) "bandwidth" parameter. You can see from the form of the function that s is just the dimensionless "standard deviation from the mean" of the Gaussian:

        "1-sigma" value = s*wp
Thus, the frequency range 2*wp*s centered at w = wp contains 68.3% of the spectral energy in the spectrum.

FYI, you can inspect the spectrum directly using any SeaSoft editor:

1. If necessary, set a relatively dense period grid around the spectrum peak you want to study (e.g., 50 or 100 periods centered on your chosen peak period).

2. Go to the last editor page and ask for a WAVEOUT file. It contains pretty much all the wave kinematics and spectral info (including arcane stuff like the group spectra).
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have noticed what would seem to be "impossibly peculiar" behavior of the peak low-frequency surge and sway excursions reported in LOWOUT (which asymmetry bleeds through, as presumably it should, to the XCLDAT summary file). Specifically, in strongly crossed conditions, where the environments are such that the "Total One sigma variation" for surge and sway are comparable, I sometimes see the *peak* surge and sway excursions to be enormously different and exhibiting different plus-side/minus-side asymmetry about the mean. How can that be? If the RMS ("sigma") surge and sway are the same, shouldn't the peak surge and sway values also be reasonably close to each other?

This is probably what is happening: Most low-frequency excitation forces (fluctuating wind and current in particular, and also most user-specified variable forcing such as VIV simulation) are at least approximately Gaussian and therefore roughly symmetric about the mean force values. Wave-related low-frequency excitations (arising from wave reflection and wave drag, a.k.a. "wave absorption") are *not* Gaussian. There is another nearby FAQ on this issue. In consequence of this fact, wave reflection and drag forces are starkly non-symmetric about their mean values, whereas Gaussian processes are at least reasonably symmetric about the mean. Very large LF wave forcing values are much more probable (and negative values impossible) than they would be were the wave forces Gaussian.

As a result, when you have strongly crossed wind, wave and current conditions, if the wave direction is more closely aligned with one normal mode (e.g., surge), then that normal mode will exhibit the strongly asymmetric plus-side versus minus-side peak values that characterize LF wave excitation. The orthogonal normal mode (sway in this example) is driven primarily by Gaussian processes (wind, current, and possibly user-specified forcing) and will have correspondingly symmetric plus-side and minus-side peak excursions. In this case, even if the net RMS oscillations (the summed contributions from all environmental sources) for surge and sway are comparable, the surge DOF, being heavily influenced by waves, may show the asymmetry you notice while the sway DOF will not. These non-Gaussian considerations, as noted elsewhere, can be countered to some extent by mooring nonlinearities which produce an asymmetry that can in some situations partially or fully cancel the asymmetry discussed here.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

Very long question here; sorry for that... I just carried out a little experiment to better understand the "legacy" versus the "new" (version 5.5+) surge-sway Normal Mode treatments. My understanding is that for a perfectly linear system the new and legacy methods should produce essentially the same XCLDAT output stream (in which all quantities are provided in either vessel-relative or global-relative coordinates). To do this, I constructed a symmetric deepwater mooring for a symmetric vessel and artificially forced all environmental forces to small values (small wind and current speeds and artificially small wave reflection and drag coefficients). The two comparison cases comprised (1) a mean vessel offset at 45 degrees to the North-South axis and (2) a mean vessel offset along the North-South axis. The North-South and quartering offsets were established with small (and steady) user-specified forces, sized however to be larger than any of the other *mean* environmental forces, which were artificially reduced using available parameters (flow speeds, wave heights, etc.). That is, the mean vessel offset was controlled by the user-specified steady force and not the wind/current/wave mean forces. I then configured the *variable* environments (wave reflection, wave drag, wind, current) to be substantial by suitable adjustment of available parameters (spectral values, enhancement factors, etc.). This produces a nearly linear and azimuthally symmetric system in which the surge/sway periods and damping are very similar for both the "legacy" surge-sway modes (North-South and East-West) and the new, quartering normal modes (aligned along and perpendicular to the 45 degree mean offset direction). I would therefore expect that the XCLDAT output stream would be essentially identical for the two cases. This seems to be the case for the mean and RMS motions and loads, but there is a noticeable discrepancy in the extreme motions and loads in the two cases. What is going on here?

You are too damned inquisitive for you own good. I will tell you but then I will have to kill you.

This is a variation on the question immediately above, although with a more complex problem statement.

The culprit here, as before, is the non-Gaussian extreme response due to variable wave reflection and wave drag forces. When these variable wave forces are resolved into the two competing normal mode coordinate systems in your two numerical experiments (e.g., the North-South normal mode versus the quartering normal mode), as you have noted the mean and RMS values, when compared in the *same* coordinate system (the North-centric Global system) are about the same. However, this is not necessarily the case for the plus-side and minus-side peak factors associated with the waves. For a linear, azimuthally symmetric system, such as yours, we *should* carry out our peak factor analysis in a system aligned with the waves, rather than with either the mean offset or the vessel axes. However, for asymmetric or nonlinear systems where the normal modes do not exhibit 360 degree azimuthal symmetry, this procedure would not be optimal. We are running up hard against a fundamental limitation of the normal-mode approach as it relates to peak excursion estimates. For more realistic systems, which will exhibit more complicating nonlinearities, this shortcoming, while still present, is believed to be the lesser of the available evils.

Note 1: If you turn off the waves, leaving only Gaussian-distributed variable forces (wind, current, user-specified external forces, etc.), you should recover approximately equal RMS *and* peak values in XCLDAT for your two test cases.

Note 2: In one particular set circumstances, where the variable LF motions arise predominantly from variable wave drift and/or wave drag forces, you may be best served, in the analysis of the low-frequency motions and line load variations, by choosing the "legacy" normal mode treatment and selecting the vessel "surge" axis to lie in the plane containing the predominant wave-vector, or alternatively along the direction of the mean wave drift + drag force. This could be accomplished by preparation of a suitable USERRAOS.txt file for this now-bizarre vessel to provide suitable RAOs (since the built-in RAO routines assume lateral vessel symmetry which will be broken, at least for shipshaped vessels, by the non-bow-aligned surge direction). Your ability to deal in a meaningful way with complex and subjective circumstances like this is the reason they are paying you the big bucks.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

In Moorsim, TLPsim and Sparsim, SeaSoft version 5.5 and later has a flag controlled by this editor item: 

    "Use 'Legacy' Low-Frequency correlation model ........... (Yes/No)".
Could you explain what that means?

Along with the important changes in the treatment of lateral low frequency normal modes for spread-moor systems in version 5.5, there was a major overhaul in the treatment of correlations between (1) the two lateral-orthogonal low-frequency degrees of freedom (surge and sway in the legacy nomenclature, or "high and low" in the revised v5.5+ nomenclature), and (2) between the various environmental contributions (wind, waves, etc.). The "legacy" treatment assumed that the preponderance of LF excitation came from a single environmental source (usually, waves), and that the correlation between *net* surge and sway motions (which includes in general contributions from all environmental players, not simply the largest) was perfect (100% correlation). This treatment is statistically valid only for simulation of a single, or overwhelmingly predominant, environmental influence and lacks statistical rigor in the presence of uncorrelated contributions from multiple environmental players of comparable importance (e.g., wind and wave, or current and wave, or wind and current, or any combination, including user-applied contributions). Version 5.5 uses a more comprehensive methodology wherein the lateral degrees of freedom (e.g., surge and sway) remain perfectly correlated for each environmental contributor, but are uncorrelated *across* the different environmental contributors.

The flag in question permits reversion to the "legacy" (pre version 5.5) methods as an aid to understanding the impact of these changes to historical simulation studies.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

TLPsim seems to have more difficulty with its equilibrium search than the other applications (Moorsim, Sparsim, SPMsim, etc.). Could you discuss that issue?

Sure. Equilibrium finding in TLPsim is much more fragile and problematic than any of the other SeaSoft products due to the very stiff restoration characteristics mediated by the tendons.

As in Sparsim, equilibrium finding in TLPsim requires a search through a 6-parameter vessel configuration space (arising from the 6 degrees of freedom, aka DOF) for the minimum potential energy or (the null net force/moment point). We carry out this search via a 6 DOF algorithm modeled after Newton's Method for 1-dimensional systems. Such a search is incapable of systematically finding all equilibrium points in the 6-space (if there are in fact more than one). So, TLPsim simply thrashes it finds one. If there exists more than one equilibrium point, and if the points are "near" each other in the 6-space, the search may bounce around inside a region containing the multiple equilibria. This bouncing is exacerbated by the extreme stiffness of the system to pitch, roll and heave. Hence, when multiple equilibria (or near-equilibria) exist, TLPsim is likely to fail to find even one of these. Thankfully, this only happens at fairly large offset values; for the vast majority of cases, including extreme hurricane or loop-current forcing environments, there is only a single equilibrium. Multiple equilibria most commonly arise when "playing" with environmental parameters or external forcing values leads to unrealistically large mean offsets or unreasonably stiff systems.

This does raise an interesting issue however. If a TLP under extreme mean forcing does approach a boundary in its 6-DOF space beyond which boundary multiple equilibria can be found (meaning TLPsim may fail to produce a simulation), it is fair to ask what might actually happen in real life (or in the model basin). To our knowledge this hasn't been explored for TLP-type systems, but it seems likely that in some circumstances, the system will simply transition randomly between available nearby equilibria during the course of the storm or test. This could in principle produce rather chaotic quasi-static motions, which behavior lies beyond TLPsim's current capabilities to describe. This kind of behavior has in fact been observed in the wave basin for simpler, but dynamically analogous, systems. One such example: the motions of the turret-moored FPSO in the DeepStar FPSO hurricane tests, where the observed system behavior was exactly as described above (i.e., random transitions occurred between two equally probable, symmetrically-disposed, equilibrium yaw angles).
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

TLPsim and Sparsim both exhibit a peculiarity that has me stumped. In either simulation, if I run two cases identical except for the state of the "Estimate current loads on mooring lines and risers" flag, I obtain different values in LOWOUT for the mean forces due to both "wave reflection" and "wave drag". I don't see why these wave-related mean forces, which I thought acted only on the vessel hull, should depend on whether or not the forces due to current acting on the moorings and risers is included. This behavior does not occur in Moorsim with a semisubmersible vessel type. Can you explain?

This one took a while for us to figure out; good question!

Mean (and variable) forces due to wave reflection and wave drag depend upon the vessel wave-frequency response (i.e., its RAOs). You can understand this if you think about the wave reflection and drag forces associated with a very short and thin water-piercing spar buoy. Since such a buoy moves almost perfectly with the waves, like every nearby water particle, its wave-frequency motion RELATIVE TO THE SURROUNDING FLUID is nearly zero; hence both wave reflection and wave drag forces will essentially vanish. However, hold that spar buoy fixed relative to the waves, or imagine a huge spar which does not move relative to the waves by virtue of its size, and the reflection/drag forces will be substantial as a result of the large relative buoy-water particle motions.

Turning on the mean current forces acting on moorings and risers causes an increase in the net environmental offsetting force on the vessel; that in turn produces, in Sparsim and TLPsim (but not Moorsim) additional vertical pull-down of the vessel, which increases the effective vessel draft. That increased draft impacts all RAOs and produces more wetted area for the waves to act on; both of those factors influence the mean wave reflection and drag forces, as well as the VARIABLE reflection and drag forces. During equilibrium-finding, this circumstance requires that the RAOs and the mean wave (reflection and drag) forces must be re-computed for every trial offset point as the search for equilibrium proceeds. This is one of the reasons that equilibrium finding is more problematic in Sparsim and TLPsim than in the other simulations. Note that you should also see a small impact on the mean current loads arising from the same increased draft due to pulldown effects. The changes in mean wind forces from this mechanism are generally too small to be noticed.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

TLPsim and Sparsim both exhibit another peculiarity that has me stumped. In either simulation, if I run two cases identical except for the presence of a user-supplied constant force acting on the "Moorings", as expected the mean position of the vessel changes, reflecting the added mean force. However, in LOWOUT.stxt and XCLDAT.stxt, the net vessel loads differ between the two cases, but by a much smaller amount than the applied mooring force. Can you explain what is happening?

Because your applied force acts on the "moorings", it produces a change in the vessel mean offset as you noted. However, the other environmental and user forces on the vessel have changed very little if at all. If anything, you should expect that the net "Vessel" forces (or, what is the same thing, the net mooring/riser/tendon forces acting on the vessel) should not change at all. That is, in fact, what you would see in Moorsim or SPMsim, for example. However, as noted in another FAQ, TLPsim and Sparsim both accommodate vessel "pulldown" in response to mean environmental and user forces. Any change in pulldown may cause a secondary change in other environmental forces, notably those due to waves and current. Therefore the net vessel loads in your example are due, *not* to your applied mooring loads, but to the secondary effect of the pulldown resulting from your applied mooring load; absent any unusual mitigating circumstances, this secondary effect will be small compared to the magnitude of your applied force.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

TLPsim fails to output the familiar RANOUT.stxt per-tendon and per-riser data. This information has been useful to us in Moorsim and Sparsim; how can we obtain or recover this functionality for TLPsim?

The RANOUT-style per-line statistical breakdown is not currently available for TLPsim because the processing required to evaluate this data is not appropriate to TLPsim. This is due to the tight coupling and high correlation between TLP offset and pulldown that is absent for other simulations. This functionality has been replaced, for TLPsim, by the XCLDAT.stxt output stream.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

Does the current load calculated on the mooring lines terminate at the anchor for each line even if the anchor lies above the sea floor? What happens if both fairlead and mooring leg anchor are at or near the surface?

The current load calculation for each line knows about the catenary profile of the line and the position of the anchors, so the current drag on the line should accurately reflect arbitrary anchor depths for anchors that are not bottom-resident. The handling of mooring lines that penetrate the waterplane are problematic, however.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

In simulating a mooring system which includes riser legs with considerable top-end buoyancy (comprising in this case a "Single Line Offset Riser", a.k.a. SLOR), we observe that the current loads on the SLOR are relegated disproportionally to the vessel fairlead rather than the SLOR anchor. Can you suggest what might be going on here and how to remedy this?

You have identified a circumstance in which the apportioning of current load between fairlead and anchor in SeaSoft's methodology breaks down. Here is what is happening:

SeaSoft's treatment of current loads on mooring and riser structures assumes that the horizontal force on line elements arising from current are small compared to the gravity-related horizontal forces arising from fairlead offsets. For most mooring and riser structures this assumption is satisfied and produces reasonable current load estimates at both fairlead and anchor. In extremely large currents, or in other circumstances where current forces exceed the purely gravity-associated (catenary) horizontal forces, this approximation breaks down. A SLOR in strong current is an example of this breakdown.

When the current forces on the buoyant elements of the SLOR become comparable to or exceed the horizontal forces that would materialize in the absence of current, the current load apportioned to the fairlead will be in error. In these circumstances, as you have noted, the additional current-associated SLOR forces acting on the fairlead/vessel will generally be small since the position of the SLOR in response to current loads will adjust so that the current forces will be absorbed almost entirely by the SLOR anchor. The work-around therefore is to eliminate or reduce the current loads on the SLOR (by adjusting downwards the drag coefficient, for example) to prevent those forces from being inappropriately applied to the fairlead.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I am using Shipsim to generate RAOs; the client wants RAOs for 15 degree intervals from 0 to 180 degrees. This means 13 headings. Shipsim currently permits a maximum of 12 headings. Is it possible to increase the number of headings for RAO output?

You can get a great many other RAOs by combining regular wave requests (Editor pp 5) and irregular wave requests (pp 6). Or, for your purpose, just ask for 13 irregular wave directions. To get still more, turn on item 20 on page 6 for up to 36 additional "angular wedges" and get RAOs for all wedges (item 3 on page 9). The RAOs generated by the various requests are independent.

I think you can get 12 + 37 + 36 + 1 = 86 in a single go if you work at it.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I just completed an SPMsim run where the most-exposed LOWOUT line tension at a snapshot turnaround point is greater than the max tension in RANOUT or XCLDAT. The SNAPOUT tension is almost the same as in LOWOUT. Can you please comment on this? I would think that the LOWOUT tension would always be lower than RANOUT (RANOUT mean + low is much lower than the LOWOUT estimate in this case).

The "max turnaround points" in LOWOUT are very subjective. In the present example they correspond to the corners of a rectangle determined by the maximum estimated surge, sway and yaw motions. Obviously, the locus of constant mooring energy is elliptical, not rectangular, so the corners of the rectangle actually represent higher mooring energy than they should. This issue is the reason for the existence of item 32 on pp 20:

  32) Use elliptical bounding box for snapshot coordinates ...... No
If you look at the help notes for that item, you will see it has been largely neglected since its implementation, mostly because it tends to produce smaller loads and therefore works against our "conservative" bias in subjective issues regarding loads. It has never gotten much attention from users, so it has basically lain dormant since its implementation.

If you want to explore this issue further, try switching that value to Yes and compare the results.

Calculations in RANOUT and XCLDAT by contrast use another algorithm altogether, one that makes much more sense from a statistical perspective. Trying to infer "snapshot" turnaround locations and vessel orientations without benefit of a complete time history is necessarily an exercise in subjectivity.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

Running Moorsim: When I checked the "line on bottom" length it reported a negative length. The negative length seemed to be consistent with what I needed to add to make the Line on bottom zero - is this a new feature or bug?

You're falling off the high-load end of the interpolation table and the interpolation routines are choking. That's what this pesky old warning is about:

 ++> Warning: An estimated tension for line number  4, and possibly
              others, lies outside the reliable interpolation range for
              line type a. This may lead to unphysical
              results and/or serious interpolation errors.
Just bump your max interpolation table load to something bigger (double it for starters and work back if necessary) and you should be good to go.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

Running Catsim with "specify lateral offset values" on Page 5 "Hand of God" offset specification, with Initial [X, Y, Z, yaw] offsets set on page 9: "Apply initial (non-equilibrium) vessel offset". Can we start our run from absolute (or global) [0,0,0]? It seems that the Catsim calculation always starts from "equilibrium", which may be displaced from [0,0,0] if the mooring is not perfectly symmetric.

Try toggling item 3 on page 14 to "No" to turn off equilibrium finding.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

Can you confirm that the reference point for the RAOs supplied in a USERRAOS file is at midships, at KG?

That is correct; at the plan-view origin used for specifying the fairlead coordinates, and vertically at the VKG. I can't quite believe that this doesn't seem to appear in the manual. Sorry.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

How are the XCLDAT bandwidth, spectral peak and zero-upcross frequency parameters ("WF_Bandwdth", "WF_SpecPeak", and "WF_Zero_Up") determined when two wave trains (wind waves plus swell) are present, or when a strongly multi-peaked user wave spectrum is applied?

This (wave spectra or spectral combinations lacking a single prominent and well-defined spectral peak) is a very subjective area for the SeaSoft methodology and requires careful subjective analysis to arrive at the "least bad" engineering attack.

When you have both wind waves and swell, it is normally best to choose as the "wind wave" component the one with the largest maximum wave height. However, when wind wave peak periods are *longer* than the swell period, and the wind wave & swell heights are comparable, there is an issue that arises if the "spectral peak period" and "bandwidth" data in XCLDAT is of importance to fatigue analysis.

The issue: There is no physically meaningful way to define a bandwidth for a strongly double- or multi-peaked combination spectrum, and only a marginally meaningful way to define a "peak period". Therefore, when there are only wind waves, or both wind waves AND swell, the bandwidth and spectral peak data reported in XCLDAT is for the WIND WAVE spectrum response alone. Not much we can do about this. The reasoning is that when both wind waves and swell are present, the wind waves are usually shorter period and larger amplitude; the anticipated use for the information would normally relate to fatigue considerations, so this choice (to use wind wave bandwidth & spectral peak data for the combination wind waves + swell) is a conservative one. Note that these comments do not relate to the zero upcross numbers, which have a well-defined meaning regardless of response spectral shape.

To see what I am talking about, and to see how it might affect your workflow or use of the output, duplicate a run by swapping swell and waves and comparing the XCLDATs. Again, these comments only affect the bandwidth and peak period declarations.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have two different line types in Moorsim and the only difference between them are the Elastic Coefficients for one of the segments. The first set: 

  Alpha_1 =  0.950E-04
  Alpha_2 = -0.500E-07
  Alpha_3 = -0.100E-11
 
Produces impossible results in the MOOROUT.stxt interpolation tables.
 
The second set:  

  Alpha_1 =  0.100E-03 
  Alpha_2 = -0.100E-06  
  Alpha_3 =  0.700E-10
 
Produces unremarkable interpolation tables.
As verified by plotting the load-elongation characteristics in Excel, these two sets produce very similar curves across physically relevant stress-strain values, but produce wildly different interpolation tables.

Ok, this looks to be a fairly knotty problem without a very clean solution...

The issue appears to be that the problematic stress-strain cubic is multi-valued. By this I mean there is more than one tension level that will produce the same strain (at large, possibly even ridiculously large, tension values). This condition interferes with some of the internal iterative processes, which were designed to only know about monotonic stress-strain relationships. It is the nature of the many search algorithms in the simulations, such as those required for preparing the static interpolation tables, that they sometimes sample well outside the physical range of parameters (strains, in this case) when hunting for a solution. In some cases, like this one, the algorithm simply settles on the "wrong" strain solution (i.e., the one associated with the larger, nonphysical tension).

I have to say this is the first time this situation has arisen, ever.

It is problematic to hard-code logic that will always find the "right" (i.e., the intended) value of the strain in a multi-valued situation. Therefore, we're probably going to have to live with failures of this type, and seek a workaround.

One workaround is to avoid cubics with multi-valued tensions (this usually just means avoiding cubics with a negative Alpha_3, although theoretically you could get in trouble with *any* non-positive Alpha coefficient, depending on coefficient magnitudes). The worst-case scenario is that you would have to go the "user-supplied" stress-strain route for the problematic line(s).

Sorry the news is not better.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

I just received the following error message: 

 >>> SPM-sim Version 5.32b: Copyright (C) 2008 by SeaSoft Systems

 >>> Preparing level  1 interpolation table for line type A of 13 types...

 >>> Preparing level  1 interpolation table for line type B of 13 types...

 >>> Preparing level  1 interpolation table for line type C of 13 types...

 >>> Preparing level  1 interpolation table for line type D of 13 types...

 ++> Buoyant line handling error. Anchor distance in first row
     ONLY of interpolation table may be slightly in error.
     Contact SeaSoft Systems to report this message...
The message only appears for a small subset of my line types, all of which are risers with a buoyant section towards the lower end of the riser. For other risers with a similar configuration there is no error message. I have inspected the SPMOUT file and the line types that are affected show a negative endpoint separation on the first row of the interpolation table. I am guessing this is harmless since loads falling between the 1st and 2nd row of the interpolation table so not occur at any point in the simulation. Should I worry about this?

The level 1 interpolation table, associated with a zero horizontal tension component, has to be handled as a special case since it cannot easily be determined as a limit Tx ==> 0 using floating point calculations. The special handling occasionally fails for buoyant lines and midline buoys. As you note, unless your simulation actually samples the interpolation tables between rows 1 and 2, there is no consequence. Not much can be done about this.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

Running SPMsim here, I notice that two of my mooring lines lines are showing a tremendous amount of wave frequency line load variation in RANOUT. I have no idea where to begin troubleshooting this.

Looking at the elastic properties for your two problematic lines, I see both have suspiciously large compliance coefficients in some of the elements.

Typographic errors in elastic values are very difficult to troubleshoot. For this reason, when having problems of this kind, it is often useful to replace the elastic properties with a simple linear stress-strain characteristic (Alpha_1 very small and positive, or even zero; Alpha_2 = Alpha_3 = 0).

In your case some compliance coefficients are large enough that the natural period of longitudinal elastic waves in the line become very large (and most likely unphysical). To see this in action, set those problematic compliances to zero and you will get more reasonable wave-frequency load variations.

Longitudinal elastic waves become very important whenever their quarter-wavelength approaches the total line length. If the compliance coefficients are made large enough, this will always happen and will produce strange-looking (and probably unphysical) results.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

We have observed the effects of elastic longitudinal waves when we see wave-frequency line load variations that are larger at the anchor than at the fairlead. However, how valid is the calculation of these waves if the line is made out of synthetic fiber with quite a bit of internal damping?

As I think you have surmised, there is no damping included in the SeaSoft longitudinal wave calculations.

Like any damped dynamical system, as long as you are far from "resonance", the damping is pretty inconsequential. In this instance, "resonance" means that the fairlead-anchor line length, and frequency of tangential fairlead motions, are such that the fairlead load oscillation falls to zero while the anchor load becomes twice the "static" (zero-frequency) value. This corresponds to 1/4 of the lowest-mode elastic wavelength squeezed into the length of line between fairlead and anchor. I don't think I have ever seen a real-life case with long enough line or elastic properties sufficiently extreme to lead to this condition for wave-frequency fairlead motions (i.e., 5-20 second periods or so).

In any event, if you are actually getting very close to this regime, SeaSoft's elastic corrections would cease to be meaningful; they will be *completely* nonsensical whenever the anchor-fairlead line length becomes greater than 1/4 the wavelength of the lowest longitudinal elastic mode; usually, the lowest-mode wavelength is many, many times the line length. That is the limit in which SeaSoft's strain-wave corrections are meaningful.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I noticed some odd differences in the reporting of wave frequency line tension variations at the anchor between RANOUT and XCLDAT, and within RANOUT whenever the "node load" option for load specification at elemental endpoints along each line have been requested. Is it possible that the one sigma line load variations that are reported in RANOUT section XI and in XCLDAT have been calculated without the effect of seabed friction?

That is correct.

The reason for the neglect of bottom friction in the "node load" case is not profound: For a number of sound reasons, the friction correction was simply never applied to the "node load" reports (which appear, when requested, in both RANOUT and XCLDAT). Note that the calculation of "node loads" is a completely separate enterprise from the "legacy" fairlead/anchor load reports in both RANOUT and XCLDAT.

Elsewhere, (in the legacy "Section XI" RANOUT tables that always appear regardless of whether or not node loads have been requested, and in XCLDAT when node loads are NOT requested), the anchor loads do get the friction correction.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

When I was running SPMsim in a batch configuration, with fully-submerged buoyant elements on some riser lines, I got error messages that seem to result in the XCLDAT file not being created (see attached Diagnostics.stxt file): 

   ++> Buoyant line handling error. Anchor distance in first row
       ONLY of interpolation table may be slightly in error.
       Contact SeaSoft Systems to report this message...
   .
   .
   .
   .
   ++> Warning: An estimated tension for line number 10, and possibly
                others, lies between interpolation rows 1 and 2
                of line type d. This may lead to unphysical
                results and/or serious interpolation errors.
   .
   .
   .
   
   ++> Iteration overflow in iter8_RTMI1
   .
   .
Any suggestions on how to get this to run to completion?

Two ideas:

1. Quick & dirty but discouraged: Try turning off the buoyant element flag (pp2, Item 19). That fixes the problem here.

As a general point, when that flag is "yes", the code does a lot of thrashing; it should only be set to "yes" if there are buoyant elements (usually, surface buoys in the mooring leg) that can conceivably reach the surface during the LF excursions.

2. Preferred: Your main problem is the second "warning" message above; some routine is sampling the interpolation tables between rows one and two; never a good thing if it can be avoided. In this case, that problem is easily solved by reducing the first nonzero horizontal force value (row 2) in the interpolation tables from 5 tonnes to 1, which change eliminates the warning above AND the premature termination.

You can almost always fix these out-of-interpolation-bounds errors; you should strive to do that as standard practice, especially before you start making batch runs...

The "Buoyant line-handling error" (first error message in your Diagnostics.stxt file) is another issue altogether: There isn't much that can be done about it.

The first interpolation table row corresponds to 0 horizontal tension in the line; evaluating this row requires special handling; it it too pathological (all line elements are vertical or horizontal) to be analyzed via catenary-elastic equations. When buoyant elements are involved, it has been impossible to circumscribe all the possibilities (location of buoyant elements along the lines, etc.) in enough generality to guarantee avoidance of the issue flagged by that warning notice. So, for buoyant lines, that first row is going to be nonsense from time to time, depending on where the buoyancy is along the line, no matter what you do. As long as that first "zero-horizontal-load" row isn't used in subsequent analyses, no harm. That's one reason (there are others) why it is *very* important to avoid that first interpolation row altogether by always having a small enough horizontal tension in the *second* row to eliminate access to the first row for all possible points in the vessel's LF excursion space. Sometimes, trial and error is inevitable to get a satisfactory table. It might be possible to modify the code so that it would simply refuse to use that first row at all, but that might have the unintended consequence of simulation failure in cases where a user might want to see parts of the output anyway. We generally err on the side of trying to get to completion, even if issues arise during execution, so that the (possibly flawed) output can help troubleshoot the problematic issues.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

At some point, around version 5.3x, you evidently improved the functionality of the default interpolation table construction (with regard to the horizontal tension increments used between successive interpolation table rows). I'm talking about the interpolation table you get if you set item 4 ("Smallest nonzero horizontal load") on editor page 2 *exactly* to 0. Can you give a brief explanation of this more intelligent default table? I noticed that it starts with a lower bound of 0.05 but that the steps increase from there.

Well, I'm not sure "intelligent" really qualifies; all it does is pick a very small second row horizontal tension value (called HMIN): The current value of HMIN is .05 in whatever units; that's either 50 lbs or 110 lbs depending on unit choice. The increment between table rows then doubles for each succeeding row for a number of rows that depends on HMIN and on the maximum table value HMAX (typically, the next 5 to 10 table rows get this treatment). Hopefully, that first row value is small enough to catch all but the most extreme slack-line offset conditions during LF excursions.

The algorithm then simply increments equally the remaining horizontal tension values for all the remaining rows (there will typically be around 80-85 or so of these if the full 90 rows are requested) up to the user-specified maximum value HMAX. That makes for pretty small increments across most of the table (hence a good general interpolation environment) but still has a very small granularity down near zero, which matters for risers, buoyant lines and certain other mildly pathological cases.

So far, this seems to work well across a broad range of required circumstances (TLP tendons to nylon hawsers to mooring legs with buoyant elements).

Note: If you specify a NONZERO value for item 4 ("Smallest nonzero horizontal load") on editor page 2, the granularity of the interpolation table follows the legacy scheme. The scheme described here is limited to the "default" case which can only be realized by setting item 4 on editor page 2 exactly to zero.
Added:     Sep 4, 2010
Modified:  Sep 4, 2010

Are the binary data files used by SeaSoft cross-platform compatible? That is, can I take a Windows CATDAT file and run it on a Mac OS X system?

Yes, as of version 5.5 all the legacy SeaSoft data files (classic Mac Motorola 68k, classic Mac PPC, Mac OS X PPC and Intel, and Windows (Intel) should all be interoperable. Very old datafiles should as a general practice be brought up to date with the most recent available version of the software on the platform that they originated on.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have noticed, when running SPMsim, that the quasi-static turret moments at the various snapshot points given in LOWOUT.stxt and SNAPOUT.stxt often do not agree exactly. They are usually close, but not identical. What is the reason for that; shouldn't they be exactly the same?

In a word, yes. For historical reasons the SNAPOUT values do not take into consideration the slight rotation of the turret (relative to an earth-fixed, anchor-relative, global coordinate system) as the vessel moves from its quiescent null-environment equilibrium to its mean environmentally-determined offset, or as it meanders about its low-frequency (LF) surge, sway and yaw offset envelope during LF oscillations about its mean position and orientation. The LOWOUT values, by contrast, do account fully for any changes in turret orientation relative to the global coordinate system during LF excursions.

If the mooring system has sufficient plan-view symmetry, the LOWOUT and SNAPOUT mean loads in mild environments will be very close (because there will be, at most, only a very small global rotation of the turret as the vessel moves in its LF envelope). As the asymmetry of the mooring system grows, or as the strength of the mean environment grows, the net vessel mooring moments (VMx, VMy) will exhibit progressively larger LOWOUT-SNAPOUT differences, due primarily to the ever-growing mean turret rotation at equilibrium (which rotation, again, is extremely small for symmetric systems). This mean turret rotation (again, relative to its global orientation at quiescent equilibrium) is not reflected in the SNAPOUT moments, which are therefore slightly in error, with larger errors for larger mooring asymmetries or larger mean environments. Note that the net vessel loads (VFx, VFy, VFz) are nearly immune to these small turret rotations, so that LOWOUT-SNAPOUT differences are only noticeable in the net vessel moments.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have noticed that the net max/min loads reported in XCLDAT.stxt sometimes do not seem to jive with the max/min loads reported in SNAPOUT.stxt at what would seem to be the worst-case snapshot points. Example (taken from the same simulation): From XCLDAT: 

        Max [VFx,VFy] = [212, 101]
From SNAPOUT: 

        "Max Fx+" turnaround point: Max [VFx,VFy] = [211, 100]
        "Max Fy+" turnaround point: Max [VFx,VFy] = [50, 57]
In this case it looks like the Fx+ turnaround point in SNAPOUT captures BOTH the max VFx and VFy from XCLDAT, but I was wondering why the SNAPOUT Fy+ turnaround point has such low loads (both VFx and VFY); I would have expected, at the very least, that the max VFy at the Fy+ snapshot would be very close to the max VFy reported by XCLDAT. In other words, shouldn't the VFx max load at the Fx+ snapshot point and the VFy max load at the Fy+ snapshot point be close to the respective max [VFx,VFy] loads reported in XCLDAT?

Often, perhaps, but not in general. The max loads in both SNAPOUT and XCLDAT are a composite of both low-frequency (LF) and wave-frequency (WF) loads (in addition to the mean loads, of course).

The "Maximum Fy+ turnaround snapshot point" provided in SNAPOUT.stxt is established by the maximum LF component of the VFy loads, NOT the total (LF+WF) loads; similarly for the Fx+ point. It sometimes happens, as here, that one of these snapshot points (in this case, Fy+) is actually pretty wimpy, quasi-static-load-wise, so that the maximum VFy *including* WF component (as reported in XCLDAT) does not occur anywhere near the "Maximum Fy+" quasi-static turnaround point identified in LOWOUT and SNAPOUT, but rather occurs at or near the Maximum Fx+ point.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

In SPMsim's "legacy" LOWOUT summary, you report the modal stiffness of the high sway-yaw mode. Is that stiffness based on oscillations about the mean vessel heading or about the quiescent (zero-environment) vessel heading? This would make a difference in the case of a grouped mooring system where the horizontal mooring stiffness is not the same in every direction.

All LOWOUT data relate to the mean position/heading in the full environment.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

Can you tell me what the difference is between the "RelBow", "RelMoon" and "RelMoorCentr" outputs in XCLDAT? In particular, when we are working with an external turret located forward of the bow, can we use the moonpool relative wave values to check for green-water immersion of the turret?

RelBow is a "relative motion" variable (wave frequency only for SPMsim, Moorsim, but containing a low-frequency contribution for TLPsim, Sparsim). This describes the water level variations as determined by a wave probe attached to the vessel at the "bow".

RelMoon is the water-surface to vessel relative motion in the moonpool, resulting from wave-related pressure variations at vessel keel underneath the mooring centroid (as would be measured by a vessel-mounted wave probe at the moonpool center). Since the relative motions in a moonpool are driven by water particle accelerations at the keel in addition to vessel motions, this relative motion variable is influenced by wave pressure attenuation with depth. For SPMsim and Moorsim, this has only wave-frequency contributions, but includes low-frequency contributions for TLPsim and Sparsim.

RelMoorCentr is the same as RelMoon except that the "waves" measured by the vessel-mounted imaginary wave probe experience no depth attenuation; this variable is useful, for example, in assessing green water impingement on a bow-mounted cantilevered turret structure.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I am getting "NAN" values for wave-frequency variables, like the zero-upcross frequencies in XCLDAT. What is the reason for these?

Most likely, you have specified no irregular waves in your simulation. XCLDAT does not test for the presence of random waves, so when you run a case without wind waves or swell (perhaps supplying variable wind and current only, no waves), there will be occurrences of floating point operations on non-existent, non-defined, or zero values. "NAN" stands for "not a number", and usually refers to a compiler's best effort at supplying an output value when attempting to execute a non-meaningful operation (often on an INF, which is itself the result of a division by zero).
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I cannot find documentation on the variables presented in XCLDAT; is there a glossary of these somewhere?

These haven't made it into the user manuals yet. Perhaps this XCLDAT description will help:

Gx, Gy, Gz are global motions of a simulation-specific "plan-view point of interest" (the turret centroid for SPMsim; the vessel centroid, i.e., the user-specified coordinate origin, for Moorsim/Sparsim/TLPsim) at waterline level.

VFx, VMx, etc., are vessel-bound mooring forces and moments (aligned with vessel axes).

VFz is the variation in vertical mooring forces from the quiescent (no environment) equilibrium point; that is, VFz = 0 at the quiescent equilibrium.

VFz+ is the total vertical mooring force, including a nonzero mean component at the quiescent equilibrium point.

VFxy and VMxy are the horizontal net mooring force and moment. These are positive definite quantities. The statistical parameters of VFxy, for example, would be determined from the time series sqrt(VFx(t)^2 + VFy(t)^2), where VFx(t), VFy(t) are the measured time series for VFx and VFy.

RelBow is the relative motion variable (wave frequency only for SPMsim, Moorsim, but containing a low-frequency contribution for TLPsim, Sparsim). This is the water level as determined by a wave probe attached to the vessel at the bow.

RelMoon is the water-surface to vessel relative motion in the moonpool, resulting from wave-related pressure variations at vessel keel underneath the mooring centroid (as would be measured by a vessel-mounted wave probe at the moonpool center). Since the relative motions in a moonpool are driven by water particle accelerations at the keel in addition to vessel motions, this relative motion variable is influenced by wave pressure attenuation with depth. For SPMsim and Moorsim, this has only wave-frequency contributions, but includes low-frequency contributions for TLPsim and Sparsim.

RelMoorCentr is the same as RelMoon except that the "waves" measured by the vessel-mounted imaginary wave probe experience no depth attenuation; this variable is useful, for example, in assessing green water impingement on a bow-mounted cantilevered turret structure.

Vx-Acc Lo, Vx-Acc Hi, etc., are the vessel-bound accelerations at two vertically separated (Low and High) points at the mooring centroid. Like all SeaSoft accelerations, these contain a "small angle" contribution from gravity that is proportional to the instantaneous pitch or roll angle. That is, these are the acceleration components which would be read on a vessel-attached accelerometer (as compared, for example, to the second derivative of the coordinate point variation).

For the time being, the two points (Lo, Hi) are separated by 100 of the chosen units (ft or m). The "Lo" point is at keel level.
Added:     Sep 4, 2010
Modified:  Oct 16, 2013

How is the "WF_Zero_Up" variable provided in XCLDAT defined? Is it meaningful in the case of crossed wind and swell seas?

This is the zero up-crossing frequency, a spectral quantity; it is equal to the square root of the ratio of {[the variance of a process (e.g., vessel heave variance at the mooring centroid)] divided by [the variance of the *rate* of that process (i.e., the vessel heave time derivative in this example)]}. These variances are simply integrals over all frequencies of the process spectrum; since the statistical significance of WF_Zero_Up depends only on the amplitude spectrum of the process of interest, it is meaningful regardless of the complexity of the wave system producing those variations.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

XCLDAT remains an enigma to me. Can you say something about what it is, how it differs from other output (like RANOUT and SNAPOUT), and how it is used?

XCLDAT is a tab-delimited summary of the most-requested statistical motion and load data in a "wave-basin" type format. It is therefore suitable for direct model test comparisons. It was developed to facilitate comparison of the output from TLPsim, Sparsim and SPMsim with the DeepStar model test series for a Gulf of Mexico TLP, caisson spar and FPSO tanker during 2001-2002.

XCLDAT is further designed to be imported or copy/pasted directly into a spreadsheet program such as Microsoft Excel for further processing. Its name, in fact, is a shortened version of "ExcelDat"

XCLDAT comprises post-processed data developed and displayed separately in "MEANOUT" (mean positions, vessel and mooring structure forces and moments), "LOWOUT" (low-frequency vessel dynamics and mooring load summaries) and "RANOUT" (low-frequency, wave-frequency and net line loads summaries). It also includes some data that is not available elsewhere in the simulation, such as zero up-cross periods for most dynamical variables, bandwidth and spectral peak estimates for wave-frequency dominated processes, green-water variables, vessel-wide acceleration, load and moment summaries, etc. The variables reported in XCLDAT have been chosen by user request; it is intended that anything that can be asked of the simulations will ultimately be presented in XCLDAT. However, for a complete understanding of the dynamics of these systems it is imperative that the "source" output files (MEANOUT, LOWOUT, RANOUT, DYNOUT and SNAPOUT) be completely understood. Focussing solely on XCLDAT will lead to an imperfect understanding of the "big picture" and place the user at risk of overlooking unphysical or impossible output caused by a flawed input stream. Such problems are most easily spotted by scanning the source output files.

Depending on the user's choice of line load algorithm, XCLDAT produces two or three tables; you will always get the two tables that SeaSoft feels are the most valuable (the "SeaSoft Upper Bound" and the "API net loads best estimate"), you can't turn these off. If your specified line load algorithm is one of these, you will only get those two tables in XCLDAT. If you choose any other (for example, the "Lower Bound" estimate), then you will get your requested table in addition to the other two.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

I have observed that the low-frequency and wave-frequency RMS line loads given in XCLDAT do not exactly match those in RANOUT. Sometimes they are close, other times not so close. Can you address that apparent discrepancy?

The low-frequency and wave-frequency RMS line load values given in XCLDAT will not in general match those given in RANOUT.stxt except for very linear mooring lines (e.g., massless springs). This difference arises from the approximations required to estimate statistical quantities of nonlinear processes without actually producing a load time series on which to perform the statistics.

The RANOUT values (1-sigma or 2-sigma) correspond to the load response to, respectively, a one or two sigma fairlead tangential motion. Furthermore, in the case of the wave-frequency load component, RANOUT's quoted loads relate to fairlead motions that take place about a point in the fairlead's low-frequency offset space corresponding to the line load algorithm chosen (e.g., the "Upper Bound Algorithm", or either of the "API" algorithms). This procedure is not formally rigorous because of the nonlinearity of the fairlead motion-line load transfer function (it would be rigorous only if the load response to fairlead motions was linear). In general, because of the nature of the load nonlinearities, the "1-sigma" load thus approximated will be an underestimate of the actual 1-sigma load. XCLDAT attempts to correct this underestimate by constructing its "RMS" line load estimates from a weighted average of the 1-sigma load value and one-half of the 2-sigma load value, the weighting depending on the degree of nonlinearity of each line's response to its fairlead motion. This estimation procedure is designed to be slightly conservative so that under most circumstances, the 1-sigma line loads quoted in XCLDAT will represent a (very modest) upper bound to the true 1-sigma loads. Therefore, using the XCLDAT 1-sigma (a.k.a. RMS) loads in line fatigue analyses will, for conventional mooring systems, result in a slightly conservative fatigue life.
Added:     Sep 4, 2010
Modified:  Oct 8, 2013

A symmetry test applied to Moorsim with and without the legacy normal mode treatment appears to fail slightly. We ran two cases on a fore-aft and port-starboard symmetric vessel (and mooring system) with a co-linear beam-on environment of winds, waves and current at 90 degrees: One test case has the "legacy" normal mode flag set to "Yes", and the other with the same flag set to "No". Everything else is the same. I would expect that the low-frequency results for all individual line loads would be the same; although they are close, they are not identical. I traced this to a slight difference in the low-frequency excitation due to wave reflection which is not identical in the two cases (i.e., the value for the "Approximate Sway normal mode" wave excitation in the first case does not exactly match that of the "High normal mode (lateral motions parallel to mean offset)" in the second case). Can you help me understand this discrepancy?

You are right to expect that your two cases should produce identical line loads. The culprit here is the (very weak) dependence of the low-frequency wave-reflection excitation on the normal mode periods. This is a bug in the normal mode rotation option, one that has not yet been remedied, and may not be due to its very insignificant effect on the low-frequency motions.
Added:     Aug 3, 2013
Modified:  Oct 8, 2013

Is there a way to simulate a circular spread-moored buoy by itself, without tanker, and obtain coupled wave frequency motions (with mooring line feedback) like those provided in CALMsim?

Yes; Moorsim is set up to do that. Enter the buoy hydrostatic and mooring data in Moorsim, select the "Puck-shaped Buoy" option on the "Vessel Hydrostatic Characteristics" page and set the "Feedback mooring forces to wave-frequency motions?" flag on the "Vessel Period and Damping Specifications" page to "Yes".
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Is there a way to obtain coupled (mooring line feedback) wave frequency motions for semisubmersibles and shipshapes like those available in Moorsim for CALM buoys?

Not at the present time. It is assumed that semis and shipshapes are so large that wave-frequency mooring forces can be neglected relative to the much larger hydrodynamic forces. This is not the case in general for CALM buoys, whose hydrodynamic forces are much smaller relative to the mooring forces.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Around version 5.5, a new editor option appeared on the startup splash screen called "(B) Batch modify". What is that all about?

This capability was added to address a batch-processing issue with the many two-state "Toggle" data items in the SeaSoft input data stream. The "(B) Batch modify" option is functionally identical to the "(M) Modify existing" option *except* in the way the editor programs handle access to "Toggle" data items.

It is hard to describe these changes briefly, although we will do our best further below. It is easier for you to just fire up an editor or application, select the "B"atch modify option on the splash screen, page until you see any "Yes/No" toggle item, select that item and see what happens. Then, find another two-state toggle item that is NOT a "Yes/No" item, such as the "Computed/Specified" toggle on the "Vessel Period and Damping Specifications" editor page and play with that. You'll see what it is all about.

In-depth:

Under the "M"odify scheme, entering the item number of a toggle, such as:

  30) Estimate current loads on mooring lines and risers ........ No
results in an immediate state switch of that item to:

  30) Estimate current loads on mooring lines and risers ........ Yes
If the state of this item is *not* known in advance, as might be the case in a batch execution scenario, where many data files will be processed automatically and whose internal variables therefore may not be completely known, then the toggle item cannot be set to a desired value; it can only be *switched* from its existing (unknown) value to its toggled (but still unknown) value. The "B"atch modify capability corrects this handling of "Toggle"-type items by converting the "M"odify one-step data access for toggles into a two-step process: First select the item number, then supply, in response to a prompt from the editor, a "1" or a "0" in the second step to achieve the desired, known, final state (regardless of the initial state of the variable). Using the above example, the two step process would look like this: . . 30) Estimate current loads on mooring lines and risers ........ No . . Enter number of selection ("H" for help):___

[User, or batch script, enters 30 to access the item; editor responds as below:] . . Enter number of selection ("H" for help): 30 Enter 1 for "Yes", 0 for "No":___

[User, or batch script, enters 1 at the prompt to achieve a "Yes" setting:] . . 30) Estimate current loads on mooring lines and risers ........ Yes . . Similarly, the User or batch script could have entered a 0 at the prompt to achieve a "No" setting, regardless of the initial state of item 30.

To use this capability in a batch script, simply enter the "B"atch mode in your script, rather than the "M"odify mode, as the first editor command. "B"atch handling of non-Toggle items is identical to the "M"odify procedure.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

This is a recurring area of confusion for me. It seems that forward speed and current should be the same thing physically. Can you go over this once again in the context of Slowsim? For example, I find that two otherwise identical Slowsim runs in which (1) a 3 kt head-on current (and zero forward speed) is compared to (2) a 3 knot forward speed (no current) produce different results for both the wave reflection (drift) and wave absorption (drag) forces and coefficients. Can you discuss this?

Sure; this is confusing as hell. You are correct that current and forward speed are fundamentally the same thing (think Galilean Relativity). For historical reasons, and for an added degree of flexibility, in the SeaSoft simulations "forward speed" impacts only wave-frequency forces on the vessel (think first-order RAOs), while "current" impacts only mean and quasi-static (slowly-varying) forces. In order to achieve the most formally rigorous simulation results, current should be accompanied by an equal and oppositely directed forward speed in order to capture both (1) the first order and (2) the mean and quasi-static higher order dynamic effects. However, for flexibility and granular control (e.g., to simulate special circumstances such as current loads artificially simulated in model tests by external spring-loaded lines), SeaSoft provides separate user control over these two consequences of an underlying current.

Note: It is usually the case, for the longer waves and modest currents encountered in the design of offshore structures, that the effect of Doppler-shifted frequencies on vessel RAOs is modest, so a specification of zero forward speed does not necessarily fatally compromise the engineering usefulness of the simulation. However, the decision to utilize a "zero speed" simplification in the presence of real current should as a general rule be validated on a case-by-case basis.

To expand somewhat: Because wave amplitudes and frequencies are always specified in an earth-fixed frame, the frequency of a wave in a frame co-moving with the current (i.e., in a reference frame where the current vanishes) is Doppler shifted from the frequency as viewed in an earth-fixed frame. Said another way, the wavelength of a wave of a given earth-fixed frequency is different if the wave rides atop a current than it would be in still water. The wavelength and the underlying current strength are the principal determinants of the momentum flux carried by the wave, which is the ultimate source of the mean and variable second-order wave reflection forces. Further, the wavelength and the wave frequency as viewed *from the vessel* are the principal determinants of the first-order wave forcing that determines the first-order vessel motions.

The wave-frequency and low-frequency regimes intertwine in the final analytic synthesis to determine static and low-frequency vessel forcing. This interplay arises because both current speed and vessel RAOs impact the instantaneous orbital speed of water particles as viewed from the vessel, which orbital speed is an essential ingredient in the determination of both second-order slowly-varying wave-reflection forces and the even higher order slowly-varying wave-absorption forces.

To summarize: Both current and forward speed effect wave reflection and wave absorption coefficients, but in different ways. Current impacts (1) the momentum flux carried by the wave and the water-particle orbital speed relative to the vessel, and (2) the forward speed effects the vessel RAOs, which indirectly impact the water-particle orbital speed relative to the vessel. The momentum flux dependence impacts the wave reflection forces, and the water-particle orbital speed relative to the vessel impacts both wave reflection and wave drag coefficients.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

If I am reading the manual correctly, there should be a "frequency distribution" output in Slowsim associated with the "mean irregular wave absorption" forces, but I don't see such an option item in the Slowsim editor.

The manual is out of date. At one time there was such an output item to provide symmetry between the wave reflection and absorption force output stream. However, there is no rigorous analog, for wave absorption forces, to the wave reflection frequency distribution. This option has therefore been eliminated from the Slowsim output stream.

To expand further: The use of "frequency distributions" to understand the details of the mean wave reflection (aka drift) force is approximate and is not their real purpose; rather, the distributions are offered to provide physical insight and help identify the spectral frequencies in the wave field that contribute most profoundly to the mean quasi-static wave reflection forces. These distributions are defined as the product of the relevant (frequency-dependent) dimensionless force coefficient with the wave spectrum. In the case of wave reflection forces, the process of inferring the mean wave force as an integral over this distribution is sometimes referred to in the literature as the "Newman Approximation". It is just that, an approximation, but usually a very good one, even in fairly broad-banded wave environments; it is exact in the limit of a narrow-banded wave spectrum.

In the case of the wave absorption forces, there is no rigorous counterpart to this "integrated distribution" approximation, because the net mean dissipative forces depend on complex temporal and spatial correlations between local oscillatory dissipative forces spanning the entire wetted surface and therefore do not scale, even approximately, with the square of the wave amplitude (as they do for the wave reflection component).
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I have noticed, when comparing the environmental loads in TLPsim (and Sparsim) with those in Slowsim for an identical environment and vessel heading, that the results, while generally close, are often not exactly the same. Can you explain this difference?

By design, Slowsim lacks the complete internal infrastructure to estimate such quantities as vessel pulldown, or quasi-static roll and pitch angles, that the full TLPsim (or Sparsim) application has access to. What you are seeing are the (usually rather small) adjustments to environmental loads arising from the (generally slight) vessel orientation and draft differences.

Said another way: The Slowsim output assumes zero pulldown, zero roll/pitch offset, and vessel RAOs computed using that same simplified vessel configuration. This results in slightly different environmental loads when output from Slowsim and the full simulations are compared, particularly for loads that depend on vessel RAOs (such as wave reflection and absorption forces).
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I'm sorry if this is too elementary, but it is has been bugging me for some time. The Slowsim output pages for wave reflection coefficients give the following recipes to convert the coefficients into dimensional forces and moments when English units are in play: 

            Head-on force (k.lbs) = .5*B*Dm*g*(a^2)*Cx
            Beam-on force (k.lbs) = .5*L*Dm*g*(a^2)*Cy
            Moment at CG (kip-ft) = .5*(L^2)*Dm*g*(a^2)*Cz

            a = wave amplitude = .5*(wave height)

            L    =  325.000 ft
            B    =  325.000 ft
            Dm*g =    0.064 kips/(ft^3)
And, for absorption forces: 

            Head-on force (k.lbs) = .5*Dm*B*(w^2)*(a^3)*Cx
            Beam-on force (k.lbs) = .5*Dm*L*(w^2)*(a^3)*Cy
            Moment at CG (kip-ft) = .5*Dm*(L^2)*(w^2)*(a^3)*Cz

            a = wave amplitude = .5*(wave height)
            w = wave frequency

            L    =  325.000 ft
            B    =  325.000 ft
            Dm*g =    0.064 kips/(ft^3)
            g    =   32.200 ft/(sec^2)
Could you explain what, exactly, Dm is? The expression above implies 

            Dm = 0.0020 kips*[(sec^2)/ft]/(ft^3) (English units)
            Dm = 0.1045 m.t.*[(sec^2)/m.]/(m.^3) (metric units)
Are those supposed to be mass densities? I just don't get it.

This trips up even SeaSoft luminaries from time to time; no apology necessary.

As a nod to historical wave basin and nautical usage, all SeaSoft applications use the following for the "large" unit of force (and weight):

English units: kip; 1 kip = 1000 lbs

metric units: metric ton (aka tonne); 1 m.t. = weight of 1000 kilograms ~ 9810 Newtons ~ 2200 pounds ~ 2.2 kips, approximately.

The admittedly bizarre numeric values you have deduced are a consequence of those choices. Since the simulation unit of force was chosen to be a kip (or tonne), the simulation unit of mass is, by definition, (F = M*g):

      simulation mass unit = 1 kip/g or 1 tonne/g
where g is the acceleration of gravity in the relevant units. That corresponds to an, ahem, peculiar unit of mass (in metric units it would be 1000/9.81 ~ 101.94 kg; in English units it would be 1000/32.2 ~ 31.06 slugs). Sorry.

The Slowsim output stream notation is designed to alert the user that in the wave reflection force evaluation, the relevant density is seawater *weight* density Dm*g while in the wave absorption calculation the relevant density is the *mass* density Dm.

To use the Slowsim formulae, just plug in the numbers as given, and you will get the forces in the correct fundamental SeaSoft force units (kips or tonnes).

(Sorry; two now-retired model test engineers, who shall remain nameless, forced this upon all of us. The SeaSoft developer, left to his own devices, would have used cgs units throughout. :o)
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I have noticed, in MEANOUT.stxt, that the sum of squares of the (x,y) mooring forces given in global coordinates sometimes does not equal the sum of squares of the mooring forces given in Vessel coordinates. Can you explain how there could be a discrepancy? Seems these should be the same.

You have probably specified a mean heel and/or trim angle in your input stream. The "Vessel" mooring force resolution in MEANOUT, as noted in the column label, is in a *Deck-Vertical* system. With trim or heel, deck-vertical and earth-vertical are not the same. If you check the *total* force magnitude

      (Fx^2 + Fy^2 + Fz^2),
that should be the same for the two systems. You should also see a difference between the LOWOUT "Page IV. Static Equilibrium Summary" values for the mean vessel-based x & y forces (which are resolved in a "gravity-vertical, vessel centerline = x axis" and the LOWOUT "VIb. Low-Frequency Net Vessel Motion and Load Summary", whose vessel-based mean force decomposition are resolved in a *deck-vertical* system. If trim and heel both vanish, these two representations should match.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

Can you offer any general guidance on the use of the confusing proliferation of "Legacy" parameters in the SeaSoft simulations (primarily the "comprehensive" offerings like Moorsim or SPMsim)? When should these be used?

The various "Legacy" settings are available primarily for users who have simulations run with earlier versions of the software to assist them in evaluating the source and significance of output changes they observe when comparing simulations run on earlier versions of the applications. As a general rule, the "Legacy" flags should be turned off to take advantage of the many, many developments and model improvements that have occurred over time. New users, in particular, should always avoid "Legacy" options; in particular, "non-legacy" (i.e., "Use Legacy" items set to "No") is the default condition for all new datafile creation.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am checking Slowsim's frequency-dependent "wave absorption coefficients" ("WAC") against the mean wave drag forces also available in Slowsim (which mean forces presumably result from the integration over frequency of the product of the wave spectrum times the WAC). I can't seem to get an acceptable match. This process works fine when using the wave reflection coefficients ("WRC") and mean forces. Can you explain this finding and explain why a procedure that works for the wave reflection (aka "wave drift") forces seems to fail for the wave absorption (wave drag) forces?

You are working way too hard here; my advice is to show this question to your boss, ask for a raise, and then go home and have a beer.

The problem lies in your assumption that the mean wave drag forces result from an integration over frequency of the WAC times the wave spectrum; this assumption does in fact apply (approximately) to the wave drift forces and the WRC, but not to the wave absorption/drag contribution. Note that the WAC apply to regular waves of a *single frequency* (this is also true of the WRC of course). However, in building up the net mean forces from the WRC, a simple integration of the WRC times the wave spectum is for the most part generously adequate (though not formally rigorous), even for broad-banded wave spectra such as the Pierson-Moskowitz spectrum. However, for the WAC, this simple process fails for several reasons: Most notably, without some sort of trickery applied first to the wave spectrum, the process does not even make dimensional sense (because the WAC requires multiplication by the CUBE of a wave amplitude to produce a force, not the SQUARE of a wave amplitude like the WRC).

Note that because the WAC requires a cubed wave amplitude to produce a force, you can do something like this for a *narrow banded* wave input such as a swell spectrum: Find the standard deviation for the spectrum, cube that, and multiply the result times the WAC associated with the peak frequency of the swell spectrum. This process will become progressively less precise as the bandwidth of the spectrum increases, as you can investigate using Slowsim.

A glimpse into the SeaSoft process for determining the mean and variable wave absorption forces associated with broad-banded spectra: The estimation involves a complex process that includes a tedious evaluation of cross-correlations (a) between subsurface and surface wave absorption contributions, (b) cross-correlations between wave reflection and wave absorption forces, and (c) cross-correlations between all wave frequencies represented in the wave spectrum. This is why you pay the big bucks to SeaSoft...
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I am looking at the RelMoorCntr variable in XCLDAT and notice that the "WF_Max" is not the same as the "NET_Max"; I also note that RelMoorCntr can have a nonzero mean. Shouldn't WF_Max and NET_Max be the same given that RelMoorCntr has only a first-order wave frequency contribution in the case of SPMsim/Moorsim? And, shouldn't the mean value be zero for the same reason?

The "WF max" XCLDAT table header is a misnomer for the three relative motion variables (RelBow, RelMoon, RelMoorCentr); our apologies. These XCLDAT variables are the only ones that are detectably impacted by the crest/trough asymmetry associated with waves of finite amplitude. (Note that this asymmetry typically doesn't survive much depth attenuation, so it usually doesn't show up in "RelMoon", but only in RelBow & RelMoorCentr.)

The "WF_max" value is by definition just the appropriate (duration-dependent) Gaussian peak factor times the relative (wave-hull) elevation RMS; i.e., it represents the maximum (and minimum) WF fluctuation expected if the wave train exhibited "small amplitude" sinusoidal behavior. The "NET_Max" (and "NET_Min") values by contrast reflect any wave profile asymmetry.

Except possibly for buoys or other small/shallow draft objects, we assume the wave crest/trough asymmetry isn't an issue for vessel motions because of lateral averaging and vertical attenuation of wave pressure variations over the hull; i.e., it only affects the wave contribution to the "wave-hull relative motion" calculus in the XCLDAT output stream.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

When I manually set the roll damping of an FPSO to a very small value (0.2%), I noticed a surprising increase in various parameters (forces and low frequency excitation levels) associated with "wave drag" (aka wave absorption) effects. Can you illuminate the source of this connection?

The wave drag/absorption forcing and associated low frequency excitation depend in part on the relative motion between the wave field and vessel near the waterline. Very small roll damping levels can produce anomalously large (and physically implausible) values of this relative motion. That in turn can produce very large wave drag forcing, particularly for beam waves near roll resonance. This phenomenon can be explored in Slowsim by comparing regular wave drag forcing for waves of near beam-on incidence close to roll resonance.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

One of my risers is of the "Lazy Wave" type which, in its deployed configuration, exhibits a sinusoidal fairlead-to-anchor profile when viewed from a distance. Such configurations require buoyant riser elements to be interspersed along the line. The static interpolation table for this riser exhibits a questionable value for the fairlead-to-anchor distance in the first interpolation table row, with a very large discontinuity in that distance between the first and second interpolation table rows. All other rows appear normal. Can you address this apparent error? If the value is in error, does it impact the simulation results in any way?

The first row of all static interpolation tables relates to a perfectly "slack" condition; in mathematical terms, this means the horizontal tension everywhere along the mooring line (or in this case, riser) is precisely zero. This condition corresponds to a singularity in the catenary-elastic equations used to describe the line profile. Therefore, this first table row must be handled as a special case, without benefit of the (analytically exact) catenary-elastic equations that are used elsewhere.

To address your last question first: It should be noted that only in the most extraordinary circumstances is this first table interval (between the first two table rows) accessed by the simulation once the table has been created. When it IS accessed, the simulation will issue a warning; the user normally has sufficient control to prevent this occurrence (using the "Smallest nonzero horizontal load" parameter in the input stream, in particular). Simulation warnings similar to:

    ++> Warning: An estimated tension for line number 2, and possibly
                 others, lies outside the reliable interpolation range for
                 line type 1. This may lead to unphysical
                 results and/or serious interpolation errors.
should always be addressed and corrected to reduce the risk of compromised simulation results.

To address your first question in more depth: Obviously, for a conventional mooring line with positive weight/unit length everywhere, the "slack" first-row special case comprises a limp vertical segment from the fairlead to touchdown and thence a bottom-resident portion for the remainder of the distance from touchdown to anchor. When buoyant elements are involved, predicting a meaningful "slack" condition is much harder, requiring in the general case multiple vertical segments (each buoyant segment producing, in the face of a zero horizontal tension component, a vertical loop whose vertical extent depends on the details of segment buoyancy and weight/length of adjacent elements). SeaSoft's attempt to analyze this slack condition fails under a number of circumstances, notably those in which the first buoyant element is far enough along the line that the first contiguous *weighted* line segments, starting at the fairlead, can reach the bottom before encountering the first buoyant element.

The "bottom line": Don't worry about it. Just fix all the warnings you encounter and you should be fine.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I am having trouble obtaining an initial configuration specification (i.e., the tension/fairlead angle/etc. to use in the "quiescent", null-environment condition) when simulating a single mooring leg with an in-line buoy. *Provided that the in-line buoy cannot reach the surface* in the null environment condition (when the horizontal component of line tension vanishes at all points in the mooring leg), I can use either zero horizontal tension or a vertical initial line angle for my "Mean line profile" parameter, and the simulation will run to completion. However, if the buoy tether length is so long that the null-environment configuration comprises a floating buoy with slack line underneath it (e.g., a buoy-to-anchor tether of 100 meters in 90 meter water depth), SPMsim will not run to completion. How can I accommodate these "too-long mooring buoy tethers" in SPMsim?

Discussion: As mentioned in other FAQs, the first row of all static interpolation tables relates to a perfectly "slack" condition; in mathematical terms, this means the horizontal tension everywhere along the mooring leg is precisely zero. This condition corresponds to a singularity in the catenary-elastic equations used to describe the line profile. Therefore, this first table row must be handled as a special case, without benefit of the (analytically exact) catenary-elastic equations that are used elsewhere. In particular, the actual configuration of even simple single-line mooring legs with zero horizontal tension is pathologic: The line tangent has a discontinuity as it turns from vertical to horizontal at the seabed touchdown.

Resolution: The configuration you have described was not anticipated when the special handling for "row 1" analysis was developed, and as a result produces a simulation failure when using "Fairlead line angle", "Fairlead line tension" or "Fairlead horizontal force" for the "Mean line profile determined by" parameter, as you have noted. You can, however, get SPMsim to produce a meaningful simulation for your moor if you select as the "Mean line profile" parameter the "Fairlead-anchor horizontal distance", and set this value to zero.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I noticed recently, when examining output from SPMsim, that the lateral wave-frequency RMS values seem to disagree between XCLDAT ("Gy") and SHIPRAN ("sway"). Can you indicate what might be causing this? Is it a bug in the output stream?

The "Gy" value in XCLDAT refers to the global y coordinate of either: (1) the vessel centroid for Moorsim (this is normally at or near the vessel CG) or (2) the turret center, usually far from the vessel CG, for SPMsim. If you were running Moorsim, and if the mean vessel angle was close to global zero, then the estimated wave-frequency Gy RMS found in XCLDAT and the sway RMS found in SHIPRAN would match. However, for SPMsim the Gy parameter includes a wave-frequency yaw contribution so even if the mean vessel heading were zero, the SHIPRAN sway value (which relates to the vessel center) and the XCLDAT Gy value (which relates to the turret) would not be the same.
Added:     Oct 4, 2013
Modified:  Oct 17, 2013

I have noticed that when using the "B"atch option (as offered on the initial splash screen of an SeaSoft application) from within a batch script, if I make an invalid selection in the script (for example, if I attempt to change the value or toggle state of a non-existent line number on an editor page, or worse, attempt to change data on a non-existent editor page) that the results can be somewhat surprising, to say the least. What kind of error checking is done to prevent the chaos that might theoretically develop in that circumstance?

None. It is just not possible to try and codify the user's intention when she inputs invalid data. You should always check each batch script carefully, by hand, before running the script; the script will simply automate exactly what you see when doing the identical keystrokes manually. If you tell it to do something stupid, it will :)
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

The revised normal mode analysis for SPMsim that appeared in version 5.5 seems to have influenced how user-specified low-frequency damping is handled. When I request 25% yaw damping in my input stream AND I select "Legacy" processing, LOWOUT faithfully reports the high sway-yaw mode damping as 25%. When "Non-Legacy" normal mode handling is selected, LOWOUT reports something completely different, the exact value depending in a rather non-intuitive way on various parameters in the input stream (like environmental intensities, among other things). Can you comment on this change in behavior?

In the "Legacy" treatment, when you specify low-frequency (LF) surge, sway or yaw damping, that damping is used, without modification, for the "approximate" normal mode most closely characterized by the degree(s) of freedom (DOF) for which you supplied damping; these values pass directly through to LOWOUT.

In the more comprehensive normal mode analysis introduced at version 5.50, "surge", "sway" and "yaw" are thoroughly mixed in each normal mode. In particular, LF damping associated with: (i) a slowly varying yaw oscillation about the vessel center; (ii) a slowly varying surge oscillation; (iii) a slowly varying sway oscillation; alone or in any combination will affect the damping levels of all three normal modes. Yaw in SPMsim is particularly problematic in this regard since LF yawing motions comprise a combination of pure yaw about the CG and motion of the CG about the turret, each of which owe their damping to kinematically different circumstances (yaw about the turret contains a large contribution from "pure sway" damping which is lacking in yaw about the CG, for example). A modest attempt has been made in the new normal mode analysis to apply user-specified damping in a way that will reproduce similar output in circumstances where both the New and Legacy treatments should give the same result (for example, closely aligned environmental conditions).
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am confused by the handling of user-specified surge, sway and yaw damping of low-frequency motions in Moorsim. My understanding is that the concepts of "Surge", "Sway" and "Yaw" are dependent on the simulation type (SPMsim versus Moorsim, for example) and the "Legacy" status. Can you clarify the usage in these various contexts?

In "spread moor" simulations (including Moorsim, TLPsim, Sparsim), regardless of the state of the "Legacy" flags, user-specified "Surge", "Sway" and "Yaw" damping have their conventional vessel-bound meanings. Imagine these quantities as being supplied by thrusters attached to the hull and programmed to produce speed-proportional damping to the specified vessel-bound degree of freedom.

In "Legacy" spread mooring simulations, user damping flows directly through to, and appears unchanged in, LOWOUT's summary for each degree of freedom (surge, sway, yaw). In "Non-Legacy" simulations, user damping is apportioned between the three low-frequency normal modes (which no longer comprise pure vessel-bound "Surge", "Sway" and "Yaw" motions); therefore the user-supplied values will not appear as input in the LOWOUT normal-mode summaries (since they are processed internal to the simulation in the non-legacy case).

It is worth emphasizing that the damping reported in LOWOUT for the (non-legacy) normal modes (for all mooring simulations, spread or single-point) is a qualitative quantity. It is not possible, in the most general case, to rigorously define single-valued damping levels for complex normal modes (as it *can* be for a legacy spread-moor case where low-frequency motions comprise three decoupled single-degree-of-freedom motions). Put another way: The very concept of modal damping fails in coupled multi-degree-of-freedom systems. The damping values quoted for non-legacy modal degrees of freedom in LOWOUT are provided to permit qualitative "at-a-glance" comparisons between the various dissipative mechanisms affecting low-frequency motions.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I have observed rare execution failures when requesting "Non-Legacy" normal mode handling in SPMsim in aligned environmental conditions. Is there a workaround?

When conditions are perfectly aligned (wind, waves, current all from exactly the same direction), *and* the equilibrium vessel centerline is aligned with that common environment, the new normal mode analysis may sometimes encounter processing singularities. That should be extraordinarily infrequent, but should it happen, you can switch to "legacy" normal mode processing, which should be completely adequate for aligned environmental conditions.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

My understanding is that the "Legacy" normal mode treatment for SPMsim was formally limited to situations in which the vessel was closely aligned to the environment and that the newer normal mode treatment is more rigorous and remains valid for arbitrary mean orientations of the vessel and the directions of environmental forcings. I would therefore expect that for overlapping cases where both treatments should be valid (nearly aligned vessel, turret offset and environment) that the output streams should be very similar. What do you recommend using in marginal (nearly aligned) situations?

There are differences in the degree of rigor of the two treatments (i.e., "Legacy" versus "Non-Legacy" for SPMsim). Your guiding principle should be this: When you can, use the newer (post version 5.50) processing; it is better. When that fails, or if you are suspicious for any reason of its output, you should check against the Legacy processing model which, for all practical purposes, should be perfectly adequate when the mean vessel angle lies close (10 degrees or so) to the mean offset direction of the mooring centroid.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I have noticed that pre version 5.5 (for example, version 5.45), which earlier versions I believe you refer to as "legacy" in regard to the low-frequency normal mode behavior, the so-called "low sway-yaw" mode had a symmetry that is lacking in the later versions when run with the "legacy" flag set to "yes". (Setting that flag to "yes" leads me to expect the same low-frequency results as in 5.45; am I correct in that?). The 5.5x "legacy = yes" output shows the same kind of +/- asymmetry in the "low sway-yaw" *peak* amplitudes as has always been a feature of the "surge" normal mode. Can you comment on that difference?

A number of bug fixes and improvements to the legacy normal mode treatment also came into play at version 5.5x; because the legacy treatment remains important in the analysis of very highly aligned conditions, we felt it was more important to continue improving that model as bugs arise or modeling improvements are made. So, to answer your first question, the later software (post-version 5.50) with the legacy flags set to "yes" will NOT in general replicate exactly the results from, for example, version 5.45. That said, you should not be seeing large differences...
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Prior to version 5.5x, I preferred to use the "Elliptical bounding box" option as it seemed to provide better low-frequency motion estimates and in any event seemed the more logical option since the low-frequency envelope boundary clearly will not contain "corners". Post 5.5x, it no longer seems to have any effect? What happened?

The "elliptical bounding box" still has purchase, but only in the context of the "legacy" normal mode analysis. With the updated normal mode analysis, the elliptical option is no longer relevant.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

Are the normal mode periods quoted in LOWOUT the zero-damping periods, or the peaks of the harmonic-oscillator response curve, which shifts to longer periods with increasing damping?

The LOWOUT periods are given assuming zero damping; as you note, the response peak associated with the modes will be shifted to somewhat longer periods due to finite damping. For supercritical damping there *is* no response peak but the value of the *undamped* periods in LOWOUT are still of value in understanding the dynamics.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I recently evaluated roll response of an FPSO with SPMsim, using hurricane hindcast data, with and without wave spreading. I note that FPSO equilibrium headings are identical with or without wave spreading. That suggests that SPMsim does not evaluate the effect of wave spreading on mean wave drift forces and moment. Is that correct?

Short answer: yes. Slightly longer answer: There have been sporadic efforts over time to correct that deficiency; for a number of reasons, completion of that project has not yet risen to the level of other "must-do" improvements. The introduction of multi-directionality in the wave field produces complicated issues of wave-drift and wave-drag correlations between non-parallel wave trains that need to be fully addressed before implementing a formal solution valid in a crossed wave environment. Correlations between reflection and absorption contributions to variable forcing are problematic even in the presence of a single long-crested wave field; in multidirectional seas, they are much, much more so. The correlations between the reflective (drift) component alone across waves of differing approach angle should in principle be considered as another user-specifiable variable. It is not clear at present when this problem might be attacked afresh. Note that these comments apply to the low-frequency dynamics of the FPSO; the wave-frequency dynamics of the nonlinear subsystems (line/riser loads for example) have their own set of issues that go beyond the scope of your question.

The correlation issue between crossed wind waves and swell are less problematic since it is reasonable to assume the two wave trains are statistically independent so that correlations can be ignored.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

In another FAQ regarding the asymmetry produced by the "non-gaussian" nature of low-frequency wave excitation, you mention that a second asymmetry-producing factor is nonlinearity in the static mooring offset curve, and that in many circumstances these asymmetries act in opposite directions and tend to partially cancel each other. Is there any way to gauge the relative size and importance of these two asymmetry-producing effects?

Sometimes, at least qualitatively.

For practical purposes, the non-Gaussian asymmetry effects only the low-frequency plus-side/minus-side *peak* factors and not the RMS deviations; specifically, they contribute negligibly to the vessel low-frequency standard deviations (or RMS, or "1-sigma" values). On the other hand, the mooring nonlinearity impacts both the RMS *and* peak motions. Therefore, the strength of the mooring asymmetry can be gauged by comparing the "plus" and "minus" side RMS values (which are equal in the limit of a linear mooring system). That will give at least a qualitative feeling for the portion of the *peak* motion "plus" and "minus" side asymmetry that comes from the mooring nonlinearity; the remainder comes from the Gaussian asymmetry and, as noted, very often cancels a portion of the mooring nonlinear asymmetry. In particular, when the RMS plus-minus difference is small, it follows that most of the *peak* plus-minus variability flows from the non-Gaussian statistics.

Finally, note that there is presently no non-Gaussian model implemented for yaw in Moorsim, TLPsim or Sparsim. Therefore, any asymmetry noted in the RMS *or* peak yaw values flows entirely from the mooring nonlinearity.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I notice that in TLPsim the "Fairlead centroid Global Displacements" in section IV: "STATIC EQUILIBRIUM SUMMARY" of LOWOUT sometimes do not agree exactly with the mean vessel offset values presented in the vessel-wide snapshot forces and offsets summary in Section VIb: "Low-Frequency Net Vessel Motion and Load Summary". Can you comment on that discrepancy?

Yes, this is annoyingly confusing. The output presented in LOWOUT Section IV is a simple 3 DOF (surge, sway and yaw) presentation (similarly for the mean (Gx, Gy) positions quoted in XCLDAT); they are agnostic to the small rigid-body rotations of the structure due to unbalanced tendon forces as the vessel moves about within its low-frequency envelope. When we compute net snapshot mooring forces presented at the end of section VI, however, these rigid-body rotations, which result in slight 3 DOF motions of the vessel CG from the position reported in Section IV, are taken into account to obtain more accurate net vessel force treatments. The snapshot offsets reported in Section VIb reflect these slight motions and therefore do not agree exactly with the values quoted elsewhere.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I notice that subsequent to version 5.5, the sign of the equilibrium offset in LOWOUT for the "surge" normal mode (motions parallel to mean offset) has changed. Is this a bug?

No, not a bug, but admittedly annoying. This was deemed to be the "least bad" choice in our goal of bringing consolidation and consistency to Moorsim, Sparsim, TLPsim and SPMsim.

With the introduction of the new normal mode modeling for both Moorsim and SPMsim around version 5.5, we adopted the convention that in all simulations, the positive direction for the "high" lateral mode (called the "surge" mode in the legacy SPMsim output) should be represented by an arrow pointing *from* the environmentally determined equilibrium *towards* the quiescent equilibrium. With that convention, all mean "surge" offsets are negative, and all mean "sway" offsets are zero when non-legacy processing has been requested. This choice only affects the output in LOWOUT.
Added:     Oct 4, 2013
Modified:  Oct 17, 2013

I am surprised by the sometimes marked differences, particularly in the peak motion estimates provided in LOWOUT, between the "legacy" (pre-version 5.50) results and those of the newer ("non-legacy") normal mode method. Sometimes they show suspiciously large differences. Which should I believe?

Differences between the pre- and post- version 5.50 normal mode estimates should be small whenever one of the vessel principal axes (surge or sway) is closely aligned with the mean offset direction; otherwise, the differences will generally grow monotonically, sometimes to a rather large degree, as the mis-alignment increases. This is precisely the circumstance the newer code was developed to deal with. Naturally, until the cumulative body of experience with the newer code and methodology approaches that of the older code, there is a possibility you have encountered a bug. If you remain suspicious, submit a support request to SeaSoft. Otherwise, go with the new and don't look back...
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Since the introduction of the improved normal mode model in TLPsim/Moorsim/Sparsim (around version 5.5), the nomenclature for the first mode displayed in the LOWOUT output stream (i.e., the "High lateral mode", which was called the "surge" mode in the legacy treatment) now exhibits the caption "motion roughly parallel to mean offset". What does that mean, exactly?

The legacy normal modes for spread moorings were approximated by motions parallel to the vessel axes (and labelled accordingly: surge, sway, yaw). The improved normal model simply re-defines the normal mode axes as directions parallel and perpendicular to the mean offset. However, even these do not *rigorously* represent the true normal modes of the system; hence our equivocation. The data in LOWOUT is only meant to give a physical feeling for, and some rough physical parameters associated with, the low-frequency motions of the vessel. They are not meant to precisely circumscribe the true normal modes, which comprise in the general case more complicated combinations of surge, sway and yaw.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

With the change from "legacy" to "non-legacy" normal mode analysis around version 5.5x, a new labeling for the variable portion of the quasi-static (low frequency) motions appeared on the "Low lateral mode" page in LOWOUT. In particular, you refer to: 

      Variations orthogonal to mean environmental offset (right-hand rule):
What concept are you trying to convey here?

The low-frequency (LF) *variations* in general are not symmetric. There are several FAQs that deal with this phenomenon which generally arises from mooring nonlinearities and/or non-Gaussian low-frequency excitations (waves, in particular). Because of this asymmetry, the two opposing directions associated with each degree of freedom ("DOF"), call them "plus" and "minus" momentarily, need to be matched with the appropriate asymmetric excursion value. To this end we have adopted, for the LF DOF in which the vessel moves away/towards the quiescent equilibrium point, the nomenclature "INCREASES OFFSET"/"REDUCES OFFSET" to identify the direction associated with the two asymmetric motion values. For the DOF comprising motions *transverse* to the mean offset direction, we take advantage of the engineering right-hand rule, in conjunction with the convention that the "x" axis extends *from* the environmentally-established mean position *to* the quiescent equilibrium position. With that convention, the "positive" lateral LF motion lies along the "y" axis, as determined by the "x" axis and the right-hand rule ("z" axis points vertically upwards); the "negative" value lies opposite to that. A decent example of the adage: A picture is worth a thousand words (as you may have noted, we are graphically compromised).
Added:     Oct 4, 2013
Modified:  Oct 17, 2013

I am trying to include risers and umbilicals in an SPMsim analysis. I received a warning message when running SPMsim in interactive mode: 

   ++> Warning: Fairlead locations appear inconsistent
       with specified turret centroid x-coordinate.
However, SPMsim proceeds without complaint if run in silent mode.

This is not a problem, just ignore the message if you have double-checked your fairlead locations & departure angles; if you look at the diagnostics.stxt output file from the silent mode run, you should see the same message. There are a number of "non-fatal" warnings like this that may be encountered in an interactive run; they do not prevent execution in *either* interactive or silent mode. They are advisories only, to help catch common input errors. Just tell the program to "Execute" again after you see the warning and it should go.

In the present case, SPMsim is performing a simple runtime check, looking for a consistent mooring centroid amongst all "moorings" to help catch errors in the input file. The asymmetry produced by the addition of risers and umbilicals was detected and reported, that is all.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

Apologies, but I am getting old, have declining brain capacity and some short-term memory loss. I simply cannot keep all the coordinates systems used in LOWOUT in my head at one time. Vessel system, global system, Normal Mode system, line tangent system; it is mind-numbing. Why are all these necessary to convey the data in LOWOUT?

We sympathize; trying to get a mental image of the simulation results from LOWOUT can be like drinking from a fire hose. It is natural to report forces and motions in the coordinate system for which they are relevant. Vessel loads (turrets, fairleads, etc.) relate to the vessel system. Model basins report vessel motions in the global system. And, for understanding the fundamental normal mode behavior of the system, the "normal mode" system is the natural choice. For study of vessel motions, perhaps you should focus your consideration on the low-frequency envelope data in LOWOUT and the global motion data in XCLDAT, which envelope and motions are reported in the global system, like the output summary from a model basin.
Added:     Oct 4, 2013
Modified:  Oct 17, 2013

I have noticed in scanning the SNAPOUT net vessel loads at various extreme vessel snapshot positions (also given in LOWOUT: "Max. VFx+", "Max. VFy-", etc.) that the reported composite Low-Frequency + Wave-Frequency loads are often considerably larger than what I find in XCLDAT. Shouldn't these be at least approximately the same?

"Snapshot" vessel positions and orientations are a purely low-frequency analog of the "SeaSoft Upper Bound" mechanism for combining low- and wave-frequency motions and loads: To remind you, the "Upper Bound" algorithm simply adds the maximum estimated wave-frequency and low-frequency variations together for each parameter (line load, turret load, etc.); the reason this results in an upper bound is because low- and wave-frequency vessel motions are not perfectly correlated; their maxima will only occur together in a statistically improbable subset of experiments.

The "Snapshot" quantities in LOWOUT and SNAPOUT are similar: They assume that the extremes of all three plan-view low-frequency degrees of freedom (Surge, Sway, Yaw) can occur at the same instant. This is of course statistically improbable since the low-frequency motions are not perfectly correlated, so the "Snapshot" locations (and their associated Low-Frequency loads) represent an upper bound of sorts to the 3 DOF vessel motion envelope.

The loads and motions reported in XCLDAT, on the other hand, have been processed to represent a reasonable statistical compromise to mitigate the above-mentioned statistical improbability of the extreme L.F. motions all occurring at the same instant. As a result, the low-frequency "snapshot" line loads and net vessel loads in LOWOUT and SNAPOUT are generally larger than the "low-frequency extreme" values in XCLDAT.

Finally, these comments apply as well to Moorsim, TLPsim, Sparsim and SPMsim.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I have noticed something peculiar in the LOWOUT reports of RMS and peak motions; the asymmetries exhibited by these two parameters is sometimes inconsistent and I wonder if there is a bug at work? With conventional mooring systems (which generally have a nonlinearly increasing net restoring force with increasing vessel offset), I am used to seeing (and I understand) that the low-frequency RMS values associated with *increasing* mean vessel offset from quiescent equilibrium will generally be somewhat smaller than the values associated with vessel motion *towards* quiescent equilibrium due to the mooring nonlinearity. Because peak values are so much larger than RMS values, I assume this nonlinear asymmetry should generally be greater than that of the RMS values. However, in some circumstances I actually see the asymmetry between RMS and peak motion variations to be *reversed*. I don't see how that can happen.

What you are seeing is the interplay between two asymmetric characteristics when a nonlinear mooring system is excited by a non-Gaussian process (such as low-frequency wave reflection or wave absorption forcing). Depending on the details of the environment, these effects (i.e., the non-Gaussian forcing and the mooring nonlinearity) can work against one another. The RMS motion asymmetry is for the most part governed only by the nonlinearity of the moor. The peak motion asymmetry is governed by both the mooring nonlinearity and the non-Gaussian excitation. Therefore, the peak motion asymmetry can be qualitatively similar to the RMS asymmetry (e.g., when non-Gaussian and mooring asymmetries work together) or they can even be reversed (when the non-Gaussian asymmetry opposes and overwhelms the mooring nonlinearity). There are several other FAQs relating to this issue: Search on "Gaussian"...
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

In a recent simulation of an unusual stress-strain curve, I created a LINE_STRAIN_DB.txt file which contained a "kink" in the stress-strain curve; i.e., a change from one nearly linear segment to another nearly linear segment with a different slope. This produced mild, but unexpected "oscillations" in the tension-offset curve (which was extracted and plotted from the output interpolation tables for that mooring line). Comments?

The LINE_STRAIN_DB.txt facility works like this: A cubic fit to the curve at any point is constructed using LINE_STRAIN_DB.txt points bracketing the curve point of immediate interest. Cubics are notorious for producing unwanted oscillations in the resulting cubic approximation if the points used to define the cubic are too far apart. The solution is to bracket any discontinuities or other curve pathologies with a generous density of LINE_STRAIN_DB.txt points. As a general rule, the more points the better when using the LINE_STRAIN_DB.txt facility.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

When comparing the output streams of SPMsim versions 5.4x and 5.5x, I notice a substantial change in the normal mode periods for the sway-yaw modes. Since damping of a degree of freedom quoted as a percent of critical depends on the value of the natural period, these period differences automatically lead to substantially different damping values as well. Could you comment on this period difference?

During the low-frequency dynamics overhaul associated with version 5.5, a number of improvements were made which could reasonably be applied as well to the "legacy" normal mode treatment. These included improvements to the sway-yaw modeling in SPMsim. As the "legacy" treatment may retain some value in (hopefully rare) instances when the newer code fails to produce a satisfactory simulation, we ported a subset of these improvements to the "legacy" treatment as well.

Note that these period differences also flow through to the the low-frequency motions since they are dominated by the spectral values of the LF excitations (wave reflection force, wind force, current force, etc.) near the normal mode periods. These low-frequency motion differences subsequently flow through to the wave-frequency and net mooring forces in RANOUT, SNAPOUT and XCLDAT. The differences should not be large, but they will be pervasive.

The newer stuff is better; let that old stuff go :)
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I notice a change in the low-frequency wave reflection and absorption damping in all simulations following the release of version 5.5. The difference appears to be exactly a factor of 2 in all instances and applies to both "legacy" and "non-legacy" low-frequency flag settings. Could you elaborate?

This behavior resulted from a bug fix; as you note it is exactly a factor of 2. The newer code is better. Go with it.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I am confused by the continued proliferation of "Legacy" flags in version 5.5+; also the runtime warnings about "mixing" legacy and non-legacy models. Could you discuss?

The legacy flags exist for several reasons; they provide an interim mechanism to revert to earlier analytical models as an emergency fallback/workaround should newer models fail in some unanticipated way. In general, "legacy" treatments should be avoided in all but the following circumstances:

(1) Failure of the "non-legacy" state of a flag to produce a satisfactory simulation. (2) Investigation of simulation output stream changes (i.e., when comparing output between current and earlier versions of the software).

In particular, the use of "Legacy" tanker and semisubmersible wave drift/wave drag models should be scrupulously restricted to one of the above motivations.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

It seems that the flag controlling "Legacy" surge/sway normal mode processing has a somewhat different status than the other legacy "version 5.x" flags. Simulations usually issue a warning when "mixed" legacy flags are detected at runtime (for example, when the "legacy" tanker wave drift model is combined with a "non-legacy current-wave drift force interaction model"). However that warning seems not to appear when "Legacy surge/sway normal mode processing" is combined with other "non-legacy version 5.x" flags. Could you comment on this?

The "legacy" nomenclature is unfortunate in this instance, as you note. The improved normal mode analysis introduced around version 5.5 is of a fundamentally different character than the enhanced analytical models for low-frequency forcing (such as the current-wave interaction effects or the tanker wave drift model) introduced around version 5.0; this earlier collection of low-frequency forcing models (tanker or semi wave drift model, current-wave interaction model, low-frequency peak motion and loads model) were introduced together as part of a comprehensive upgrade of the the indicated low-frequency dynamics and, as such, should for most users be enabled or disabled as a group (i.e., not "mixed"). Mixing of those legacy flags will produce a non-fatal runtime warning.

While in general we still strongly recommend the use of the newer normal mode model, it is not part of the integrated modeling effort that included the above-mentioned legacy low-frequency dynamics flags; we therefore chose not to issue a guidance warning when using the "legacy" normal mode treatment with "non-legacy" low-frequency dynamics flags.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I understand that the SPMsim low-frequency dynamical model changed around version 5.5; however, I was under the impression that although the "Legacy" treatment had known deficiencies in highly crossed conditions, that the legacy normal mode periods themselves were exact. But, for highly crossed environments, there is a substantial difference in the normal mode periods reported in LOWOUT depending on the state of the "Legacy" flag. Could you indicate the cause of this difference?

Two things to be aware of:

(1) The "Legacy" evaluation of normal mode periods prior to version 5.5 ignored a contribution to the yawing restoring moment about the vessel CG from the change in environmental moment with yaw angle; this deficiency in the legacy model was corrected around version 5.5. That is, prior to version 5.5, the yaw restoring moment was assumed to arise solely from the moorings. Including the additional environmental contribution in the legacy treatment at version 5.5 has a minor effect on the legacy periods when comparing the pre- and post- version 5.5x normal mode periods (i.e., comparing legacy to legacy runs).

(2) Your comment that the "Legacy" normal mode period calculation was "exact" is incorrect. The legacy treatment simplified the 3 DOF low-frequency problem by breaking it into a 1 DOF (surge) subsystem plus a 2 DOF (sway-yaw) subsystem and handled both of those "exactly"; this reduction is exact and rigorous only in the limit of aligned vessel and environment (although it proved to be surprisingly robust and useful even in moderately crossed environments). The post-version 5.5 "Non Legacy" model treats the entire 3 DOF low-frequency dynamics problem monolithically, without the reduction to simpler subsystems. This has a very noticeable effect on the modal periods in cases where the environment is highly crossed. The most extreme scenario for this circumstance is one in which environmental forces conspire to produce a mean vessel heading at right angles to the mean turret offset.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am puzzled by the appearance and subsequent disappearance of some "legacy" flags in SeaSoft versions 5.4x and 5.5x. For example, around version 5.47, on editor page 20 there appeared these "legacy" flags" 

   37) Use "Legacy" Low-Frequency surge/sway damping model ....... No
   38) Use "Legacy" Low-Frequency correlation model .............. No
These disappeared around version 5.53 and in their stead appeared this: 

    36) Use "Legacy" surge/sway normal mode processing ............ Yes
Could you explain how best to do comparisons of the output of earlier versions, such as 5.47, using the "legacy" flag 36 above in version 5.53 and later?

Yes. Frankly this is a mess, especially for users, mostly beta testers, who have used some of the intermediate software versions between major releases.

The untidy state of affairs you have encountered results from a desire to keep available at least the bare essentials of the "legacy" SPMsim model (which by now has a lot of very successful model test verifications under its belt) around as a sanity check against the many changes going into the major software release at version 5.5x.

Around version 5.53, the proliferation of confusing "legacy" flags was revisited; as a result, many of the flags were eliminated in favor of a single "legacy" flag that, for SPMsim at least, basically reverts to "legacy everything since about version 5.3x" (except for bug fixes affecting the version 5.5x "legacy"-forced output stream). That change eliminated flags that appeared in some intermediate versions (like items 37 and 38 in v5.47, as you have noted).

The basic rule, to get as close as possible to v5.47 using the single item 36 "legacy" switch in v5.53+ is to use "legacy" status in 5.47 for any flag which does *not* also appear in version 5.53. That would include item numbers 37 and 38 in your question.

For flags that appear in *both* 5.53 and 5.47, like:

    33) Use "Legacy" current-wave drift force interaction model ... No
    34) Use "Legacy" peak low-frequency motion and loads model .... No
the settings should match between the two versions being compared.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I notice that around version 5.5, the maximum permitted size of the various user-specified environmental spectrum files increased considerably (from 61 entries to 1000 entries). Could you comment on the reason for that massive increase?

We discovered, during analysis of past model tests, that measured environmental spectra (particularly, current spectra) were often poorly presented in the wave basin engineering reports. Because these spectra are very important inputs to the simulations, we decided to permit the use of raw PSD data (derived from the FFT of basin time histories of current speed, for example) without the filtering or averaging commonly applied by the basin prior to report presentations. This capability permits preservation of all available frequency distribution information at the low frequencies vital to our low-frequency dynamical analyses. Because the raw, un-averaged FFT periodograms generally contain a large number of spectral points, we expanded the size limit of all user-supplied environmental spectra (CRNTSPEC.txt, WAVSPEC.txt, WINDSPEC.txt) to levels which would permit every frequency point in the FFT periodogram in the low-frequency regime (periods greater than 50 seconds or so) to be included in the user input stream, using commonly utilized wave basin time history parameters (prototype durations up to 10 hours, and prototype sampling rates of several samples/second).
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Can you discuss the internal differences at play when the dynamic heading control spring value in SPMsim is set by the user versus determined internally by the simulation?

Generally, when you are simulating a real DP heading control system, you have knowledge of the DP gain controls whose settings determine the effective spring constant produced by the DP controller. You can and should hardwire that spring value, but you should also confirm after the fact that the specified "spring" is sufficiently robust to achieve the requested heading in the specified environment; the required DP moment is given in LOWOUT. The value of this spring constant will impact many low-frequency dynamical variables (normal mode periods, motions, etc.). As the spring constant is increased, you should see a shortening of the sway-yaw mode periods, for example.

Rather than supplying a spring value, you can ask the simulation to estimate a "reasonable" spring constant; in that event the software will iteratively determine, to within a factor of 2, the *minimum* torsional spring necessary to achieve the requested heading in the specified environment. As before, this spring value flows through to other low-frequency dynamical quantities, such as the normal mode periods and RMS and peak LF motions.

For certain specialized engineering analyses, it may be desirable to control to some extent the torsion spring's influence on normal mode periods and LF motions. In that event, you can specify any spring value (and damping) whatever be used. For instance, to completely eliminate the "downstream" dynamical effects of the spring, the spring value can be set to zero; the simulation will then simply apply a yaw-angle-independent moment which results in the desired target heading, but without imposing a spring constant that will influence the other LF dynamics.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am comparing two runs, identical except for the source of spectral data for current. In Case 1 I use a the "Band-limited white spectrum", which I believe applies the same current density at all low-frequency periods of vessel motion. In Case 2, I use a CRNTSPEC.txt file prepared using measured current spectral data. The "Current spectral density" reported on the LOWOUT Page "V" normal mode summaries for the Case 1 (white spectrum) is the same for all normal modes as expected. So far, so good. The "Current spectral density" for the Case 2 surge mode happens to be smaller than the corresponding "Case 1" value. Again, no problem; it could be anything at all since it comes from the CRNTSPEC file. However, the surge contribution from current in Case 2 is LARGER than that in Case 1 in spite of the reported SMALLER current spectral value. Is this a bug? If not, please explain how this can be.

Very confusing, without doubt. The "Current spectral density" item in LOWOUT is left over from the days when the only current spectral value used for each mode was the value associated with the normal mode frequency. The justification for this is discussed briefly in the user manual. Following the overhaul of the normal mode dynamical models around version 5.5, we began a more rigorous evaluation of current (and wind) excitation, taking into account the entire spectrum, not just the values at the normal mode periods. The "Current spectral density" item in LOWOUT was left in place; it continues to report the current spectral density at the normal mode frequencies just as before, because we feel this value has utility in qualitatively characterizing the spectral intensity. However, when using a CRNTSPEC.txt file, the spectral details make it possible to produce the (unintuitive) reversal of reported normal mode spectral intensity and the current contribution to LF motions that you have reported. Identical considerations apply to wind (WINDSPEC.txt). So, not a bug, but certainly confounding.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I need to simulate two wave trains, one a distant swell (which is dominant), and one wind sea (with a much smaller energy). Both the "Irregular wave specifications" page and the "Background swell characteristics" page contain the same set of spectral possibilities. Does it make a difference if I specify my (dominant) swell on the "irregular wave page", or should it be specified on the "swell" page?

In a perfect world, it would make no difference on which editor page you specified your swell/waves. Historically, faced with your situation, we advised that the largest of any two wave trains be designated on the "Irregular wave specifications" page. There has been a steady effort over time to eliminate this asymmetry, so it should not make any difference in versions 5 and beyond. Prudence suggests, however, that the historical advice be followed, simply in case vestiges of the asymmetry remain undetected.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I have noticed in some circumstances (for example, when irregular wave or swell excitations have been turned off) some fields of the XCLDAT output stream (such as zero up-cross periods "WF_Zero_Up") contain, instead of an expected numeric value, the string "NAN". What does that mean? When NAN makes an appearance in XCLDAT, sometimes other numeric values (e.g., wave frequency spectral peak "WF_SpecPeak") also seem to have unreasonable values. Please explain.

When you turn off random wave processes (i.e., no swell or wind seas), XCLDAT's wave-dependent variables become zero or undefined. Zero values (for quantities like the wave frequency RMS values "WF_RMS") are easy to understand in that situation, but other quantities depend on *ratios* of wave-frequency quantities, such as the zero up-cross period or frequency. Evaluation of these quantities often generate zero divided by zero internally which the compiler reports as "NAN" (for "Not a Number"). Further, the algorithm that searches spectral densities to determine their peak values also fails since the spectral densities will be zero at all frequencies in this scenario. It would be possible to trap for such situations and make a more meaningful notation in the output stream, but this is a low priority, so this FAQ will have to do for now.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I have noticed that in aligned conditions (parallel wind, waves, current, and vessel perfectly aligned with same), when using SeaSoft's built-in RAOs, XCLDAT reports numeric values in all fields. When I switch to user-supplied RAOs (changing nothing else), some XCLDAT fields are reported as NAN, and some other numeric values take on peculiar or otherwise unphysical values.

As noted in the previous FAQ, anomalous XCLDAT behavior can develop in the absence of wave-frequency excitation and associated vessel motions due to the occurrence of zeros in the wave-driven quantities. When using SeaSoft's built-in RAOs, due to the fact that there is no exact representation of 180 degrees (pi radians) in conventional FORTRAN floating-point calculations, such quantities as sway, roll and yaw of a bilaterally symmetric vessel do *not* vanish identically in head seas (wave heading of 180 degrees). These quantities are *very* small (zero to within floating point precision), but not identically zero. Therefore, even in head waves, SeaSoft's sway, roll and yaw RAOs do not vanish identically. For the same reason, the sway, roll and yaw spectra developed from the RAOs are not identically zero. When utilizing user-supplied RAOs, by contrast, the RAOs associated with 0 and 180 degrees wave headings usually vanish identically, producing the same situation for sway, roll and yaw as would exist in the complete absence of waves.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am using Slowsim to compute environmental loads on a TLP. I notice that when running a 12 second swell, with and without an aligned current, I get the paradoxical result that the net wave drift (aka "wave reflection") force in the absence of current is *less* than the net force in a wave-aligned current. This is rather counter-intuitive. Can that be possible?

In the presence of an underlying current, the wave drift force is modified primarily by two current-associated effects, whose contributions can be additive or subtractive, depending on circumstances including wave period and relative wave/current direction. When running atop a current, and in the same direction, the wave length viewed in an earth-fixed reference frame is greater than the wavelength of a wave with the same earth-fixed frequency in the absence of current (think Doppler). Longer wavelengths generally produce weaker wave reflections (hence, smaller wave drift forces). At the same time, by virtue of the additional momentum flux gained by the wave field from piggybacking atop the underlying current, one would expect the wave reflection forces to be correspondingly larger (these being roughly proportional to the total momentum flux in the wave). It is usually the case that the reduction in wave reflection efficacy due to the longer wave length overwhelms the momentum flux enhancement, which circumstances combine to produce the result you have noted.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I often observe in the Slowsim output stream for a semisubmersible vessel that the regular wave reflection/absorption coefficients, and the corresponding mean vessel wave forces in irregular waves, lack an expected symmetry in the lateral (Fy) forces, and the z-moment (Mz) in head waves: Namely these values are often non-zero, even with waves incident directly bow-on. Shouldn't Fy and Mz be zero in head waves by virtue of the bilateral symmetry of the vessel?

Yes, you would be correct in the absence of current. If you are seeing nonzero values for Fy and/or Mz, you have undoubtedly included an underlying current at a nonzero angle to the wave direction; such a current breaks the expected symmetry in the wave forcings and will in general result in nonzero values of Fy and Mz in head waves.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

An investigation using Slowsim to explore the wave reflection coefficients in the presence of an underlying cross-current for a tanker and a conventional semisubmersible has me puzzled. The results can only be characterized as bizarre. For example, with an underlying current heading 150 degrees relative to a tanker with bow heading North (0 degrees), and for waves approximately head-on to the tanker (say, with attack angles between -10 and +10 degrees of head-on), the lateral ("Fy") reflection coefficients fall to zero for a substantial, and asymmetrical, band of headings around zero. If the current is eliminated, the reflection Fy force coefficient symmetry returns (with identically zero "Fy" being reported only for waves at zero attack angle; i.e., perfectly head-on to the vessel). For a semisubmersible vessel in the same environmental conditions there is no band of zero Fy angles as there is for a shipshape. Can you comment on the reason for this somewhat unsettling behavior?

This is a very, very complex issue and we are not going to be able to do it even approximate justice in a FAQ. The physics underlying your observations relates to the near-field current flow around a shipshape compared to that near a semisubmersible. The semi is relatively transparent; the current can flow relatively unimpeded through the vessel due to its relatively open subsurface structure. This is not the case for a shipshape, which can most simply be characterized as a thin, small-aspect-ratio airfoil (aspect ratio being twice the vessel draft/length ratio). Said airfoil has a profound influence on the current flow field around the shipshape; that flow interference is lacking in the flow around a semisubmersible.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I understand the notion of "group" structures in a wave field; individual groups (aka "wave packets") look qualitatively like the autocorrelation function of the irregular wave spectrum (i.e., the Fourier Transform of the wave amplitude spectrum S(w)). An irregular wave field looks qualitatively like a sequence of such packets, each with a different maximum wave amplitude whose distribution amongst packets is determined by S(w). For waves, therefore, I assume the "Intergroup Spacing" is just the wave group speed divided by the group "Frequency" variable provided in spectral tables describing wave reflection group force/moment spectra. But what is the significance of the "Intergroup Spacing" as it relates to wind and current speed/force/moment spectra?

The "Intergroup Spacing" is just a construct to help provide a mental image of the spatial distance between wind/current speed fluctuations (and their associated force/moment fluctuations) as they advect with the mean flow. It is defined, as in your excellent description of the wave Intergroup Spacing, as the ratio of the wind/current speed to the Frequency parameter.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

SeaSoft seems to not include the current loads on mooring lines and risers when computing current loads, moments and low-frequency forcing spectra in Slowsim. How come?

Slowsim lacks the infrastructure required to compute catenary-elastic line profiles for moored systems. The static and low-frequency forcing information available from Slowsim is therefore limited to the vessel only. Some consideration is being given to extending this capability to mooring structures and risers, but as yet this has not been implemented.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

When importing an SPMDAT file into Slowsim to produce tables of forces, moments, and low-frequency spectral values, SeaSoft reports the spectral moments about the CG, although *static* moments are reported about the user-specified offset from CG set in the Slowsim editor, which is usually at the turret location. Is there a rational reason for this inconsistency? If so, could you explain it?

Generally, one is interested in static (i.e., mean) moments to study the vessel equilibrium angle and stability in a crossed environment; this presumption dictates that static moments be reported about the rotation center (i.e.,turret center, or the vessel CG of a conventional spread moor). However, moment *spectra* are a bit more complicated when the rotation center is not near the CG. This is because the moment spectra about an off-CG location involves correlations between (1) pure spectral moments about the CG and (2) sway force fluctuations acting at the CG. For this reason, all *spectral* (i.e., fluctuating) moments in Slowsim are reported about the CG, where this correlation complication does not arise since the sway force contribution to moments about the CG vanish.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

A recent Slowsim run produced the following lines of output under the heading "Mean Wind and Current Forces & Moments": 

            Water depth/draft ratio ............   48.33
            Water depth/draft parameter ........   48.33
What is the reason for this duplication of information and bizarre nomenclature?

We thank Marin and their OCIMF reports for this little gem. The OCIMF reports use a water depth/draft "Parameter" to characterize the current coefficients of various tanker types as a function of draft and water depth. Sadly, the OCIMF data uses "full load" tanker draft as the divisor in their "depth/draft parameter", irrespective of the *actual* tanker draft to which the data applies, providing distinct data sets for several different percentages of full draft. Therefore, for tanker drafts less than 100% of full load draft, the OCIMF depth/draft *Parameter* (based on full load draft) will differ from the depth/draft *Ratio* (based on the actual simulated draft). The latter is also an important parameter, so we have elected to display both. The "Parameter" is the number to be used when referencing the OCIMF coefficients. Obviously, for full load simulations, the values, as you have noted, are identical; if you were to run, say, a 50% load case for the same tanker, you would find different values in SLOWOUT.stxt for the "parameter" vs the "ratio".
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I often get confused by the two Slowsim designations ("Attack Angle" versus "Relative Heading") for relative angles between vessel centerline and environmental directions. They seem to me to be annoyingly and confusingly duplicative. Why don't you just settle on one or the other?

Once again we thank Marin and their various OCIMF reports for this schizophrenia. The original (ca 1977) OCIMF report used an "attack angle" as the independent variable for their description of wind and current loads on tankers. The 1977 definition of "attack angle" differs by 180 degrees from the environment heading angle relative to the vessel x-axis (the vessel bow is always in the +x direction from the vessel center in SeaSoft's universe). The later (ca 1993) OCIMF report changed its independent variable from the 1977 "attack angle" to the "relative heading angle". (Worse yet, they still called the relative heading an "Angle of Attack" *AND* they changed the *sign convention* of the moment coefficients from the 1977 to the 1993 report as a consequence of changing from a right-handed to a left-handed coordinate system.) Some people prefer the 1977 OCIMF attack-angle convention, others (including SeaSoft) prefer the heading convention. For historical continuity we offer both. Sorry it annoys you; it annoys us as well, as you can probably tell from the tone of this FAQ.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I am puzzled by the seemingly inconsistent choices for the angular variable used in environmental load tables in Slowsim. In environment-specific tables (these tables, relating to waves, wind and current, are labelled by Roman Numerals I -> VIII), the angles are given relative to each individual environment direction (e.g., relative to the wind, or wave, or current direction, depending on the table) rather than relative to 0 degrees (true North). Yet in the net environmental loads tables (labelled with Roman Numerals IX and X), the angular variable is the vessel heading relative to true North (i.e., 0 degrees). Please comment on that inconsistency.

Nothing profound here. We simply feel that when displaying, for example, current-relative load data, the natural angular variable for the presentation is the vessel direction relative to the current, irrespective of the actual current direction relative to the global coordinate system. Similarly for all other environmental variables. However, since each environmental component is in fact associated with a different global direction in general, the presentation of greatest utility for the *net* vessel load tables is the vessel heading relative to global North. This is particularly useful when using Slowsim in support of SeaSoft's comprehensive simulations (SPMsim, Moorsim, etc.).
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I am curious about the difference between the mean horizontal environmental loads reported in MEANOUT and LOWOUT. MEANOUT gives: Global system Vessel system (Gravity Vertical) (Gravity Vertical) 

    X Mooring Force             -696.92 m.ton          -733.28 m.ton
    Y Mooring Force             -696.83 m.ton          -658.46 m.ton
    Z Mooring Force            -3758.38 m.ton         -3758.38 m.ton
    Total Plan View Force        985.53 m.ton           985.53 m.ton
    Plan View Force Angle       -135.00 deg            -138.08 deg
    X Mooring Moment           29152.53 ton-meter     27365.87 ton-meter
    Y Mooring Moment          -32542.37 ton-meter    -34058.55 ton-meter
    Z Mooring Moment               0.00 ton-meter         0.00 ton-meter
And LOWOUT gives: 

    Mean (x,y) forces due to wind:             (     34.0,     30.6) metric tons
    Mean (x,y) forces due to wave reflection:  (     14.1,     12.7) metric tons
    Mean (x,y) forces due to wave drag:        (      7.1,      6.4) metric tons
    Mean (x,y) forces due to current (vessel): (    678.0,    608.8) metric tons
    Mean (x,y) forces due to current (lines):  (    140.5,    126.2) metric tons

    Net mean (x,y) environmental forces:       (    873.8,    784.6) metric tons
BUT: Sqrt[873.8^2 + 784.6^2] = 1,174.4 (from LOWOUT) does -not- equal 985.5 (from MEANOUT). What am I missing here?

Sharp eyes there, Grasshopper. Note that if you exclude current forces on lines in the LOWOUT accounting, you get the MEANOUT value (985.5).

This is as it should be because, as indicated by the labeling, the net horizontal force magnitudes values given in MEANOUT represent *fairlead*-transmitted forces ("mooring forces"), while in LOWOUT they are *environmental* forces. The net horizontal fairlead loads (summed across all mooring/riser fairleads) only counter horizontal environmental forces acting directly on the vessel (such as mean forces due to wind, hull current, waves, etc.); the anchors take up the net horizontal current loads (i.e., summed across all lines) acting on the lines. (Note: For an individual line/riser, the current load *is* distributed between fairlead and anchor, but summed across the complete collection of lines and risers, the anchors absorb all horizontal current loads on said lines and risers.) Of course, current loads on lines/risers do impact the mean vessel offset in a profound way despite not being represented in the summed fairlead loads. Have a beer and think about it for a while.

Since the summed horizontal current loads on the lines/risers represent environmental offsetting forces that the fairleads do *not* have to counter, the summed horizontal fairlead loads are independent of them; therefore the MEANOUT net horizontal load values are lower than those in LOWOUT.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I have done a simple hand calculation of the total horizontal load on the mooring lines for a simplified SPMsim mooring and find that my hand calculation gives a substantially larger value than that reported in LOWOUT. I have triple-checked my calculation and can find nothing wrong; can you explain this discrepancy?

The net horizontal load on lines/risers quoted in LOWOUT only comprises the portion of the total current load on the lines/risers which is absorbed by the fairleads; it lacks anchor-side contributions which your "total" current load would presumably include. We report it in this way because the fairlead contribution is the portion of the current force on lines which actually produces an additional mean vessel offset.

Note that, somewhat counter-intuitively, the offsetting force due to current loads on the lines has in our model no effect on on the *net* horizontal turret load (or net vessel load, for Moorsim/TLPsm/Sparsim) since the current load contribution to downstream fairleads increases the horizontal line tension component experienced by those fairleads, but for upstream fairleads it *reduces* the horizontal tension component; that is, once the vessel has achieved its equilibrium position, the sum over fairleads of this correction vanishes to "zeroth order" (i.e., "zeroth order" in the deformation of the line profile from the null-current profile) . This means, of course, that the total current load on lines (the value you computed) is equal to the sum over all *anchor* contributions (again with upstream and downstream horizontal current-associated anchor load corrections having the opposite sign, but in this case *not* summing to zero as for the fairleads). If this confuses you, rest assured you are not alone; it is said that even Newton was once overheard mumbling to himself about it.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

As an aid to understanding SeaSoft's underlying handling of current loads on mooring lines, I constructed a simple two-line system (fore and aft fairleads with oppositely directed line departures), using neutrally buoyant mooring lines and a very low pretension value. I turned off all environmental forces but current on the lines (by setting the current hull enhancement factor to zero to eliminate even that environmental contribution). Thus, the only forces acting on the system are the current loads on the two mooring lines. The resulting offset and net loads (as reported in MEANOUT in LOWOUT) seem reasonable, but the individual line fairlead and anchor loads appear nonsensical. Can you explain this behavior?

You have simply tread outside the bounds of what can be meaningfully processed using the SeaSoft methodology. The main problem is that the current load calculation for lines assumes these loads represent a perturbation, in the sense that the horizontal load contribution due to current at each point along the line is presumed to comprise only a small fraction of the zero-current horizontal tension value (which is constant along the line in the zero-current case). Frankly, I am surprised the code even runs for your test case with near zero pretension.

A related issue is that we do not presently attempt to adjust the reported horizontal loads at fairlead *or* anchor to reflect the current corrections. The reason for this is twofold: (1) Our primary goal for this feature is to determine with some fidelity the vessel mean offset in the presence of an underlying current, as experienced in model tests and at prototype; current loads on lines are a very important contributor to mean position in these situations but the fairlead-by-fairlead details are irrelevant (only the sum across all fairleads matters for this purpose). (2) Under the assumptions of the calculation (per-line current load increment small compared to mean horizontal tension in the line), there is little to be gained by attempting to correct individual fairlead and anchor quasi-static loads; the adjustments will be lost in the noise for realistic configurations. We are, nonetheless, looking into the possibility of adjusting the reported fairlead and anchor mean and quasi-static loads to correctly reflect the current load contribution; perhaps in an upcoming release. This may permit certain extreme cases such as yours to be handled with more grace.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

In the discussion of phase leads and phase lags in the user manuals, you never explicitly state the convention for the complex representations; do you use Exp[+i(w*t + Phase)] or Exp[-i(w*t + Phase)]?

It doesn't matter. This is because only the real part of the complex RAO is physically meaningful, and because

        Real{Exp[+i*Q]} = Real{Exp[-i*Q]} = Cos[Q].
What does matter is whether the overall phase of motion for a positive value of "Phase" is taken to be {i(w*t + Phase)} or {(i*wt - Phase)} since that convention determines whether a positive phase angle (Phase > 0) represents a "lead" or a "lag". Like most analysts, we use the first convention so, for example, the vessel lateral motions in regular waves of unit amplitude and angular frequency "w" follow from:

        motion = Real Part of {|RAO|*Exp[+i(w*t + Phase)]},
where |RAO| is the magnitude of the RAO and "Phase" is, well, the phase. Clearly a positive value for "Phase" means, for example, that the maximum "motion" value occurs earlier in time than the wave crest at the vessel coordinate origin (the wave phase having, by definition, Phase = 0); that is, when "Phase" > 0, the "motion" leads the wave.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

Because the WAMIT diffraction analysis program is widely accepted by regulatory bodies worldwide, and in our country in particular, we frequently utilize it to cross-check SeaSoft RAOs in critical applications. We recently became aware that WAMIT's angular RAOS (i.e., roll, pitch and yaw) differ substantially from those of Shipsim/Semisim/Discsim. The difference appears as a constant multiplying factor (i.e., is frequency-independent). In contrast, SeaSoft's displacement RAOs (surge, sway, heave) generally agree well with WAMIT. Can you explain this SeaSoft/WAMIT angular RAO discrepancy?

SeaSoft's displacement RAOs are dimensionless; in the metric system they are represented by [meters of motion]/[meter of wave amplitude]. WAMIT's displacement RAOs are defined the same way and therefore are directly comparable.

SeaSoft's angular RAOs can be output in either dimensional form ([degrees motion]/[meter of wave amplitude]) or dimensionless form (degrees/degree or radians/radian, i.e.,[degrees motion]/[degree of wave slope]). Like WAMIT displacement RAOs, WAMIT angular RAOs are always dimensionless; *however*, WAMIT non-dimensionalizes their angular RAOs, not with the wave slope (which is the natural choice in our view), but with a unit wave amplitude rendered dimensionless by a user-defined length scale (called ULEN in WAMIT-speak). That is, WAMIT's angular RAOs are represented by: [radians of motion]/[(unit wave amplitude)/ULEN]. Thus the WAMIT dimensionless angular RAOs differ from SeaSoft's *dimensional* RAOs (degrees/meter) by a constant factor of ULEN*Pi/180, which factor depends on the user-defined length scale ULEN. In particular, WAMIT's convention results in dimensionless RAOs (i.e., pitch in head waves and roll in beam waves) which do *not* tend to unity in the deep-water, long-wave asymptotic limits. Of course, dimensionless RAOs given in terms of [degrees motion]/[degree wave slope] (or radians/radian) *do* tend to unity in the aforesaid asymptotic limits, as do all dimensional displacement RAOs; historically, this has been used as a first-line sanity check on theoretical wave models.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

The Moorsim Manual description of the requirements for the USERRAOS.txt file (containing user RAOs for all SeaSoft simulations) gives the following RAO format requirements for the six source RAOs: 

        CUSRG,CUSWY,CUHEV - Complex Dimensionless RAO data at each frequency & angle
        CUROL,CUPIT,CUYAW - Complex Dimensionless RAO data at each frequency & angle
We sometimes use a third-party application (WAMIT) which produces dimensionless RAOs, as specified above. Yet, something seems wrong. For example, the angular RAOs for pitch in head waves or roll in beam waves, using degrees/degree format output from Shipsim and using USERRAOS.txt developed from WAMIT as input, do not tend to unity in the long wave limit as they must. Do you have an explanation?

You are correct: The documentation should be more explicit; the "Dimensionless RAOs" referred to in the USERRAOS documentation, assuming metric units momentarily, *must* be in the form [meters/meter of wave amplitude] for displacement RAOs (i.e., surge, sway, heave) and [degrees motion/degree of wave slope] (or, equivalently, radians/radian) for angular RAOs (roll, pitch, yaw). You are also correct that all WAMIT outputs are dimensionless, but their *angular* RAOs are not of the required form (i.e., are not in the form [radians motion]/[radian wave slope]). In brief, all the WAMIT dimensionless *angular* RAOs used in USERRAOS.txt preparation must first be divided by the constant factor [ULEN*Pi/180], where ULEN is the user scale length used in the preparation of the WAMIT output and Pi is 3.14159. Search the FAQ for keyword WAMIT to learn more about this issue.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am never comfortable with the subjective choice of semisubmersible member selection in Moorsim/Semisim. The manual examples are helpful, but beyond actually developing both and comparing simulation results, I would appreciate any other guidance you could provide. Of particular interest is a semisubmersible with perfect four-fold underwater symmetry but whose smallish columns would seem to argue for a "Pontoon-Dominant" decomposition; however it seems that the "Pontoon-Dominant" decomposition, at least in my implementation, lacks the expected perfect 4-fold symmetry in the vessel properties (pitch/roll periods, for example) and RAOs. Comments?

You have our sympathy; this subjectivity is annoying, at best.

You have discovered one consideration that is helpful in making the choice between Column and Pontoon Dominant semisubmersible member decomposition: Vessel symmetry. Your vessel, like many modern semisubmersibles and virtually all TLPs (with the exception of some "mini" TLPs which have triangular symmetry), has a perfect four-fold symmetry in its underwater configuration. It is the nature of the "Pontoon Dominant" member decomposition that the simulation of the resulting member set will *not* in general possess a 4-fold symmetry axis unless you are careful in your choice of member definitions (see below for one method of improving pontoon symmetry). Usually, the asymmetry is negligible from a practical standpoint. Still, if seeing perfect symmetry is important to you, then choose the Column Dominant decomposition, which will ensure the desired 4-fold symmetry with a minimum of fuss.

That said, the pontoon-dominant configuration has desirable features, including a less problematic member added mass evaluation. To achieve the most symmetric possible pontoon-dominant configuration for your 4-fold symmetric case, do the following:

1. Lay out your pontoon structures as a singular 4-fold symmetric square annulus.

2. Choose an (off-center) pontoon member, with "base" at the water interface of the upper left corner of your annulus and with "top" abutting against a similar off-center member that covers the upper right corner of the annulus. Note: This second member comprises a simple 90 degree clockwise rotation about the annulus center of the first member. The second member, and the remaining two members of the 4-member annulus can therefore be obtained from the first by sequential use of the "Copy member" and "rotation" options in the editor. Note that the "base" of the first member should be type "free, submerged", and the "top" end of that member should be "wall terminated". (The proper end types will transfer automatically to the the correct ends of the other 3 members by the editor software during the copy operation.)

This procedure will produce a perfectly symmetric pontoon structure upon which to set the columns. Final note: While this procedure should produce a perfect symmetry in your pitch/roll periods, your RAOs will still show a small asymmetry (example: there may be a very small yaw moment in head seas). This is an unavoidable consequence of the approximations used to estimate forces and moments arising from fluid accelerations in the member added mass fields. This RAO asymmetry should be negligible from a practical point of view, but once again, if you need perfect symmetry, you're going to have to go to a column-dominant decomposition.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

When running Shipsim for a barge-like vessel with substantial forward speed (> 5 knots), I see some bizarre behavior; specifically, the surge motions appear to go haywire in following seas and the "Encounter Period" posted to SHIPRAO.stxt becomes very large (in my case, the longest wave encounter period reported is over 50 times the associated earth-fixed period). Is this a bug?

This is a Doppler shift/encounter period issue. The speed correction in Shipsim only accounts for the encounter frequency and wavelength of the requested waves; it cannot deal with the pathologies that develop when the vessel speed approaches the phase speed of the waves (i.e., the vessel is overtaking waves moving into the same angular hemicircle).

Physically, the problem is easy to understand, especially in the limit of following waves with phase speed exactly equal to vessel speed: In a first order model, if the vessel is moving in lockstep with a (following) wave field, the first-order surge/sway-related wave pressures are constant in time, so the vessel steadily accelerates in response to the steady forcing since there is no process in this linearized model to interfere with the forcing, and no static restoring force to counter it (as there is for heave, pitch, and roll). This is a fundamental limitation of the underlying linear analysis.

There are in addition other more subtle issues, such as the fact that the wave encounter period-versus-wavelength ("WE-WL") curve becomes double-valued for short wavelengths in following seas; that circumstance has some consequences for the spectral integrations.

In approaching seas, this pathological circumstance does not materialize; in following seas, it certainly does. In your case, any wave with an encounter period that is hugely distorted towards large values (compared to the earth-fixed wave period), such as your encounter period of > 50 times the earth-fixed wave period, should be excluded from your period set. You will see more of this, even in sway/yaw, if you carefully choose your following wave direction and period to capture the pathology.

You must simply limit your input period array so that the WE-WL curve does not become double-valued; otherwise, Shipsim will not give meaningful results. The encounter period column in each RAO table can be used, in a trial-and-error manner, for this purpose.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

I am having some trouble with single-line moorings in SPMsim and Moorsim. For example, a moored sailboat with a single tether to an anchor. Do you have any guidance on how to set up a simulation like this?

Moorsim cannot be used for this purpose; SPMsim is the tool of choice. That said, single line configurations present issues that need to be handled as special cases in the code, so you need to be prepared to carefully analyze the results of any such simulation. That is, you need to be on the lookout for suspicious behavior that appears unphysical; such behavior may flag a circumstance that was unforeseen by the "special case" paths through the code.

The central problem is that the quiescent equilibrium ("Q.E.") for a single-line system is ill-defined (since any vessel position/orientation which permits a limp vertical line from fairlead to bottom is a legitimate static equilibrium, associated with zero horizontal force and zero vertical moment). In order to function, SPMsim *needs* a well-defined Q.E. state. To achieve this, you have a couple of options:

1. Configure a two- or three- line system which *does* have a Q.E. For any nontrivial environment forces, the environmentally-driven mean offset will be one in which the up-weather line is acting, in essence, like a single mooring tether (the others essentially hanging limp).

2. If you (understandably) prefer a single-line moor, you can create a meaningful Q.E. by specifying your "pretension" condition for the single line using a "horizontal tension" of zero (on the "General Mooring Information" editor page). In this case, in the Q.E. state the single mooring line hangs limp from the fairlead until it contacts the bottom, then runs horizontally from touchdown to the anchor, using the entire line length to "find" the anchor. It is not hard to see that the presence of buoyant elements in that single line may interrupt this tidy picture, so even this strategy may fail if your single line has buoyant elements. In that case, you may be stuck with (1) above.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

The version 5.5x release notes explain that the output for the two settings of the "Legacy" normal mode flag in all of SeaSoft's comprehensive simulations (including SPMsim, Moorsim, TLPsim and Sparsim) should be nearly identical in aligned environmental conditions. I understand that some variables which do not affect the motions in aligned conditions, such as sway-yaw periods, damping, etc., will still differ). However, it seems to me that the surge motions *do* in fact depend on the setting of that flag even in perfectly aligned conditions. Can you comment on this? Which of these two differing results should I believe?

The release notes are referring to the underlying dynamical models for the normal modes themselves, which indeed are the same in the limit of perfectly aligned conditions and, other things being equal, would produce identical surge motions. However, there are differences in other details that can produce different surge motions, as you have observed. These differences relate to how the low-frequency response modes (which are the same) are used to obtain the statistical motion estimates. Obtaining these estimates requires integration of the response across the spectrum of excitations. In the "Legacy" treatment, this integration is forgone in favor of a simplified analysis that assumes the (slowly-varying) environmental spectra (waves, current, wind, etc.) are constant across the relevant low-frequency regime. This is a good approximation, but is not perfect. The newer treatment does the spectral integrals explicitly. This is an improvement over the legacy treatment; the newer stuff is better. Go with it.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I notice that in aligned conditions, the two settings of the "Legacy" normal mode flag in SPMsim produce quite different damping estimates for the two sway/yaw modes, even in perfectly aligned conditions. My understanding was that in aligned conditions there should be little, if any, differences in the SPMsim output stream between the two flag settings. Can you explain the differences I am seeing?

You should see only negligible differences in the reported *motions* (which are all in the "surge", or "parallel to mean offset" directions in perfectly aligned conditions). However, the damping of the sway-yaw modes will generally differ between the two flag settings; these values have no impact on the surge motions and can be ignored. The differences you note reflect in a qualitative way the approximate nature of the "Legacy" damping calculations, which calculations have been massively overhauled in the latest modeling efforts (post version 5.5) to replace the "Legacy" models. It should be stressed that, in any event, the breakdown in damping between the various environmental contributors is extremely qualitative; only the *total* damping levels are rigorously meaningful, for *either* setting of the "Legacy" normal mode flag.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

The Moorsim manual does not seem to clearly state whether mooring feedback forces are taken into account in estimating wave-frequency vessel motions, or even estimates of the natural periods of motion, for the moored vessel. Are they?

Except for the simulation of CALM buoys, as discussed in the Moorsim manual, Moorsim and SPMsim assume that mooring effects are negligible for the purpose of determining the natural periods of motion of the moored structure (usually, a shipshape or a semisubmersible). Accordingly, there is no feedback of mooring forces to vessel natural periods of heave, pitch or roll, or wave-frequency vessel motions. Mooring forces in Moorsim are, of course, managed fully, in all their nonlinear glory, for the purpose of low-frequency surge, sway and yaw estimates.

For Sparsim and TLPsim, the mooring structures play a noticeable (Sparsim) or central (TLPsim) role in the wave-frequency dynamics. Therefore, mooring feedback is fully accommodated in the wave frequency modules of Sparsim and TLPsim, both in natural period estimates and in vessel wave-frequency RAOs. One detail: For Sparsim, the mooring matrix contributions to natural periods are evaluated at the environmentally-determined mean offset. However the quoted heave, pitch and roll period estimates for TLPsim are evaluated, not at the mean offset, but at the quiescent (null environment) equilibrium point.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

The net spectral value tables in SLOWOUT.stxt seem to be in error. I presume these are simply sums of the individual contributions (wind, current, wave reflection, and wave absorption), which also are available in SLOWOUT. However, when I sum the individual contributions by hand, they do not match the value in the "Net Spectral Values" table.

You probably have the item "Exclude wave drag from net loads tables" toggled to "Yes" on Slowsim's "Page 15: Slowsim Output Options 2". If that is the case, SLOWOUT's "Net" values exclude the wave absorption (aka "drag") contribution from the Net values; if you also exclude these in your hand calculation, you should recover the "Net Spectral Values" result.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

In comparing SPMsim "legacy" and "non-legacy" output from LOWOUT, for otherwise identical datafiles, I am puzzled by the reporting of yaw motions in the two cases. In the "legacy" case, two of the "normal modes" produce yawing motions (i.e., the two "sway-yaw" modes, which typically are associated with vastly different natural periods). Depending on the details of the legacy simulation, either mode can dominate the net yaw. In the newer (v 5.55+) incarnation, there is reported only a single "yaw" mode which purports to include all yawing motion, so it presumably contains contributions from both of the "legacy" sway-yaw modes. But in v 5.55+ all this yaw energy is reported at a single modal period (usually a very short period, comparable to the legacy "high-sway-yaw" mode period). Can you comment on this peculiar circumstance? Surely the dynamics model cannot be that different between the two (i.e., legacy and non-legacy). Prior to the newer normal mode treatment, I regularly used the yaw information in LOWOUT to estimate the low-frequency lateral motion spectra of riser attachments; how can I extract equivalent yaw spectral information from the newer normal mode reports?

You are absolutely correct; the qualitative numerical characterizations of the new "normal modes" presented in LOWOUT are very subjective and fail to provide much useful insight to low-frequency motions in some circumstances (usually, in highly crossed environments). In the newer version 5.5+ modal treatment, the 3 low-frequency degrees of freedom comprise yaw, plus the x-y location of the turret (reported in a right-handed coordinate system whose x-axis points from the turret towards the quiescent equilibrium point). The "legacy" reporting was problematic for comparisons to model test results because, among other problems, the two "sway-yaw" modes do not correspond to commonly reported quantities. In reasonably aligned conditions (vessel aligned within 15 degrees or so to the turret mean offset vector; this is a rough upper limit of the range of validity for the legacy treatment), the three new modes correspond approximately to the legacy modes. That is, the new "second" mode ("motion roughly orthogonal to mean offset"), which usually (but not always) has the longest reported period, corresponds roughly to the legacy "low sway-yaw" mode; as such it will usually be responsible for considerable yawing motion, in addition to sway. Similarly, in highly *misaligned* conditions (for example, vessel heading close to 90 degrees from the mean offset vector), the new "first" mode will likewise be responsible for considerable yawing. The *magnitudes* of the net yaw are always given by the RMS and peak values for the new "third" mode, but *each* of the three new modes can contribute appreciably to net yaw, so the spectrum of the yawing motion can in general display three response peaks, one at each of the three normal mode frequencies. In this sense, the period associated with the newer "third", a.k.a. "Yaw" normal mode is only associated with a portion of the net yaw, which as noted has in general contributions from all three modes. In most cases, the majority of the yawing does come from the third mode, but this is by no means always the case. Note that in the near-aligned circumstances for which the "legacy" treatment is valid, the yaw spectrum will typically display two well-defined peaks.

With respect to determining the spectra of the low-frequency motions for riser analysis, you actually have much better information in the new (v 5.55+) output stream. In particular, a new output file ("LF_SpecDat.stxt"), gives vastly improved low-frequency spectral estimates; search the FAQ for "LF_SpecDat" for notes on this resource.
Added:     Oct 4, 2013
Modified:  Jan 16, 2014

Could you indicate the SeaSoft source information on the Ochi-Hubble and TMA wave spectra?

Everything we can tell you can be found in the online help for those items: A widely available reference paper by Ochi and Hubble can be found in the Proceedings of 15th Conference on Coastal Engineering, Honolulu, Hawaii, 1976; "Six-Parameter Wave Spectra". The SeaSoft implementation supports up to 4 sub-spectra. The original TMA reference is "The TMA Shallow-Water Spectrum"; 1984; Hughes, S.; US Army Corps of Engineers Technical Report CERC-84-7.
Added:     Oct 4, 2013
Modified:  Oct 4, 2013

My understanding is that the "Legacy" and "Non-Legacy" output streams should be nearly identical in the limit of fully aligned conditions (i.e., aligned environment and vessel aligned with the mean offset). However I regularly see differences that are greater than any expected "numerical chatter". Could you address this issue?

If you ever see substantial differences (say, ~10% or more) between legacy and non-legacy treatments in the aligned conditions that you describe, please submit your data file to SeaSoft. There are differences in the legacy and non-legacy treatments that can lead to (usually small) low-frequency motion estimates, even in perfectly aligned conditions. The most significant source for these differences, and the likely cause of your observed discrepancies, is how the two methods derive their motion variances. The "legacy" treatment uses a simplified "white noise" method to estimate motion variances (i.e., it assumes that the spectral shape of all low-frequency excitations is sufficiently flat in the vicinity of the relevant low-frequency resonant frequencies that the variances can be derived from a simplified "white noise" integration that uses *only* the spectral values at the three resonant frequencies.

The "non-legacy" treatment, by contrast, actually performs the necessary spectral integrations, thereby sampling portions of the environmental spectral function far from the modal periods. In the limit of very low damping, these two methods should yield the same result. However, for finite damping the results can differ, usually more or less in lockstep with the associated damping levels.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Do the various options for internal SeaSoft semisubmersible RAO estimates, such as: 

  4) Square-law driving force treatment: <<Resonant damping ONLY, no square-law driving forces>>
impact the output stream when providing user RAOs with a USERRAOS.txt file?

With respect to measures of motion (RAOs, RMS values, etc.), no. The supplied user RAOs are used for *all* vessel motions regardless of the value of the "Square-law driving force treatment". However, some useful portions of the output stream (e.g.: The natural periods and damping estimates reported in SEMISUM.stxt, the driving force RAOs reported in SEMIRAO.stxt, the significant forces and moments reported in SEMIRAN.stxt) can obviously *not* be obtained from a USERRAOS.txt file. Instead, these estimates must be derived from the internal dynamics algorithms. Again, however, these values do not impact the reported wave-frequency *motions*.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Shipsim can estimate linearized roll damping from bilge keels. (And Semisim can estimate heave, pitch and roll damping from square-law forces on its members.) Will those damping estimates be used to modify RAOs if one specifies a USERRAOS.txt file? Or are user-supplied RAOs understood by your software to have already been corrected for any nonlinear effects?

The latter: When you supply RAOs, they are not altered in any way before being used. Shipsim (and Semisim, and Discsim) *will* still estimate the damping, and report it in SHIPSUM.stxt (or SEMISUM.stxt, DISCSUM.stxt). If you have no other way to estimate this damping, you could do a run (with or without user RAOs), get the SeaSoft square-law damping estimates, and then incorporate those into your external RAO generator. This is pretty kludgy and problematic, especially since the exercise needs to be repeated for every environment if you seek any defensible level of rigor.

One additionally important semisubmersible consideration: There is no mechanism, when using user-supplied RAOs, to have the heave/pitch/roll/surge/sway/yaw amplitudes *at all periods* reflect the impact on regular-wave vessel response (amplitude and phase) of square-law drag forces acting via the relative fluid-vessel member velocity field. This SeaSoft-only option is superior, in our view, to other available methods of estimating and applying "effectively linearized" damping constants to the otherwise linear responses produced by all external diffraction-based RAOs.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I understand that Shipsim has no accommodation for differing longitudinal benchmark points (such as LCB, LCG, waterplane centroid, mooring centroid, etc.). For at least one purpose, though, it would seem to matter: The location of mooring fairleads. What point on the actual vessel should I use as the solitary "SeaSoft Centroid" with respect to the fairlead locations?

First, just to review: Shipsim simulates an "equivalent box" with LCG, LCB, waterplane centroid, and fairlead centroid all overlaying the box plan-view center of symmetry. Therefore, there is an element of engineering judgement in deciding what to use as the longitudinal origin for vessels lacking perfect fore-aft symmetry when moorings or other vessel-bound measurements are involved (e.g., wind or current area centroids). Note that Discsim and Semisim, similarly, have a single "SeaSoft Centroid" for all the same plan-view "centers" (LCB, LCG, etc.). Only in rare cases does the non-coincidence of these points on a real vessel matter for an analysis of mooring performance. However, as you have noted, there is one issue worth pondering: The main objective for any mooring analysis is obtaining the best possible estimate for wave-freqeuency fairlead motions. That objective is arguably best served by choosing the "SeaSoft Coordinate Centroid", whose principle function is to establish the fairlead locations in space, to be the waterplane centroid of an asymmetric vessel. This choice assures that in the important long-wave limit (in which all hydrostatically stable floaters become surface-following objects with deck parallel to the instantaneous surrounding water surface), the fairlead motions are as faithfully represented as a first-order analysis will allow.

To further clarify the waterplane centroid coordinate origin recommendation: As an extreme example, if the coordinate origin used to define fairlead locations were to be located at the stern of a shipshaped vessel, then any pitching would evidently produce considerable error in both the phase and amplitude of earth-relative vertical fairlead motions (given that all "equivalent box" wave-frequency angular motions will be returned relative to the waterplane centroid). In the long wave limit the vertical positions of fairleads are only perfectly represented if their coordinate origin lies at the vessel waterplane centroid.

Practically speaking, however, you are going to be just fine if you use, as most engineers will do without even thinking about it, the LCG as the SeaSoft plan-view coordinate origin used to establish fairlead locations.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

All SeaSoft simulations go beyond commonly available diffraction-analysis-based "wave drift forces" (a.k.a. "DFCs" or "quadratic transfer functions") with (1) square-law Morrison-type hull forces due to wave-vessel relative motions (I will call these "viscous" drift forces), and (2) current corrections for both the DFCs and the "viscous" contributions. Mean current effects are particularly profound in crossed current-wave conditions. If I supply my own wave DFCs (obtained with, e.g., WAMIT) in a DRFTCOFS.txt file, are all these other features ("viscous" drift force, wave-current interactions) then disabled, or are they still functional?

All SeaSoft "comprehensive" simulations (SPMsim, Moorsim, TLPsim, Sparsim, Towsim, CALMsim) will, upon request, supply current corrections to user-supplied drift coefficients (DRFTCOFS.txt). There is an option to turn this feature on or off, which appears once you select the DRFTCOFS.txt option; the corrections are OFF by default. The "viscous" contributions are also controlled with an on/off flag under user control, so you can mix and match DRFTCOFS.txt, current corrections and "viscous" contributions at your liesure.

However, we would point out that in all cases we have investigated (admittedly not exhaustive), the differences between SeaSoft built-in DFCs and WAMIT DFCs are inconsequential when viewed in light of the (typically) profound effects of both DFC current modifications and the inclusion or exclusion of "viscous" low-frequency forcings. In our view, this observation suggests that user-supplied DFCs are of questionable value in improving the quality of your SeaSoft low-frequency motion estimates.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I prepared two Sparsim datafiles that were identical except for the global angles of vessel, mooring and environment. The "baseline" file had a head-on environment (wind, waves and current with 180 degree headings). The second data file was identical except that the vessel initial heading and all mooring line departure angles were rotated through 45 degrees; the second file's environment was likewise rotated through the same 45 degrees. I was checking to see if all vessel- and mooring-line related output items (low- and wave-frequency motions and loads) were the same between the two cases, as symmetry would demand. For the most part, the expectations of symmetry were realized, *except* the net vessel snapshot loads presented in LOWOUT and SNAPOUT. These were in some cases significantly different. Looks like a bug to me.

Annoying and confusing, yes; arguably even poor simulation design, but not a bug.

The global "snapshot" locations selected in your two cases will not be the same (as explained below), hence the snapshot *loads* quoted will also be different, even though the environment, relative to vessel and moorings, is identical between your two cases.

Snapshot locations are a somewhat arbitrary collection of (Gx, Gy, Yaw) points within the vessel's low-frequency motion envelope, (said envelope comprising all energetically achievable locations of the vessel centroid (Gx and Gy) and vessel yaw angle). The heuristic used to choose these snapshot points depends on the orientation of the (roughly elliptical) low-frequency envelope, which envelope is specified in the *global* coordinate system. The snapshot selection process involves finding the {Gx,Gy} extremes of the envelope; a non-circular envelope will in general produce snapshot points that lie at different locations along its closed envelope curves, depending on its orientation in the global coordinate system (e.g., rotated 45 degrees in your computer "experiment" when going from "baseline" case to your second, rotated, case). At this moment, we would be hard-pressed to defend this methodology as optimal; it is more or less an historical accident. If we were doing it over again, we would seriously consider using *vessel-based* coordinates for snapshot point selection in order to eliminate the symmetry failure you have noted. Fixing this is on our to-do list but is low priority.

Note that the same issue applies to TLPsim and Moorsim, although the perfect azimuthal symmetry of a moored spar made it easier to spot. Furthermore, the snapshot locations also creep into the XCLDAT vessel extreme and RMS load estimates, so these loads will likewise fail a strict symmetry analysis similar to the snapshot loads given in LOWOUT and SNAPOUT.

Finally, realize that the *practical* implications of this symmetry failure are nil; the differences you note lie well within the acknowledged range of uncertainty of these simulations, so aside from cosmetics, this annoyance is a non-issue.
Added:     Oct 4, 2013
Modified:  Oct 17, 2013

I created a shallow-water single-column semisubmersible in Moorsim to simulate a round drilling vessel (my company has no Discsim license; this was a temporary work-around until we could make licensing arrangements). The "wave drag" particulars for this vessel are significant, so I ran Slowsim to get the wave absorption (aka wave drag) coefficients for head-on waves and aligned current (I naturally expected the wave drag coefficients, like the wave drift/reflection coefficients, to be negative in head waves). I was quite surprised to see that for a small range of wave periods about the vessel natural heave and pitch periods (which were nearly the same in this case), the wave drag coefficients changed sign and became positive. This would seem to be impossible; have I discovered a bug?

The analysis of wave drag on a cylinder is surprisingly tricky and full of surprises; you've just come across one. The drag coefficients depend on the relative RAO between the vessel and the incoming wave. As the relative motion goes to zero (as it will for very long waves, where the vessel motion closely mimics an extended fluid volume undergoing its canonical orbital motion), the wave drag coefficient likewise goes to zero. A simplifying approximation is made in computing this relative vessel-wave RAO: The vessel motion at the "bow" (by which in your case we simply mean the vessel point which first encounters an incoming wave crest) is used for the relative motion calculation. The deepwater surge RAO (in meters of surge/meter of wave amplitude) for an unmoored vessel will always be less than unity (tending to unity in the long wave limit and to zero in the short wave limit). The pitch RAO, by contrast, can produce substantial "surge" motions of the "bow" at waterline level, depending on the location of the CG and CB, the pitch damping levels, etc. A resonant pitch contribution (in a lightly damped circumstance) can produce a surge RAO of the vessel bow point greater than unity and with a considerably altered phase relative to the water particle motions. When circumstances are right for this to occur, it can set the stage for a reversal of the wave drag forces (which as you correctly surmised, will always be in the direction of the incoming wave vector if impinging on a fixed vessel). So, what is likely happening is that your vessel is getting a sufficient phase and amplitude shift in the "bow-at-waterline relative to water particle" RAO (due to resonant pitching), thereby reversing the sign of the drag force. The fact that you observe the reversal in a band of periods near pitch resonance supports this likelihood. If you use Semisim to get bow-at-waterline surge RAOs, you should be able to verify this. Note: Semisim supports output of the "relative RAO" needed to assess and analyze this phenomenon in detail.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

In the analysis of wave drift and drag forces on a caisson spar, I noticed something that I do not understand. When running waves "downstream" (i.e., parallel to the current), the wave drag (aka wave absorption) coefficients indicate drag forces in the downstream (and down-wave) direction, as expected. However, when I run waves *against* the current I sometimes find, for a (usually limited) range of wave frequencies, a change of sign in the wave drag coefficients (i.e., the drag forces align with the direction of the *current*, and opposite the direction of the *waves*). My primitive understanding of the physics of the wave drag forces suggests the force should always be in the direction of the waves. Can you suggest what is producing this reversal?

The wave drag (aka absorption) forces are full of surprises in the presence of an underlying current. With current and waves aligned, there is not much to catch your eye, but once the wave and current directions are in opposition, there are complications. Furthermore, the relative vessel-wave particle relative RAO also comes into play (see the preceding FAQ for an instance of that complication).

The SeaSoft implementation of the wave drag/absorption force on a column comprises separate contributions from the "surface" wave zone (between wave crest and trough) and from the "sub-surface" zone (depths beneath the wave troughs). For a *fixed* cylindrical column, and for a regular (i.e., single-frequency) incident wave, to which we limit this discussion for simplicity, the "surface" wave drag force contribution always lies in the 180 degree angular sector bisected by the wave vector (to lowest meaningful order in the incident wave amplitude), regardless of the direction of the current. Similarly, and again to lowest order in the incident wave amplitude, the "sub-surface" wave drag force contribution lies in the 180 degree angular sector bisected by the *current* velocity vector, regardless of the wave vector direction. (Note that the "wave drag" contribution to the total sub-surface drag force is in addition to the usual Morison square-law force arising from the mean current.) When wave and current align, the surface and sub-surface force contributions are aligned; when wave and current oppose, the net effect can favor either the surface or the sub-surface contribution; that is, the projection of the resulting net (surface + subsurface) force on the wave vector can be positive or negative, depending on details (current speed, current profile, wave frequency, etc.). Furthermore, since the [wave-relative-to-vessel] RAO is implicated, there is still further opportunity for mischief, although for a caisson spar, vessel motion can generally be ignored in this kind of qualitative discussion.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I have noticed, when using the "Full square-law driving force calculation at all wave periods" damping option in Semisim, that the RAO peak values at heave resonance (from SEMIRAO.stxt), sometimes appear to differ slightly from what I would expect based on SeaSoft's percent of damping (as quoted in SEMISUM.stxt) and the quoted force RAOs (also appearing in SEMIRAO.stxt). I have had another colleague check my work and I am certain our calculations are not in error; can you comment on a possible source for these differences?

Using linear (or linearized) damping when computing and/or comparing RAOs from linearized theories is formally a little problematic in this circumstance, since the SeaSoft damping quotes (given in SEMISUM as you have noted), when using the "Full square-law driving force calculation at all wave periods", relate to a completely separate nonlinear damping estimate, unconnected to the output RAOs. When the "Full square-law" damping option is selected, the independently estimated (SEMISUM) damping values, though unused, are provided as a kind of "sanity check", but the RAOs reflect, as advertised, the full quadratic damping at each wave period; no linear damping (likewise, no "effective linear damping") even enters the RAO calculations in that case. So there will always be differences between "Full square-law" treatment RAOs and any RAO produced (by SeaSoft or anyone else) based on a simpler linear/"effectively linear" model (such as the "Resonant damping ONLY, no square-law driving forces" SeaSoft option). This is a little like the situation when providing your own RAOs (Semisim or Shipsim or Discsim); the SeaSoft damping/period estimates are still given in SEMISUM/SHIPSUM/DISCSUM, but they are for qualitative/informational purposes only. They are not used in the output motion estimates.

So, bottom line, the precise agreement you expected between your RAOs and an "equivalently linearized" damping value is not going to materialize in general. That said, even with the "Full square-law" option in play, Semisim RAO peak value differences with quoted resonant damping should be, as you have in fact observed, modest.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I am studying the effects of wave drag excitation (a.k.a. "wave absorption") on low-frequency surge motions in TLPsim. In the process, I compared TLPsim output (specifically, LOWOUT) to the information (differently presented but supposedly equivalent) produced by Slowsim in SLOWOUT. In some of my environments, TLPsim predicts greater surge variability (as quantified by the surge RMS contributions in LOWOUT) from wave drag forcing than from wave drift forcing. Yet, looking at the regular wave spectral information for "drag" and "drift" available in SLOWOUT, it seems to me that wave drag forcing variability should be *less* than wave drift variability. Can you comment on this apparent discrepancy? Which of these predictions should I believe, TLPsim or Slowsim?

We are embarking on a pretty esoteric discussion here, so gird yourself. The quick answer to your last question is that both Slowsim/SLOWOUT and TLPsim/LOWOUT are correct, but need to be properly interpreted.

Historically, the "wave drag" contribution to steady and variable forcing for semisubmersibles, spars and TLPs, especially in the presence of a significant background current, has in our view been woefully neglected in the design process; nonetheless, in a nod to user expectations and to historical interest, we therefore felt compelled to give a central role in LOWOUT to wave-drift-only forces and variability, whether or not wave drag effects are requested by the user (wave drag *can* be disabled in all SeaSoft simulations, and it often is, much to our dismay). Furthermore, when wave drag effects *are* included, the user plainly wishes in addition to the "wave drift only" contribution, to determine the *net* [wave drift + wave drag] forcings and variability. For mean forces, this is simple: mean forces arising from the two contributions simply add to produce the net wave-related quasi-static forces and moments. The *variability* of these forcings, however, is a bit more complicated.

Wave drift and wave drag forces are highly correlated; both are directly related to the crest envelope of passing wave groups, or wave "packets". This means that as a large wave group passes the vessel, both wave drift and wave drag forces rise to their highest levels, and subsequently fall off again, approximately in lockstep with the envelope of the passing packet. Put another way, these forces are not statistically independent as are, for example, wind and current forcings. In quantifying the net variable forcing from the wave [drift + drag] combination in spectral terms, one must take into account the strong correlation between the two contributions. This means that the spectral strength of the combination of [drift + drag] will be greater than the simple sum of the spectral contributions of each taken alone; this is in contrast to the [drift + drag] mean force contributions, which as noted above simply add. In extreme cases (equal contributions from drift acting alone & drag acting alone), the net wave variability (measured by the net [drift + drag] wave forcing spectrum) will be *twice* that which would obtain if the two were statistically independent (or statistically dependent but totally uncorrelated).

But it gets more complicated still: The wave drag force comprises a "surface" and a "subsurface" component; in the absence of current the lowest-order *subsurface* contribution vanishes but, in the presence of a mean current it can be considerable (indeed it commonly dominates the total wave drag contribution in that case). This means that in the most general situation (i.e., involving current), the wave [drag + drift] spectral calculus involves *three* highly correlated contributions: wave drift, subsurface wave drag and surface wave drag. Frankly, that produces too much spectral information to be useful (auto- and cross-spectra between 3 independent forcings along 3 directions: (3x3)^2 = 81 contributions, 45 of which are independent) to attempt to organize and display meaningfully. Therefore we have elected to display in LOWOUT only the drift-only spectral information (in terms of the drift-related RMS surge variability in your case), and "everything else" that flows from the inclusion of wave drag effects and their correlation with wave drift. In practice, this means that the wave drag excitation, when viewed *without* wave drift contributions (this relates to the Slowsim output stream) can be smaller than the wave drift excitation alone, but adding the two effects together can make the difference between the *total* variability (drift + drag), and the *drift alone* variability, greater than the *drag alone* variability because of the correlations. Mathematically:

      Stot(w) = Sdft(w) + Sdrg(w) + Sdft-drg(w).
Here, Stot, Sdft, Sdrg, Sdft-drg represent the total drift + drag spectral energy, the drift contribution, the drag contribution and the total cross-spectral contribution from the interaction of drift and drag.

In the LOWOUT display, we display the variability (for each low-frequency normal mode) due to wave drift (Sdft), and due to all drag-associated phenomena, which we call here Sdrg_LOWOUT:

      Sdrg_LOWOUT = [Stot - Sdft].
In highly correlated systems, as we have here, it is common to find that even though drift-alone forcing exceeds drag-alone forcing:

      Sdft > Sdrg
that the totality of drag-associated forcing (Sdrg_LOWOUT) exceeds the drift-alone contribution (Sdft):

      Sdrg_LOWOUT = [Stot - Sdft] = [Sdrg + Sdft-drg] > Sdft.
That is the explanation for the evident discrepancy you have noted. Moral of the story: It can be tempting, but dangerous, to "neglect" the smaller of two contributions to a highly-correlated pair of forcings,
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I understand from other FAQs that the mean and variable forcings due to wave drag (a.k.a. "wave absorption") depend sensitively on the mean speed and vertical speed distribution of any simultaneous current. Yet, experimentation with both Moorsim and Slowsim seems to indicate that this dependence does not extend to shipshapes. Could you please explain this?

It is pretty simple in this case; natural complexity sometimes forces us into imperfect analytical simplifications to make even modest progress.

The issue of wave drag contributions to the low-frequency dynamics of semisubmersible/spar/TLP type vessels ("semi-type structures") is expected to be particularly important for this simple reason: The highly transparent nature of these structures to the wave field means that the drag forces have a greater opportunity to compete with wave reflection forces (a.k.a "drift" forces) for impacting system low-frequency dynamics. This is in contrast to shipshapes, whose blocky surface and sub-surface profiles are notoriously opaque to the waves, offering relatively less surface-relative-to-displacement-volume upon which to act. Therefore we anticipate that wave drag forces, especially as enhanced by current, will be relatively more important for semi-type structures than for shipshapes.

SeaSoft's "semi-type structure" wave drag analysis is presently limited to surface-piercing columns; these are simple shapes geometrically, but even with that simplicity, evaluation of the spectral properties of wave drag forcing in the presence of current is a *very* complex enterprise. Shipshapes require a still more complicated analysis in the presence of current; indeed it may not be possible to make a meaningful and physically justifiable analytical model, absent a full-on CFD implementation (computational fluid dynamics analysis of the complete Navier-Stokes equations). For this reason, our shipshape wave drag analysis is presently limited to the "zero current" condition. As a result, as you have noted, wave drag contributions (mean and variable forcing) to low-frequency dynamics of shipshapes are independent of current. Since the presence of current will, in the important case of aligned waves and current, enhance the potency of the wave drag contributions to mean and variable forcings, SeaSoft's implementation of wave drag on shipshapes should be expected to provide a lower bound on wave drag effects in the presence of current. The underestimation of the drag effects may be substantial; until we can actually compute it in a meaningful way, we can't even estimate the degree of underestimation. (Note: Drag force estimates for waves running *against* the current can be expected to be *overestimated*).

As an aside, we have not to date extended the semi-type analysis of wave drag to the deeply submerged pontoon structures associated with semisubmersibles or TLPs, primarily because the limited wave action at pontoon depth (due to exponential attenuation with depth) means that wave drag forcing on those structures is much smaller than that on surface-piercing members. Indeed, in the *absence* of current there is *no* wave drag contribution from submerged members, to lowest order in our analysis. Even in the presence of a current (which presence elicits a wave drag contribution to lowest computed order, even for submerged structures), we estimate the ignored pontoon contribution to be less than a few percent of the total [drift + drag] contribution in all but contrived situations. Nonetheless, as for the neglect of current on shipshape wave drag, this omission does mean that in the important "aligned wave and current" cases, our wave drag forcing estimates for semi-type structures with pontoons are, formally speaking, lower bounds, although we expect the error from this omission to be dwarfed in practice by other errors, omissions and imponderables. Again, as for shipshapes, in cases with waves running *against* the current, the omission of submerged members in the estimate will cause the wave drag forces to be overestimated (i.e., the estimates can be considered upper bounds).
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I have been a SeaSoft user since 1990; we have some very early SPMsim data files (these date to version 3.x, I believe) that I wish to resurrect and run under the current SPMsim. So far, I have been unable to get this to work. Any ideas?

Very old data files (pre Version 4) are problematic; many, many changes to the SPMDAT structure have occurred since the earliest versions (Version 1.0 -> Version 4.0). If you *really* want to do this, we will try to help. You may already have the required software tools in your archives, but it will probably require access to a classic Macintosh, which was the platform your file was created on. However, you are *almost certainly* best served by just rebuilding the SPMDAT file from scratch in your current 5.57 application, using the SPMIN text file associated with your SPMDAT file (you did archive both of those as recommended, right?).

If you have time on your hands and don't have access to the SPMIN text file, your work is cut out for you. In addition to the need for a computer capable of running the classic Macintosh apps described below, you will have to deal with the transition from Macintosh 68k -> Macintosh PPC -> Macintosh Intel hardware and Operating Systems. We have done this and it *is* possible, but is not for the weak of heart.

1. Depending on your SPMDAT version, you will have to run it through one or more SeaSoft datafile updaters. The SeaSoft data files went through three major reorganizations that were profound enough to require separate updaters. These all must be run under the Classic Macintosh OS (on actual hardware, or in an OSX version that supports classic apps, such as OSX 10.4 Tiger).

      Version 1.x -> Version 2.x (Updater "V1V2")
      Version 2.x -> Version 3.2 (Updater "V2V32")
      Version 3.7x -> Version 3.8x (Updater "16-49" 16-mooring line to 49-mooring line conversion)
2. There is also an issue in the transition from Macintosh OS 10.x PPC apps to Macintosh Intel apps, which may require access to a Mac that runs PPC apps (this requires OS 10.6.8 or earlier).

If you are determined to do this, you should start by sending us a copy of the datafile and we will try and help with specific instructions (or, we may just do it for you).
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

A TLP analysis I am conducting is producing different quasi-static loads between TLPsim and Catsim for an identically configured vessel and mooring setup: I first made a TLPsim run with waves alone plus a simulated current and wind using applied forces (specified on editor Page 11: External Force/Moment Specifications). For simplicity, the simulated wind and current loads were aligned with the wave vector and applied at the waterline; thus, all forces act at the same vertical point on the TLP (i.e., KZ = vessel draft). I then prepared a Catsim run with the identical vessel and mooring/riser setup, selecting the "Offset Type: Specified Force; Continuous Static Equilibrium" option, with a selection of "global" forces in the same direction and acting at the same application point (at the waterline-level plan view centroid) as the applied forces in TLPsim. When I compared the tendon tensions and horizontal component of tendon tensions between TLPsim's LOWOUT.stxt and Catsim's OFFSETS.stxt, the results were reasonably close, but I was anticipating indistinguishable output. Generally, the LOWOUT.stxt values in the tendons with largest mean tensions are consistently larger than the OFFSETS.stxt values (for the same offset distances); the tendons with smallest mean tensions are consistently smaller than the OFFSETS.stxt values. Is this a bug, or is there an explanation?

This difference arises from an algorithmic design choice in TLPsim, made to trade off execution time against computational rigor. In TLPsim, a Catsim-level of effort in the determination of quasi-static mooring loads as a function of the 6 degrees of vessel freedom required for TLP low-frequency response analysis proved to be unacceptably cost intensive computationally, so a simpler and more approximate procedure was adopted. The precision loss was deemed to be acceptable and within uncertainties set by many other considerations, both numerical and physical. It is a design judgement call. Which values are best? The Catsim values should be better.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I have noticed very substantial differences in the low-frequency yawing estimates coming from the "legacy" and "non-legacy" normal mode treatments in SPMsim. I have seen differences of as much as a factor of five in the rms yaw (the magnitude of these differences is very environment-dependent). The differences are sufficiently large that I would like some explanation, as well as some guidance as to which results are more trustworthy.

I agree this is a little troubling, but you are always best served by using the newer ("non-legacy)" modeling; it is almost without exception vastly superior to the "legacy" modeling.

Some historical perspective may provide insight: When the legacy model for SPMsim was first developed, the central objective was to provide estimates of mooring loads; this objective drove software design decisions that strongly favored low-frequency mooring *loads* over *motions*. Further, the so-called legacy "low sway-yaw mode" can be roughly visualized (at least in highly aligned environmental conditions) as a slow yawing of the vessel about a point in space not far from the anchor centroid on the seafloor (or, more accurately, the *null-environment* turret location). As visualization aid, imagine a compound pendulum (the vessel) suspended by a tether (the mooring system) in a very weak "gravitational field" (produced by mean environmental forces). It is intuitively evident that very slow oscillatory motions of this system, having as they do resonant periods usually well in excess of 20 minutes, produce negligible accelerations of the vessel and, correspondingly, contribute negligibly to mooring forces; so negligibly, in fact, that the low-sway yaw motions are completely ignored in legacy mooring load estimates. Thus, even large errors in the low sway-yaw motion estimates for this mode are tolerable with respect to mooring loads. As a result, the net vessel low-frequency yaw, which will generally include a large contribution from the low sway-yaw mode, received relatively little attention in the legacy modeling. It was in response to this and other related deficiencies that the "legacy" model was replaced, around version 5.55, with a rigorous 3 degree-of-freedom low-frequency dynamical model that produces more reliable low-frequency yaw predictions, even in highly crossed conditions.

Generally speaking, the "legacy" and "non-legacy" treatments can only be expected to give comparable yaw results in highly aligned environments. If the mean vessel heading, relative to the turret mean offset vector (the "misalignment" angle), is more than about 10 degrees, or more generally in any highly crossed environment (even one which, by virtue of near cancellation of opposing environmental moments about the turret, produces a misalignment angle near zero), the yaw predictions of the legacy model will be compromised (sometimes, as you have noted, very substantially so).
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

In early versions of Moorsim for semis, the vessel length and beam at waterline ("LWL", "BWL"), appearing on the "Vessel Hydrostatic Characteristics" page of the editor, played a role in determining the wave drift force coefficients ("DFC's") used internally to compute the mean and variable wave drift forces on the vessel, and available as tabular output in Slowsim. This dependence appears to remain when the "Legacy Semi" DFC model is selected. However, I notice that the more recent DFC model ("semi 2001" in the DFC selection list) does not seem to depend on the LWL, BWL values, yet the mean drift forces do depend on those values. Could you review for me how the LWL and BWL are used in the two semisubmersible DFC models ("2001" and "legacy")?

Apologies for the confusion; you are not alone. First, we strongly recommend the use of the newer ("2001") semi DFC model; the "legacy" model is only supported to permit backwards compatibility with earlier versions of Moorsim.

As you have noted, the 2001 semisubmersible dimensionless drift force coefficients (as output by Slowsim and used internally by other SeaSoft products) are independent of LWL and BWL. However, as noted on the SLowsim output pages, the *dimensional* {x,y} forces are proportional to the product of the dimensionless coefficients and the BWL or LWL, so that the drift forces themselves also depend on those values.

As noted in the online help item for beam and length at waterline, for semisubmersibles these values should comprise the total waterline length of all water-piercing members projected against a vertical plane. This restriction on LWL, BWL for semis is not enforced (e.g., by execution failure), but will produce a runtime notification if the semi water-piercing member information is at variance with the LWL or BWL.

This is all subjectively quite different from the situation with the "legacy" DFC model for which, as you note, even the *dimensionless* drift force coefficients depended on the LWL, BWL and "shadowing" factors. To restate: here and elsewhere, avoid the "legacy" models unless you have a very good reason to choose them.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I notice that there are two types of current loading on semisubmersibles in Moorsim; one relates to hull projected areas and a "current enhancement coefficient", the other is via hull member's drag coefficients. Are both of these used simultaneously, which means double dipping the current load? This is admittedly very confusing; there are a number of historical issues involved that contribute to this state of affairs. But, be assured: There is no "double dipping".

Briefly, the mean current load, and any variable current-only load (from a specified current spectrum), is derived from the user-specified current areas and "enhancement factors" specified on the "Vessel Environmental Area, Moment and Enhancement Data" page of the editor. Note in particular: *These* loads are independent of the wave environment and depend *only* on the current and the areas and current enhancement coefficient, and current spectrum if any. Note that these current-only parameters need to be specified *even in the absence of current*: They are used elsewhere in all comprehensive Moorsim-type mooring simulations, including SPMsim, TLPsim, etc. (for example, in order to estimate nonlinear square-law damping arising from low-frequency surge/sway/yaw motions).

On the other hand, semi member drag coefficients are used only for *wave-related* purposes:

1. They impact the wave-frequency RAOs through Morison forcing, and

2. They are used in the "wave drag" (aka "wave absorption") contribution to mean and low-frequency vessel forcing.

Nonzero static (mean) and low-frequency forcing from item 2 requires a wave field and is independent of the current-only forcing set by the projected areas. The wave drag contribution *does* depend on the current, in addition to the waves, but this is an additive contribution, above and beyond the current-only contribution.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I have noticed, when reviewing the "Diagnostics.stxt" file associated with each execution in a batch run scenario, different styles of progress indicators associated with different notifications. For example, gathered from a recent run, I found the following distinct alert/progress items: 

      >>> Computing mean vessel offset and orientation...

      --> Computing raos and irregular wave statistics...

      ++> Infinite surge period in QDYNAM

      +=> Suspiciously large separation between pitch and roll rotation centers;
          please forward this datafile to SeaSoft for analysis.
Can you comment on the logic, if any, behind the typographic structure of these notification darts?

Progress/notification dart differences can be useful for doing searches on batches of Diagnostics.stxt files for particular types of exceptional conditions encountered at runtime.

Here is a partial catalog of the dart styles found in the runtime console stream (and in Diagnostics.stxt files):

      >>> Computing mean vessel offset and orientation...
This is routine progress information to help track of where in the execution sequence runtime anomalies occur; by far the most common, it is issued directly by the calling program (e.g., Moorsim or SPMsim).

      --> Computing raos and irregular wave statistics...
This is routine progress information issued by subordinate routines to the calling program (e.g., issued by Shipsim modules invoked during an SPMsim run).

      ++> Infinite surge period in QDYNAM
This is a informational warning of a serious condition encountered at runtime; it will often, but not always, result in termination of batch jobs.

      +=> Suspiciously large separation between pitch and roll rotation centers;
          please forward this datafile to SeaSoft for analysis.
This [ +=> ] dart style flags the occurrence of an unexpected and possibly (but not necessarily) serious runtime anomaly, usually relating to relatively recent code changes that have yet to benefit from exhaustive testing "in the field" under routine use; these will usually be accompanied by a "Please report this occurrence to SeaSoft" or equivalent. We call these "Gamma test flags", where...

"Alpha" testing comprises the first round of testing of a new algorithm/feature/program by the development team, and sometimes by sophisticated users.

"Beta" testing is more broadly based and is performed, usually by sophisticated users, on pre-release versions of software incorporating major changes or new features.

"Gamma" testing is the software analog to "in the field" experiences by the target universe of consumers following FDA approval of a new drug (the drug companies call them "victims", off the record, of course).
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I have a question regarding the wind and current moment implementation in Moorsim. I could not find any input data for wind or current center of pressure (or area center with respect to CG of hull) which can be used for the yawing moment calculation. How does Moorsim implement environmental moments without providing a moment arm?

When using the simplified wind/current "SeaSoft Barge" force model, there is a place on the "Vessel Environmental Area, Moment and Enhancement Data" editor page to specify the [x,y] location of the area centers relative to the "cg". In this context, "cg" is shorthand for the plan-view origin of the vessel coordinate system with which everything else is defined, including semisubmersible member locations, fairlead locations, etc. Usually that coordinate origin will be at the waterplane centroid, or the cg, both of which are considered "equivalent" in the simplified SeaSoft universe of vessels (there are additional FAQs on that related issue). For other built-in environmental forcing models (such as the OCIMF "Tanker" models), the yaw "moments" are actually yaw *couples* about a vertical axis (i.e., they are agnostic as to the plan-view location of that axis).

Note: If you are specifying your own wind or current coefficients (using the LOWDAT mechanism, and/or CRNTCOFS.txt, WINDCOFS.txt), your moment coefficients *must* be given relative to the vessel origin of coordinates noted above.

Note 2: With regard to trim/heel moments, rather than yaw moments: For Moorsim, and for for other SeaSoft applications (except Sparsim and TLPsim; see below) quasi-static trim/heel arising from environmental forces are neglected under the assumption that for practical purposes, vessel hydrostatic righting moments dwarf any achievable environmental overturning moments.

For Sparsim and TLPsim, static and slowly-varying trim and heel arising from wind, current and other slowly-varying environmental conditions (including variable user forcing) is estimated and reported; this produces a corresponding slowly-varying (i.e., at periods far removed from wave-frequency excitations) pitch/roll response.
Added:     Oct 4, 2013
Modified:  Oct 17, 2013

I understand that an underlying simplification for Moorsim and SPMsim is that environmentally-induced trim and heel effects are neglected in those simulations due to the very stiff pitch/roll restoring characteristics of shipshapes and semisubmersibles. Sparsim and TLPsim on the other hand both accommodate slowly-varying pitch and roll response to mean and variable environmental conditions, as witnessed in particular by the appearance of non-zero "low-frequency" RMS and extreme motions in XCLDAT (in addition to the expected first-order "wave frequency" RMS pitch/roll motions). Further, I notice that for Sparsim, LOWOUT.stxt has, in addition to pages summarizing the "surge", "sway" and "yaw" normal mode degrees of freedom in the waterplane, pages for "pitch" and "roll". The information on those Sparsim LOWOUT pages flow through to the XCLDAT summary, as expected. TLPsim likewise exhibits a similar XCLDAT low-frequency pitch/roll variability, yet there is no corresponding TLPsim LOWOUT normal pages for pitch/roll. Could you please explain why?

The pitch/roll response in TLPsim to slowly-varying environmental forces is treated quasi-statically because the natural periods of pitch and roll for TLPsim are extremely short. Sparsim, by contrast, has much longer natural periods of pitch and roll, usually much longer than wave periods. Therefore, for pitch and roll, Sparsim exhibits well-defined dynamical subsystems, just as for surge, sway and yaw. What you are seeing in the TLPsim XCLDAT file for low-frequency pitch/roll RMS is the static trim/heel produced by the quasi-static adjustments of the tendon/riser complex by slowly varying environmental forces acting on the hull and moorings. Since there is no interesting pitch/roll normal mode dynamical response in TLPsim, as there is for Sparsim, there are no LOWOUT pages.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

You say that in aligned conditions, the legacy and non-legacy normal mode treatments should give very nearly the same answers. This seems generally to be the case, but I have a Moorsim semisubmersible case in which the low-frequency variable motion due to wind differs by nearly 30%; by comparison, the other contributions (current, wave, etc.) are much closer. Is this reasonable?

There is one improvement to the non-legacy low-frequency motion estimates which has not been carried back to the "legacy" code branch. Briefly, the legacy calculation uses an approximation for the required spectral integrals which, while very good for single-degree-of-freedom systems with slowly varying excitation spectra, cannot be used in the full non-legacy 3 DOF generalized normal mode treatment, which uses instead a formal numerical integration of the motion spectra. A side effect of this difference is that in aligned conditions, for which the legacy and non-legacy spectral integrals are formally identical, the spectral integral estimates will differ. In systems with strongly frequency-dependent environmental spectra across the frequency range of interest (zero to ~ .04 HZ), the full integral and the approximation used in the legacy treatment can differ by the amount you observe. The NPD wind spectrum is particularly problematic in this regard, with a spectral peak at 0 frequency and a pronounced monotonic fall-off across the frequency range of interest. In that and other similar circumstances, the newer (non-legacy) treatment is superior. If you wish to confirm that this is what is going on, replace your wind and current spectra with a "white" spectrum (constant spectral energy at all frequencies); that should bring your legacy and non-legacy motions into conformity.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I would appreciate some guidance in the "best" choice for the number of interpolation layers in Moorsim and SPMsim applications, especially for deepwater cases. I usually just use the maximum permitted number of layers but that produces a very large amount of interpolation table data that is difficult to manage and seems unnecessary. Can you give any guidance?

In most deepwater cases (water depth greater than ~ 50 times the maximum wave amplitude), a single interpolation layer is sufficient. The "multiple layers" mechanism is primarily for use in (a) shallow water cases where the static interpolation tables can vary significantly from wave-amplitude sized changes in the vertical fairlead positions and (b) TLPsim/Sparsim, whose interpolation tables, due to the taut nature of the moorings, are usually very sensitive to vertical changes in fairlead positions. Getting rid of unnecessary layers, when possible, will speed up the simulations, and make for much smaller (and more easily understood) interpolation tables. The simulation will warn you it believes you need multiple layers, so as a general rule start with one layer and go to multiple layers if necessary to eliminate the warnings. For Moorsim and SPMsim, you should only rarely need more than 3 or 5 interpolation layers.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I have read the online help for the above item (# 38 in "Output options 1"), but would appreciate some more information. In some quick testing on my semisubmersible system, setting that flag to "yes" does not appear to produce noticeably different values for *any* low-frequency variables in the output stream, but as advertised, takes a lot more CPU cycles. Does toggling this option ever produce a meaningfully different outcome?

Sometimes, yes; but not terribly often. Your observation is testament to the fact that the approximate "white noise" spectral methods utilized by SeaSoft are usually quite good, at least as long as the dominant fluctuating environmental variables (be they wind, waves, or current) possess reasonably "flat" spectral shapes across the low-frequency band of importance (zero up to around .04 Hz). In the white noise limit (i.e., the same environmental spectral values at all forcing frequencies), the approximate spectral integrations are exact, so nothing is gained by doing a more thorough (and more time consuming) numerical integration. In unusual circumstances, however, when the environmental spectra show a strong frequency dependence (as sometimes happens with special-purpose user-supplied spectra), you may find that the full integration procedure is necessary to capture your low-frequency RMS motions with adequate precision.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

While preparing to model a thruster assist in SPMsim, I created a data file with zero environmental forces (i.e., no wind, waves or current), but with a single vessel-relative backwards-directed force at the stern. SPMsim would not complete, reporting instead: 

       ++> No equilibrium condition found.
Can you explain why no equilibrium between the thruster force and mooring restoring forces was found?

The configuration you describe has an infinite set of neutrally stable equilibrium configurations. With a vessel-relative reverse thrust at the stern, and a turret or single-line mooring, every vessel heading is one of neutral stability. If you want to select *one* of these, you could add a second, very small (say, 0.1 Tonne) global-relative force, which will produce a single stable equilibrium position & orientation.

Note: when you begin to add additional environmental forces (which will usually produce a well-defined equilibrium orientation and position), you will probably be able to eliminate the above-described "direction-selection" global-relative force, thereby simplifying your datafile.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I am simulating a scenario in which dynamic-positioning thrusters are used to reposition a semisubmersible to very near its quiescent equilibrium point; that is, the thrusters are programmed so as to counter the mean environmental forces and moments from wind, waves and current. In a "legacy" simulation of this condition, Moorsim runs without issue. When I switch to the newer normal mode model, it throws various errors, like this: 

 +=> Exponential growth detected in SORT_FREQS;
     If you have eliminated all other error messages, please report this to SeaSoft...

 +=> Two identical mode indices reported in QDYNAM:EIGEN_MODES;
     If you have eliminated all other error messages, please report this to SeaSoft...
Can you cast any light on these errors and what, if anything, I should do about them?

The newer normal mode methods require a well-defined offset vector from quiescent equilibrium to the environmentally-determined equilibrium. In your case, you are using external (i.e., thruster) forces to cause the length of that vector to approach zero; as I am sure you can imagine, that is problematic. To avoid the errors, you should configure your thruster forces so that there is *some* non-zero offset from quiescent equilibrium, however small. That will avoid creating an ill-defined offset vector for the normal mode analysis to work with. It shouldn't take much; adjust this imbalance until you get a satisfactory simulation run (you might start with ~1 tonne or even less). This procedure has an added benefit: *you* are in control of the normal mode axes used in the LOWOUT report; it might be convenient, for instance, for the (small) residual offset to align with (a) Global North, or with (b) the vessel x-axis, at equilibrium.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

On the "External Force/Moment Specifications" page, I can set values for the spectral variation of my externally-applied forces and moments, but it is not clear to me what to use for the "resonance" frequency. The online help refers to the "appropriate normal mode". I have a vague notion of what to do, but could you provide some informed guidance?

The feature you wish to access is admittedly semi-quantitative in the most general case. The best you can do to implement the spectral variability of an external force is to provide a spectral value at the frequency of that normal mode which is of most engineering importance to your project. This will often (but not always) be the mode which is responsible for the largest low-frequency mooring offsets, and hence the largest low-frequency mooring force oscillations (that is, the "surge" mode in SPMsim or the "High lateral mode" when using the recommended (non-legacy) modal decomposition of Moorsim, TLPsim and Sparsim). Yaw resonance is less problematic: To establish your Z moment spectral value for non-legacy modal decompositions, you should use the period of the "yaw" mode; for "legacy" normal mode decompositions, you should use the frequency of the "high sway-yaw" mode.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

The "External Force/Moment Specifications" page in Moorsim (also in SPMsim, Sparsim and TLPsim) permits applying the external force to the "moorings". The online help implies, but does not state exactly, that the "moorings" force(s) are applied at (or just below) the fairleader connection to the vessel. Is that correct?

Yes; the forces applied to "moorings" are actually applied to the mooring fairleaders so they act as if they had been transferred to the fairleaders by the mooring structures.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am comparing two Semisim RAOs, one [a] produced using Semisim-estimated heave damping (the damping reported in SEMISUM.stxt in this case was 8.0%) and a second [b] produced with an identical data file except I *specify* a user damping level of 8.0%. I expected the two RAOs to be nearly the same, but they are quite different. Am I missing something? I am using the driving force option: <<Full square-law driving force calculation at all wave periods>>.

Short answer: The RAO curves for your two cases ([a] built-in damping estimation with SEMISUM-reported damping of 8.0% and [b] heave damping "hardwired" to 8.0%) will not be the same. In fact, [b] will exhibit a heave RAO consistent with approximately *twice* the damping of [a].

Discussion: When using the option

    <<Full square-law driving force calculation at all wave periods>>,
there are actually two underlying damping calculations in play:

(A) The resonant damping estimate reported in SEMISUM, which, all other vessel and environmental details being identical, will be the same for all "driving force" options:

1. <<Resonant damping ONLY, no square-law driving forces>> 2. <<Full square-law driving force calculation at all wave periods>> 3. <<Resonant damping PLUS square-law driving forces on fixed vessel>>

and

(B) square-law damping produced by relative motion between water particles and submerged vessel components (pontoons, columns, braces, etc.).

When you specify ("hardwire") a damping level on the "Vessel Period and Damping Specifications" editor page, *and* the "Full square-law" option is in play (as described in the "Full square-law" online help), your specified damping is included as a linear damping contribution to the nonlinear dissipation model. This will result in a total "equivalent" damping approximately equal to the sum of the linear (hardwired) contribution and the linearized square-law contribution. Since your hardwired damping in case [b] is equal to the linearized square-law contribution from [a], the net damping in case [b] will be roughly twice that of case [a].
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I would appreciate some guidance on the choice of constant wave height or constant wave slope for RAO specification in Semisim. I understand that the amplitude of regular waves affects the magnitude of the RAOs due to square-law nonlinearities in the driving force and damping mechanisms, which arise from relative motion between hull and water particles in the wave field. Can you suggest which option (constant slope or height) for the regular wave amplitudes makes the most sense from a practical point of view?

From an engineering point of view, there is no practical difference in the constant wave height versus constant wave slope option RAO; this option exists as a support feature for model tests (which historically used regular waves of either constant height or constant slope to study system nonlinearities).

That said, using constant wave slope (instead of the default constant wave height) for Semisim RAOs has one useful consequence: For periods on the short side of the range or interest (3-5 seconds, say), both wave height and wave slope have sensible and realizable magnitudes. A constant wave height, by contrast, causes the wave slope to become impossibly large at very short wave periods. (Interesting tidbit: This kinematic fact of life means that the RMS wave slope, for all analytic wave spectral representations in common use, is infinite). Those physically impossible short-period wave slopes can have a (very) small effect on short-period RAOs when the important <<Full square-law driving force calculation at all wave periods>> is in play, since the relative water-hull speed (and the square-law driving forces and dissipation they produce) will, at a given wave period, grow along with the wave slope. This should not make any meaningful difference in the RAOs (a few percent at most) but is at least a theoretically defensible consideration to guide your choice.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

This has puzzled me for some time: Why do you offer two different mechanisms for setting wave amplitude for RAOs in SeaSoft? I assume this has to do with the fact that any nonlinear processes (such as square law roll damping) are going to produce a different "nonlinear RAO" depending on the wave amplitude assumed for the response calculation. But why the choice of amplitude versus slope for establishing that amplitude?

A brief history: The regular wave amplitude options in SeaSoft exist because in the dark ages model tests usually included "regular wave" tests, said tests being made with waves from a selected set of wave periods of interest with a prescribed wave height or wave slope. Typically in these tests, depending on test objectives, the entire regular wave collection would be run with either a constant wave height or a constant wave slope at all wave periods in the test. Nonlinearities would be analyzed by repeating selected periods at two or three different amplitudes (heights or slopes). The SeaSoft simulations were designed to replicate, as closely as possible, that early testing methodology.

As to which choice is "best" for RAO estimation (constant height versus constant slope), of course it does not matter for linear systems. However, when nonlinearities are important, such as roll of ship-shape vessels, or heave of semisubmersible vessels, the "constant slope" option has one modest advantage, explained in this FAQ: "Semisim: Best to use regular wave height or slope for RAO generation?"
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am comparing output between two Semisim executions; input data is identical in all respects *except* for the specification of the regular wave input to the RAO routine (on the "Regular Wave Characteristics" editor page I specify a constant wave height in Case 1, and a constant wave slope in Case 2). The specified *irregular* wave spectrum has in each case the same significant wave height and peak period [Hs, Tp]. Furthermore, in each case I choose the magnitude of the regular wave height and slope according to the online help recommendation for the height/slope toggle: The regular wave height for Case 1 is set to Hs/Ã2 and the regular wave slope for Case 2 is the slope of a regular wave with height Hs/Ã2 *and* period Tp. Put another way, both cases have *identical* regular wave height and slope at the Tp of the irregular wave spectrum. I expected these two cases to produce identical output streams (damping, periods, RAOs, etc.) but they do not. Can you explain why?

In the case of purely linear damping, your two cases will of course give identical results, as you anticipate. However, for nonlinear damping (associated with square-law hydrodynamic processes), the following methodology is used: First, the natural periods of heave, pitch and roll are estimated in the absence of nonlinear processes. Then, if square-law dissipation is important (e.g., for roll in shipshapes, or heave, pitch and roll in semisubmersibles), an estimate of the (nonlinear) peak RAO response to a regular wave excitation at relevant resonance periods is made, using an input wave whose amplitude (and slope) are determined by user specification (i.e., employing the specified constant slope or height). Since the resonance periods will not in general match the spectral peak period, the amplitude of the regular wave used to determine the height of each required resonant RAO curve will be different depending on the setting of the slope/height toggle.

For example, consider a Semisubmersible with heave resonance at 20 seconds; further, consider two Semisim runs using this vessel, both with a 10 meter significant Bretschneider spectrum at Tpeak = 12 seconds, but Case 1 at constant regular wave height of 7 meters, and Case 2 at constant regular wave slope of 5.61 degrees. (This [height,slope] pair corresponds to a regular deepwater wave of period 12 seconds.) In this example, the regular wave at the spectrum peak period is identical in the two cases. However, the regular wave used to determine the nonlinear heave response RAO peak at resonance will be quite different in the two cases: In Case 1 the height of the 20 second wave will of course be 7 meters, but the slope will be only ~ 2 degrees; in Case 2 the slope of the 20 second resonant wave will be 5.61 degrees and its height will be 21.44 meters. So the wave height of the resonant wave used to determine resonant damping differs by over a factor of 3 between the two cases. This will, roughly speaking, lead to resonant damping in the two cases differing by a factor of ~ Ã3 for square-law dominated damping. That means both the RAO heave peak at heave resonance, and the damping reported in SEMISUM.stxt, will differ substantially in the two cases; these differences would in fact be observed if the two cases were run in a testing facility using regular waves at constant height or slope per our specification.

SeaSoft uses the pseudo-RAOs obtained as outlined above ("pseudo" because strictly speaking an RAO relates only to linear systems) as if they were true RAOs and obtains RMS and other statistical motion measures using standard spectral methods. Note that although the RAOs are very different at heave resonance in our two cases, they are identical at the peak of the requested spectrum, and very, very close to each other at periods near the spectral peak, so that the two RAOs will produce practically indistinguishable RMS (and most-probable peak) motion estimates despite their very substantial shapes at very long periods. Further, it should be noted that if the spectral Tp in our test case had been identical to our heave resonant period (20 seconds), by design the heave RAO at 20 seconds would be identical for both states of the slope versus height toggle, and all the derived statistical measures (RMS heave, etc.) would, again, for practical purposes be the same.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I am not clear on what, exactly, the damping values reported in SHIPSUM.stxt and SEMISUM.stxt actually mean. Are these true linear damping coefficients? "Effective" linear damping coefficients? Could you offer a brief tutorial on the meaning of these numbers?

This is reasonably murky and not well-documented, so you are forgiven for your confusion; an element of "assumed expert user" elitism exists in this and other areas of documentation shortcomings. Sorry.

The basic rule is this: If a particular degree-of-freedom (DOF: roll, heave, etc.) for a particular vessel type (ship, semisubmersible, etc.) is known to be importantly affected by nonlinear processes (in this context, almost all these processes relate to square-law nonlinearities of the fluid-dynamic type), then the damping reported by SeaSoft is an "equivalent" linear damping, which will be dependent on wave amplitude, and can be thought of as that "equivalent" linear damping which produces the same RMS motion as the actual, nonlinear, process. Damping for some degrees of freedom for some vessels is dominated by linear processes (e.g., wave radiation); in those circumstances, the damping reported by SeaSoft is simply an estimate of that linear damping. However, most SeaSoft damping mechanisms comprise both a linear and quadratic component. Some are so dominated by one or the other mechanism that the less important mechanism is ignored (e.g., heave, pitch and roll damping of semisubmersibles, which are utterly dominated by square-law processes).

The user is assumed to be sufficiently sophisticated to know which degrees of freedom, for his vessel type of interest, are impacted in a meaningful way by nonlinear damping processes.

In summary: If a DOF/vessel combination has an important nonlinear damping contribution, SeaSoft's quoted damping is an "Equivalent Linear Damping" whose value will depend on wave intensity (i.e., significant wave height, or SWH). Otherwise, it is an actual linear damping and will be independent of SWH.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

What are the impacts of user-supplied damping and periods for heave, pitch and roll when I supply RAOs for Shipsim or Semisim via the USERRAOS.txt mechanism? It seems to have no effect on vessel motions but does affect the output in the SEMISUM.txt, SHIPSUM.stxt output files. Why don't the SEMISUM, etc. periods and damping reflect the underlying USERRAOS information when that information is supplied?

There is simply no meaningful general way to extract natural period or damping information from a USERRAOS table.

When you specify RAOs via the USERRAOS mechanism, SeaSoft's simulations continue to carry out their own estimates for natural periods, damping, driving forces, etc. These internal estimates then appear in their usual places (SHIPSUM for periods and damping, SHIPRAO for SeaSoft force RAO estimates, etc.); it is felt this provides at least some assistance in understanding the important fundamental physical properties of the vessel in the given environment, even if it is not used in the motion estimates. *All* motion related information, such as motion RAOs and RMS motions in irregular waves (in SHIPRAO and SHIPRAN, for example) rely only on your supplied RAO data from USERRAOS.

In particular, if you were to "hardwire" natural periods or damping for heave, etc., those hardwired values would be used in the internal calculations (and appear in SHIPSUM period and damping reports, SHIPRAO force RAOs, etc.) but, again, would have no impact on reported motions.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Sometime after Version 5.5, there appeared in the output stream a new file called "LF_SpecDat.stxt"; I can find no documentation for this file. Please enlighten me.

"LF_SpecDat.stxt" contains low-frequency spectral information relating to the three low-frequency degrees of freedom (surge, sway and yaw) in Moorsim, Sparsim, SPMsim, and TLPsim. Lateral motion spectra (i.e., "surge" and "sway") are resolved into three different right-handed coordinate systems for convenience, identified in the LF_SpecDat header as follows: [1] Motions parallel ("R_Spec" for "R"adial) and perpendicular ("P_Spec" for "P"endicular) to the mean offset direction (this system provides greatest insight into net low-frequency mooring load fluctuations); [2] Motions resolved in the Global coordinate system [Gx_Spec, Gy_Spec] (here x is aligned with "Global North", this system is included in most model test reports); [3] Motions resolved in the vessel coordinate system (surge and sway, represented by [Vx_Spec, Vy_Spec], useful for analysis of low-frequency turret loads). Yaw spectra are agnostic to the lateral coordinate system and yaw spectral information therefore only appears once, as "Yaw_Spec".

Spectral units are Q^2/[radian/second], where "Q" is (a) the simulation unit of length (feet or meters) for lateral motions, or (b) radians for yaw.

Spectral values are derived from the cumulative response to requested low-frequency variable forces (wind, waves, current and user-specified external forcings), driving low-frequency vessel motions. The periods selected for display range from 0 Hz to ~.025 Hz (40 seconds), that is, to a point well beyond the upper limit of physically occurring wave periods. The [R,P] lateral coordinate representation is the representation referred to in LOWOUT.stxt as motions "parallel and perpendicular" to the mean vessel offset. In particular, you can recover the net RMS motions presented in LOWOUT by integration of the [R,P,Yaw] spectra given in LF_SpecDat. Since the underlying mechanical system comprises three degrees of freedom, plots of LF_SpecDat output will in general exhibit multiple distinct peaks, possibly including one for each underlying DOF and, in some cases, additional peaks deriving from the structure of the environmental forcing spectra.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

Sometime after Version 5.5, there appeared in the output stream a new file called "Node_Motn.stxt"; where can I find documentation for this file?

"Node_Motn.stxt" contains motion summaries for the nodal "break" points specified for your mooring lines and risers. The information and table layout matches that of "XCLDAT.stxt"; in particular the information is tab-delimited for importation into spreadsheets. Most of the information presented is self-explanatory; for additional detail about definitions of header quantities, you might wish to look at the XCLDAT FAQs.

Statistical low- and wave-frequency nodal motion information is resolved relative to a line-specific [x,y,z] coordinate system; each line's coordinate origin is at its anchor; z is earth-vertical, x is towards the fairlead in the stationary equilibrium plane of the line, and y is perpendicular to said line plane, per the right-hand rule.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I cannot reconcile the wave-frequency [x,z] fairlead motions given in Node_Motn.stxt (from a moored FSPO in SPMsim) with those obtained for an identically configured vessel (same vessel, same relative wave environment) from Shipsim. Can you explain the discrepancy? Looks like a bug to me.

You are partially correct: There is a real conflict, but it is not a bug. First, a point about SeaSoft's wave-frequency line load algorithm: Because, to a first approximation (an excellent one, it should be noted), the dynamics of line motions and internal stresses depends, for a fixed anchor, only on tangential motion of the fairlead (i.e., fairlead motion parallel to the departing mooring line). The simple physics of this observation is instructive: Infinitesimal fairlead motions in a plane perpendicular to the line tangent cannot inject energy into the line subsystem (since such motion is by design orthogonal to the instantaneous force/tension vector at the attachment). As a consequence, small amplitude fairlead motions in that plane (i.e. motions, such as wave-frequency oscillations, small compared to other important mooring scale lengths like water depth or distance to anchor) do not get transmitted down the line in the same way as motions *tangential* to the line. This underlying consideration also applies to the evaluation of nodal motions for nodes "far" from the fairlead. However, fairlead motions in this plane *will* obviously impact motions at line locations near to the fairlead. That is a shortcoming of Node_Motn.stxt that has at this point not been remedied. It is important to restate, however: The influence of the neglected fairlead motion components on nodal motions removed from the fairlead by something like 10-20 times the neglected motion amplitudes will normally be negligible; for the fairlead itself, of course, the resulting error is most assuredly *not* negligible. This is the reason for the discrepancy between the Shipsim/SHIPRAN results and the Node_Motn you observe.

To further your understanding of this, a 3-way comparison of SHIPRAN (Shipsim), SHIPRAN (SPMsim) and Node_Motn for the identical configuration may be instructive: If you look at the SHIPRAN output from your SPMsim execution, you will see that the SHIPRAN fairlead motion data is given in a coordinate system with z axis aligned to the line tangent for exactly this reason. The fairlead tangential motion given in SHIPRAN from SPMsim should reflect the [x,z] values found in Node_Motn once resolved into an earth-vertical coordinate system.

Finally, be aware that these comments apply equally to Moorsim-, Sparsim-, TLPsim-, Semisim- and Discsim-based output.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

The Node_Motn.stxt file always shows zero wave-frequency motion for the "Y" components of all nodes, including the fairlead. that clearly cannot be correct since each fairlead's motion *will* in general have components of motion perpendicular to its line plane. What gives?

This issue is also addressed in a nearby FAQ posing essentially the same issue about the disagreement of the "Z" fairlead motion reported in Node_Motn compared to that of Shipsim & SHIPRAN. You are correct that the "Y" fairlead motion in the general case can be anything at all and will virtually *never* be exactly zero. However, because the "Y" component is perpendicular to the line tangent at the fairlead such motions do not, to the order of precision reflected in SeaSoft's modeling, impact line loads and are likewise ignored in the Node_Motn report. Only low-frequency motions, which are assumed to be wholly quasi-static in nature (i.e., governed by the static interpolation tables), have a "Y" motion contribution in this model.

Note: A more comprehensive model of these damped transverse-to-line-plane waves propagating down the line from fairlead towards the anchor support the physically motivated arguments given above, and suggest that for physically important wave-frequency fairlead motions (motion amplitudes of order 20 or more times the effective line diameter; e.g., 5' amplitude transverse fairlead motions of a 3" diameter line), these 'guitar string' waves are heavily damped by square-law processes and are severely attenuated for nodes distant from the fairlead.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

I do not fully understand the meaning of the modal damping values quoted in LOWOUT for the "normal modes". My understanding is that for damped systems of two or more degrees of freedom (DOF), the conventional 1 DOF damping concept of a single exponentially decaying response breaks down. That said, what is the meaning of your "modal damping" for a single normal mode of a multi DOF system? Further, given the impossibility of establishing a single *overall* damping value for a single mode of a multi-DOF system, how can modal damping and RMS motion contributions due to individual environmental contributors (waves, current, etc.) be isolated for each mode? Can such a breakdown possibly be meaningful?

First, let us remind everyone that the "normal mode" pages of LOWOUT.stxt are very, very qualitative; they exist to provide rudimentary insight and intuition into [1] low-frequency vessel motions, [2] damping levels of the different modes of motion, and [3] the interplay between dynamics and environmental forcing levels (i.e., RMS motions and environmental damping from each environmental contributor). To do this in a rigorous way is impossible except in very special circumstances. We have chosen to do our best to present this type of imperfect information in more complex circumstances because we feel *some* kind of qualitative physical understanding of vessel motions is essential to support a comprehensive engineering understanding. The LOWOUT modal page information approaches a reasonable level of rigor only in a few highly idealized circumstances (e.g., a turret mooring in perfectly aligned conditions, or a spread mooring of a symmetric vessel in a symmetric moor).

These caveats aside, you are basically correct in your understanding of the dynamical issues here; one cannot rigorously define a 1-DOF-type net "equivalent damping" value for a single DOF of a coupled 3 DOF dynamical system, even a linear one. However, one *can* determine an exponential attenuation rate for each normal mode and convert that value into a meaningful measure of damping in the same way that the "Q" attenuation value is related to percent damping for a 1 DOF spring-mass system. That association is the basis for the net normal mode damping values quoted in LOWOUT.

The per-environment damping contributions and RMS motions presented in LOWOUT, as noted above, are offered as *qualitative* indicators of the rates of energy absorption and motions arising from each environmental contributor. By design, these qualitative estimates approach the single DOF damping values and motion amplitudes of the modes of similar "separable" systems (mentioned above) as the parameters (moorings, environment, etc.) of the complex system merge continuously into those of the simplified system. For the most complicated systems, our approximate deconstruction of dissipation and motion into individual environmental contributors are at best of semi-quantitative value. In the spirit of the LOWOUT modal page "raison d'etre", we hope that a qualitative understanding of environmental breakdowns to damping and low-frequency motions will be useful in mooring design and as an aid to determining what matters, and what is ignorable, in any particular circumstance.

The above issues of formal rigor aside, note however that the approximations and subjective choices involved in the estimation and presentation of individual environmental damping and motion contributions on the LOWOUT normal mode pages do *not* contaminate the *net* RMS or peak low-frequency motion estimates, also presented in LOWOUT and in XCLDAT.stxt, because the latter values flow from a rigorous analysis that depends only on the modal low-frequency response curves and the low-frequency forcing spectra, both of which are free of subjectivity.

Finally, if you find this discussion hopelessly opaque, you may get additional insight by searching for related FAQs on LOWOUT's normal mode pages, both "legacy" and "non-legacy" ("non-legacy" here means post v 5.55). Some useful keywords: LF_SpecDat, LOWOUT, modal.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I would appreciate some guidance on how to best handle equilibrium-finding errors in Moorsim. Can you discuss this runtime error message and the consequences of the various options to proceed when it is issued? 

         ++> Iteration failure in mean position determination after  500 attempts;

         Current Position error estimates {x,y,yaw (deg)}:   -0.48E-02 -0.27E-01 -0.39E+01
         Current Net Force/Moment error estimate {x,y,yaw}:   0.10E+02  0.26E+02  0.33E+03

         Enter 99 to continue with current best estimate OR...
Enter "A" to abort or Press <RETURN> to continue:

Entering "99" at the failure notification causes Moorsim (as well as Sparsim, SPMsim, TLPsim) to terminate its search and just move along with the current values of (x,y,yaw); those might be pretty good, or they could be dismal. The error estimates are issued to give you guidance as to how best to proceed. In the above example, the angle error of 3.9 degrees is probably unsatisfactory, although the {x,y} errors might be acceptable. The error estimates are in the units of the simulation (feet/meters, kips/tonnes, etc.).

Note: There are situations where no amount of iteration will produce a convergent equilibrium search. When there is more than one variable that must be varied in the search, it is formally impossible to guarantee an equilibrium will be found with any numerical algorithm (at least when using finite precision floating point variables). Basically, the search algorithm can result in a repeating loop (call it a "stable bad path"), continuously traversing the same path through the possible solution space (often a very complicated path) that does not converge to an equilibrium solution. In many cases, changing one or more input values by a trivial amount (like a wave/current/wind heading or magnitude, or whatever) will cause the "bad locked-in path" to be avoided and a convergent path will be traversed instead.
Added:     Oct 4, 2013
Modified:  Oct 5, 2013

It is not clear to me how to interpret the "Mean (x,y) forces due to current (lines)" in LOWOUT when "Estimate current loads on mooring lines and risers" has been requested. Current forces on lines and risers are countered by forces at both fairlead and anchor points. Is the value quoted in LOWOUT the sum of only the fairlead forces attributable to the line/riser current loads? Or is it the total current load on the lines, which would include the anchor contribution as well?

Your first instinct is correct here: The LOWOUT values comprise the sum across all vessel fairleads of the incremental force on each line arising from the action of the mean current integrated along the line from anchor to fairlead. This is the value which contributes to additional net displacement of the vessel from its quiescent equilibrium point arising from current loads on the slender members.

Example: If you record the (x,y) current-associated mooring/riser forces in your case, then turn off the "Estimate current loads on mooring lines and risers" option and add back the force you just recorded as an "Auxiliary External Load" applied to the "Moorings", you will recover the same mean vessel offset as in your original simulation.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

I have noticed that in nearly aligned environmental conditions, the damping levels for motions orthogonal to the environment (I will call these "sway" motions) are often nonzero, and appear sensitive to small changes in the input parameters (i.e., small changes in the direction of one environmental variable, such as wave heading changing from 180 to 180.1 degrees). I realize that the lateral motions in these conditions are so small that they are ignorable, but this still leaves me curious as to the source of the damping and to the differences in damping estimates produced by small changes in the environment. Can you comment on this observation?

This is a complex issue, but a flavor of what is going on may help: Many of the low-frequency damping mechanisms at play are approximately proportional to the ratio of a mean environmental force divided by the mean transport speed associated with the environmental momentum (fluid speed for wind and current, for example). In the limit of aligned "head-on" environmental conditions, although both the lateral mean force and the lateral fluid speed will vanish, the ratio of mean force to lateral speed can have a finite limit. Numerically, this finite limit can be hard to determine (as a result of floating-point limitations in the calculation of the ratio of extremely small numbers) and the damping estimates can therefore become problematic; as you note however, the motion amplitudes are negligible so the damping values, and their uncertaintity, have no practical consequence in this case.
Added:     Oct 4, 2013
Modified:  Oct 8, 2013

Catsim and Statmoor seem to be very similar. Why are there two offerings so similar in nature?

They exist as separate programs largely for historical reasons. Statmoor was SeaSoft's first mooring statics calculator and is rather limited in its capabilities, although as indicated below it has a few features (such as support for sloping seabeds) absent in Catsim. Catsim was developed to more gracefully complement dynamical simulations such as Moorsim and to add features, such as the "continuous equilibrium" options that would be difficult to incorporate into Statmoor's legacy source code framework.

Capabilities of Catsim not available in Statmoor:

+ The permitted mooring line complexity in Catsim is much greater. Each line can be composed of 16 sub-lines which can be of arbitrary composition; in particular, any element can represent a "buoy" in the sense that it can possess a negative "weight in water" value. Statmoor by contrast permits a maximum of 3 line elements plus one buoy and one clump weight at special locations along the mooring leg.

+ The permitted types of "Hand of God" vessel offsets permitted by Catsim are much more complex and comprehensive than those in Statmoor. In particular, Catsim permits rectilinear offsets in any direction, including vertical and oblique offsets not lying in the waterplane, and rotational offsets about any axis, including non-vertical oblique axes. Statmoor, by contrast, permits only lateral vessel offsets confined to the waterplane and rotational (yaw) offsets about a vertical axis.

+ In addition to the comprehensive "Hand of God" offsets permitted in Catsim, "instantaneous equilibrium" offsets are allowed in which the vessel responds to the development of mooring and hydrostatic forces and moments during the offset sequence in order to maintain at all times a mathematically rigorous equilibrium. Such offsets will, in general, result in simultaneous translation and rotation of the vessel in any direction (including out of the waterplane) and about any axis (including non-vertical).

Capabilities of Statmoor not available in Catsim:

+ Statmoor possesses comprehensive sloping bottom capabilities; Catsim accommodates individually specifiable anchor depths, but the sea bed between fairlead and anchor is treated as flat, not sloping.

+ Statmoor treats buoys and clump weights as point objects, which is in some cases a slightly more realistic implementation. 
Added:     Oct 5, 2013
Modified:  Oct 5, 2013

When comparing the SEMISUM.stxt file produced by Semisim, and the same file (i.e., for the same vessel and wave environment) produced by Sparsim, I notice several differences: 1. There are several extra fields in the Sparsim version ("LONGITUDINAL RIGHTING ARM", "TRANSVERSE RIGHTING ARM", "VERTICAL PULL-DOWN", "MOOR-MODIFIED" periods). 2. There are noticeable differences in several other fields that occur in both (DISPLACEMENT, pitch and roll "CENTER OF ROTATION", "EQUIVALENT VERTICAL KG", and all natural periods and damping values). Could you please explain and comment on these differences?

The differences you note arise from the inclusion of mooring system stiffness in the Sparsim-produced SEMISUM output. Semisim is agnostic about mooring forces; its output relates to an unmoored vessel.

Sparsim by contrast incorporates several relevant mooring system properties in its SEMISUM/SEMIRAO/SEMIRAN reports. For example, the vertical stiffness of the mooring system at the mean offset point is accommodated in the dynamics; this generally reduces the natural periods of heave, pitch and roll motions from their unmoored values. The mooring forces also explain the differences in the displacement (which includes a hydrostatic contribution from the "vertical pull-down" of the vessel at the mean offset point; that contributes to the mean vertical mooring force). Likewise, the mooring forces influence the pitch and roll centers of rotation, albeit only slightly. The longitudinal and transverse "righting arms" are the associated hydrostatic GMs corrected for a mooring contribution.

Note: The "[Unmoored] Natural Pitch and Roll Periods" reported in the Sparsim version of SEMISUM.stxt will not be the same as the periods reported in Semisim for the same spar. This is because Sparsim has to account for the *hydrostatic* changes caused by the mooring/riser complex (increased draft at mean offset is the most obvious consequence, but as mentioned above the hydrostatic moments are likewise affected). The two "periods" ("Natural" and "Moor-Modified") reported by sparsim's SEMISUM version are for [1] a "hypothetical" spar, only with moor-mediated pulldown hydrostatics (and appropriate points of action for the mooring forces), and [2] the same hypothetical spar with additional "restoring springs" provided by the moorings acting against pitch/roll about the mean.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

There appears to me to be an issue with SeaSoft's low-frequency vessel response when combining independent swell systems. Since wave drift forces scale with the square of the wave amplitude for regular waves, superposing two identical and *perfectly correlated* swell systems (same direction, same spectrum and same significant height) must produce mean and variable wave drift forces that are *four* times those of one of the swell systems acting alone. This expectation is realized in SeaSoft, which can be demonstrated by comparing two single-wave-systems, one with a significant wave height double that of the other. That comparison shows the expected factor of four in both mean wave-drift force and vessel motions due to variable drift forces. (I assume here that, for approximately linear low-frequency response characteristics, RMS vessel motion can be used as a rough proxy for RMS drift forces.) Consider the same comparison between *statistically independent* swell systems (again, both having the same direction, same spectrum and same significant height): The *combined* wave amplitude spectrum at each frequency in this case is simply *double* that of each swell system acting alone (rather than four times as in the coherent wave combination of my first scenario above). The doubled wave spectrum of the combined uncorrelated swell systems *should* produce both mean and variable drift forces (and variable vessel motions) *twice* those of one swell system acting alone. Once again, this expectation is realized for the mean wave drift forces, but not for the *variable* vessel motions. Instead, I find that RMS vessel motions for the uncorrelated double swell system appear to be Sqrt[2] times larger, rather than twice as large, as those associated with one of the swell systems acting alone. Can you please look into fixing this problem?

Hang on there Grasshopper; there is no error in the SeaSoft result you are reporting. Rather, in your discussion of the second case (the incoherent superposed double swell system), you are overlooking an additional loss of coherence in the variable drift *force* spectrum which goes beyond the loss of coherence in the wave *height* spectrum. The formal demonstration of this requires more discourse than we care to provide here, but a simple intuitive argument will hopefully suffice:

Two statistically independent (but otherwise identical) superposed swell trains each produce the same mean wave drift force (as you have noted), so the net drift force in your superposed swell system is simply twice that of a single swell acting alone. But, each component of the superposed system also produces a wave drift force *spectrum* identical to that of a single swell system acting alone. Since the superposed swell waves are statistically independent, so are the variable drift forces produced by them, so the spectrum of the combined variable forces is simply the sum of the force spectra of the two component systems. This produces a drift force variance for the combined system (i.e., the integral over the net drift *force* spectrum) of twice the variance of each component swell force spectrum taken alone. The net RMS force (i.e., the square root of the force variance) for the combined system is therefore increased by a factor Sqrt[2] over the RMS force produced by a single component swell acting alone. And, as you have correctly noted, for an approximately linear system, the response will increase by the same factor.

Note that wave *drag* (aka wave absorption) forces scale differently with wave amplitude than wave *drift* (aka wave reflection) forces: The former scale with the cube of the wave height in the absence of underlying current; in the presence of current the wave drag scaling is more complicated and will lie between the square and the cube of the wave height depending on details of the current profile and the vessel subsurface geometry.

Exercises for the motivated: Call [F0,RMS0] the [mean wave drift force, RMS surge] produced by wave drift forces from a single swell system ("swell 0") of 1 meter height acting on a linearly moored vessel.

Consider now a pair of *identical* superposed swell systems with the same directionality and the same spectra as "swell 0" except for an overall multiplicative constant; these superposed wave systems are assumed to be statistically independent (hence, incoherent and uncorrelated).

1. What significant swell height is required for each of this pair of identical superposed wave systems to produce the same net mean drift force [F0] as the larger "swell 0" (1-meter) swell? What is the ratio of the RMS vessel motions for "swell 0" to that for the pair?

2. What significant swell height is required for each of this pair of identical superposed (but statistically independent) wave systems to produce the same RMS surge [RMS0] as the single larger (1-meter) swell? What is the ratio of the net mean drift force in the single swell system versus that of the superposed pair?

Answers:

1. Required Height for same mean drift force = 2^(-1/2) meters (~ 0.707 m); RMS Motion Ratio [Superposed swell system]/["swell 0"] = 2^(-1/2) ~ 0.707 Tidbit: The RMS motion of a *single* .707 m swell is exactly 1/2 that of the 1 m swell.

2. Required Height for same RMS motion = 2^(-1/4) meters (~ 0.841 m); Mean Force Ratio [Superposed swell system]/["swell 0"] = 2^(1/2) ~ 1.414
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

If I compare two MEANOUT.stxt files whose input files (SPMIN.stxt) are identical except for the setting of the flag: 

    "Output line loads and motions at element endpoints"
(in one case that flag is "Yes", in the other it is "No"), the two MEANOUT files produced are not identical; why should the setting of this flag affect the numeric values in MEANOUT and elsewhere?

When nodal loads are requested, a slightly different path through the code is taken for the computation of fairlead and anchor loads. The differences you see should not rise above the level of accumulated single precision floating-point roundoff errors, but since the code paths are different, the results will not in general be identical.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I have been seeing the following runtime error messages on an otherwise unexceptional Moorsim run; could you indicate what is going on here? 

   +=> Questionable Eigenvector in GET_EINGENVEC!
   +=> Two identical mode indices reported in QDYNAM:EIGEN_MODES;
If you have eliminated all other error messages, please submit this datafile to SeaSoft...

These kinds of error messages relate to the evaluation of eigenvalues (normal mode frequencies) and eigenvectors for the normal mode analysis in Moorsim. They generally occur when a "degenerate" condition is detected; in the language of modal analysis, a degenerate condition is one in which two or more eigenvalues are identical (or in the floating-point world of computer analysis, nearly identical). In real systems, such degenerate cases are rare, and there are other pathological conditions that might give the same error message; hence we request users to forward to us the input stream producing these messages for our inspection and quality-assurance efforts.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

When using USERRAOS.txt data generated by a diffraction analysis like WAMIT, it is unclear to me what I should use for the SeaSoft coordinate origin for fairlead locations (Moorsim, etc.) or vessel motion specification points (Shipsim, etc.). Should I use the plan-view cg for [x,y] and the keel level for [z], or something else?

Your SeaSoft origin should be at the same [x,y] plan-view location (often, but not necessarily, the center of gravity) you used for the diffraction analysis; the z origin is always at the level of the vessel keel datum .
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

When vessel RAOs are supplied via the USERRAOS.txt mechanism in Shipsim or Moorsim, is it still necessary to populate the "**** Regular Wave Characteristics ****" page with a wave *period* array? Isn't a suitable *frequency* array already determined by, and available in, the USERRAOS.txt file?

The "**** Regular Wave Characteristics ****" wave period array is *always* required. The USERRAOS.txt data is only used, via interpolation, to provide user RAOs for each of the wave periods requested in the "Regular Wave" array. The internal integration grid used for wave spectrum, motion spectra, etc., is uniquely determined by the "Regular Wave" array, and is unrelated to the frequency array associated with USERRAOS.txt.

Note: To increase the numerical accuracy of the integrations, the number of wave periods can be increased (by reducing the period interval between consecutive periods), thus trading off run-time performance for better numerical results. Using Shipsim as an example, you can see this in play by watching the "CALCULATED SIGNIFICANT WAVE HEIGHT" in SHIPRAN.stxt approach the requested irregular wave height in SHIPIN.stxt as you increase the density of wave periods used.

Furthermore, the frequency range internal to USERRAOS (when translated to a period range interval) should always be fully contained within the period limits set by the regular wave period array to avoid any problematic extrapolation of your RAOs outside the boundaries of the USERRAOS array.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

Around SeaSoft Version 6.12, there appeared a new option for "chain hinge relative motion at fairlead" and an associated output file "Hinge_Motn.stxt"; there also appeared some new related output in SHIPRAN.stxt and SHIPRAO.stxt. I have a general idea what this is about, but am having trouble understanding the interplay between the "ball hinge" angles (are these vessel-relative or global-relative?) and the line departure ("dip") angle contributions to the so-called "chain hinge" wear analysis. Could you elaborate?

Certainly; this will exercise your 3-d visualization ability and may provide a measure of protection against Alzheimer's disease.

The "hinge motion" analysis flows from user requests for an analytical tool to assist investigation of, and design support for, relative-motion wear and fatigue near the fairlead attachment point of mooring lines. Historically, the most problematic cases are mooring lines whose first fairlead-end sub-line comprises chain. In that circumstance, the relative motion between the last vessel-fixed link (which is locked to the vessel superstructure), and its adjacent anchor-side link (which is *not* locked to the vessel with respect to relative rotations), is much greater than the relative motion between any other pair of links. The interface between those two links is thus prone to accelerated wear and, perhaps, fatigue. This locked-to-free link pair acts kinematically as a "ball hinge", such as the human shoulder joint. Such a structure possesses three degrees of relative angular freedom, between a fixed "socket" (e.g., the ball joint of a human shoulder or the last vessel-fixed link in the chain wear model) and its attached, movable component (the humerus bone in the human arm and the first free link in the chain wear model).

As in the human shoulder model, the chain link interface supports 3-dimensional rotation; rotations about *any* axis passing through the links' contact point are allowed, so a complete description of the motion requires specification of three independent angular variables; these are most conveniently taken to be small rotations about an [x,y,z] coordinate system (whose orientation differs in general for each fairlead), with origin at the mean position of the link interface contact point. This set of axes is completely determined by the mean line plane, the mean line tangent, and the right-hand rule as follows: [x,z] lie in the (earth-vertical) mean plane containing the line; z is tangent to the line (positive away from the anchor), x is perpendicular to z upwards from the water surface (again, in the mean line plane); y is perpendicular to the mean line plane (and therefore always horizontal), with direction set by the right-hand rule and the directions of x and z. There are actually *two* such coordinate systems to consider, one vessel-fixed and one globally-fixed. These two "partnered" coordinate systems coincide when the vessel is in its mean position and orientation.

The angular and lateral motions of the vessel-fixed set of axes, when viewed against its globally-fixed partner, are the building blocks of two contributions to the desired relative hinge motion; we call these the "vessel" and "catenary" contributions. "Vessel" contributions arise from vessel *rotations* about the fairlead-local globally fixed [x,y,z] axes (these contributions evidently depend *only* upon vessel roll, pitch, yaw), while the "catenary" contributions arise from *rectilinear* motions of the coordinate origin (i.e., the links' contact point) along the same globally-fixed [x,y,z] axes; these rectilinear motions depend on *all six* degrees of vessel motion. Both "vessel" and "catenary" contributions to the hinge angle comprise wave-frequency and low-frequency components; it is usually assumed that the wear and fatigue history will be dominated by the wave-frequency components of relative hinge motions, though this may not always be the case.

The "y" axis (parallel to the waterline), is in most cases the axis of greatest interest for wave-frequency wear and will be singled out here for a more detailed discussion to illustrate the details of the analysis. As noted, the net wave-frequency "y" hinge angle can be broken into two contributions, each of which in general will contain both wave- and low-frequency components:

[1] Vessel rotations about the (globally-fixed, waterline-parallel) "mean y" axis arise via phased contributions from vessel roll and pitch (the yaw component has no horizontal component). This rotation we call the "vessel contribution" ("HAy_ves" in the output stream) to the total y-relative wave-frequency rotation ("HAy_tot" in the output stream). Since low-frequency variations in pitch and roll are neglected (except for Sparsim), HAy_ves is considered for purposes of this discussion to be a purely wave-frequency quantity with no low-frequency contribution. Note however that HAx_ves and HAz_ves *do* in general contain both wave- and low-frequency contributions.

[2] The mooring line vertical and plan-view angle variations relative to the mean (global) fairlead coordinate system (these variations are determined primarily by the catenary-elastic nature of the suspended line and the frequency spectrum of lateral motions of the fairlead) has both wave-frequency and low-frequency components that develop due to *translations* in space of the fairlead (which translations, as mentioned earlier, in general have phased contributions from *all 6* degrees of vessel motion). This we call the "catenary contribution" to net y relative rotation ("HAy_cat" in the output stream).

Note that the wave-frequency portions of [1] (HAy_ves) and [2] (HAy_cat) have a frequency-dependent relative phase relationship; the correlation between these contributions can therefore be usefully characterized by a wave-frequency correlation coefficient that varies between -1.0 (perfectly out-of-phase HAy_ves and HAy_cat) to +1.0 (perfectly in-phase), which correlation coefficients are reported in Hinge_Motn.stxt. As usual, wave-frequency and low-frequency contributions to HAy angles are assumed to be uncorrelated. Low-frequency correlations are not provided; generally speaking the low-frequency contributions to all hinge variables will be very highly correlated.

Relative hinge rotations about the "x" axis [HAx], which axis is in a vertical plane orthogonal to the line tangent (z), and "torsional" relative rotations about the z axis [HAz], also contribute to link wear and fatigue, albeit generally less profoundly than the y contribution in most cases; note that while HAx and HAz have both "vessel" and "catenary" contributions, the catenary contributions are normally small.

SeaSoft's analytical model assumes that vessel wave-frequency motions (all 6 DOF) are approximately linear (and hence approximately Gaussian), and consequently that the "_ves" W.F. contributions to HAi (i = [x,y,z]) are also linear (and Gaussian). Wave-frequency catenary contributions to HAy_tot, however, are nonlinear responses to wave excitations and hence exhibit non-Gaussian statistics, analogous to wave-frequency line tension oscillations.

Since all three hinge angle components have both wave-frequency and low-frequency contributions arising from wave-frequency and low-frequency vessel motions, their statistical properties are reported in an XCLDAT.stxt-style format, isolating and displaying both wave- and low-frequency contributions and other statistical properties.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

Can you say a few words about the [Catenary, Elastic] tangential fairlead motion percentages and the "Cross-Correlation Coefficients" reported in "Hinge_Motn.stxt"?

The "Cross-Correlation Coefficients" are included in the hinge-angle output stream because they provide insight into the interplay between catenary (e.g., HAy_cat) adjustments arising from [x,y,z] wave-frequency fairlead motions, and the "hinge" rotations (e.g., HAy_ves) contributing to the total "hinge angle" between the vessel and the line tangent [HAy_tot = HAy_ves - HAy_cat; note the minus sign]. The cross-correlation Coefficient (CCC), when negative, means that the vessel- and catenary- portions of HAy_tot are out of phase, resulting in large differences; when the CCC is positive, these contributions are subtractive, leading to relatively less wear and/or fatigue. It is theoretically possible to construct environment conditions which would, for a given fairlead, produce equal and out-of-phase [HAy_ves, HAy_cat] contributions that sum to zero (CCC would be +1.0 in that case), producing negligible wave-frequency wear at that fairlead in that environment.

The "Tangential Motion Percentage" is a statistical measure of the fraction of the tangential fairlead motion due to (1) gravitational catenary adjustment versus (2) that due to elastic stretch; the breakdown for an inelastic line is therefore [Catenary, Elastic] = [100, 0], while for a neutrally buoyant elastic line, [Catenary, Elastic] = [0, 100]. Generally, for any line with both catenary and elastic adjustments, this percentage will depend upon the amplitude and spectrum of the incident wave field, arising from the highly nonlinear nature of the catenary contribution.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I notice that some RMS angular variations reported in "Hinge_Motn.stxt", such as the low-frequency contribution to HAy_ves, appear often (always?) to be zero. Also, the wave-frequency RMS values for HAx_cat and HAz_cat likewise are often zero. Do these zero values result from some underlying approximation? I don't see any reason why they should vanish.

HAy_ves, by construction, depends only on the vessel pitch and roll degrees of freedom; you may need to think about that a bit (recall the fairlead-local y axis is always horizontal). SeaSoft's only support for low-frequency pitch and roll motions is in Sparsim; in Moorsim and SPMsim, vessels are assumed to have negligible low-frequency pitch and roll. Hence, Sparsim aside, the LF contribution to HAy_ves will always vanish in Moorsim and SPMsim.

Note: The SeaSoft model assumes wave-frequency vessel motions (all 6 DOF) are linear and Gaussian, and therefore the "vessel contribution" HAy_ves is also linear and Gaussian. The "catenary contribution" HAy_cat is generally nonlinear and non-Gaussian, just like wave-frequency tension oscillations, and is treated similarly.

Regarding the wave-frequency RMS values for HAx_cat and HAz_cat: These angular contributions arise only from vessel wave-frequency surge and sway (the fairlead-local [x,z] plane is vertical). Because the fairlead-anchor distance is usually very much greater than surge and sway amplitudes, the angular variations of the instantaneous line tangent due to those motions is small, often so small as to not register even at the .01 degree reporting level. Only rarely are they identically zero however; that *can* happen if all LF fairlead motion for a particular fairlead is confined by circumstance to the mean line plane.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

With the release of SeaSoft version 6.12 there appeared, in the SHIPRAO and SHIPRAN output streams (produced when "vessel motions" are requested in Moorsim or SPMsim), tables of "Ball Hinge" data (RAOs and significant values). What is this quantity and why has it been included?

The "Ball Hinge" output data to which you refer, recently added to all Moorsim/SPMsim/Sparsim/TLPsim vessel motion output streams (Semi, Ship or Disc), comprises the wave-frequency portion of "HA_ves" (i.e., HA_ves also contains low-frequency contributions) of the total Hinge Angle ["HA_tot"] introduced at the same time; note that HA_ves derives solely from angular vessel motions (surge, sway, yaw) about the fairlead and is independent of vessel lateral motions (surge, sway, heave).

You may wish to search the FAQ for references to a complementary new output file ("Hinge_Motn.stxt") for additional discussion of HA_ves and the role it plays in the target variable HA_tot.

The "ball hinge" terminology is meant to conjure images of the human shoulder joint, which permits rotations about 3 axes instead of only one, as with a normal single-axis (knee, or door-type) hinge.

The new wave-frequency HA_ves output stream comprises RAOs [SHIPRAO, SEMIRAO, etc.] and significant values [SHIPRAN, SEMIRAN, etc.] for all three components of small-amplitude, wave-frequency rotations of each fairlead relative to the *mean*, globally fixed, mooring line tangent vector pointing from that fairlead away from its anchor. Put another way, these angle variations are the small-amplitude vessel rotation components (roll, pitch, yaw) resolved in a special fairlead-specific globally fixed coordinate system. The "ball hinge" angles, when added (with proper phasing) to wave-frequency line departure angle deviations produced by *lateral* fairlead motions, is a factor in the rate of wear and local fatigue between two specific chain links: the last link mechanically locked to the vessel, and the immediately adjacent anchor-side link (free to move relative to the first; i.e., not constrained by the vessel). [The statistical characteristics of this combined, phased relative angular motion, between the fairlead-bound chain link axes and the global-system-relative oscillating line tangent, is reported in "Hinge_Motn.stxt".]

To restate for emphasis: There is no information in the SHIPRAO or SHIPRAN "ball hinge" data regarding: (1) low-frequency contributions of any kind, or (2) wave-frequency variations in the line tangent angle arising from fairlead rectilinear motions (lateral or vertical); those variations are analyzed, then combined with the HA_ves (i.e., rotational) contributions, and reported in Hinge_Motn.stxt.

Note: The coordinate system used to describe the "ball hinge" angular motions is identical to that used to describe the "tangential" and "normal" components of fairlead motion relative to the mean line tangent in SHIPRAO, SHIPRAN and elsewhere: origin at the fairlead; z away from anchor along the mean line tangent; x in plane of the line orthogonal to z; y horizontal (perpendicular to the [x,y] plane; direction specified by the right-hand rule). The three rotation *angles* are the small-amplitude, wave-frequency vessel pitch, roll and yaw rotations resolved along these fairlead-specific axes; rotations about z, for example, are "twisting" motions of each mooring line about its fairlead tangent.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I have turned the flag "Output "chain hinge" relative motion at fairlead" to "yes", but there is no Hinge-Motion.stxt file.

Hinge-Motion.stxt is not currently available for CALMsim, SALMsim, TLPsim or Towsim, nor for "legacy" normal mode runs of SPMsim, Moorsim, Sparsim; otherwise, you should find a Hinge-Motion.stxt file. Also, the item "Prepare tab-delimited output summary file (XCLDAT.stxt)" must be toggled to "yes".
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I tried to use SPMsim to find the vessel equilibrium position and orientation in a crossed, steady wind and current. It seems to go into some kind of infinite loop and never completes the run. How can I fix this?

This is a known issue and has been resolved as of version 6.12. If you have an earlier version, or if you have possibly encountered an untested problematic path through the code, try this to get moving again: Apply a trivial amount of variability *somewhere* in your environmental specification. For example, replace your steady wind with the same mean wind with a negligible point spectral value for the wind speed (e.g., .00001 m^2/sec). That may allow the simulation to terminate normally and should result in negligible vessel motion.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I have an SPMsim license and wish to use the "locked turret" option. This vessel has a central, not offset, turret. Should I be using Moorsim for this application?

In general, yes. SPMsim's normal mode model may have singularity issues if the so-called "sway-yaw" modes become pathological, as they can when the mooring centroid and vessel centroid coincide. That condition is Moorsim's assumed configuration. That said, we have done some comparisons of these two cases (Moorsim vs locked central turret in SPMsim) and were surprised how closely they comported.

At the very minimum, you should do at least one spot check against Moorsim to be sure SPMsim is not going off the rails for your specific environment and configuration.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I am puzzled that you can assign damping estimates for the system normal modes in SPMsim versions 5.5 and later. My understanding of these things is that "equivalent linear" damping estimates are only meaningful for one-degree-of-freedom systems; yet the version 5.5+ modal analysis purports to be a fully coupled 3-degree of freedom analysis. Could you discuss this?

You are correct. First, some history: For the purposes of damping estimation, the "legacy" normal mode treatment for SPMsim comprised a single DOF subsystem [surge] with a fully-coupled two DOF subsystem [sway-yaw]. This treatment was formally restricted to near-aligned mean vessel heading and mean turret offset, although it proved surprisingly robust even for relatively large angles between vessel heading and turret offset. Even in that simplified analysis, the breakout of damping contributions from the various environmental contributors (still water, wind, current, etc.) was a qualitative procedure that required modeling of the coupled 2 DOF subsystem, approximately, as two de-coupled 1-DOF subsystems. Though qualitative, we felt this breakdown was important in helping to identify the sources and strengths of the various damping contributions.

Modal damping estimates in the post version 5.5 treatment, valid for arbitrarily misaligned vessel and mean offset, are developed by a different means: As for a single degree of freedom system (such as a simple spring-mass-damper), each normal mode of a multi-degree-of-freedom coupled system is characterized by an oscillating part and a decaying part (i.e., described by an exponential function with a complex exponent). The "decaying part" of the solution is a meaningful measure of the "linear damping" associated with excitations of that isolated mode. It is that decay parameter that is being reported in LOWOUT, presented in such a way that it transitions into the legacy report as the vessel-mean offset alignment trends to the legacy limit (i.e., perfect alignment).

The same general procedure also is used for the "surge-sway" normal modes of Moorsim, Sparsim and TLPsim;, although there the situation is conceptually simpler because sway-yaw and surge-yaw coupling are essentially non-existent.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

Unlike Moorsim, the "Mooring Stiffness" reported in MEANOUT for "legacy" runs of Sparsim and TLPsim does not match the stiffness reported in LOWOUT. Please explain...

The value in LOWOUT is better; it accommodates incremental vessel pulldown & trim/heel variations during small-amplitude offsets that is ignored in MEANOUT.
Added:     Dec 5, 2016
Modified:  Dec 5, 2016

I do not see a manual for Squallsim in your documentation; where can I obtain it?

Squallsim-specific input items all can be found on the "Time-Domain Options" Editor Page for all SeaSoft "comprehensive" simulations, including SPMsim and Moorsim. The only pedagogical resources available at this time for Squallsim options are in the online help entries for the items on that page, and in the Technical FAQ.
Added:     May 9, 2017
Modified:  May 9, 2017

I see SPMsim and Moorsim mentioned in the FAQs as supporting Squallsim. I also note that the "Time-Domain Options Page" exists for the TLPsim and Sparsim editor programs. What is the status of Squallsim support for TLPsim and Sparsim?

If market forces dictate, Squallsim will ultimately support all SeaSoft "comprehensive" simulation applications, including Sparsim and TLPsim. Squallsim v .75b (Early 2017) may *appear* to run to completion for TLPsim and Sparsim, but they are not yet fully supported; any output stream produced, while possibly of some qualitative value, should not be trusted for engineering analyses.
Added:     May 9, 2017
Modified:  May 9, 2017

I am uncertain what would motivate me to "Force-rebuild all support data". My understanding was that the parent program (e.g., SPMsim) would automatically rebuild everything necessary each execution.

It may become necessary to force rebuild *all* Squallsim support files during a troubleshooting effort, and it certainly will not hurt in general. However, forcing rebuilds will result in substantially longer execution times.

In the interest of faster turnaround, especially during design or "quick look" scenarios, you can leave this option set to "No" (the built-in "table rebuild" mechanisms will remain in effect); SeaSoft does indeed check during each time-domain support execution to see which maps, if any, need to be rebuilt due to datafile changes since the preceding execution. This check is NOT, however, a bullet-proof, ironclad guarantee that something will not be overlooked, especially as Squallsim development is still in the early stages and the opportunities for exhaustive testing of the table updating and management algorithms are limited.

Therefore: [1] rebuild as a troubleshooting measure when you encounter or suspect problems of any sort, and [2] prudence suggests you force a fresh rebuild before carrying out any final or "production" run. See also this FAQ: "Avoiding unnecessary re-computation of Squallsim's support tables?"
Added:     May 9, 2017
Modified:  May 9, 2017

How do I prevent re-computation of the various Squallsim map tables (Moor_Force_Map.sqsm, Fairlead_Load_Map.sqsm, etc.); it appears that they take considerable CPU time to create. Is re-computation of these always necessary?

In theory, unless you have selected to "Force-rebuild all support data", Squallsim should only rebuild support tables when necessary (due to changes made to your input data). So, for example, if you simply execute Squallsim twice sequentially with identical SPMDAT and SQUALDAT files, the necessary tables will already exist before the second execution, and will not be rebuilt. If, however, you make changes to the SPMDAT file (e.g., vessel, environment, mooring, etc.) for the second execution, those changes in general will affect, however slightly, the low-frequency excursion/orientation maps required by Squallsim. This means that if, on the "Time-Domain Options" Page, you choose the "default L-F excursion disc" (by specifying a value of exactly "0"), SPMsim will produce a new universe of support maps with *any* change in mooring, vessel or background environment variables, even a trivially small change in any environmental force (e.g., even a .01 knot increase in wind speed).

You can eliminate the automatic re-build of maps circumstance by setting the "Diameter of L-F excursion disc" on the Time-Domain Options Page to a non-zero (i.e., non-default) value that represents a meaningful "excursion disc upper bound diameter" for your mooring and environment; here, we use 175 m for illustration purposes; you will need to prepare a value for your specific circumstance, as indicated further below:

        Diameter of L-F excursion disc (0 for default) .....   175.00 m.
The diameter you choose for your system should be large enough that the associated plan-view circular area (centered on the quiescent mooring centroid) will contain the most extreme mooring centroid excursions that will be encountered. For a squall analysis, you aren't always going to be in a position to make a good estimate of this diameter in advance, so there may be some trial and error involved. But note: If *any* squall history in your universe of time histories produces vessel excursions that exit your hardwired excursion disc, you will be notified during that Squallsim run. This circumstance will normally result in a premature termination; output, if any, following any such warning should not be relied upon.

Here is how we at SeaSoft minimize or eliminate reconstruction of mapping tables when analyzing multiple similar Squall events:

[1] Make a run with a default disc diameter of zero, using your best guess for the *most severe* squall history in your design universe (i.e., a squall instance you anticipate will produce the largest extreme vessel offset).

[2] Estimate a "taut line limit" [TLL] excursion disc diameter from your knowledge of the system static offset characteristics; that is, the largest excursion circle which would still (barely) avoid any kind of mooring system failure.

[3] Choose for your diameter estimate the value reported by Squallsim from [1], times a "cushion factor" of, say, 1.25 or 1.50.

[4] If your preliminary diameter estimate from [3] exceeds that of your TLL excursion circle from [2], choose the largest diameter that will just avoid exceeding the TLL, say 95%-99% of the TLL.

This procedure will normally permit all (or at least most) of your cases to run to completion with a single set of *.sqsm tables (these are in the "td_aux" directory), thereby minimizing run-times for all but the first execution of your universe of squall histories.
Added:     May 9, 2017
Modified:  May 9, 2017

Can you clarify which input items will result in a rebuild of Squallsim support data?

Any change to any simulation parameter NOT listed on the "Time-Domain Options" Editor Page; this includes everything: vessel, environment, mooring/riser complex, damping options, etc. Never execute Squallsim after making any changes to SPMDAT/MOORDAT without first running the parent application (SPMsim/Moorsim, etc.).

With only two exceptions (the Excursion Disk Diameter setting and the "force rebuild" option), values on the "Time-Domain Options" Editor Page can be modified without rebuilding the "*.sqsm" time domain support files. Changes restricted to the "Time-Domain Options" page, in conjunction with the "Chain to Squallsim" option on the last ("End of Session") page, result in exceptionally fast Squallsim turn-around times for exploring "what if" scenarios.
Added:     May 9, 2017
Modified:  May 9, 2017

Experimenting with changes to background current intensity and direction suggests that any such change will cause a complete rebuild of most (all?) Squallsim support tables. Why is that?

Any change in surface current will change all the wave forces (this is due to the dependence of both mean and variable wave drift and drag forces on current).

WARNING on current eddy option: The current eddy option probably does NOT do what you expect with respect to current impacts on wave forcings: ALL current effects on wave forces presently use only the "background" current from SPMsim/Moorsim (and ignore the current specified in Eddy_Hist.txt). This is admittedly illogical, and is expected to be remedied in a future release.
Added:     May 9, 2017
Modified:  May 9, 2017

I have noticed that execution times for semi-submersibles in Moorsim are noticeably impacted by the state of the flag: 

        "Exclude wave absorption damping and excitation."
What is your recommendation on the use of that flag in Squallsim?

Please read the online help for the "Time-Domain Options" Page item "Ignore wave drag variability to low-frequency force?" for a quick introduction to the Squallsim-relevant issues.

My personal preferences reflect my impatience. When beginning a new semi project in Moorsim/Squallsim, I often turn off the "wave absorption damping and excitation dynamics" ("wave drag" for short) until the dust settles around a particular design or environment of interest, then turn it back on to investigate how important it is in that specific context. (Note that the "Time-Domain Options" Page item "Ignore wave drag variability..." mentioned above is not applicable when wave drag is disabled, and is therefore hidden in that case.) Generally speaking, wave drag forces can be important for semis, especially in the presence of a background current, but they only rarely dominate; proceeding as above gives a feeling for how significant they are in a given circumstance.

In Moorsim (as well as Squallsim), the *variable* wave drag computations (as contrasted to the *mean* wave drag computations) are much more time-consuming. In Moorsim this is usually not a problem, but in Squallsim, because the calculations must be carried out at many spatial/orientation grid points in the low-frequency excursion envelope, it can be annoyingly time-consuming. Toggling "Ignore wave drag variability to low-frequency force?" to "Yes" will eliminate the computation of those tables as you troubleshoot your Squallsim options, at which point it can be restored to "No" for your production run(s).
Added:     May 9, 2017
Modified:  May 9, 2017

I noticed a new item ("LCG-to-Midships distance") on the SeaSoft "Vessel Hydrostatic Characteristics" Editor Page with version 6.50. My understanding was, as a simplifying principle, SeaSoft treated LCG, Midships, mooring centroid of a spread-moored vessel, etc., as functionally identical for practical purposes. Has that position changed?

In a word, yes. The introduction of Squallsim prompted a more refined specification of the longitudinal datums. Our historical recommendation to use the LCG at keel level for the coordinate origin of vessel-bound locations (such as fairleads, risers, tug attachments, acceleration point coordinates, etc.) has not changed. However, since OCIMF environmental moment coefficients apply about the *Midships* point (i.e., LPP/2), and not to the LCG, some users raised the reasonable question as to which location (LCG or Midships) would be the better choice for vessel coordinate origin. The introduction of this additional variable eliminates the confusion; you now must specify both. To recover the pre-v6.50 behavior, simply set "LCG-to-Midships distance" to zero, even if it is not.
Added:     May 9, 2017
Modified:  May 10, 2017

Can you give some guidance on the use of the "Orcaflex Emulation Mode?". This evidently requires three parameters (a "Cross flow principle reduction factor" and "added sway-yaw damping coefficients").

The "added sway-yaw damping coefficients" are described in the Orcaflex online documentation, where they are referred to (ca. 2017) as "Yaw Rate Drag Factors".

There is a brief background discussion of the "cross flow principle" [CFP] issue in Appendix H of the Moorsim manual; you should review that if you have not. In brief, SeaSoft and Orcaflex use a different methodology to compute hydrodynamic loads on subsurface slender members (i.e., moorings and risers), with SeaSoft's force estimates often being substantially larger for the member collection as a whole. In order to obtain the same Orcaflex and Squallsim mean vessel position, SeaSoft's hydrodynamic slender member loadings must be adjusted to roughly match those of Orcaflex. (Other environmental forcings, such as wind, waves and current forces on the hull, should automatically be identical if the same OCIMF-style coefficients and wave-drift/drag force coefficients are used.)

For a turret-based system, obtain the *mean* offset for the environment of interest in both Orcaflex and SPMsim. The "Cross flow principle reduction factor" estimate is simply the Orcaflex mean offset divided by the SPMsim mean offset (as noted above, this ratio will generally be less than 1; usually between 0.5 and 1.0).

This is plainly a very approximate procedure, but if the mooring/riser system static restoring curve is reasonably linear out to the mean offset point, as it usually will be, this CFP factor will produce roughly the same mean position in Squallsim as in Orcaflex, so that Orca-Squallsim *variable* vessel motions can be more meaningfully compared.
Added:     May 9, 2017
Modified:  May 9, 2017

Could you say a few words about the "td_aux" directory, its contents, and the other files associated with a Squallsim preparatory run of SPMsim?

Squallsim's user-controllable universe comprises:

1. User choices occurring on the Editor "Time-Domain Options" Page. 2. The vessel, system specification, and background environment specified in the SPMDAT file. 3. A handful of other Squallsim-specific user-supplied input files, including:

   Squall_Hist.txt
   Eddy_Hist.txt
   RanTable.txt
Squallsim's file naming rules follow the SeaSoft file convention:

  *DAT   - User data input saved by SPMsim during an editor session
  *.txt  - Auxiliary user-supplied (or user-specified) tabular data
  *.stxt - Program generated output files
Squallsim's "*_Hist.txt" files are self-explanatory; they are user-specified and prepared according to instructions in the online help of the "Time-Domain Options" Editor Page.

RanTable.txt, if not found at runtime, will be generated internally by Squallsim. It can also be supplied by the user (or copied into the working directory from an earlier, saved, execution) in order to achieve the same stochastic time series for environmental forcings during each Squallsim execution.

SPMsim also generates a collection of tabular data needed by Squallsim; these are text files with file suffixes "*.sqsm" and saved in the "td_aux" directory, which directory appears alongside SPMDAT and the *.stxt output stream from SPMsim in your working directory. Although the contents of the td_aux directory are mostly text files, viewable in any editor, care should be taken not to alter, delete or move them; doing so will likely produce an abnormal termination of Squallsim, and may cause troubleshooting headaches. Look but don't touch.

Squallsim-specific *.stxt output files, which lie alongside other SPMsim output files (RANOUT.stxt, etc.), currently comprise:

  TD_HistoryOut.stxt
  TD_WFlineStatsOut.stxt
  TD_Statistics.stxt
  
The names suggest their function and are discussed further in nearby FAQs.

Added:     May 9, 2017
Modified:  May 9, 2017

When should I use the "Chain to Squallsim" option on the "End of Session" Page of SPMsim?

Please read carefully the help item for that option, which has the best guidance we can offer. It simply causes SPMsim to chain automatically to Squallsim following a successful SPMsim invocation. It was designed to facilitate quick-turnaround in "what if" experimentation runs that alter only data on the "Time-Domain Options" Page (thereby obviating the need for any rebuilding of Squallsim's support tables by SPMsim and producing a very fast [SPMsim + Squallsim] execution cycle).
Added:     May 9, 2017
Modified:  May 9, 2017

What is the function of the Net_LF_Force_Dat.sqsm file?

This can sometimes be useful for troubleshooting analysis & support; it is basically a Slowsim-style tabular display of the net quasi-static background environmental loading as a function of vessel heading, *exclusive of any transient contributions* (e.g., from squalls or eddies).
Added:     May 9, 2017
Modified:  May 9, 2017

I am getting rather cryptic file I/O errors at runtime; they look like Fortran-reported system errors during attempted file access. What should I do?

This is a symptom of corrupt or missing support files in the "td_aux" directory which can happen if you move, alter or delete anything inside that directory, perhaps inadvertently. The fix is to simply delete your entire "td_aux" directory and re-input your "Time-Domain Options" Editor Page data from scratch; this will force the re-creation of "td_aux" and all of its data tables on the next SPMsim invocation. 
Added:     May 9, 2017
Modified:  May 9, 2017

I know which SPMsim user-supplied data files to submit with a support request (e.g., SPMDAT, LOWDAT, *COFS.txt, *SPEC.txt, *RAO.txt, etc.). And, I assume that for Squallsim support I will also need to include SQUALDAT, the squall/eddy time history, etc. Anything else?

You have the right idea. Note that the RanTable.txt file should also also be included, as should all *.txt files, (but NOT *.stxt files or *.sqsm files, unless specifically requested by SeaSoft). 
Added:     May 9, 2017
Modified:  May 9, 2017

I recently saw some very unusual runtime error messages that are not in SeaSoft's usual messaging format; in particular, they were in ALL CAPS. Comments?

These are produced by the NIST time-domain solver ["TD-solver"] and interpolation packages we are currently using. If you are unable to achieve runtime completion employing reasonable troubleshooting efforts, you should forward your input dataset (SPMDAT, SQUALDAT, *.txt), along with a copy/paste of the error message(s), to SeaSoft.
Added:     May 9, 2017
Modified:  May 9, 2017

I understand SeaSoft uses either [1] a user-specified or [2] a SeaSoft run-time estimate for the diameter of a plan-view "vessel excursion limit circle". Where can I find the numerical value of the SeaSoft estimate?

When you specify an excursion diameter of "0" on the "Time-Domain Options" Page, SeaSoft prepares its own estimate; that estimate is reported in the header block of each output file, e.g., TD_HistoryOut.stxt or TD_Statistics.stxt.
Added:     May 9, 2017
Modified:  May 9, 2017

Can you discuss briefly the relationships between the "default" fairleads and the "selected" fairleads (on the "Time-Domain Options" Page) and "lines for dynamic evaluation" (on the "Dynamics-Related Mooring Information" Page)?

Every SPMsim execution is associated with a number of fairleads equal to the number of [mooring + riser] members specified on the "General Mooring Information" Page. Output volume from that universe of fairleads can be "pruned" with the "lines for dynamic evaluation" selector (found on the "Dynamics-Related Mooring Information" Page); this provides user control of a subset of lines for inclusion in SPMsim's output stream (e.g., RANOUT.stxt or XCLDAT.stxt). That "pruned" set of fairleads is the "default" set for output from a follow-on Squallsim invocation. To offer still more control of Squallsim output volume and file sizes, that "default" selection of fairleads may be further pruned as desired on the "Time-Domain Options" Page; this final Squallsim-specific line collection is the "selected" set; it determines which lines will be included in Squallsim's output stream ("TD_WFlineStatsOut.stxt" and TD_Statistics.stxt). Note that lines "pruned" by either mechanism (i.e., on either "Dynamics-Related Mooring Information" or "Time-Domain Options" Pages) are fully engaged in the dynamical response; they are NOT treated as "broken lines". Broken lines, which are handled the same in both SPMsim and Squallsim, are set elsewhere in the SPMsim editor (on the "More General Mooring Information" Page).
Added:     May 9, 2017
Modified:  May 9, 2017

Can you say a few words about the cryptic "<<< Time-Domain Support Resources (sec) >>>" block of a Squallsim-associated "Diagnostics.stxt" file? In particular, what is the "Angular spectra prep" item?

The "<<< Time-Domain Support Resources (sec) >>>" block is just a quick-and-dirty FYI to give an idea of the Squallsim-related computational load (in cpu seconds) for a few of the most CPU-intensive Squallsim-support tasks carried out during the parent SPMsim execution. The "Angular spectra prep" time relates to the preparation of the L.F. vessel forcing spectra for wind, waves, and current as a function of vesel-relative environmental approach angle. For waves, this task includes wave drift, wave drag and their correlated combination. Wave drag spectra for semis comprise a particularly time-consuming component that can be turned off, if desired, to improve runtime performance (at the expense of losing the variable wave drag forcing, of course).
Added:     May 9, 2017
Modified:  May 9, 2017

I am having trouble determining the logic governing Squallsim's "duration"; can you provide some guidance?

The "duration" of the simulation output time history will be the *smallest* of:

1. The requested Squallsim duration (the default is the parent application's "Storm duration"; Squallsim can use a different value, which is specified by the user on the Squallsim options page).

2. The shortest duration of any wind squall or current eddy event (as codified in the Squall_Hist.txt and/or Eddy_Hist.txt file[s]).

Note: The "Storm duration" of the parent application (i.e., Moorsim or SPMsim) *always* governs the peak values reported in LOWOUT, RANOUT, XCLDAT, etc., regardless of the duration set (either directly, or indirectly by squall/eddy duration) for Squallsim. This is also true of the wave-frequency component of peak line loads reported in the Squallsim statistical output (TD_WFlineStatsOut.stxt). That is admittedly illogical, since the Squallsim duration can be different from the parent's "Storm duration"; this will likely be addressed in a future version.
Added:     May 9, 2017
Modified:  May 9, 2017

Can you discuss the methodology behind Squallsim's wave-frequency line load statistical measures {mean, sigma, two sigma, peak}, reported at each time step in TD_WFlineStatsOut.stxt?

In the present incarnation of Squallsim, reported wave-frequency variations in line loads, available at each time-step in the "TD_WFlineStatsOut.stxt" output file, are estimates synthesized using the wave-frequency statistical algorithms in the parent executable (SPMsim or Moorsim), applied to the vessel position/orientation at each time step. This statistical approach runs counter to, and has no equivalent in, a Conventional Time Domain Analysis [CTDA], which instead computes at each time step the line load resulting from the instantaneous position, motion and acceleration of the vessel at that time step (with no decomposition into low-frequency [LF] and wave-frequency [WF] parts); by design, the CTDA approach offers no per-time-step WF statistical load information; it simply estimates the total actual load in each line at each point in time.

SeaSoft's WF algorithms, by contrast, are those used to prepare the wave-frequency load statistics reported in XCLDAT. The Squallsim quantities are estimated under the (fictitious) assumption that the vessel remains in the position and orientation associated with each time step for the entire "Storm duration" specified in the parent executable. In our (admittedly biased) view, the Squallsim line load statistics carry far more information for design and survivability purposes than the line load time histories flowing from a single CDTA execution.

First, a qualitative aside about correlation issues: Even in the absence of non-wave-related forcings (wind, current, etc.), WF vessel offsets are only weakly correlated (in the strict mathematical sense) to LF vessel offsets (i.e., offsets driven by slowly-varying wave drift and drag forcings). This is because maximum WF vessel motion amplitudes are very *strongly* correlated with maximum wave amplitudes (and hence with maximum slowly-varying wave drift and drag forces). Put more simply, maximum LF wave-drift/drag forces occur in concert with the maximum amplitude of wave-frequency vessel motions. But, the LF *motions* associated with those slowly-varying wave drift/drag forces tend to be *weakly* correlated with the LF forces themselves, and hence are also weakly correlated with the WF motions. This is because moored-vessel dynamical systems behave qualitatively (on time scales long compared to a typical wave period) like heavily damped nonlinear oscillators, whose maximum (LF) motions (which occur at oscillation frequencies near modal resonance peaks) are ~ 90 degrees out of phase with their driving forces. A 90 degree phase difference between two random variables is the hallmark of uncorrelated behavior. Think about a stochastically-driven one DOF spring-mass-dashpot system to get some physical insight to this.

Terminology: The "Quasi-Static Configuration Space" [QSCS] is the 3-D set of realizable coordinate/heading combinations [X,Y,Theta] which are physically accessible to the vessel without failure of any mooring structures; the outer boundary of this space forms a well-defined 2-D surface in the 3-D QSCS. The boundary surface of a turret-moored FPSO is particularly simple because quasi-static line loads are, to a good approximation, independent of vessel rotations about the turret. The QSCS for a turret system is therefore just the region inside a closed curve in the [X,Y] plane (which will be roughly circular for a highly azimuthally-symmetric mooring layout). Things are a bit more complicated, obviously, for a spread-mooring system, where the QSCS is fully three-dimensional, with a much more complex shape. (Exercise for the interested student: sketch the QSCS for a spread-moored spar in a perfectly azimuthally-symmetric mooring; ignore pulldown for simplicity. Extend your sketch to encompass multiple 360 degree yaw rotations, assuming the hull is 100% transparent to the mooring lines, so that the mooring layout returns to its quiescent state as the spar approaches the zero degree heading point after completing a 360 degree rotation, and that no lines break during a 360 degree rotation.)

Every time domain simulation, whether Squallsim or CTDA, comprises one path through the 3-D QSCS. A perfect representation of every possible path is required for perfect statistical characterization of the system within the set of all storm histories of interest. In reality, CTDA's are rarely used for more than one, or at most a few, "statistically equivalent" environmental time histories. In a CTDA, when waves play an important role in load variability, it is fundamentally impossible without an impractical amount of computation time to get a meaningful statistical estimate of the likelihood of line failure near any particular region of interest in the configuration space.

Referring to the correlation discussion above, we believe that the wave-frequency component of mooring/riser loads are most usefully quantified using Squallsim's unified statistical treatment, which superposes the wave-frequency motions atop each quasi-static trajectory of interest in the QSCS. This approach permits, for example, a simple and straightforward approach to answering an important question: What is the likelihood of a mooring/riser failure when the vessel passes through or near quasi-static offset regions of maximum quasi-static vulnerability? That question has relevance, for example, in preparing the mooring/riser layout during site analysis and performance evaluation utilizing historical environment data. It is true that Squallsim's approach loses the correlation between LF and WF vessel motions that flow automatically from a CTDA; for that reason Squallsim cannot at present replicate a fully-correlated CTDA treatment, although there are no problems of principle to implement such a treatment, should user demand warrant it. Whether the Squallsim methodology is superior or inferior to conventional methods for engineering purposes is will depend on the objectives of the analysis; it does, however, offer a powerful system design and analysis tool, which is arguably more comprehensible and concise than a large, statistically significant ensemble of conventional independent time histories.
Added:     May 9, 2017
Modified:  May 9, 2017

The "Time History Vessel Motion Statistics" block of TD_Statistics.stxt is reasonably clear to me. The "Time History Line Tension Statistics" block, much less so. Please explain and discuss the "Line Tension" column labels; I find them a little cryptic, and I'm unsure what to make of the "History Average" of "WF Sigma+", etc. What, exactly, is the relationship of the quantities in TD_Statistics to the WF load time histories in TD_WFlineStatsOut.stxt? Follow-on: What is the significance of the "+" in "WF Sigma+"?

You are right; these labels are quite confusing. Please review the FAQ nearby entitled "TD_WFlineStatsOut.stxt methodology & motivation" for additional clarification and enlightenment.

The data appearing in TD_Statistics.stxt comprise various straightforward along-the-time-history averages and extremes of vessel motions (from TD_HistoryOut.stxt) and line loads (from TD_WFlineStatsOut.stxt). You should be able to reproduce all the data in TD_Statistics.stxt by processing the parent data in TD_HistoryOut.stxt & TD_WFlineStatsOut.stxt. To do this yourself, process the line load columns in TD_WFlineStatsOut exactly the same as you process vessel position and rate columns from TD_HistoryOut.

The line *load* data in TD_Statistics is of two conceptually simple kinds:

1. Quasi-static (low-frequency) data (the first four data columns of TD_Statistics): These comprise, as sampled along the time history, the mean ["History Mean"], standard deviation ["History LF Sigma"], and max/min ["History LF Max/Min"] of the *quasi-static* fairlead line load. Conceptually, these loads are simply the time-history averages of the low-pass-filtered line load (i.e., wave-frequency contributions filtered out) as they might be measured by a fairlead tensiometer whose output is subjected to low-pass filtering.

2. Wave-frequency data: The remaining columns in TD_Statistics provide a kind of "statistical meta-analysis" of the wave-frequency statistical load data presented in each column of TD_WFlineStatsOut. By this we mean the along-time-history statistics performed on all the columns of TD_WFlineStatsOut, which columns are themselves already per-time-step wave-frequency statistical measures.

The data columns of TD_WFlineStatsOut comprise, for each requested line at each reported time step, the quasi-static "mean load" at that time step, along with the following wave-frequency statistical measures (also discussed in a "TD_WFlineStatsOut.stxt" FAQ nearby): (1) the "WF sigma+" load, (2) the "WF 2sigma+" load and (3) the "WF Peak+" load. The appended "+" simply indicates that the quantity refers to the 'plus side' of the WF load cycle. This distinction is necessary because the WF cycles of the (nonlinear) load processes are not symmetric about their mean, usually exhibiting larger plus-side peaks than minus-side troughs. Each of those three per-timestep TD_WFlineStatsOut wave-frequency statistical columns is then subjected to the same kind of along-time-history averaging as for the mean line load, even though they are *already* statistical in nature. That results, for each column in TD_WFlineStatsOut, a collection of average ("Hist. Avg."), standard deviation ("Hist Sig.") and max/min values ("Hist. Max/Min") in the TD_Statistics.stxt summary.

The remaining two columns "Estimated Net Max/Min" are simply estimates of the combined ("Net") maximum and minimum load experienced by each line; these are not represented directly in TD_WFlineStatsOut.stxt but are rather post-processed algorithmically from the LF and WF data to offer similar functionality to the Max/Min loads for each line reported automatically by a Conventional Time Domain Analysis [CTDA].
Added:     May 9, 2017
Modified:  May 9, 2017

I am having trouble seeing the practical value of the per-line "sig+, 2sig+ and peak+" columns in the TD_WFlineStatsOut time history. Can you discuss briefly? Follow-on question: What is the significance of the "+" in "WF Sigma+", etc., appearing in both TD_Statistics and TD_WFlineStatsOut?

Nomenclature, here and throughout, for wave-frequency [WF] line load components:

sigma = 1sig = WF fairlead load contribution due to tangential motion of one standard deviation. two sigma = 2sig = WF fairlead load contribution due to tangential motion of two standard deviations. peak = WF fairlead load contribution due to the most probable peak tangential fairlead motion

The appended "+" simply indicates that the quantity refers to the 'plus side' of the WF load cycle. This distinction is necessary because the WF cycles of the (nonlinear) load processes are not symmetric about their mean, usually exhibiting larger plus-side peaks than minus-side troughs.

It remains early days regarding the usefulness of this kind of statistical metadata, or its acceptance by users. Our feeling is that there is enormous value to a rigorous statistical estimate, integrated directly into the Squallsim output stream, that quantifies in a meaningful way the range of WF line load contributions that might be encountered at every point visited by the vessel in its transit through the configuration space (search the FAQ for "Quasi-Static Configuration Space" or "QSCS" for a discussion of this important concept in the present context).

Whenever vessel wave-frequency motion, when superposed atop motion arising from other low-frequency [LF] environmental players (wind, current, etc.) cannot be ignored, then the *largest* WF+LF loading events can occur nearly anywhere in the QSCS (particularly if the wave-frequency loading is comparable to the low-frequency loading), possibly resulting in line load excesses, anchor drag, etc. anywhere along the vessel track. It may seem that the locus of the largest events will always be near the boundary of the QSCS, but this is not necessarily the case in the presence of substantial waves. A peak wave event occurring near the quiescent equilibrium point may well produce the largest peak line load in the simulation. The point is, the WF line load contribution for any line at any point in the QSCS is governed by the choice of random phases adopted for each spectral contribution.

Put another way: As the vessel moves about the QSCS, consider a small region surrounding a point that lies somewhere along the vessel track. WF vessel motions associated with that point in space-time can be anything at all because of the freedom, for a given wave energy spectrum, represented by the random phases of the component wave spectral contributions. That is, for any space-time point along the vessel track, one choice of wave phases can produce a nearly calm water surface at that time step, while another equally probable choice of phases can conspire to produce the most probable peak wave at that same space-time point. A given time history can capture only one of the infinity of possible WF phasing choices.

In the context of a conventional time domain analysis [CTDA], the only way to quantify statistically the engineering risks of missing an unfortunate simultaneity in the LF and WF components of a line load time history is to prepare a large ensemble of CTDA runs using identical environments, differing *only* in the choice of random phases for the wave spectral components. This is a substantial computational undertaking and represents a post-processing challenge due to the huge datasets involved. Squallsim's statistical approach obviates that problematic issue for each time history in a tidy and uncomplicated way. That's our story, and we're sticking with it, for now...
Added:     May 9, 2017
Modified:  June 10, 2019

The time column in TD_History_Out appears buggy. I always request 1 second intervals, but sometimes the reported interval is 1.1 seconds, leading to a time column that does not display uniform differences row-to-row. Is this a bug?

No; the time solver software does not use your requested interval in any way; the solver has a mind of its own and will choose each time step "on the fly" to meet its convergence requirements. When things are changing rapidly (e.g., large accelerations), the internal time steps are quite small. When forces are small (small accelerations), the internal time steps can become quite large. The attempt to obtain a uniform spacing in the output table is therefore fraught, and your requested interval can only be achieved in an average sense.
Added:     May 9, 2017
Modified:  May 9, 2017

What are the different file types produced by Squallsim; I am referring to the file suffixes ".stxt", ".txt", ".sqsm",".dbug", etc.

The file naming convention parallels other SeaSoft input/output files, with a couple of Squallsim-specific additions.

Files lacking a suffix, such as SPMDAT or SQUALDAT, are raw input data files produced by the SeaSoft editors; some of these are binary and unreadable without the associated SeaSoft program or editor application.

"*.txt" files are ascii tabular input files supplying environmental or system properties (usually these are user-supplied: e.g., environmental spectral tables such as CRNTSPEC.txt, vessel property tables such as WINDCOFS.txt, etc.). Note: Squallsim's RanTable.txt is a tabular collection of random real numbers on [0.,1.] which are used to create random phase factors for building stochastic wind, wave, current, etc., time histories. RanTable.txt will be produced automatically by Squallsim if not found at run time (it could exist either from a previous execution, or be user-supplied to insure identical "random" time histories between executions).

"*.sqsm" files are tabular intermediate support files, produced by the parent SeaSoft application (e.g., SPMsim) for exclusive use by Squallsim; they are normally of little interest to the end-user, but may be requested by SeaSoft for troubleshooting purposes. Also, in an important subset of simulation scenarios, these will comprise re-useable data from an earlier Squallsim invocation that can prevent time-consuming rebuilding of some tables.

"*.dbug" files are tabular support files used by SeaSoft for development and debugging purposes; their purpose and function may change over time; they are normally of no interest to the end-user, but may be requested by SeaSoft for troubleshooting.

"*.stxt" files comprise the "SeaSoft text" output from all simulations. In Squallsim, these are all tab-delimited to facilitate import into spreadsheets or other post-processing software tools.
Added:     May 9, 2017
Modified:  May 9, 2017

I experimented briefly with the "Time-Domain Options" Page in SPMsim; now every time I make a new SPMsim run, it executes very slowly. What is it doing?

You probably left the toggle at the top of the "Time-Domain Options" Page ("Prepare Squallsim support files?") set to "Yes", even though you are not interested in a follow-on Squallsim execution. The "Time-Domain Options" Page options only apply to Squallsim and have no effect on SPMsim or Moorsim output. When running a straight SPMsim/Moorsim simulation (i.e., without intending a follow-on Squallsim execution), you need to be sure the top-level "Time-Domain Options" Page toggle is set to "No", otherwise the (extensive) Squallsim-support tables will be rebuilt on every SPMsim/Moorsim execution that modifies your SPMDAT/MOORDAT file (environment, mooring particulars, whatever). That is the likely source of your observed execution sluggishness.
Added:     May 9, 2017
Modified:  May 9, 2017

I am familiar with SPMsim and Moorsim and want to use Squallsim. Do you have "quickstart" advice for experienced SeaSoft users?

Most things will be self-evident; Squallsim is very tightly integrated with moorsim/spmsim and uses all the environmental/mooring/vessel data from SPMDAT; there are actually very few additional options specific to Squallsim.

You will want to set up a quick plotting mechanism; we use Mathematica; MatLab and Excel should both work fine, but Excel's performance with the massive amount of data in the time histories may be problematic.

Just fire up spmsim/moorsim v 6.50 or higher and "M"odify an existing system of interest. All the Squallsim options are on editor page 22 (note the "chain to Squallsim" option on page 23). Just start with defaults.

Execute the parent program (moorsim or spmsim) like you normally do; it will create all the stuff needed for Squallsim per your pp22 options. There exists a wide range of complexity in the support file prep time; semis with lots of members are the worst, many mooring lines/risers slows things down some. Squallsim-support table preparation is going to take one to several minutes to complete, depending on the complexity, before an actual Squallsim run can be carried out (either by chaining or by running Squallsim stand-alone).

The "Chain to Squallsim" item should not be used after any changes have been made to *non-Squallsim* data; you will get a warning to that effect if you try. When you have made changes to environment or mooring or whatever, just do a normal moorsim execution and then run Squallsim separately (or, after refreshing the support tables with a normal moorsim execution, go back into moorsim and chain to Squallsim from there after moorsim has rebuilt the Squallsim support stuff). This will eventually be handled automatically, but for now it aids users in getting used to how changes in the MOORDAT file impacts the Squallsim support table-rebuilding process.

You can start over from scratch at any time by deleting the entire "td_aux" directory and SQUALDAT, without affecting the underlying spmsim/moorsim input or output stream.
Added:     May 9, 2017
Modified:  May 9, 2017

Could you mention any operational tips that might be useful to someone with relatively limited Squallsim experience?

Note: The online help has numerous suggestions.

For quick turnarounds, experimentation and exploring "what-if" scenarios, following the initial spmsim/moorsim run to build the TD support tables, just make any desired changes on pp 22 (*except* the excursion diameter value; changing that will always require a complete rebuild of all support data; the program will warn you if that happens), go to the "L"ast page item 10, and execute Squallsim. No need to actually run the parent app again; this option just quits the parent app editor immediately and chains to Squallsim. You can do this as often as you want to explore sensitivities, etc. The turnaround is very fast using this method as the parent app does not get involved beyond the page 22 changes to SPMDAT and SQUALDAT

It is a Good Idea to archive the random variables (i.e., the RanTable.txt file) any time you archive *any* of the Squallsim output for any reason (currently, this only comprises TD_HistoryOut.stxt, TD_Statistics.stxt, TD_WFlineStatsOut.stxt). That will permit you (and SeaSoft) to reproduce your run at a later time if we need to troubleshoot something. Note: The RanTable.txt file only changes from run to run if the item

        Random seed choices reproduce time histories?
is set to "No", which you should avoid doing (except to test) unless you know you want that.
Added:     May 9, 2017
Modified:  May 9, 2017

Do you have a troubleshooting checklist you can share with new users?

Yes. Here is a short list:

1. Always force rebuild the support files at any sign of problems. Just delete the entire td_aux directory and start over, or use option 6 on pp 22 to do it more surgically. If problems persist, delete td_aux, RanTable.txt, and SQUALDAT. That gets rid of everything accessed by Squallsim. Deletion of SQUALDAT means you will have to rebuild all your pp 22 options by hand.

2. If you have plotting problems with the data produced by Squallsim (TD_HistoryOut.stxt or TD_WFlineStatsOut.stxt), it is possible that some "NaN" strings may have been written into the support tables; that would be a bug. If you have trouble plotting or post-processing, do a quick batch text search of the entire td_aux directory for a NaN string; there should not be any of those, ever. But we had some early on, so it is worth checking.

3. If you are getting TD-solver ALL CAPS MESSAGES (there is another FAQ on those), something is seriously wrong. If you can't eliminate that issue with sensible re-tries and option change testing, zip up:

        SPMDAT/MOORDAT
        SQUALDAT
        RanTable.txt
        SPMIN.stxt
        All other *.txt support files produced by you (WINDCOFS.txt, etc.)
and forward it to SeaSoft. 
Added:     May 9, 2017
Modified:  May 9, 2017

 

SeaSoft Home