FeaCoupling of an External floater (platform+mooring) with Openfast #791 #801
Replies: 8 comments 28 replies
-
Dear Zahid, Can you clarify what type of coupling you are envisioning? Are you envisioning a one-way coupling where you first run your external floater code, from which motions of the floater would be calculated, then you would input these motions to OpenFAST in a subsequent simulation? Or you are envisioning a two-way coupling where your external floater code is coupled to OpenFAST time step by time step such that the reaction loads at the tower impact the floater motion from your external floater code? The former method is much easier to implement, but less accurate, than the second method. The biggest challenge overall is that the ElastoDyn module of OpenFAST considers the motion of the floating platform as internal degrees of freedom, so, ElastoDyn wants an external module to provide load input of the platform (from hydrodynamics and moorings) rather than motion input. Best regards, |
Beta Was this translation helpful? Give feedback.
-
Dear Dr. Jonkman You have always been helpful and I was waiting for your valuable suggestions on the current issue. I am envisioning a two-way coupling where there is an exchange of parameters (forces and motion) at each time-step of simulation. I was also a bit concerned about the ElastoDyn module as it encompasses floating platform, tower, rotor, and nacelle. Is it possible to somehow suppress the platform part of the ElastoDyn module while the remaining tower+rotor+nacelle remains active? |
Beta Was this translation helpful? Give feedback.
-
Dear @ZahidUllah33400, What you are proposing would require a rearrangement of the ElastoDyn equations of motion. That is, without modification, the loads applied to the floating platform (apart from those transferred through the tower from the turbine) are known inputs to ElastoDyn and the platform accelerations are unknowns (solved via generalized F=ma), from which the velocities and displacements can be found via time-integration. What you are proposing would swap this so that the acceleration is input and the loads are unknowns (solved via generalized F=ma). This would not be an easy change to make. Can you change your external floater code to calculate loads instead of motions? Can you back up and clarify why you are trying to couple an external floater code with OpenFAST? What functionality does your external floater code have that is not captured by OpenFAST already? Best regards, |
Beta Was this translation helpful? Give feedback.
-
Dear Dr. Jonkman Your description is helpful that without modification the known inputs are load rather than platform acceleration. In one of the recently published articles, the author has described coupling between Fast v7 and Ansys AQWA, and illustrations in the paper show accelerations as inputs. I want to do a similar coupling but with a different floater code. I would highly appreciate your comments on that coupling procedure and if that (procedure) can be helpful. (article title: Development and Application of an Aero-Hydro-Servo-Elastic CouplingvFramework for Analysis of Floating Offshore Wind Turbines, https://doi.org/10.1016/j.renene.2020.07.134) Regarding the functionality, the subroutine (for the platform) we want to couple with Openfast considers a flexible platform and will compute the hydrodynamic loading on it. |
Beta Was this translation helpful? Give feedback.
-
Dear @ZahidUllah33400, Well, I looked briefly at this article and it does not mention that the FAST v7 source code was modified to accept platform acceleration inputs. However, the paper links to a github site where the source code can be found. I have not reviewed the files here, but you could review them and reach out to the authors of the paper for clarification. The ElastoDyn module of OpenFAST was derived from the structural model of FAST v7, and both have the same formulation for load input and motion output of the platform. So, I would guess that they rearranged the equations of motion for the platform DOFs as I summarized in my prior post. FYI: The ability to model floating substructures as structural flexible bodies with hydro-elastic effects and the ability to calculate internal member-level loads was introduced in OpenFAST v2.6 and newer. Best regards, |
Beta Was this translation helpful? Give feedback.
-
Dear @ZahidUllah33400, The ability to model floating substructure flexibility and member-level loads and associated updates to SubDyn, HydroDyn, and the OpenFAST glue code has now concluded, including code development and verification against OrcaFlex for the TetraSpar in collaboration with Stiesdal. The source code from #537 has been reviewed and approved and released in OpenFAST v2.6 and newer. However, the full-system models we’ve tested contain proprietary information, so, these models cannot be shared publicly; we’ve posted the need for an example FOWT model with substructure flexibility in this r-test issue: OpenFAST/r-test#39. The user-documentation has been updated, but is still incomplete. The SubDyn and HydroDyn input files have changed and these changes are reflected in the updated r-test (https://github.com/OpenFAST/r-test). There is some documentation of the input file changes in the OpenFAST readthedocs (https://openfast.readthedocs.io/en/main/source/user/api_change.html). Likewise, the SubDyn documentation has been completely revamped, as included in the OpenFAST readthedocs (https://openfast.readthedocs.io/en/main/source/user/subdyn/index.html). The HydroDyn outputs have been updated a bit, as documented in the updated OutListParameter.xlsx spreadsheet—see: https://openfast.readthedocs.io/en/main/_downloads/3f19498a5dc774461e022b671ff01ec6/OutListParameters.xlsx. The theory basis on many of the new features is summarized in the following NREL technical report: https://www.nrel.gov/docs/fy20osti/76822.pdf. Here are a few general guidelines for running OpenFAST with this new capability:
Best regards, |
Beta Was this translation helpful? Give feedback.
-
Dear @ZahidUllah33400, Your sketch seems reasonable, but please note that it is missing the velocities (V) and accelerations (A) that must be passed into OpenFAST. The implementation can likely be completed in 4 months, but I have not done it myself and can't guide you through all of the details. You'll have to modify the source code of both ElastoDyn and the OpenFAST glue code. You'll need to change ElastoDyn so that the 6-DOF motions of the platform (U,V,A) are passed as input instead of the 6-DOF platform loads, the 6-DOF platform loads (RF) are output instead of the 6-DOF motion of the platform, and rearrange the equations of motion so that the 6 platform loads are the unknowns instead of the 6 platform accelerations. You'll need to change the OpenFAST glue code so that it calls your hydrodynamic subroutine and that the updated ElastoDyn inputs and outputs are transferred through this call. I'm not sure if the coupling approach will be implicit or not (i.e. if the acceleration input to OpenFAST (A) is directly dependent on the reaction force (RF) output from OpenFAST). If the coupling is implicit, you'll have to address that too (similar to how we solve implicit coupling between modules now in the OpenFAST glue code through a rigorous nonlinear input-output solve), otherwise the coupling between OpenFAST and your code would be numerically unstable without a very small time step. I hope that helps. Best regards, |
Beta Was this translation helpful? Give feedback.
-
Dear @ZahidUllah33400, Yes, the process you've used to compile standalone InflowWind is correct. What error you are getting when you do the same for standalone AeroDyn? You can use the precompiled standalone drivers from FAST v8 for running standalone simulations, but coupling to Abaqus will require source code development and compiling. And you should note that InflowWind, AeroDyn, and ServoDyn have all been updated in OpenFAST relative to FAST v8, so, using the older versions will not provide the most updated functionality. Best regards, |
Beta Was this translation helpful? Give feedback.
-
Hello
I have been using Fast v8 and currently, I have started learning Openfast. I am interested in coupling of an external floater with the Openfast. what I want to do is that I want to develop my code that simulates the floater motion (floater: mooring lines+platform) and I want to use those six degrees of freedom motion of floater as an input argument for Openfast. This means I want to suppress the mooring module and platform kinematics of Openfast. Now I understand that the Elastodynamic module of Openfast includes the platform+tower+rotor+nacelle. Does this mean I have to somehow suppress the platform of the elastodynamic modules? As a beginner, I have few points in mind and would highly appreciate the expert's opinion on those.
My Goal:
At each time-step of the simulation, my code will provide the platform motion to the Openfast (at the base of the tower) and in return the Openfast would give me the reaction forces at the tower.
Key points of clarification:
To achieve my target I need to learn the development side of Openfast but I want to know where should I start.
Is it a difficult job and possible to be done in 4 months.
Can anyone gives me key step I have to follow to get to my target (just mention main things I have to learn to get to my target)
I will highly appreciate the expert's remarks and suggestions. Thanks
Beta Was this translation helpful? Give feedback.
All reactions