Input Files =========== The user configures the hydrodynamic model parameters as well as the substructure geometry and properties via a primary HydroDyn input file. When used in standalone mode, an additional driver input file is required. This driver file specifies initialization inputs normally provided to HydroDyn by OpenFAST, as well as the per-time-step inputs to HydroDyn. No lines should be added or removed from the input files, except in tables where the number of rows is specified. Units ~~~~~ HydroDyn uses the SI system (kg, m, s, N). .. _hd-driver-input: HydroDyn Driver Input File ~~~~~~~~~~~~~~~~~~~~~~~~~~ The driver input file is only needed for the standalone version of HydroDyn and contains inputs normally generated by OpenFAST, and are necessary to control the hydrodynamic simulation for uncoupled models. A sample HydroDyn driver input file is given in Appendix B. Set the **Echo** flag in this file to TRUE if you wish to have ``HydroDynDriver`` echo the contents of the driver input file (useful for debugging errors in the driver file). The echo file has the naming convention of ``OutRootName.dvr.ech``. **OutRootName** is specified in the HYDRODYN section of the driver input file. Set the gravity constant using the **Gravity** parameter. HydroDyn expects a magnitude, so in SI units this would be set to 9.80665 :math:`\frac{m}{s^{2}}`. **WtrDens** specifies the water density and must be a value greater than or equal to zero; a typical value of seawater is around 1025 kg/m\ :sup:`3`. **WtrDpth** specifies the water depth (depth of the flat seabed), based on the reference MSL, and must be a value greater than zero. **MSL2SWL** is the offset between the MSL and SWL, positive upward. This parameter is useful when simulating the effect of tides or storm-surge sea-level variations without having to alter the substructure geometry information. This parameter is unused with **WaveMod** = 6 and must be set to zero if you are using a potential-flow model (**PotMod** = 1 or 2). **WaveMod** and **PotMod** are specified in the HydroDyn primary input file. **HDInputFile** is the filename of the primary HydroDyn input file. This name should be in quotations and can contain an absolute path or a relative path. Note that neither the standalone HydroDyn program nor HydroDyn as part of OpenFAST can run without SeaState. Therefore, in addition to the primary HydroDyn input file, the path to a SeaState input file must also be provided through **SeaStateInputFile**. All HydroDyn-generated output files will be prefixed with **OutRootName**. If this parameter includes a file path, the output will be generated in that folder. **Linearize** can be set to either TRUE or FALSE. If TRUE, linearized 6-by-6 stiffness, damping, and added-mass matrices will be computed and printed to the calling terminal. **NSteps** specifies the number of simulation time steps, and **TimeInterval** specifies the time between steps. Motion of the structure can be specified in different ways according to **PRPInputsMod**. Irrespective of the choice of **PRPInputsMod** (which are explained below), the translational displacement, velocity, and acceleration are always specified in the global inertial-frame coordinate system. With OpenFAST now updated to support potentially large platform rotation, the specification of rotation differs from previous versions. HydroDyn now describes body rotation using Tait-Bryan roll, pitch, and yaw angles with the convention of intrinsic (about body-fixed axis) yaw rotation first, followed by pitch rotation, and roll last. Furthermore, HydroDyn now expects the first and second time derivatives of the Tait-Bryan roll, pitch, and yaw angles in place of angular velocity and acceleration. The standalone HydroDyn driver will convert these inputs to angular velocity and acceleration internally. Setting **PRPInputsMod** = 0 forces all platform reference point (PRP) input motions to zero for all time. If you set **PRPInputsMod** = 1, then you must set the steady-state inputs in the PRP STEADY STATE INPUTS section of the file. Setting **PRPInputsMod** = 2 requires the time-series input file whose name is specified via the **PRPInputsFile** parameter. The PRP input file is a text-formatted file. This file has no header lines. Each data row corresponds to a given time step, and the whitespace separated columns of floating point values represent the necessary motion inputs as shown in :numref:`hd-prp_input_table`. .. _hd-prp_input_table: .. table:: PRP Inputs Time-Series Data File Contents (**PRPInputsMod** = 2) :widths: auto ============= ====================================================================== ====================================== Column Number Input Units ============= ====================================================================== ====================================== 1 Time step value .. math:: s 2-4 Translational displacements along *X*, *Y*, and *Z* .. math:: m 5-7 Tait-Bryan roll, pitch, and yaw angles .. math:: \text{radians} 8-10 Translational velocities along *X*, *Y*, and *Z* .. math:: \frac{m}{s} 11-13 First time derivatives of the Tait-Bryan roll, pitch, and yaw angles .. math:: \frac{\text{radians}}{s} 14-16 Translational accelerations along *X*, *Y*, and *Z* .. math:: \frac{m}{s^{2}} 17-19 Second time derivatives of the Tait-Bryan roll, pitch, and yaw angles .. math:: \frac{\text{radians}}{s^{2}} ============= ====================================================================== ====================================== With **PRPInputsMod** = 1 or 2, any potential-flow bodies and strip-theory members defined in the primary HydroDyn input file will follow the prescribed motion of the PRP according to rigid-body kinematics. The standalone HydroDyn does not check for physical consistency between motions (displacement, velocity, and acceleration) specified for the PRP in the driver file. The user is responsible for generating consistent kinematics if that is important. If the HydroDyn model contains one or more potential-flow bodies, **PRPInputsMod** can be set to a negative number with :math:`|\ \text{**PRPInputsMod**}\ | = \text{**NBody**}` in the HydroDyn primary input file. In this case, an alternative form of the PRP input file shown in :numref:`hd-prp_input_table_2` can be used to specify different motions for the PRP, which controls the motion of all strip-theory members based on rigid-body kinematics, and for each potential-flow bodies separately. With this option, the user only specifies the translational and rotational displacements. HydroDyn will compute the velocity and acceleration by numerically differentiating the displacement with respect to time. .. _hd-prp_input_table_2: .. table:: PRP Inputs Time-Series Data File Contents (**PRPInputsMod** < 0) :widths: auto ============= =================================================================================== ======================== Column Number Input Units ============= =================================================================================== ======================== 1 Time step value .. math:: s 2-4 Translational displacements of the PRP along *X*, *Y*, and *Z* .. math:: m 5-7 Tait-Bryan roll, pitch, and yaw angles of the PRP .. math:: \text{radians} 8-10 Translational displacements of the 1st potential-flow body along *X*, *Y*, and *Z* .. math:: m 11-13 Tait-Bryan roll, pitch, and yaw angles of the 1st potential-flow body .. math:: \text{radians} 14-16 Translational displacements of the 2nd potential-flow body along *X*, *Y*, and *Z* .. math:: m 17-19 Tait-Bryan roll, pitch, and yaw angles of the 2nd potential-flow body .. math:: \text{radians} ... ... ... ============= =================================================================================== ======================== .. _hd-primary-input: HydroDyn Primary Input File ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The HydroDyn input file defines the substructure geometry, hydrodynamic coefficients, incident wave kinematics and current, potential-flow solution options, flooding/ballasting and marine growth, and auxiliary parameters. The geometry of strip-theory members is defined by joint coordinates of the undisplaced substructure in the global reference system, with the origin at the intersection of the undeflected tower centerline with MSL. A member connects two joints; multiple members can use a common joint. The hydrodynamic loads are computed at nodes, which are the resultant of member refinement into multiple (**MDivSize** input) elements (nodes are located at the ends of each element), and they are calculated by the module. Member properties include outer diameter, thickness, and dynamic-pressure, added-mass and viscous-drag coefficients. Member properties are specified at the joints; if properties change from one joint to the other, they will be linearly interpolated for the inner nodes. The file is organized into several functional sections. Each section corresponds to an aspect of the hydrodynamics model or the submerged substructure. A sample HydroDyn primary input file is given in :ref:`hd-primary-input_example`. If this manual refers to an ID in a table entry, this is an integer identifier for the table entry, and these IDs do not need to be consecutive or increasing, but they must be unique for a given table entry. The input file begins with two lines of header information for your use, but they are not used by the software. On the next line, set the **Echo** flag to TRUE if you wish to have HydroDyn echo the contents of the HydroDyn input file (useful for debugging errors in the input file). The echo file has the naming convention of **OutRootName**\ *.HD.ech*. **OutRootName** is either specified in the HYDRODYN section of the driver input file when running HydroDyn standalone, or by OpenFAST when running a coupled simulation. Floating Platform ----------------- This and the next few sections of the input file have "Floating Platform" in the title, but the input parameters control the potential-flow model, regardless of whether the substructure is floating or not. The potential-flow solution cannot be used in conjunction with nonzero **MSL2SWL** or **WaveMod** = 6 in SeaState. If the load contributions from potential-flow theory are to be included, set **PotMod** to 1 to use frequency-to-time domain transforms based on WAMIT output or 2 to use FIT (FIT is not yet documented in this manual). The remaining parameters in this section are only used when **PotMod** = 1. **ExctnMod** can be set to 0 for no wave excitation, 1 for frequency-to-time domain wave excitation using discrete Fourier transform, or 2 for the state-space wave-excitation model. Depending on the choice of **ExctnMod**, suitable hydrodynamic input files must be provided through the **PotFile** input. More information below. **ExctnDisp** specifies if and how structure displacement in the horizontal plane should be considered when evaluating the potential-flow wave excitation. Setting **ExctnDisp** = 0 ignores structure displacement, and wave excitation will be computed using the undisplaced structure position as in previous versions of OpenFAST. If **ExctnDisp** = 1, HydroDyn will compute the potential-flow wave excitation using the unfiltered instantaneous PRP position in the horizontal plane. If **ExctnDisp** = 2, HydroDyn will instead compute the wave excitation based on the low-pass filtered PRP position in the horizontal plane. The cutoff frequency is specified through **ExctnCutOff** in Hz. This option is useful when second-order potential-flow wave excitation is enabled. The cutoff frequency should be set to filter out as much of the wave-frequency PRP motion as possible while retaining the low-frequency drift motion to prevent double counting the contributions from first-order structural motion already included in the second-order potential-flow wave excitation. HydroDyn now supports large but slow (well below wave frequencies) transient platform yaw motion with both strip-theory only and hybrid potential-flow models. To enable this capability, the inputs **PtfmYMod**, **PtfmRefY**, **PtfmYCutoff**, and **NExctnHdg** must be set appropriately. Note that HydroDyn still requires the platform roll and pitch angles to be small, i.e., within +/-15 deg. To conform with the first- and second-order potential-flow theory, which limits the structure to small displacement about a reference mean position, a constant or slowly varying reference platform yaw orientation must be established. Setting **PtfmYMod** = 0 lets HydroDyn use a constant reference yaw angle given by **PtfmRefY** in degrees. In this case, the platform yaw rotation during the simulation, as given by the **PRPYaw** output channel, must stay within +/-15 deg of **PtfmRefY** specified by the user. A severe warning will be displayed if this requirement is not met at any point during the simulation, while still allowing the simulation to continue if possible. With a hybrid potential-flow model, the potential-flow wave excitation input file needs to cover a suitable range of wave headings relative to the platform after a yaw offset of **PtfmRefY** is applied. Alternatively, **PtfmYMod** = 1 lets HydroDyn update the reference yaw position **PtfmRefY** dynamically based on the low-pass-filtered platform yaw rotation, analogous to the modeling of slow-drift motion with **ExctnDisp** = 2 above. In this case, the **PtfmRefY** input allows the user to specify the initial reference yaw position at **t** = 0. The cutoff frequency of the first-order low-pass filter for platform yaw rotation can be set with **PtfmYCutoff** in Hz. Ideally, **PtfmYCutoff** should be placed between the wave frequency region and the characteristic frequency of any slow but large change in platform heading to filter out as much wave-frequency platform motion as possible while minimizing the phase shift in the low-frequency heading change. Throughout the simulation, the instantaneous platform yaw rotation should stay within +/-15 deg of the now time-dependent **PtfmRefY**. A severe warning will be displayed if this requirement is not met at any point during the simulation, while still allowing the simulation to continue if possible. With **PtfmYMod** = 1, HydroDyn requires the first- and second-order (mean- or slow-drift loads from Newman's approximation only) potential-flow wave excitation input file(s) to cover the full range of possible wave headings with the first (smallest) wave heading being exactly -180 deg and the last (largest) wave heading being exactly +180 deg (the duplicated wave headings of +/-180 deg are intentional). HydroDyn will error out if this requirement is not met by the input files. HydroDyn uses this information to precompute the wave excitation on the platform for **NExctnHdg** evenly distributed platform yaw/heading angles over the range of [-180,+180) deg. For instance, with **NExctnHdg** = 36, HydroDyn will precomupte the wave excitation for 0, 10, 20, ..., 350 deg platform heading. The instantaneous wave excitation applied on the platform during the time-domain simulation is interpolated from this data based on the instantaneous **PtfmRefY**. **NExctnHdg** should be set appropriately to ensure adequate angular resolution in platform heading. However, a high **NExctnHdg** can increase memory use by OpenFAST substantially. Additional constraints on HydroDyn inputs apply when **PtfmYMod** = 1. The strip-theory hydrodynamic load must be evaluated using the wave kinematics and dynamic pressure at the displaced structure position by setting **WaveDisp** = 1. State-space wave excitation cannot be used. **ExctnMod** must be either 0 (no wave excitation) or 1 (frequency-to-time domain transform using inverse discrete Fourier transform). Lastly, full difference- and sum-frequency QTFs are not supported, requiring both **DiffQTF** and **SumQTF** to be set to 0. However, mean- or slow-drift loads based on Newman's approximation can be included through the **MnDrift** or **NewmanApp** inputs explained below. Note that the inputs **PtfmYMod** and **PtfmRefY** also affect the strip-theory hydrodynamic load. This is because the orientation of the strip-theory members is updated based on **PtfmRefY** instead of the instantaneous platform yaw rotation. Behavior of previous versions of HydroDyn can be approximately recovered by setting **PtfmYMod** = 0 and **PtfmRefY** = 0 deg, in which case, the inputs **PtfmYCutoff** and **NExctnHdg** are not used. HydroDyn has two methods for calculating the radiation memory effect. Set **RdtnMod** to 1 for the convolution method, 2 for the linear state-space model, or 0 to disable the memory effect calculation. For the convolution method, **RdtnTMax** determines how long to track the memory effect (truncating the convolutions at *t* – **RdtnTMax**, where *t* is the current simulation time), but it also determines the frequency step used in the cosine transform, from which the time-domain radiation kernel (radiation impulse-response function) is derived. A **RdtnTMax** of 60 s is usually more than sufficient because the radiation kernel decays to zero after a short amount of time; setting **RdtnTMax** much greater than this will cause HydroDyn to run significantly slower. (**RdtnTMax** does not need to match or exceed the total simulation length.) Setting **RdtnTMax** to 0 s disables the memory effect, akin to setting **RdtnMod** to 0. For the convolution method, **RdtnDT** is the time step for the radiation calculations (numerical convolutions), but also determines the maximum frequency in the cosine transform. For the state-space model, **RdtnDT** is the time step to use for time integration of the linear state-space model. In this version of HydroDyn, **RdtnDT** must match the glue code (OpenFAST/driver program) simulation time step; the DEFAULT keyword can be used for this. Depending on the choice of **RdtnMod**, suitable hydrodynamic input files must be provided through the **PotFile** input. More information below. HydroDyn supports the inclusion of multiple potential-flow bodies. **NBody** specifies the number of potential-flow bodies present. **NBodyMod** controls how multiple potential-flow bodies should be modeled. HydroDyn will retain the full hydrodynamic coupling among the potential-flow bodies if **NBodyMod** = 1. For this option, all bodies should be present in the same WAMIT run with **NBody** in HydroDyn being equal to NBODY in the WAMIT input file. The WAMIT output files should contain results for 6·NBody modes. HydroDyn will neglect hydrodynamic coupling among the potential-flow bodies if **NBodyMod** = 2 or 3. In either case, WAMIT should be run for each body separately one at a time. If the WAMIT computation is run with each body centered at the origin (XBODY=0 in WAMIT), **NBodyMod** = 2 should be used in HydroDyn. In this case, HydroDyn will process the WAMIT outputs to account for the shift in wave phase due to any offset of each potential-flow body from the origin/PRP. HydroDyn will also rotate the WAMIT outputs according to the heading of each body in HydroDyn. **NBodyMod** = 2 is convenient when, e.g., multiple identical potential-flow bodies are present in the structure. If the hydrodynamic coupling among the bodies can be neglected, the same set of WAMIT output files can be used for each body by setting **NBodyMod** = 2. On the other hand, **NBodyMod** = 3 should be used if each body is already positioned and oriented correctly relative to the origin/PRP in WAMIT by setting XBODY in the WAMIT input file. In this case, HydroDyn will use the provided WAMIT output as is. The **PotFile** input should contain the path and root name (without extensions) for the WAMIT output files enclosed in quotation marks. These files consist of the *.1*, *.3*, *.hst*, and second-order files. The *.hst* file contains the hydrostatic restoring (stiffness) matrix. The *.1* file contains the frequency-dependent hydrodynamic added-mass and damping matrix from the wave radiation problem. The *.3* file contains the frequency- and direction-dependent first-order wave-excitation vector from the linear wave diffraction problem. These are written by the WAMIT program and should not include any file headers. When the linear state-space model is used in place of frequency-to-time domain transformation for wave excitation or in place of convolution for radiation, the *.ssexctn* file for wave excitation (more information to be provided in the future) and/or the *.ss* file for radiation generated by `SS_Fitting `__ must have the same root name as the other WAMIT-related files. When **NBodyMod** = 1, **PotFile** should only contain one entry irrespective of **NBody** because the hydrodynamic coefficients for all bodies with hydrodynamic coupling should be contained within a single set of files. When **NBodyMod** = 2 or 3, **PotFile** should contain **NBody** entries, each enclosed in quotes and separated from each other with commas or spaces. Each entry of **PotFile** corresponds to a single potential-flow body. In the reminder of this section, each input should contain **NBody** entries separated by commas or spaces, irrespective of **NBodyMod**. The output files from WAMIT are in a standard nondimensional form that HydroDyn will dimensionalize internally upon input. **WAMITULEN** is the characteristic body length (in m) used to redimensionalize the WAMIT output. The body motion and force/moment in these WAMIT files are always resolved in the body-local frame of reference given by XBODY in the WAMIT input file. To correctly interpret the WAMIT outputs, the position and heading of each potential-flow body relative to the origin/PRP must be specified using **PtfmRefxt**, **PtfmRefyt**, **PtfmRefzt**, and **PtfmRefztRot** (in m or deg). With the exception of **NBodyMod** = 2, these inputs must match XBODY in the WAMIT input file. When **NBodyMod** = 2, these inputs can be set freely except for **PtfmRefzt**, which must always be zero. While HydroDyn expects hydrodynamic coefficients derived from WAMIT, if you are not using WAMIT, it is recommended that you reformat your data according to the WAMIT format (including nondimensionalization) before inputting them to HydroDyn. Information on the WAMIT format is available from Chapter 4 of the WAMIT User's Guide :cite:`LeeNewman:2006`. **PtfmVol0** is the displaced volume of water when the potential-flow body is in its undisplaced position (in m\ :sup:`3`). This value should be set equal to the value computed by WAMIT as output in the WAMIT ``.out`` file. **PtfmCOBxt** and **PtfmCOByt** are the *X* and *Y* offsets (in m) of the center of buoyancy of each body from the origin/PRP, NOT from **PtfmRefxt** and **PtfmRefyt**. .. _hd-2nd_order_floating_platform_forces_input: 2\ :sup:`nd`-Order Floating Platform Forces ------------------------------------------- The 2\ :sup:`ND`-ORDER FLOATING PLATFORM FORCES section of the input file allows the option of adding second-order contributions to the potential-flow solution. When second-order terms are optionally enabled, the second-order terms are calculated using the first-order wave-component amplitudes and added to the first-order wave excitation at the difference and/or sum frequencies. The second-order terms cannot be computed without also including the first-order terms from the FLOATING PLATFORM section above (**PotMod** = 1). Enabling the second-order terms allows one to capture some of the nonlinearities in the wave loads, permitting more accurate modeling at the expense of greater computational effort (mostly at HydroDyn initialization). While the cut-off frequencies in the :ref:`sea-2nd_order_waves_input` section of the SeaState module apply to both the second-order wave kinematics used by strip theory and the second-order diffraction loads in potential-flow theory, the second-order terms themselves are enabled separately. The second-order wave kinematics used by strip theory are enabled in the :ref:`sea-2nd_order_waves_input` section while the second-order diffraction loads in potential-flow theory are enabled in this section. The second-order difference-frequency potential-flow terms can be enabled in one of three ways. To compute only the mean-drift term, set **MnDrift** to a nonzero value; to estimate the mean- and slow-drift terms using Standing et al.’s extension to Newman’s approximation, based only on first-order effects, set **NewmanApp** to a nonzero value; or to compute the mean- and slow-drift terms using the full difference-frequency QTF set **DiffQTF** to a nonzero value. Valid values of **MnDrift** are 0, 7, 8, 9, 10, 11, or 12 corresponding to which WAMIT output file the mean-drift terms will be calculated from. Valid values of **NewmanApp** are 0, 7, 8, 9, 10, 11, or 12 corresponding to which WAMIT output file the Newman’s approximation will be calculated from. Newman’s approximation cannot be used in conjunction with directional spreading (**WaveDirMod** must be 0) and the second-order cut-off frequencies do not apply to Newman’s approximation. Valid values of **DiffQTF** are 0, 10, 11, or 12 corresponding to which WAMIT output file the full difference-frequency potential-flow solution will be calculated from. Only one of **MnDrift**, **NewmanApp**, and **DiffQTF** can be nonzero; a setting of 0 disregards the second-order difference-frequency contributions to the potential-flow solution. The .\ *7* WAMIT file refers to the mean-drift loads (diagonal of the difference-frequency QTF) in all DOFs derived from the control-surface integration method based on the first-order solution. The .\ *8* WAMIT file refers to the mean-drift loads (diagonal of the difference-frequency QTF) only in surge, sway, and yaw derived from the momentum conservation principle based on the first-order solution. The .\ *9* WAMIT file refers to the mean-drift loads (diagonal of the difference-frequency QTF) in all DOFs derived from the pressure integration method based on the first-order solution. For the difference-frequency terms, 10, 11, and 12 refer to the WAMIT .\ *10d*, .\ *11d*, and .\ *12d* files, corresponding to the full QTF of (.*10d*) loads in all DOFs associated with the quadratic interaction of first-order quantities, (.*11d*) total (quadratic plus second-order potential) loads in all DOFs derived by the indirect method, and (.*12d*) total (quadratic plus second-order potential) loads in all DOFs derived by the direct method, respectively. The second-order sum-frequency potential-flow terms can only be enabled using the full sum-frequency QTF, by setting **SumQTF** to a nonzero value. Valid values of **SumQTF** are 0, 10, 11, or 12 corresponding to which WAMIT output file the full sum-frequency potential-flow solution will be calculated from; a setting of 0 disregards the second-order sum-frequency contributions to the potential-flow solution. For the sum-frequency terms, 10, 11, and 12 refer to the WAMIT .\ *10s*, .\ *11s*, and .\ *12s* files, corresponding to the full QTF of (.*10s*) loads in all 6 DOFs associated with the quadratic interaction of first-order quantities, (.*11s*) total (quadratic plus second-order potential) loads in all DOFs derived by the indirect method, and (.*12s*) total (quadratic plus second-order potential) loads in all DOFs derived by the direct method, respectively. Note that also apply here are the various considerations associated with running WAMIT for multiple potential-flow bodies discussed in the **FLOATING PLATFORM** section for first-order loads. Platform Additional Stiffness and Damping ----------------------------------------- The vectors and matrices of this section are used to generate additional loads on the platform (in addition to other hydrodynamic terms calculated by HydroDyn), per the following equation. .. math:: :label: PtfmStiffDamp \overrightarrow{F}_{Add} = \overrightarrow{F}_{0} - [C] \overrightarrow{q} - [B] \dot{\overrightarrow{q}} - [B_{quad}] ABS \left(\dot{\overrightarrow{q}}\right) \dot{\overrightarrow{q}} where :math:`\overrightarrow{F}_{0}` corresponds to the **AddF0** static load (preload) vector, :math:`[C]` corresponds to the **AddCLin** linear restoring (stiffness) matrix, :math:`[B]` corresponds to the **AddBLin** linear damping matrix, :math:`[B_{quad}]` corresponds to the **AddBQuad** quadratic drag matrix, and :math:`\overrightarrow{q}` corresponds to the displacement vector of the potential-flow bodies (translation and rotation), where the overdot refers to the first time-derivative. **AddF0** is either a column vector with 6\ **NBody** entries if **NBodyMod** = 1 or **NBody** column vectors with six entries each if **NBodyMod** = 2 or 3. In the former case, **AddF0** will span 6\ **NBody** lines with each line containing a single number in the input file. In the latter case, **AddF0** will span six lines with each line containing **NBody** numbers in the input file. **AddCLin**, **AddBLin**, and **AddBQuad** are either a single 6\ **NBody**\ -by-6\ **NBody** matrix if **NBodyMod** = 1 or six 6-by-6 matrices if **NBodyMod** = 2 or 3. In the former case, each matrix spans 6\ **NBody** lines in the input file with each line containing 6\ **NBody** numbers. In the latter case, each matrix spans six lines in the input file, with each line containing 6\ **NBody** numbers. These terms can be used, e.g., to model a linearized mooring system, to augment strip-theory members with a linear hydrostatic restoring matrix (see :numref:`hd-modeling-hydrostatic-restoring-strip-theory`), or to "tune" HydroDyn to match damping to experimental results, such as free-decay tests. While likely most useful for floating systems, these matrices can also be used for fixed-bottom systems; in both cases, the resulting load is applied at the reference point of each potential-flow body given by **PtfmRefxt**, **PtfmRefyt**, and **PtfmRefzt**. Strip theory options -------------------- **WaveDisp** can be set to 0 to compute the strip-theory loads using the wave kinematics and dynamic pressure at the undisplaced position of the structure. If set to 1, the loads will be computed using the wave kinematics and dynamic pressure at the instantaneous displaced positions of the strip-theory members. Note that when wave stretching is not used (\ **WaveStMod** = 0 in SeaState), only the *X*- and *Y*-displacements of the strip-theory member nodes are considered when **WaveDisp** = 1, while the vertical *Z*-displacement is ignored. This is done to avoid discontinuous nodal loads that can result in unphysical structural vibration with a SubDyn substructure model. When **WaveStMod** > 0 and **WaveDisp** = 1, displacements of strip-theory members in all three directions are considered when computing the wave kinematics. A load smoothing procedure is performed to avoid discontinuous nodal loads in this case. **AMMod** controls the computation of distributed strip-theory added-mass force. If **AMMod** = 0, the strip-theory added-mass force is always evaluated up to the SWL while neglecting the vertical displacement of the strip-theory member nodes, even if wave stretching is enabled. With **AMMod** = 1, the strip-theory added-mass force is evaluated up to the instantaneous free surface if **WaveStMod** > 0. The vertical displacement of strip-theory members will also be accounted for if **WaveDisp** = 1. **AMMod** should only be set to 0 if wave stretching is causing numerical instabilities with flexible fixed-bottom support structures modeled in SubDyn. Axial Coefficients ------------------ This and the next several sections of the input file control the strip-theory model for both fixed-bottom and floating substructures. HydroDyn computes lumped viscous-drag, added-mass, fluid-inertia, and static pressure loads at member ends (joints). The hydrodynamic coefficients for the lumped loads at joints are referred to as "axial coefficients" and include viscous-drag coefficients, **AxCd**, added-mass coefficients, **AxCa**, and dynamic-pressure coefficients, **AxCp**. **AxCa** influences both the added-mass loads and the scattering component of the fluid-inertia loads. Any number of separate axial coefficient sets, distinguished by **AxCoefID**, may be specified by setting **NAxCoef** > 1. There are three optional inputs that affect the viscous drag force on endplates. These are **AxFDMod**, **AxVnCOff**, and **AxFDLoFSc**. **AxFDMod** can be either 0 or 1. When set to 0, the drag force on endplates will be computed as in previous versions of OpenFAST. When set to 1, drag force will only be applied when the relative flow is directed away from the endplate where flow separation is expected, not when the relative flow is impinging on the endplate where flow separation is unlikely. Option 0 is suitable for strip-theory-only members, whereas option 1 might be better suited for hybrid potential-flow members with drag force. Note that option 1 uses a leading coefficient of 1/4 when computing the drag force, while option 2 uses the more common leading coefficient of 1/2 since drag is usually only applied to one of the two endplates of the member instead of on both. **AxVnCOff** is the cutoff frequency in Hz for high-pass filtering the relative normal flow velocity used to compute the endplate drag force. This input parameter should be used together with the weighting factor **AxFDLoFSc** (between 0 and 1). When **AxFDLoFSc** = 0, the endplate drag force is computed purely based on the high-pass filtered relative normal velocity. When **AxFDLoFSc** = 1, the endplate drag force is computed purely based on the unfiltered relative normal velocity. This formulation is added to allow the user to attenuate the drag force in response to lower-frequency motion. In some cases, this approach can help address the underprediction of low-frequency resonance motion. Users can opt to omit all three optional inputs. In this case, HydroDyn will compute the endplate drag force as in previous versions of OpenFAST. Alternatively, users can include only the optional parameter **AxFDMod**. No velocity filtering will be applied in this case. Lastly, users can include all three optional parameters to control the behavior of endplate drag force as explained above. Axial viscous-drag loads will be calculated for all specified member joints. Axial added-mass, fluid-inertia, and static-pressure loads will only be calculated for member joints of members not modeled with potential flow (**PropPot** = FALSE). Axial loads are only calculated at user-specified joints. Axial loads are not calculated at joints HydroDyn may automatically create as part its solution process. For example, if you want axial effects at a marine-growth boundary (where HydroDyn automatically adds a joint), you must explicitly set a joint at that location. Member Joints ------------- The strip-theory model is based on a substructure composed of joints interconnected by members. **NJoints** is the user-specified number of joints and determines the number of rows in the subsequent table. Because a member connects two nodes, **NJoints** must be exactly zero or greater than or equal to two. Each joint listed in the table is identified by a unique integer, **JointID**. The (*X*,\ *Y*,\ *Z*) coordinate of each joint is specified in the global inertial-frame coordinate system via **Jointxi**, **Jointyi**, and **Jointzi**, respectively. **JointAxID** corresponds to an entry in the AXIAL COEFFICIENTS table and sets the axial coefficients for a joint. This version of HydroDyn cannot calculate joint overlap when multiple members meet at a common joint; therefore **JointOvrlp** must be set to 0. Future releases will enable joint overlap calculations. Modeling a fixed-bottom substructure embedded into the seabed (e.g., through piles or suction buckets) requires that the lowest member joint(s) lie below the water depth. Placing a joint at or above the water depth results in static pressure loads being applied. Member Cross-Sections --------------------- Members in HydroDyn are assumed to be straight with either a circular cross section or a rectangular cross section. In either case, tapering is allowed, including independent tapering of the two sides of a member with rectangular cross sections. However, twisting of rectangular members is not allowed, and the four side walls of the member must remain planar. The HydroDyn primary input file contains two separate sections for member cross-section properties. The first section is for circular sections, and the second one is for rectangular sections. In the first section labeled CYLINDRICAL MEMBER CROSS-SECTION PROPERTIES, **NPropSetsCyl** different section defintions can be entered, with each section definition on a separate line identified by its **PropSetID**. The **PropSetID** is used in the MEMBERS table, as described in :numref:`hd-members` below. For each section definition, the user needs to provide the member outer diameter, **PropD**, and member wall thickness, **PropThck**. **PropD** determines the static buoyancy loads exterior to a member, as well as the area used in the viscous-drag calculation and the volume used in the added-mass and fluid-inertia load calculations. **PropThck** determines the interior volume for fluid-filled (flooded/ballasted) members. In the second section labeled RECTANGULAR MEMBER CROSS-SECTION PROPERTIES, **NPropSetsRec** different section definitions can be entered, with each section definition on a separate line identified by its **PropSetID**. The **PropSetID** is referenced in the MEMBERS table, as described in :numref:`hd-members` below. For each section definition, the user needs to provide the member outer side lengths of the rectangular section. **PropA** is the outer length of Side A, and **PropB** is the outer length of Side B (see :numref:`hd-members` on how the two sides are identified). **PropThck** is again the section wall thickness. Currently, we assume the four side walls of each rectangular section have the same uniform wall thickness, so only one **PropThck** can be specified for each rectangular section. Note that the **PropSetID** for circular and rectangular sections are independent. For instance, it is allowed to have a circular section and a rectangular section both having the same **PropSetID**. Depending on the section shape specified for each member, HydroDyn will look up the correct section properties. Hydrodynamic Coefficients ------------------------- HydroDyn computes distributed viscous-drag, added-mass, fluid-inertia, and static buoyancy loads along members. The hydrodynamic coefficients for the distributed strip-theory loads are specified using any of the three available models, which we refer to as the simple model (model 1), a depth-based model (model 2), and a member-based model (model 3). All of these models require the specification of both transverse and axial hydrodynamic coefficients for viscous drag, added mass, and dynamic pressure. The added-mass coefficient influences both the added-mass loads and the scattering component of the fluid-inertia loads. There are two separate sets of hydrodynamic coefficients with one set for the part of a member with marine growth and the other for the part without. Which members have marine growth is defined by the MARINE GROWTH table of :numref:`hd-marine-growth`. You can specify only one model type (**MCoefMod** = 1, 2, or 3) for any given member in the MEMBERS table. However, different members can use different coefficient models. .. elements per Section 7.5.2, one of the splitting rules guarantees the .. TODO 7.5.2 is the theory section which does not yet exist. In the hydrodynamic coefficient tables, **Cd**, **Ca**, and **Cp** refer to the viscous-drag, added-mass, and dynamic-pressure coefficients, respectively. For circular sections, these coefficients apply to loads in any radial direction due to axisymmetry. For rectangular sections, two sets of transverse **Cd** and **Ca** coefficients must be provided, with one set having the letter "A" appended for load components normal to Side A of the section (e.g., **CdA**) and the other with the letter "B" appended for load components normal to Side B of the section (e.g., **CaB**). Note that only the transverse **Cd** and **Ca** (with and without marine growth) make a distinction between the two transverse directions of rectangular sections. None of the other coefficients make this distinction. **MG** identifies the coefficients to be applied on member sections with marine growth (the standard values are identified without **MG**), and **Ax** identifies the axial coefficients to be applied for tapered members (the transverse coefficients are identified without **Ax**). The **Cb** coefficients allow the user to scale the hydrostatic load for, e.g., non-circular and non-rectangular member cross sections. To avoid unphysical hydrostatic loads, the **Cb** coefficients are not used to directly scale the distributed hydrostatic load. Instead, the local member diameter or side lengths (with marine growth if specified) are scaled by the square root of **Cb** when computing the hydrostatic loads. This scaling also affects the hydrostatic loads on member endplates for consistency. While the strip-theory solution assumes either a circular or a rectangular cross section, the hydrodynamic coefficients can include shape corrections. For each of the three available coefficient models, there are two separate input sections with the first one for circular sections and the second for rectangular sections. These are explained below. Simple Model for Circular Sections ++++++++++++++++++++++++++++++++++ This table consists of a single complete set of hydrodynamic coefficients for circular sections as follows: **SimplCd**, **SimplCdMG**, **SimplCa**, **SimplCaMG**, **SimplCp**, **SimplCpMG**, **SimplAxCd**, **SimplAxCdMG**, **SimplAxCa**, **SimplAxCaMG**, **SimplAxCp**, **SimplAxCpMG**, **SimplCb**, and **SimplCbMG**. These hydrodynamic coefficients are referenced in the MEMBERS table of :numref:`hd-members` by selecting **MCoefMod** = 1. Simple Model for Rectangular Sections +++++++++++++++++++++++++++++++++++++ This table consists of a single complete set of hydrodynamic coefficients for rectangular sections as follows: **SimplCdA**, **SimplCdAMG**, **SimplCdB**, **SimplCdBMG**, **SimplCaA**, **SimplCaAMG**, **SimplCaB**, **SimplCaBMG**, **SimplCp**, **SimplCpMG**, **SimplAxCd**, **SimplAxCdMG**, **SimplAxCa**, **SimplAxCaMG**, **SimplAxCp**, **SimplAxCpMG**, **SimplCb**, and **SimplCbMG**. These hydrodynamic coefficients are referenced in the MEMBERS table of :numref:`hd-members` by selecting **MCoefMod** = 1. Depth-Based Model for Circular Sections +++++++++++++++++++++++++++++++++++++++ The depth-based coefficient model allows you to specify a series of depth-dependent coefficients for circular sections. **NCoefDpthCyl** is the user-specified number of depths and determines the number of rows in the subsequent table. Currently, this table requires that the rows are ordered by increasing depth, **Dpth**; this is equivalent to a decreasing global *Z*-coordinate. The hydrodynamic coefficients at each depth are as follows: **DpthCd**, **DpthCdMG**, **DpthCa**, **DpthCaMG**, **DpthCp**, **DpthCpMG**, **DpthAxCd**, **DpthAxCdMG**, **DpthAxCa**, **DpthAxCaMG**, **DpthAxCp**, **DpthAxCpMG**, **DpthCb**, and **DpthCbMG**. Members use these hydrodynamic coefficients by setting **MCoefMod** = 2. The HydroDyn module will linearly interpolate coefficients for a node whose *Z*-coordinate lies between table *Z*-coordinates. Depth-Based Model for Rectangular Sections ++++++++++++++++++++++++++++++++++++++++++ The depth-based coefficient model allows you to specify a series of depth-dependent coefficients for rectangular sections. **NCoefDpthRec** is the user-specified number of depths and determines the number of rows in the subsequent table. Currently, this table requires that the rows are ordered by increasing depth, **Dpth**; this is equivalent to a decreasing global *Z*-coordinate. The hydrodynamic coefficients at each depth are as follows: **DpthCdA**, **DpthCdAMG**, **DpthCdB**, **DpthCdBMG**, **DpthCaA**, **DpthCaAMG**, **DpthCaB**, **DpthCaBMG**, **DpthCp**, **DpthCpMG**, **DpthAxCd**, **DpthAxCdMG**, **DpthAxCa**, **DpthAxCaMG**, **DpthAxCp**, **DpthAxCpMG**, **DpthCb**, and **DpthCbMG**. Members use these hydrodynamic coefficients by setting **MCoefMod** = 2. The HydroDyn module will linearly interpolate coefficients for a node whose *Z*-coordinate lies between table *Z*-coordinates. Member-Based Model for Circular Sections ++++++++++++++++++++++++++++++++++++++++ The member-based coefficient model allows you to specify a set of hydrodynamic coefficients for each member. **NCoefMembersCyl** is the user-specified number of members with member-based coefficients and determines the number of rows in the subsequent table. The hydrodynamic coefficients for a member distinguished by **MemberID** are as follows: **MemberCd1**, **MemberCd2**, **MemberCdMG1**, **MemberCdMG2**, **MemberCa1**, **MemberCa2**, **MemberCaMG1**, **MemberCaMG2**, **MemberCp1**, **MemberCp2**, **MemberCpMG1**, **MemberCpMG2**, **MemberAxCd1**, **MemberAxCd2**, **MemberAxCdMG1**, **MemberAxCdMG2**, **MemberAxCa1**, **MemberAxCa2**, **MemberAxCaMG1**, **MemberAxCaMG2**, **MemberAxCp1**, **MemberAxCp2**, **MemberAxCpMG1**, **MemberAxCpMG2**, **MemberCb1**, **MemberCb2**, **MemberCbMG1**, and **MemberCbMG2**, where *1* and *2* identify the starting and ending joint of the member, respectively. Members use these hydrodynamic coefficients by setting **MCoefMod** = 3. Member-Based Model for Rectangular Sections +++++++++++++++++++++++++++++++++++++++++++ The member-based coefficient model allows you to specify a set of hydrodynamic coefficients for each member. **NCoefMembersRec** is the user-specified number of members with member-based coefficients and determines the number of rows in the subsequent table. The hydrodynamic coefficients for a member distinguished by **MemberID** are as follows: **MemberCdA1**, **MemberCdA2**, **MemberCdAMG1**, **MemberCdAMG2**, **MemberCdB1**, **MemberCdB2**, **MemberCdBMG1**, **MemberCdBMG2**, **MemberCaA1**, **MemberCaA2**, **MemberCaAMG1**, **MemberCaAMG2**, **MemberCaB1**, **MemberCaB2**, **MemberCaBMG1**, **MemberCaBMG2**, **MemberCp1**, **MemberCp2**, **MemberCpMG1**, **MemberCpMG2**, **MemberAxCd1**, **MemberAxCd2**, **MemberAxCdMG1**, **MemberAxCdMG2**, **MemberAxCa1**, **MemberAxCa2**, **MemberAxCaMG1**, **MemberAxCaMG2**, **MemberAxCp1**, **MemberAxCp2**, **MemberAxCpMG1**, **MemberAxCpMG2**, **MemberCb1**, **MemberCb2**, **MemberCbMG1**, and **MemberCbMG2**, where *1* and *2* identify the starting and ending joint of the member, respectively. Members use these hydrodynamic coefficients by setting **MCoefMod** = 3. MacCamy-Fuchs diffraction load model ++++++++++++++++++++++++++++++++++++ The MacCamy-Fuchs diffraction load model can be enabled for strip-theory members using any of the three coefficient models listed above. To enable the MacCamy-Fuchs model, all transverse **Cp** and **CpMG** coefficients should be replaced with the keyword **MCF** instead of a numeric value. For the simple model, this includes **SimplCp** and **SimplCpMG**. With the depth-based model, **DpthCp** and **DpthCpMG** on all lines should have the keyword **MCF**. Finally, for the member-based model, **MemberCp1**, **MemberCp2**, **MemberCpMG1**, and **MemberCpMG2** should all have the keyword **MCF** only for the members to use the MacCamy-Fuchs model. All other coefficients can be specified as usual, including the added-mass coefficients. With this configuration, the distributed transverse fluid-inertia force on the members will simply follow the MacCamy-Fuchs diffraction load, irrespective of the added-mass coefficient set by the user. In this case, the added-mass coefficient only affects the force component proportional to the structure acceleration, not the force component proportional to the fluid acceleration. Strictly speaking, the MacCamy-Fuchs diffraction solution only applies to fixed-bottom or deep-drafted vertical circular cylinders with a constant diameter. To ensure it is approximately applicable while still allowing for some flexibility, some constraints are placed on members when applying the MacCamy-Fuchs model: * The member must have a circular cross section. * The member must be surface-piercing at least when the structure is undisplaced in calm water. * The member must be nearly vertical with an inclination from vertical less than 10 deg. * The member can be tapered slightly, but the diameter must be within +/-10% of **MCFD** in the SeaState input file. * The member must have a draft at least as large as 0.5\ **MCFD**. Because the MacCamy-Fuchs diffraction solution is based on linear potential-flow theory, second-order contributions to the fluid acceleration are neglected when computing the wave load even if second-order wave kinematics are enabled in SeaState. However, the MacCamy-Fuchs diffraction model can be used in conjunction with any of the available wave-stretching models. .. _hd-members: Members ------- **NMembers** is the user-specified number of members and determines the number of rows in the subsequent table. For each member distinguished by **MemberID**, **MJointID1** specifies the starting joint, and **MJointID2** specifies the ending joint, corresponding to an identifier (**JointID**) from the MEMBER JOINTS table. Likewise, **MPropSetID1** corresponds to the starting cross-section properties, and **MProSetID2** specify the ending cross-section properties, allowing for tapered members. **MSecGeom** indicates the cross-section shape of the member. It can be set to either 1 for circular cross section or 2 for rectangular cross section. Depending on **MSecGeom**, **MPropSetID1** and **MPropSetID2** either refer to entries in the CYLINDRICAL MEMBER CROSS-SECTION PROPERTIES table or the RECTANGULAR MEMBER CROSS-SECTION PROPERTIES table. **MSpinOrient** is an angle in degrees that specifies the spin orientation of each member, i.e., the rotation about the member axis. When **MSpinOrient** = 0, Side A of a rectangular section referenced in previous sections is parallel to the horizontal plane. If the member is perfectly vertical, Side A is parallel to the global *X*-axis when **MSpinOrient** = 0. Setting **MSpinOrient** to a nonzero value will rotate the member about its axis (pointing from the starting joint to the ending joint) following the right-hand convention by the prescribed angle. **MSpinOrient** should be specified for both members with rectangular cross sections and members with circular cross sections; however, it has no effect on the latter. **MDivSize** determines the maximum spacing (in meters) between simulation nodes where the distributed loads are actually computed; the smaller the number, the finer the resolution and longer the computational time. Each member in your model will have hydrodynamic coefficients, which are specified using one of the three models (**MCoefMod**). Model 1 uses a single set of coefficients found in the SIMPLE HYDRODYNAMIC COEFFICIENTS sections. Model 2 is depth-based, and is determined via the table found in the DEPTH-BASED HYDRODYNAMIC COEFFICIENTS sections. Model 3 specifies coefficients for a particular member, by referring to the MEMBER-BASED HYDRODYNAMIC COEFFICIENTS sections. Depending on **MSecGeom**, HydroDyn will either use the hydrodynamic coefficients from the input tables for circular sections or rectangular sections as appropriate. The **MHstLMod** switch controls the computation of hydrostatic loads on strip-theory members when **PropPot** = FALSE. Setting **MHstLMod** to 0 disables hydrostatic load. If set to 1, hydrostatic loads will be computed analytically. This approach is efficient, but it only works for fully submerged or surface-piercing members that are far from horizontal without partially wetted endplates. For nearly horizontal members close to the free surface or members that experience partially wetted endplates, a semi-numerical approach for hydrostatic load can be selected by setting **MHstLMod** to 2. This approach works with any member positioning in relation to the free surface at the cost of slightly longer computing time. Note that for members with rectangular cross sections, **MHstLMod** must be either 0 or 2. The analytical approach with **MHstLMod** set to 1 is not available for rectangular members. The **PropPot** flag indicates whether the corresponding member is included in the potential-flow solution. When **PropPot** = TRUE, only viscous-drag loads and ballasting loads will be computed for that member, with the assumption that all other load components are already included in the potential-flow solution. .. TODO 7.5.2 is the theory section which does not yet exist. .. Section 7.5.2 discusses the difference between the user-supplied discretization and the simulation discretization. Filled Members -------------- Members—whether they are also modeled with potential-flow or not—may be fluid-filled, meaning that they are flooded and/or ballasted. The internal fluid introduces hydrostatic pressure on the inner wall(s) of a flooded/ballasted member. It also adds mass and moment of inertia to the member. Both distributed loads along a member and lumped loads at joints/endplates are applied. The volume of fluid in a flooded member is derived from the outer diameter/side lengths and the wall thickness of the member and a fluid-filled level. The member is either partially flooded from the lower end joint to the fluid-filled level, if the fluid-filled level is in the middle of the member, or fully flooded, if the fluid-filled level is above the top end joint of the member. In either case, a watertight bulkhead normal to the member centerline is assumed to bound the filled section of a member on either end, so there is no internal free surface nor sloshing. Furthermore, the fluid in the member is assumed to be compartmentalized such that it moves with the member in a rigid-body fashion for the purpose of computing inertial loads on the member. However, when computing the internal hydrostatic pressure, we do not assume the compartmentalization to be watertight. Therefore, the entire filled volume of a member share a single contiguous hydrostatic pressure field. As an example, a consequence of this modeling assumption is that the weight of all ballast water inside a perfectly vertical untapered spar will rest solely on the bottom endplate of the spar instead of being distributed along the spar. Furthermore, we introduce the concept of filled member groups with each group potentially containing multiple members. The internal flooded volumes of all members belonging to the same filled member group are treated as interconnected and, therefore, share the same contiguous hydrostatic pressure field. Each filled member groups is classed as either open or closed. If at least one member in a given filled member group is partially buried in the seabed, such as a monopile, we treat this group as open to the external body of sea water through the bottom opening of the partially buried member and the porous seabed. In this case, the hydrostatic pressure of the internal fluid is in equilibrium with the external body of water with zero hydrostatic pressure at the external still water level. Furthermore, the filled level of an open filled member group cannot be higher than the external still water level, and the density of the internal fluid must exactly match the external water density. Note that any member partially buried in the seabed is considered to have an open bottom, so that there is neither external nor internal hydrostatic pressure on the bottom end of the member. If none of the members of a filled member group crosses the seabed, the filled member group is considered to be closed off from the external body of water, such as the ballast chamber of a floating platform. In this case, the internal hydrostatic pressure is zero at the instantaneous highest point of the internal fluid-filled volumes of all members belonging to this group at each time step. In this input section, **NFillGroups** specifies the number of fluid-filled member groups and determines the number of rows in the subsequent table. **FillNumM** specifies the number of members in the filled group. **FillMList** is a list of **FillNumM** whitespace-separated **MemberID**\ s. **FillFSLoc** specifies the *Z*-height of the filled level (0 for MSL). **FillDens** is the density of the fluid. If **FillDens** = DEFAULT, then **FillDens** = **WtrDens**. This option is convenient for open filled member groups, which requires the internal fluid density to match the external water density exactly. .. _hd-marine-growth: Marine Growth ------------- Members not also modeled with potential-flow theory may be modeled with marine growth. Marine growth causes three effects. First, marine growth introduces a static weight and mass to a member, applied as distributed loads along the member. Second, marine growth increases the outer diameter of a member, which impacts the diameter used in the viscous-drag, added-mass, fluid-inertia, and static buoyancy load calculations. Third, the hydrodynamic coefficients for viscous drag, added mass, and dynamic pressure are specified distinctly for marine growth. Rotational inertia of the marine growth is ignored and marine growth is not added to member ends. Marine growth is specified using a depth-based table with **NMGDepths** rows. This table must have exactly zero or at least 2 rows. The columns in the table include the local depth, **MGDpth**, the marine growth thickness, **MGThck**, and marine growth density, **MGDens**. Marine growth for a particular location in the substructure geometry is added by linearly interpolating between the marine-growth table entries. The smallest and largest values of **MGDpth** define the marine growth region. Outside this region the marine growth thickness is set to zero. If you want sub-regions of zero marine growth thickness within these bounds, you must generate depth entries which explicitly set **MGThck** to zero. The hydrodynamic coefficient tables contain coefficients with and without marine growth. If **MGThck** = 0 for a particular node, the coefficients not associated with marine growth are used. .. _hd-member-output-list: Member Output List ------------------ HydroDyn can output distributed load and wave kinematic quantities at up to 9 locations on up to 9 different members, for a total of 81 possible local member output locations. **NMOutputs** specifies the number of members. You must create a table entry for each requested member. Within a table entry, **MemberID** is the ID specified in the MEMBERS table, and **NOutLoc** specifies how many output locations are generated for this member. **NodeLocs** specifies those locations as a normalized distance from the starting joint (0.0) to the ending joint (1.0) of the member. If the chosen location does not align with a calculation node, the results at the two surrounding nodes will be linearly interpolated. The outputs specified in :ref:`hd-output-channels` determines which quantities are actually output at these locations. .. _hd-joint-output-list: Joint Output List ----------------- HydroDyn can output lumped load and wave kinematic quantities at up to 9 different joints. **JOutLst** contains a list of **NJOutputs** number of **JointIDs**. The outputs specified in :ref:`hd-output-channels` determines which quantities are actually output at these joints. Output ------ Specifying **HDSum** = TRUE causes HydroDyn to generate a summary file with name **OutRootname**\ *.HD.sum*. **OutRootName** is either specified in the HYDRODYN section of the driver input file when running HydroDyn standalone, or by the OpenFAST program when running a coupled simulation. See :numref:`hd-summary-file` for summary file details. For this version, **OutAll** must be set to FALSE. In future versions, setting **OutAll** = TRUE will cause HydroDyn to auto-generate outputs for every joint and member in the input file. If **OutSwtch** is set to 1, outputs are sent to a file with the name ``OutRootname.HD.out``. If **OutSwtch** is set to 2, outputs are sent to the calling program (OpenFAST) for writing. If **OutSwtch** is set to 3, both file outputs occur. In standalone mode, setting **OutSwitch** to 2 results in no output file being produced. The **OutFmt** and **OutSFmt** parameters control the formatting for the output data and the channel headers, respectively. HydroDyn currently does not check the validity of these format strings. They need to be valid Fortran format strings. Since the **OutSFmt** is used for the column header and **OutFmt** is for the channel data, in order for the headers and channel data to align properly, the width specification should match. For example, .. code-block:: fortran "ES11.4" OutFmt "A11" OutSFmt Output Channels --------------- This section controls output quantities generated by HydroDyn. Enter one or more lines containing quoted strings that in turn contain one or more output parameter names. Separate output parameter names by any combination of commas, semicolons, spaces, and/or tabs. If you prefix a parameter name with a minus sign, "-", underscore, "_", or the characters "m" or "M", HydroDyn will multiply the value for that channel by –1 before writing the data. The parameters are not necessarily written in the order they are listed in the input file. HydroDyn allows you to use multiple lines so that you can break your list into meaningful groups and so the lines can be shorter. You may enter comments after the closing quote on any of the lines. Entering a line with the string "END" at the beginning of the line or at the beginning of a quoted string found at the beginning of the line will cause HydroDyn to quit scanning for more lines of channel names. Member- and joint-related quantities are generated for the requested :ref:`hd-member-output-list` and :ref:`hd-joint-output-list`. If HydroDyn encounters an unknown/invalid channel name, it warns the users but will remove the suspect channel from the output file. Please refer to Appendix C for a complete list of possible output parameters.