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 <https://www.nrel.gov/wind/nwtc/ss-fitting.html>`__ 
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.
