January 25, 1998 SeaSoft Update Notes Several significant updates and bug fixes have been made in recent months. New versions of the software are now available; please email (seasoft@west.net) to arrange timing of software updates to be posted on our ftp site. ============================================================================ >>> Major bug exterminations: 1. A bug in the handling of mooring legs with a positive net buoyancy 2. A bug in the output of slack line loads in SNAPOUT 3. A bug producing erroneously computed moments in Moorsim when importing a data file from SPMsim 4. A bug that could produce output errors in some circumstances when using less than the maximum allowable number of interpolation table values in CALMsim, Moorsim and SPMsim. 5. A bug in the CALMsim wave-frequency line load estimates caused by an incorrect fairlead height-anchor distance calculation. ============================================================================ >>> Major Program Design & Load Reporting changes: 1. Reporting of "Low Frequency Variable" Loads in SNAPOUT A change has been made in the method of reporting low-frequency load *variations* in SNAPOUT. Previously, the variations reported in SNAPOUT were the same as those given in RANOUT; the logic for this choice was that there was really *no* low-frequency variation associated with SNAPOUT (since by definition the SNAPOUT report is made at a *single* point in the 3-dimensional low-frequency configuration space) and rather than report a *zero* variation that it seemed sensible to put some useful measure of low-frequency variations about the mean in the SNAPOUT report. However, our choice caused frequent confusion and has now been changed to something we hope users will find more logically appealing. Now, the low-frequency variation values reported in SNAPOUT are simply the difference between the *mean* loads and the quasi-static loads associated with the "snapshot" position used for SNAPOUT. These should, when added to the mean, now be the same as the low-frequency snapshot loads reported in LOWOUT. 2. Data file change to accommodate up to 49 mooring lines and 90 interpolation table values. Historically, all mooring simulations were limited to a maximum of 16 distinct lines and line types. Also, the historical maximum number of values in the static catenary-elastic load tables for all simulations was 30. These values became increasingly problematic as more and more complex systems evolved. Herein, when we refer to the "16-line version" we mean (16 line, 30 interpolation table values); similarly, when we refer to the "49-line version" we mean (49 line, 90 interpolation table values). For the past year, we have been supporting both the 16-line and 49 line versions with two separate simulation sets; (some users preferred to keep the 16 line versions since their existing data files were only compatible with these versions and there was no datafile cross-compatibility between the versions). This duality of effort and the proliferation of incompatible data files has caused me to abandon the 16 line version in favor of the 49 line version. To facilitate the transition, we have prepared a data file conversion utility which, when applied to a 16-line data file will produce a correctly configured 49 line data file which can then be used with the new simulations. This release will contain both the 16 line versions *and* 49 line versions. (This will be the last release of a 16-line version, so both of these should be archived away as a "matched pair" to have on hand for "resurrection debugging" of archived data files.) The version numbers of these "matched pair" of simulations in the format "Simulation Name (16 line version #, 49 line version #)" are recorded below: CALMsim (1.57, 1.60), Catsim (1.62, 1.70), Discsim (1.31, 1.40), Moorsim (3.88, 3.90), SALMsim (3.88, 3.90), Semisim (3.88, 3.90), Shipsim (3.88, 3.90), Slowsim (1.35, 1.40), SPMsim (3.88, 3.90), Statmoor (4.67, 4.70) Note that in the case of Statmoor, the number of line types and numbers is frozen at the historical value of 12, even after application of the conversion utility. However, the number of interpolation table points in Statmoor is increased to 90 by the conversion. Data files converted with the 16->49 line conversion utility should give exactly the same output between the paired versions (i.e., 16 & 49 line versions). Pre 49-line data files can be distinguished by their sizes; the 49 line versions are larger in all cases (including non-mooring simulations like Shipsim and Semisim). Note that all applications, even those like Semisim and Shipsim which contain no mooring line information, should be converted before use with the new 49 line versions. All earlier files should be directly convertible to the new format with the 16->49 line conversion utility. After converting, be sure to view the "change notices" that appear onscreen immediately after you select "M"odify on the introduction screen; these will alert you to important file changes that may require user intervention before execution (such as the recent addition of "mooring layers" to Moorsim, SPMsim and CALMsim). In a spot check of my own archives, I have found no data files that failed to be converted properly, but if you have a problem, the following work-around procedure may still produce a usable file. If a converted data file appears corrupted or suspicious when viewed or run using the 49 line version after conversion, the following procedure probably will resurrect it, provided the data file is not too ancient. (1) Load the problematic 16-line file (*before* conversion) into the 16-line version of the desired simulation accompanying this release. Many data file updates will automatically be done by the simulation, or it may alert you to the need to supply additional data. Do any necessary updates and exit the editor either by running the simulation or by selecting "Exit to operating system and update data file" on the last editor page. (2) Update the data file thus produced using the 16->49 line conversion utility. (3) Execute both 16 and 49 line versions (each with their appropriate updated data file) and compare results, which should be identical if the procedure was successful. In a worst-case scenario (i.e., when even this second more involved procedure does not produce a usable data file), you may need to enter all your data from the earlier data file by hand from the appropriate image file (eg., SPMIN or SHIPIN; you *did* archive all those input image files, didn't you?). If anyone actually has to go use either of theses more involved conversion procedures, I would appreciate hearing about it so that I can tweak the conversion utility, if possible, to accommodate the inconvertible 16 line data file. ============================================================================ >>> Major updates Note: In keeping with our usual practice of preserving the "old" way of doing things when changing or modifying existing algorithms, the "new" features, described below, can be turned on or off at will under user control of various input toggles. Synopsis: Equilibrium-search algorithms were completely reworked for SPMsim. Minutia: Previously, code common to both Moorsim and SPMsim was used for equilibrium determination. For SPMsim applications the older code, required for proper execution of Moorsim, proved increasingly problematic; that is, intermittent and unpredictable difficulties in determining equilibrium would occasionally prevent successful simulation completion. The new SPMsim-specific code is much more robust and should seldom, if ever, fail to find equilibrium (unless, as can happen, there *is* no stable equilibrium configuration). The original Moorsim-style equilibrium search can be re-enabled through a new flag on the "Output options 1" page (page 20 of the screen editor). ----------------------------------------------------------------------------- Synopsis: The default setting of the non-linear wave-frequency line load algorithm was changed from "large-amplitude" to "small-amplitude". Minutia: This change was made because the more comprehensive large-amplitude algorithm proved, over time, to be problematic in too many situations where it was simply not relevant, producing spurious warnings and generating unnecessary user angst. The large-amplitude algorithm is needed only in a (small) subset of systems exhibiting extremely "stiff" catenary behavior (such as shallow water chain moorings with relatively large static + low-frequency offsets). For earlier data files which employed the "large-amplitude" algorithm, the flag on the "Output options 1" page (page 20 of the screen editor) will need to be toggled to the "large-amplitude" setting when importing the earlier data files into later simulation. A startup warning message will identify these files. In general, the large-amplitude algorithm should be invoked, at least as a check on the small-amplitude algorithm, whenever "shallow water" conditions exist. A useful shallow water measure for this purpose is the (extreme wave height)/(water depth) ratio; when this ratio is greater than .05 (i.e., 5%), the "large-amplitude" algorithm should be invoked at least once to guard against possible systematic underestimation of wave-frequency line load contributions. ----------------------------------------------------------------------------- Synopsis: Another option for quantifying the "characteristic" level of wave-frequency line load fluctuations has been added. Minutia: In previous versions, the user could choose either One or Two "Sigma" (RMS) values to characterize the fluctuating part of loads and motions (both low- and wave-frequency). The algorithms used for these options (as applied to the wave-frequency load response) involved use of the one or two sigma tangential fairlead motion amplitudes to prepare a *sinusoidal* fairlead motion (whose period was chosen to be the spectral peak period of the fairlead motions). In some instances, the line load response at this single period could be anomalously high or low compared to the response at even fairly nearby periods. In view of this shortcoming, an additional option has been added which implements a quasi-linear spectral average over a *band* of load responses to reduce the possibility that a coincidental anomalous line load RAO at any single period will bias "characteristic load" estimations. Because wave-frequency line load fluctuations are highly nonlinear, there is no general way in a frequency-based analysis to rigorously compute RMS line loads. In this implementation, we create a line load "RAO" from the load response to regular waves whose amplitudes are chosen by the user (that is, either a one- or two-sigma wave is used according to the user "characteristic value" setting). This "RAO" is then applied against the input wave spectrum to arrive at a "variance" for the load process. The square root of this variance is then identified in the output stream as the "characteristic value", thereby substituting a spectrally-averaged quantity for the older, single frequency value. It is impossible to provide general guidance about whether the new spectrally averaged characteristic loads will typically prove smaller or larger than the old single-frequency loads. My guess is that in most cases the differences will be small. ============================================================================ >>> General Discussion: Most-loaded line loads in SNAPOUT versus RANOUT This note is to discuss the observation, which has been noted by many users in the past, that most-loaded-line loads sometimes show unexpected differences between RANOUT and SNAPOUT. This problem is distinct from the SNAPOUT slack-line problems (see "Major bug exterminations" above); or by the arguably illogical choice of output for the "Low-Frequency Variations" in SNAPOUT (see "Major Program Design & Load Reporting changes" above). There is a fundamental reason for many SNAPOUT and RANOUT load differences that is inherent in the statistical computations underlying each of these output files. We begin by noting that there should be no differences between most-loaded-line loads in RANOUT and SNAPOUT in *aligned* conditions. Differences can arise, however, in *crossed* conditions, with the potential discrepancies becoming larger with the amount of low-frequency motion reported for the "high-frequency sway-yaw mode". Furthermore, in crossed conditions, we now realize that the SNAPOUT treatment will result in an underestimate in most loaded line loads, although this underestimate should in most cases be rather small and within the bounds of the many other additional uncertainties associated with crossed-environment simulations. It is in any event an underestimate that is more easily understood than corrected... It has been mentioned in past clarifications that the RANOUT-SNAPOUT load calculation algorithms differ and that this difference is the cause of the apparent discrepancy. Let me expand on this... In aligned conditions, vessel "turnaround" points (for SNAPOUT) are well-defined since the low-frequency motion is generally confined to a single (surge) degree of freedom. In this case, SNAPOUT and RANOUT should agree (for the most-loaded line only) 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 or even unique, and in particular depends on a *combination* of the various low-frequency degrees of freedom. Out of the infinite set of possible "turnaround" points, we *chose* to report loads in SNAPOUT corresponding to a surge-DOF turnaround point associated with the *mean* vessel yaw angle. As we think about it now, this will result in an underestimate of the most loaded line load since the energy in the yaw modes has been ignored. This is a shortcoming that we will try to address as we rethink some of these issues in coming months. 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 ignoring one of them (as we currently do in SNAPOUT). This will produce a most-loaded-line load *greater* than that given in SNAPOUT since the yaw motions are not ignored. There will always be a difference in the way SNAPOUT and RANOUT loads are computed, one doing a purely statistical analysis of the low-frequency configuration space motions of the vessel (RANOUT) and the other a non-statistical analysis taken at a single point in that space (SNAPOUT). However, the current SNAPOUT calculation now seems, at least theoretically, somewhat deficient to me. As we said earlier, the practical consequence is nil, at least for modestly crossed conditions (vessel alignment less than 15 degrees from the mean offset direction vector) The same deficiency filters down to the net turret loads as well. (Again, these concerns apply to crossed conditions only). The final point we need to keep in focus is that all SeaSoft simulations use numerous "small-angle" simplifications (in the angle equal to the difference between vessel alignment and mean offset direction vector); severe crossed conditions that cause this angle to be large *will* compromise the quality of simulation load estimates, although qualitative trends may still be useful. The removal of the small-angle limitation is a high priority for the coming year. Best wishes for a safe, happy and healthy new year!