OpenFAST / openfast

Main repository for the NREL-supported OpenFAST whole-turbine and FAST.Farm wind farm simulation codes.
http://openfast.readthedocs.io
Apache License 2.0
691 stars 458 forks source link

Question related to modeling of floating wind turbine #2122

Closed WANGSUYU0809 closed 7 months ago

WANGSUYU0809 commented 7 months ago

Hi,

I have a question related to modeling of floating wind turbine in Openfast.

For example I'm modeling a Windfloat type of floating wind turbine, for which the wind turbine tower locates at one corner of the floater. For floater modeling, I guess I need to use the geometry center of the water plane area as the global origin, and I use this global origin as the reference point both in Hydrodyn and potential flow solver. Then, the tower axis will deviate from global x=0, or y=0. However, in Elatodyn, there are no option to input x or y coordinate of tower node, I guess they are always equal to 0 by default.

How could I solve this paradox?

jjonkman commented 7 months ago

Dear @WANGSUYU0809,

Because--as you said--you can't define an x/y offset of the tower centerline in ElastoDyn, to model a floating wind turbine like the WindFloat where the tower/turbine is installed on one of the offset columns of a semisubersible, you should define the (0,0,0) origin of the OpenFAST model to be at intersection of the undisplaced tower centerline and sea level, rather than at the geometric center of the floater. See similar questions discussed in a related question in OpenFAST discussions (https://github.com/OpenFAST/openfast/discussions/1920) and on our forum (https://forums.nrel.gov/t/platform-movements-signal/879).

Best regards,

WANGSUYU0809 commented 7 months ago

Dear Jason,

Thanks for your reply! I understand now I have to use the tower central axis as the global origin x=0 and y=0 now. But I'm still a bit confused about how should I model the floater. I think I have 2 options:

  1. In the potential flow solver model, I still use the geometry center of the floater water line area as the global origin, and also use this point as the reference point for hydrodynamic output. Then, in openfast hydrodyn file, I use parameter 'PtfmRefxt' and 'PtfmRefyt' to define the deviation between the global origin in openfast, and the global origin in potential flow solver ( this is also the hydrodynamic output reference point);

  2. In the potential flow solver model, I use the same global coordinate system as openfast model, so that the global origin, and also the hydrodynamic reference point locates at one column of the floater. Then 'PtfmRefxt' and 'PtfmRefyt' should be zero. However, by doing so, since the hydrodynamic reference point doesn't locate at geometry center, so there would be coupling term between heave and pitch, for example, in restoring stiffness matrix, damping matrix,,,

Which option do you suggest to use? Thanks for your time in advance!

jjonkman commented 7 months ago

Dear @WANGSUYU0809,

I would say that ether method should work.

Best regards,

WANGSUYU0809 commented 7 months ago

Thanks for you help!

A quick question: I'm wondering in HydroDyn file, although it requires user to input displacement of floater, and center of buoyancy in x and y direction, but why it doesn't require us to input center of buoyancy in z direction? I guess openfast would internally add the buoyancy force at the water plane? And maybe this also explains why in the openfat manual, it tells us we need to put center of gravity at water plane in potential flow solver, in order to calculate the restoring stiffness transfering to Openfast?

jjonkman commented 7 months ago

Dear @WANGSUYU0809,

The z-coordinate of the center of buoyancy is not an input in HydroDyn because it is not needed in the calculation. The buoyancy force in the undisplaced position is directed vertically upward, so, a z-offset of center of buoyancy will not generate a moment arm. The hydrostatic stiffness matrix, which is specified relative to the platform reference point in HydroDyn, does include the contribution of the vertical center of buoyancy, but this is specified through the hydrostatic stiffness matrix directly.

The HydroDyn modeling guidance recommends setting the vertical center of gravity of the structure to zero in WAMIT (or in an equivalent potential-flow radiation-diffraction pee-processor) so as to zero-out the contribution of body weight in the hydrostatic stiffness matrix, so as to not double account this effect that is already accounted for in the structural solvers of OpenFAST.

Best regards,

WANGSUYU0809 commented 7 months ago

Thanks for your help, it clears my question

WANGSUYU0809 commented 7 months ago

Dear @WANGSUYU0809,

I would say that ether method should work.

Best regards,

I have a further question for this topic. I have tried option1 for modeling the hydrodynamic of floater, however, from a regular wave simulation result, I found that the relative phase between surge and pitch floater response is wrong. There should be a phase difference between surge and pitch, due to very different natural period among them (I have verified the natural period for floater 6dof by free decay simulation in Openfast, pitch is around 25s, surge is around 70s), but the simulation result shows that there is almost no phase difference. I suspect it's due to the modeling strategy I used. Since I have used different global origin in Openfast and potential flow solver, this may lead to phase issue. But theoreticaly, I think it should only cause problem in the relative phase between floater 6dof response with the wave, but the relative phase between floater 6dof motion response themselves should still be correct. Do you have any suggestions here? Thank you for your help!

jjonkman commented 7 months ago

Dear @jjonkman,

I'm not sure why you getting a phase error that you are not expecting, but I would say that option 1 and 2 should give consistent results if each model is implemented properly.

Best regards