Second-order wave loads in RAFT

[lucas-carmo]

Purpose

This PR implements second-order wave loads in RAFT. For now, we only capture the magnitude of these loads, hence without the phases. This should be acceptable for single units but could be problematic for arrays. We plan to address this limitation in the future.

Two approaches are now available:

• Using precomputed Quadratic Transfer Functions (QTFs) from a frequency-domain radiation/diffraction software such as WAMIT or NEMOH. The input file is assumed to be in the WAMIT format (.10, .11, and .12 files), which is the same adopted by OpenFAST.
• Using a second-order slender-body approximation based on a modified version of Rainey's equation. In loose terms, this extends Morison's equation to include higher-order inertial terms. While not as precise as using QTFs, this approach should be sufficient in many cases and doesn't require preprocessing.

To use precomputed QTFs, the user needs to provide the following inputs:

• potSecOrder = 2: A switch to specify whether and how the second-order loads should be computed.
• qtfPath = 'string/with/path': Path to the precomputed QTF file.

To compute the second-order loads internally with the slender-body approach:

• potSecOrder = 1
• min_freq2nd: minimum frequency, in Hz, to compute the QTFs matrices.
• max_freq2nd: maximum frequency, in Hz, to compute the QTF matrices.
• df_freq2nd: frequency step, in Hz, of the QTF matrices. These parameters are only for the QTF matrices, as the second-order wave loads are interpolated to the frequencies specified in settings.
• outFolderQTF = 'string/with/path': Path to the folder to output the QTF computed with RAFT. If no path is specified, the QTF is only used internally. Currently, the file is always named "qtf-slender_body-total.12d".

Note that potSecOrder does not conflict with potModMaster. We should be able to use any combination of them. For instance, we can use Morison's equation for the first-order wave loads and QTFs from WAMIT for the second-order wave loads.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change adding functionality)
• Breaking change (non-backwards-compatible fix or feature)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Documentation update
• Maintenance update
• Other (please describe)

Testing

I included two test cases in the examples folder. They correspond to the OC3-Hywind spar using (i) precomputed QTFs and (ii) the slender-body approximation. I have done some comparisons with OpenFAST simulations, and the results match well within the inherent limitations.

Checklist

• I have run existing tests which pass locally with my changes.
• I have added new tests or examples that prove my fix is effective or that my feature works.
• I have added necessary documentation

This branch did not pass the automated tests, but it seems to be unrelated to this PR.

[mattEhall]

This looks awesome, and I think good to merge in. One last little thing: could you confirm that for the preexisting designs/examples, with no 2nd order, results from this branch match those from the dev branch?

[lucas-carmo]

Yes, they do!