Dear,
I am interested in modifying the openfast source code in a way such that I can control rotor tilt. From one of the legacy FAST versions I found out that rotor furl is the more general way to achieve this.
What I have tried so far is modifying UserRFrl in ED_UserSubs.f90. Here, the reaction furl moment can be calculated as desired. Indeed, when doing this simulations do respond differently depending on the reaction moment.
That being said, I can’t seem to modify the DOF_Flag(DOF_RFrl) during runtime. This would be ideal as it can then mimic a lock such as described in the subroutine description of UserRFrl and a controller can be implemented for furling. Is it possible to do this? Aren’t the solution matrices predefined at the beginning of the simulation?
As an alternative, I would also like to be able to prescribe a furl sequence as one can do with the yaw angle. However, as far as I understand, yaw is managed from ServoDyn, while Furl is not. How, and where in the code should I modify or overwrite the rotor furl angle and velocity? For now, this would be sufficient for my needs. If I want, I can write subroutines to control this angle in a somewhat more elegant fashion.
Summarized:
- How to turn of
DOF_Flag(DOF_RFrl) from UserRFrl?
- Where to modify/overwrite
RotFurlP and RotFurlV during simulations?
Dear @Luc.vanBeek,
The rotor-furl DOF and the SUBROUTINE UserRFrl() of ElastoDyn is available again in the current version of OpenFAST (v3.5.4). However, in OpenFAST, DOF_Flag is a parameter that cannot be changed at runtime. While RotFurlP and RotFurlV are not set through an input file, you could implement logic to calculate the reaction moment for the rotor-furl DOF in within SUBROUTINE UserRFrl() similar to what is implemented to calculate the reaction yaw moment in the user-specified yaw controller. That is, within SUBROUTINE UserRFrl(), you could use something like:
RFrlMom = - p%RFrlSpr * ( RFrlDef - RotFurlP ) - p%RFrlDmp * ( RFrlRate - RotFurlV )
where RotFurlP and RotFurlV define your desired displacement and velocity of the rotor-furl DOF.
Best regards,
Dear @Jason.Jonkman,
Thank you for coming back to me.
What I don’t like about this approach is that one needs to define a furl spring- and damper constant and I am not sure if this approach will give me the control to say that at t=t1 -> RotFurlP =X1, RotFurlV=Y1 and at another time t=t2-> RotFurlP =X2, RotFurlV=Y2. Moreover, my design does not have a physical spring nor damper for furl and the furl is controlled by an actuator. Thus, I interpret the spring and damper constants as parameters in the controller of the actuator.
I envision a method more direct such as overwriting RotFurlP, RotFurlV after the matrix inversion which yields position and velocities in Kane’s equations. As such, I can simulate prescribed motion which allows me to focus on the resulting loads given that motion rather than having to focus on tuning the spring and damper constants. So,
- Do you agree that your proposal does not fully meet my needs?
- What is the appropriate location in the code to do this?
I must say that at this point I am mostly interested in what happens in the LSShaft.
Dear @Luc.vanBeek,
While I agree that the use of a rotor-furl spring and damper will introduce some oscillations in the response relative to the desired response prescribed through RotFurlP and RotFurlV, I would think you’d be able to match the prescribed response reasonably closely through proper choices of the spring and damper. I would generally recommend deriving the damper based on a damping ratio that is 60-70% of critical damping. And the higher the stiffness, the more closely the response will follow the prescribed motion, although using too high of stiffness may require you to drop the simulation time step (DT).
FYI: Given that rotor-furl is a DOF of the model, overriding the position and velocity rather than using the values derived through the equations of motion (by integrating acceleration) would not lead to a physically consistent solution.
Best regards,