Coupling CFD code with FAST/OpenFAST

Dear Jason,

Is it possible to do a CFD+FAST/OpenFAST coupling in which the CFD code is only used to calculate the hydrodynamic loads of the platform?

The CFD code can be OpenFOAM, OceanWaves3D, etc. Have you ever heard of a similar research that was done by someone?

So, does SOWFA+OpenFOAM+FAST/OpenFAST serve for this purpose? I’m asking this question because SOWFA is usually used for evaluation of a wind farm performance. In another word, can SOWFA+OpenFOAM+FAST/OpenFAST be used for modeling the dynamics of a single floating wind turbine?

Thanks.
Yingyi

1 Like

Dear Yingyi,

SOWFA is not developed to support the modeling of hydrodynamic loads via CFD. We have used OceanWaves3D to develop wave kinematics for use in FAST / OpenFAST, but in this case OceanWaves3D is used as a preprocessor, rather than directly coupled. I’m not aware of anyone who has coupled OpenFOAM to FAST / OpenFAST to support the modeling of hydrodynamic loads via CFD in a coupled simulation. That said, we have used OpenFOAM and STAR-CCM to model the hydrodynamic loads via CFD uncoupled from FAST / OpenFAST.

Best regards,

Dear Jason,

I’m sorry to have made you confused. Indeed, our purpose is to model a floating wind turbine in a nonlinear wave environment rather than linear. That means we need to substitute the linear wave kinematics with other nonlinear ones.

For such a purpose, what way of modeling do you recommend? I would like to hear your comments.

Thanks.

Yingyi

Dear Yingyi,

What type of nonlinearities do you need? The HydroDyn module of FAST / OpenFAST support full second-order theory, including mean-dirft, slow-draft, and sum-frequency terms (both second-order wave kinematics for the strip-theory solution and second-order radiation/diffraction (QTFs) for the potential-flow solution). Do you need more nonlinearities than these models provide?

Best regards,

Dear Jason,

We hope to introduce fully nonlinear waves or strong nonlinear waves, at the later stage as well as some extreme waves, such as focused waves, solitary waves, etc. We hope to study the effect of wave nonlinearities on the dynamic response of a floating wind turbine.

Best regards,

Yingyi

Dear Yingyi,

What does your floating platform look like? Is it a thin body such as a spar buoy, which can be well simulated with the strip-theory solution? In that case, you can disable potential-flow and use OceanWave3D (or the like) as a preprocessor to generate nonlinear wave kinematics for use in FAST / OpenFAST.

Best regards,

Dear Jason,

Thanks. Indeed, we have not decided what a floating type to be used in this study. I can understand that the way you mentioned applies to a spar type.

But how about if the floater is a semisubmersible platform like the OC4 DeepCwind semi, combined by several columns and bracings, does the strip-theory solution still apply, or would it introduce large errors to your expectation?

For the details of the modeling, if we apply the strip-theory solution as you mentioned, should we input the nonlinear wave kinematics to FAST/OpenFAST via input files, or via a user-defined subroutine as the interface?

In addition, in the case if the interface is via input files, where can we find the format of these files? Thanks.

Best regards,

Yingyi

Dear Yingyi,

The strip-theory solution breaks down for large diameter / volume structures. I’ve been surprised how well the strip-theory-only solution has done modeling the OC4-DeepCwind semisubmersible, but getting the strip-theory model correct required knowledge of the added mass from the potential-flow solution. I would guess the strip-theory solution would break down for floating substructures larger than the OC4-DeepCwind semisubmersible.

User-defined wave kinematics can be specified through input files by enabling WaveMod=6. There are sample input files in the standalone HydroDyn CertTest in the standalone HydroDyn archive (nwtc.nrel.gov/HydroDyn). That said, the input file format would be a bit “clunky” for a semisubmersible model, which has many hydrodynamic analysis nodes.

Best regards,

Dear Jason,

I checked the HydroDyn (HD_v2.05.00) package, inside the folder \CertTest there is a sample case file Test_004.dat in which WaveMod=6 is enabled. However, it seems that all the given files for Test_004 are output files generated by HydroDyn, and I’m not able to find the file which is exactly the one we need in order to specify our user-defined wave kinematics. Would you mind to tell which one is?

Thanks.
Best Regards,
Yingyi

Dear Yingyi,

You’ll need 8 files to specify user-generated wave kinematics: 3 for the wave particle velocities (*.Vxi, *.Vyi, .Vyi), 3 for the wave particle accelerations (.Axi, .Ayi, .Azi), 1 for dynamic pressure (.DynP), and 1 for the wave elevation (.Elev). These are provided for TEST_004. See the draft HydroDyn User’s Guide and Theory Manual for more information on these input files: wind.nrel.gov/nwtc/docs/HydroDyn_Manual.pdf.

Best regards,

Dear Jason,

At the bottom of Page 15 of the HydroDyn_manual, it was mentioned that “Each of these files must have exactly WaveTMax/DT rows and N whitepace-separated columns, where N is the total number of internal HydroDyn analysis nodes (corresponding exactly to those written to the HydroDyn summary file).” I do find the N=16 nodes in the Test_004.sum file.

(1) Do “Nxi, Nyi, Nzi” mean the x, y, z coordinates of the so-called HydroDyn analysis nodes in the global inertial-frame system?

(2) Are these nodes user-defined or not? If they are, where (in which file) can we define the global coordinates of these HydroDyn analysis nodes?

Thanks.
Best Regards,
Yingyi

Dear Yingyi.Liu,

Regarding (1), the answer is “yes”: “Nxi, Nyi, Nzi” are the undisplaced position of the strip theory nodes in the global inertial frame coordinate system.

Regarding (2), the nodes coincident with joints are specified directly via the joint locations (Jointxi, Jointyi, Jointzi) in the HydroDyn input file. The nodes along each member are determined by the start and end joint locations and the member division size (MDivSize) in the HydroDyn input file.

Best regards,

Dear Jason,

Thanks.

I can understand that the first 8 analysis nodes as listed in the Test_004.sum file are exactly the 8 member joints as defined in the Test_004.dat file (HydroDyn primary input file) with the JointID ranging from 1~8.

(1) However, for the 9~16th nodes in Test_004.sum, I’m not able to understand how they are determined and why they need to be used repeatedly (as many of the 9~16th nodes coincide with the 1~8th nodes). Could you explain it a little bit (in case it is important)?

(2) In addition, the MDivSize value specified in Test_004.dat seems to be overlarge considering the actual length of a member. For example, Jointzi of the JointID 1 and 2 are 5.00000 and 4.00000 (indicating the member length of the No.1 member is 1.0 m), while MDivSize of the member with a MemberID 1 is 10.0 m, and 10.0m >> 1.0 m.

Thanks.
Best Regards,
Yingyi
Test_004_files.zip (6.73 KB)

Dear Yingyi.Liu,

Here are my answers to your questions:

  1. The node at Nzi = -45 m comes from the water depth, WtrDpth=45 m; HydroDyn automatically splits elements and adds nodes at the waterline and the seabed. The other nodes correspond to the joints. There are duplicate nodes at joints because they reside on two different mesh within HydroDyn. HydroDyn supports both a point mesh (concentrated forces) for loads at joints and a line mesh (distributed forces) for loads distributed across each member. These meshes overlap at the joints, creating duplicate nodes.

  2. I agree. I can’t speak much to this because I did not set up this test, but it looks to be a test more to check the robustness of HydroDyn than to be a good physical example. In general, I would recommended, for instance, that the HydroDyn discretization not exceed element lengths of 0.5 m in the region of the free surface (5 to 10 m above and below SWL), 1.0 m between 25 and 50 m depth, and 2.0 m in deeper waters. Clearly, standalone HydroDyn Test_004 does not follow this guidance.

Best regards,

Dear Jason,

Following your instructions, we performed a calculation with the FAST Test24 CertTest. Note that in the legend, ‘FAST-Morison’ stands for calculation with the built-in functionality of FAST using the complete Morison model (PotMod=0 and PropPot=FALSE, WaveMod=1); ‘FAST-Potential’ stands for calculation with the built-in functionality of FAST using the hybrid Potential-Morison model (PotMod=1 and PropPot=TRUE, WaveMod=1); ‘FOAM-Morison’ stands for calculation with the OpenFOAM-generated 1st-order Stokes wave using the complete Morison model (PotMod=0 and PropPot=FALSE, WaveMod=6). The comparison of results for the Hywind spar platform motion is shown below.

To our disappointment, the agreement seems not good. Surprisingly, the results of ‘FAST-Morison’ and ‘FAST-Potential’ do not agree with each other, especially in surge and pitch. Do you know the reason? And is it reasonable and acceptable?

Thanks.

Best regards,
Yingyi



Dear Jason,

Another question we want to ask is regarding the FAST Test 23 MIT-NREL-TLP. By setting WaveMod=6 and without specifying the input of WvKinFile in the HydroDyn setting file (which means there is no incident wave), FAST is still able to run and generate some result. Why it is able to? And what kind of incident wave has been used in the calculation? (The model can be downloaded from: share.iii.kyushu-u.ac.jp/public … WV7dZbkEli)

Best regards,
Yingyi

Dear Yingyi.Liu,

Looking briefly at the source code, it appears that a fatal error should be triggered if the wave kinematics files don’t exist. But perhaps there is an bug in error handling?

Looking briefly at your results, it appears that the wave elevation in this case is assumed to be zero

Best regards,

Dear Jason,

To make sure whether there is a bug in the source code, I then change the setting of WvKinFile to “TEST_004”, and provide the wave kinematics files with a name of “TEST_004” in the same folder “/5MW_Baseline” (This model can be downloaded from archive.iii.kyushu-u.ac.jp/publ … yWpjkN_QvC). However, the “Wave1Elev” output channel in Test23.out is still zero.

Since I do provide wave kinematics files to FAST with a proper setting, the “Wave1Elev” should no longer be zero any more. Therefore, could you check the source code? If there is such a bug in the code, could you please modify it and share the recompiled FAST_x64.exe file? We do need it in the calculations that we are doing now.

Many thanks.

Best regards,
Yingyi

Dear YingYi,

I ran your model and it appears that the wave kinematics data is not being processed correctly…likely due to formatting or naming problems with the files. I would expect FAST to throw a fatal error and abort, but it seems to be ignoring the data altogether instead. This sounds like a bug, but I have not had the opportunity to run the model through the debugger.

I would first try upgrading to OpenFAST v2.2: github.com/OpenFAST/openfast/pull/239), which has now been merged into the master branch and released in OpenFAST v2.2. If this doesn’t fix the problem I suggest reopening issue #118 on OpenFAST and explaining your problem there.

Best regards,

Dear Jason,

I substitute FAST_x64 with OpenFAST v2.2, it works. OpenFAST v2.2 will report error when an incorrect “WvKinFile” is given.

Thanks a lot.

Yingyi Liu