The function for aerodynamic force input positions in elastoDyn?

@Jason.Jonkman
Dear Dr. Jason,

Up to now, to my limited understanding, in the elastoDyn module, the wind turbine is solved for its motion according to the aerodynamic forces (ignore other modules such hydrodynamic for now). My research goal is to simulate a tandem twin rotor wind turbine (including two rotors and a tower). Therefore, I think I should add up the aerodynamic forces of the two rotors and apply them to the same one platform. However, I could not find in which function to use the aerodynamic forces to solve for the platform motion, leading me to be unsure where to add the two aerodynamic forces for the purpose of summing them.

I’m not sure I’m on the right track for my research goal. Could you give me some suggestions?

Besides, could you please tell me which function in elastoDyn module solves the platform motion based on aerodynamics forces? Also, are there any specific manuals for the elastoDyn module?
Thank you

Best regards
Tianming Cha

Dear @Tianming.Zhao,

The standalone driver for AeroDyn can support the modeling of aerodynamic loads for wind turbines with multiple rotors on the same tower and platform. However, OpenFAST does not currently support such a turbine configuration, including aero-elastic effects. We at NREL have developed an outline summarizing how we’d like to add support in OpenFAST for modeling multiple rotors on the same tower and platform, but have not been funded to develop this capability yet.

Documentation on the usage and theory basis of ElastoDyn is available here: 4.2.7. ElastoDyn Users Guide and Theory Manual — OpenFAST v3.4.1 documentation.

The platform motion is not solved independently from other degrees of freedom in ElastoDyn, but rather coupled with the motion of other degrees of freedom within the solution of coupled equations of motion.

Best regards,

Dear @Jason.Jonkman
First of all, the mentioned version of openFAST is 2.6.0

I don’t think I made my point clearly. The solver I used is SOWFA+OpenFOAM+openFAST2.6.0 (called pisoFoamTurbine.ALMAdvancedopenFAST). The main concept of this solver is: SOWFA feeds OpenFAST inflow information (velocity) at blade element; OpenFAST computes the turbine structural and system response; and the aerodynamic forces are fed back to the CFD;

Up to now, to my limited understanding, this solvers can be used for single and multiple units floating wind turbine, therefore, I would like to do some development to simulate a tandem twin-rotor wind turbine based on this solver.

This solver is able to calculate multiple wind turbines. This solver implements the coupled simulation between OpenFAST and SOWFA through fast->step() function. For a floating tandem twin-rotor wind turbine (including two rotors and a tower), the most important difference is that the aerodynamic forces of the two rotor act on the same platform compared to floating single-rotor wind turbines. Therefore, I wanted to add up the aerodynamic forces of the two rotors and obtain the combined force of the two rotors, then apply them to the same platform in OpenFAST.

Is my idea feasible? However, I am not sure which function the aerodynamic force of the rotor is transferred to the floating platform in OpenFAST. Could you give me some advice?

Besides, I think it is the elastoDyn module that transfers the aerodynamic force of the rotor to the floating platform in OpenFAST, is this right? If so, could you please tell me which function in the elastoDyn module transfers the aerodynamic force of the rotor to the floating platform in OpenFAST?

Best regards

Tianming Zhao

Dear @Tianming.Zhao,

Limitations in the wind turbine configuration of ElastoDyn are what is keeping OpenFAST from modeling wind turbines with multiple rotors on the same tower and platform (whether using AeroDyn or using OpenFAST coupled to OpenFOAM within SOWFA). That is, the ElastoDyn is limited to wind turbine configurations with a single rotor atop a tower that is attached to a floating platform. I’m sure it is possible with much work, but addressing this limitation would be the most challenging issue to address. Do you know how you want to address this limitation?

The aerodynamic loads on the rotor are transferred from AeroDyn to ElastoDyn via ElastoDyn’s module-level input BladePtLoads (which is a point mesh data structure). These loads, as well as gravity and inertial loads get transferred from the rotor to the platform within the coupled equations of motion of ElastoDyn (so it is difficult to point to “where” it happens in the source code).

Best regards,

Dear @Jason.Jonkman
Thanks for your rapid response.

Thank you very much for your advice on the input parameters of BladePtLoads. I will relearn the source code in OpenFAST 2.6.0 based on the input parameters of BladePtLoads in ElastoDyn.

To address this limitation (simulating two rotors on the same tower and platform, called dual-rotor wind turbine), this is my original idea in this solver (SOWFA+OpenFOAM+openFAST2.6.0).

Firstly, we set up the two wind turbines in the simulated case in OpenFOAM. However, the distance between two wind turbines is relatively small. For the upstream wind turbine, I intend to simulate only the rotor to get aerodynamic force without towers and platforms in OpenFAST. For the downstream wind turbine, the whole floating wind turbine including a single rotor, tower and platform would be simulated in OpenFAST.

Then, we can get the total aerodynamic force (the sum of the aerodynamic forces of the upstream and downstream rotors).

Next, we plan that the total aerodynamic force would be applied to the platform to get the motion of the floating platform.

The last, the floating platform transfers motion to the upstream and downstream rotors.

These are all my thoughts on floating dual-rotor wind turbines, do you think my idea is feasible? Could you give me some suggestions?

Best regards

Dear @Tianming.Zhao,

I gather from your explanation that you are not interested in the aero-elastic behavior. Rather, you’re interested in the impact of the dual rotors on the rigid-body motion of the floating system; is that correct? This will certainly require a source code change, but not nearly as difficult as I was first implying.

Best regards,

Dear @Jason.Jonkman ,
I would briefly describe the main concept of this coupled solver as follows:

  • SOWFA feeds OpenFAST inflow information (velocity) at blade element;
  • OpenFAST computes the turbine aerodynamic forces, structural and system response;
  • The aerodynamic forces are fed back to the SOWFA;

Therefore, in this coupled solver, It can actually deal with the aero-hydro-servo-elastic simulation as OpenFAST ( although we do not really interested in those research related to servo). Because all simulations would actually be simulated in OpenFAST. The SOWFA only provided the velocity at each blade element based on CFD method. In fact, we are really interested in aero-hydro-elastic behavior for the dual-rotor floating wind turbine.

The SOWFA, CFD-based solver, can provide much more accurate velocity for the whole flow field. Therefore, the velocity at the blade elements provided by SOWFA (CFD method) addresses (to some extent) the interference between the two rotors for the dual-rotor wind turbine.

Suppose my idea is reasonable and combining my thoughts (the previous discussion), firstly, what I need to do is find out in which subroutine the aerodynamic force is transfered to the floating platform in elastoDyn. Then I need to modify the single rotor’s aerodynamic force to be the sum of the aerodynamic forces of the two rotors to get the motion of the floating platform. Last, the floating platform transfers motion to the upstream and downstream rotors.

I’m not sure I’ve explained my thoughts clearly. do you think my idea is feasible? I really hope you can give me some advice. Besides, could you tell me which SUBROUTINE in ElastoDyn transfers the aerodynamic force of the rotor to the floating platform in OpenFAST ( I have known the parameters of BladePtLoads represent an aerodynamic force in ElastoDyn module).

Best regards,

Dear @Tianming.Zhao,

As I said, limitations in the wind turbine configuration of ElastoDyn are what is keeping OpenFAST from modeling wind turbines with multiple rotors on the same tower and platform, including aero-elastics (whether using AeroDyn or using OpenFAST coupled to OpenFOAM within SOWFA). That is, the ElastoDyn is limited to wind turbine configurations with a single rotor atop a tower that is attached to a floating platform. I’m sure it is possible with much work, but addressing this limitation would be the most challenging issue to address. Do you know how you want to address this limitation?

You would likely need to change the source code to include two instances of ElastoDyn that share common platform degrees of freedom (to model the floater rigidly) or change the source code to include two instances of ElastoDyn along with a change to SubDyn to support multiple interface nodes (to model the floater elastically). The latter is what NREL’s plan to include multiple rotors on the same platform would involve. But this change would require substantial code development.

As I said, the aerodynamic force is not applied directly to the platform in ElastoDyn, rather the load transfer happens through the equations of motion of ElastoDyn. If you intend to make the source code changes I mention above, I suspect you’ll need to thoroughly review the ElastoDyn theory documents (4.2.7. ElastoDyn Users Guide and Theory Manual — OpenFAST v3.5.0 documentation), as well as SubDyn for the second option (4.2.5. SubDyn User Guide and Theory Manual — OpenFAST v3.5.0 documentation), and associated source code before moving forward with the changes.

Best regards,

Dear @Jason.Jonkman ,

Thank you for your timely response. I think I tend to change the source code to include two instances of ElastoDyn that share common platform degrees of freedom.

I will reconsider what to do next and discuss it with you.

Thank you very much for your suggestions!

Best regards,

Dear @Jason.Jonkman

Thank you for your answers above.

To find the relationship between BladeLoads (BladeLoad to BladePtLoads through Transfer_Line2_to_Point ) to platform motion, I re-read the code.

My main goal at the moment is that: to find out how aerodynamic loads are linked with platform motion (which subroutines) when solving for platform motion. So that, then I can find a method to add dual rotor aerodynamic force to one platform.

To my limited understanding, I think the outline is that BladeLoad need to convert the BladePtLoads
(Transfer_Line2_to_Point) firstly, then the platform motion (x%qt、x%qdt) is solved in ED_UpdateStates, the last the ED_CalcOutput can be used to output.

This is the flow chart that I have put together for now (only some module related with elastoDyn).

However, in the program, the platform motion (x%qt、x%qdt) is solved in ED_UpdateStates (A), the platform motion is outputted ED_CalcOutput (B). I could not find the subroutine for BladeLoad to BladePtLoads (Transfer_Line2_to_Point( y_AD%BladeLoad(k), u_ED%BladePtLoads(k), MeshMapData%AD_L_2_BDED_B(k), ErrStat2, ErrMsg2, u_AD%BladeMotion(k), y_ED%BladeLn2Mesh(k) )) between A and B until D.

Next, in CalcOutputs_And_SolveForInputs (C), the BladeLoad was converted to BladePtLoads in ED_InputSolve (D, Transfer_Line2_to_Point()), then the ED_CalcOutpu (E) was used to output. However, the solved progress for platform motion (x%qt、x%qdt) in ED_UpdateStates was not found.

Therefore, I’m not sure how the connection between BladeLoads (BladeLoad to BladePtLoads through Transfer_Line2_to_Point ) to solve platform motion (x%qt、x%qdt in ED_UpdateStates).

Could you give me some suggestions?

Best regards

Dear @Tianming.Zhao,

Regarding why the BladeLoad output of AeroDyn is not transferred as the BladePtLoads input to ElastoDyn within FAST_AdvanceStates(), this is because ElastoDyn is the first module to advance its states (before AeroDyn). Instead, ElastoDyn uses extrapolated values of the aerodynamic loads when advancing its states, at least in the predictor step.

Regarding the ElastoDyn states x%q and x%qd, these states are advanced in the ED_UpdateStates() routine; the ED_CalcOutput() routine is used to compute ElastoDyn outputs without updating states.

Again, the aerodynamic loads input to ElastoDyn (BladePtLoads) impact the platform motions through the equations of motion of ElastoDyn, which are solved within the ED_UpdateStates() and ED_CalcOutput() routines. Effectively, the aerodynamic loads get applied to the blade, which induces accelerations within ElastoDyn through the equations of motion, which are then time-integrated (in ED_UpdateStates()) to solve for the ElastoDyn states.

Best regards,

Dear @Jason.Jonkman ,

Thank you for your timely response.

Best regards,