Disable aerodynamic forces in some directions

Dear all,

Our research group is currently working on an experimental campaign of a FOWT with a software-in-the-loop approach to account for the aerodynamic forces on the rotor. Since the setup that we are going to use is capable of emulating the thrust only (besides requiring the shaft torque for the control loop), I have tried to make a small change in the OpenFAST source code so that the simulations would be closer to the physics of the experiments. However, I am not sure whether the change I have done is correct, or whether there is something else that I should modify. Could you please help me with that?

The only modification was in the “SUBROUTINE ED_InputSolve” of the “FAST_Solver” module, right after the aerodynamic loads output from AeroDyn are mapped to ElastoDyn inputs via the “Transfer_Line2_to_Point” function (ending at line 236 of FAST_Solver.f90 from the v3.1.0 that was recently tagged in the GitHub repo). The code I added is as follows:

! For each node of each blade:
! - Write the forces/moments in the hub coordinate system
! - Set to 0 the components along the hub Y and Z axes  (I need only the thrust and shaft torque)
! - Rewrite everything back to the global coordinate system
invHubOrient = TRANSPOSE(y_ed%HUBPTMOTION%ORIENTATION(:,:,1))
DO K = 1,SIZE(u_ED%BladePtLoads,1)             
   DO J = 1,SIZE(u_ED%BladePtLoads(K)%Force,2)
      tmp = matmul( y_ed%HUBPTMOTION%ORIENTATION(:,:,1), u_ED%BladePtLoads(K)%Force(:,J) )
      tmp(2) = 0.0_ReKi
      tmp(3) = 0.0_ReKi
      u_ED%BladePtLoads(K)%Force(:,J) = matmul( invHubOrient, tmp )
                
      tmp = matmul( y_ed%HUBPTMOTION%ORIENTATION(:,:,1), u_ED%BladePtLoads(K)%Moment(:,J) )
      tmp(2) = 0.0_ReKi
      tmp(3) = 0.0_ReKi
      u_ED%BladePtLoads(K)%Moment(:,J) = matmul( invHubOrient, tmp )
   END DO
END DO

Best regards,

Dear @Lucas.Carmo,

It looks like your goal is to ignore all aerodynamic loads that do not contribute to the thrust or the torque along the shaft. I agree that your code change is doing that for the rotor thrust. However for rotor torque, the largest part of the torque is associated with lift and drag forces crossed with a moment arm equal to the radial vector from the shaft to the node. Your code change eliminates this contribution, keeping only the aerodynamic torque directly tied to local aerodynamic moments.

Best regards,

Dear @Jason.Jonkman,

Thanks a lot for your very FAST answer! I indeed completely overlooked the torque associated with the lift and drag forces. Since I intend to consider rigid blades, I think I can simply sum their contribution to u_ED%BladePtLoads(K)%Moment(:,J) right before the code from my previous post. I was thinking about something like:

DO K = 1,SIZE(u_ED%BladePtLoads,1)             
   DO J = 1,SIZE(u_ED%BladePtLoads(K)%Force,2)
      u_ED%BladePtLoads(K)%Moment(:,J) = u_ED%BladePtLoads(K)%Moment(:,J) + cross_product(lever, u_ED%BladePtLoads(K)%Force(:,J))
   END DO
END DO

where I am still trying to figure out how exactly the lever should be evaluated. Probably by the difference between u_ED%BladePtLoads(K)%Position(:,J) and the hub position, but perhaps this is already stored in some variable. Do you think that this approach would work?

Best regards,

Dear @Lucas.Carmo,

Well, ElastoDyn variable u_ED%BladePtLoads(K)%Moment(:,J) stores the applied aerodynamic point loads locally at each structural analysis node. These moments are all likely quite small (mostly just the aerodynamic pitching moment), which won’t contribute much to the torque (if at all). The contribution of the aerodynamic lift and drag to the torque happens globally. So, you shouldn’t add this contribution to u_ED%BladePtLoads(K)%Moment(:,J).

Best regards,

Dear @Jason.Jonkman,

I understand that this would be very problematic to evaluate the deformations of elastic blades, but I don’t get where is the problem in the case of rigid blades. The idea is to store the rotor torque due to the forces before setting them to zero (except for the thrust, of course) so that it could be used later in the equations of motion of the rotor. I am not very familiar with the code yet, but I thought that the torque was calculated as a combination of the forces crossed with their moment arm and the moment (per unit of length, I guess) at each node, even though they are indeed very small, so that (I thought) the total shaft torque would be preserved with this little workaround. Could you please help me to see what I am missing here?

Best regards,

Dear @Lucas.Carmo,

I agree with your description of how the torque should be obtained. If I understand correctly, you are OK with applying incorrect local aerodynamic loads if the final summation results in the correct total aerodynamic thrust and torque; is that correct?

But perhaps I’m missing the big picture here? Why do you want to zero out all but the aerodynamic thrust and torque? If all you want the aerodynamic applied rotor thrust and rotor torque, you can get these through the AeroDyn write outputs RtAeroFxh and RtAeroMxh; no change to the source code needed.

Best regards,

Dear @Jason.Jonkman,

Yes, my goal is to keep only the total aerodynamic thrust and torque. What we want is to have two different models to compare with the experiments: one with all the aerodynamic loads and blades elasticity, which would be closer to the real FOWT and would be run with the original OpenFAST, and one that would be closer to the experiments with a software-in-the-loop approach, which accounts only for the thrust and rotor torque, thus requiring some changes to the source code. This way we expect to isolate the effects that we are missing in the experiments with the SIL approach. Do you think that this makes sense?

Once again, thank you very much for your attention! This forum is extremely useful and I really appreciate the effort that the NREL team puts on maintaining it.

Dear @Lucas.Carmo,

OK, thanks for clarifying. That makes sense to me.

In that case, I agree with the change you proposed above where you set ElastoDyn variable u_ED%BladePtLoads(K)%Moment(:,J) based on the cross product of the moment arm and the applied forces, where the moment arm is computed based on the blade node position and hub position. For the later, I would add the blade node displacement field and hub displacement field to the position fields, respectively, in the calculation. (Even considering that the system is rigid, the rigid-body rotation of the rotor will generate a displacement of the blade nodes relative to the reference position.)

Best regards,

Dear @Jason.Jonkman,

Great, I will do that! Hope to have some results soon.

Best regards,