openfast icon indicating copy to clipboard operation
openfast copied to clipboard

Question on Force Balance for OC4 Floating Wind Turbine with Only Potential Flow

Open YangLeiTH opened this issue 6 months ago • 9 comments

I am currently trying to perform structural analysis on the OC4 floating wind turbine based on OpenFAST results. As an initial step, I want to verify the load case considering only hydrodynamic effects. To simplify the setup:

I have disabled all modules except HydroDyn.

In HydroDyn, I consider only potential-flow hydrodynamics (i.e. no Morison elements, and no platform mesh).

I removed other contributions to eliminate redundancy or overlaps.

Now, I want to check the force balance along the surge direction. My understanding is that the hydrodynamic force HydroFxi should balance with the inertial force (i.e., PtfmTAxi * M_total, where M_total = 3,852,180 kg) plus the tower base shear force TwrBsFxt.

However, based on the output, the left and right sides do not balance as expected.

Could you please advise if there's anything incorrect in this interpretation or approach? Am I missing some key component (e.g., internal dynamics, missing added mass, coordinate frame inconsistency, etc.)?

Thank you very much for your help!

Best regards, Lei Yang

Image

YangLeiTH avatar Jun 19 '25 08:06 YangLeiTH

Dear @YangLeiTH,

Presumably you've enabled both ElastoDyn and HydroDyn (two modules, not one) if you have platform acceleration.

Are you only considering a single surge degree of freedom (DOF) in ElastoDyn, or, do you have the six platform DOFs enabled? The scalar (one-equation) m * a = F works in a multi-degree of freedom system only about the body center of mass, but PtfmTAxi (representing "a") is not reported about the center of mass unless you changed PtfmRefzt in ElastoDyn. If you have platform rotation DOFs enabled, it could also mean that the tower-base coordinate system is not aligned with global-inertial frame coordinates, so, TwrBsFxt may not be aligned with HydroFxi.

Best regards,

jjonkman avatar Jun 19 '25 13:06 jjonkman

Thank you for your helpful reply.

Yes, I have enabled all six DOFs of the floating platform in ElastoDyn, and I am currently trying to verify the overall force balance in the surge direction as a first step before moving on to detailed hydrodynamic pressure evaluations.

I understand your point that PtfmTAxi is not reported at the center of mass unless PtfmRefzt is adjusted. For now, my focus is more on a practical force equilibrium check using OpenFAST outputs. So, may I ask is there a recommended or validated force balance equation (for surge) that I can construct directly using OpenFAST output channels?

I aim to identify a load combination that gives a reasonably closed balance (e.g., within numerical tolerance), to ensure the model is behaving as expected.

Best regards, Yang Lei

YangLeiTH avatar Jun 19 '25 16:06 YangLeiTH

Dear @YangLeiTH,

If all you are interested in is surge, simply disable all platform DOFs except surge and I would expect your force-balance equation to work out.

If you need all six platform DOFs, you'll have to be sure to consider the coupling between DOFs and the platform orientation in the force-balance equations.

Best regards,

jjonkman avatar Jun 20 '25 01:06 jjonkman

Dear @jjonkman

Thanks! I've confirmed the force balance works when only surge DOF is enabled.

However, once I enable the rotational DOFs, the balance breaks down — likely due to platform orientation changes and reference point differences.

Could you please clarify:

Are PtfmTDxt, PtfmTDxi, PtfmTAgxt, and PtfmTAgxi referenced at PtfmCMzt (center of mass) or PtfmRefzt?

What’s the difference between the "t" and "i" versions — are they in platform vs. inertial coordinates?

Thanks again for the support!

Best regards, Yang Lei

YangLeiTH avatar Jun 20 '25 03:06 YangLeiTH

Dear @YangLeiTH,

The platform motions output from ElastoDyn are motions of the platform reference point. You can ensure the platform reference point aligns with the platform center of mass if you set PtfmRefzt = PtfmCMzt (as long as PtfmCMxt = PtfmCMyt = 0).

Yes, "t" and "i" in the ElastoDyn output names refer to the tower-base (platform) and inertial coordinate systems, whose orientations differ based on the platform rotations (roll, pitch, yaw).

Best regards,

jjonkman avatar Jun 20 '25 13:06 jjonkman

Dear @jjonkman

Thank you for your assistance. I tried setting PtfmRefzt equal to PtfmCMzt as you suggested, and then transferred the tower-base forces to the global coordinate system. I found that the hydrodynamic loads, inertial loads, and tower base shear forces were completely balanced, with the resultant surge force being only around 2N, as shown in Figure 1.

However, when I enabled the mooring module, the error increased again. I calculated the total mooring force by summing L1N20fX, L1N20fY, and L1N20fZ, L2N20fX, L2N20fY, and L2N20fZ,L2N20fX, L2N20fY, and L2N20fZ and found that the resultant of the hydrodynamic loads, inertial loads, tower base shear, and mooring forces increased to approximately 10^4N.

Could there be an issue with my mooring force calculation? I would appreciate your insights on this.

Best regards, Yang Lei

Image

Image

YangLeiTH avatar Jun 23 '25 12:06 YangLeiTH

Dear @YangLeiTH,

I'm glad the load summation without MoorDyn is now working for you.

With MoorDyn, do you mean you have three lines with node 20 at the fairlead and you sum LINE1N20FX + LINE2N20FX + LINE3N20FX with the other global X-component forces?

Best regards,

jjonkman avatar Jun 23 '25 16:06 jjonkman

Dear @jjonkman,

Thank you for your feedback.

Yes, I have three lines with node 20 at the fairlead and you sum LINE1N20FX + LINE2N20FX + LINE3N20FX with the other global X-component forces. I noticed that while the individual plot appears quite large, the total force seems to be relatively small compared to other loads, most of which are on the order of 10^6. I’m not sure if there’s an issue with my calculation or if such a large discrepancy is expected due to inherent errors in the model. Could you please provide some insights on whether this is a typical behavior, or if there might be something wrong with the way I’ve approached the solution?

Looking forward to your guidance.

Best regards,

Image

YangLeiTH avatar Jun 24 '25 02:06 YangLeiTH

Dear @YangLeiTH,

I would guess there is just some numerical round-off in your calculations, e.g., because of the use of only 4 digits of precision if you are using text-formatted output files.

Best regards,

jjonkman avatar Jun 25 '25 18:06 jjonkman

Ok, thank you very much!

YangLeiTH avatar Jun 27 '25 05:06 YangLeiTH