Dear NREL,
We’ve coupled our structural solver to OpenFAST 3.5.3. We are getting good agreement for the main outputs like rotor speed, blade pitch, generator torque, generator power etc.
We are in the process of upgrading to OpenFAST 4.1.2, and are not yet getting close agreement. For a low wind speed e.g. 3m/s steady wind, blade pitch and rotor speed are in agreement. But we are seeing a divergence in generator torque which is leading to a difference in generator power. Based on investigations, we believe the discrepancies may be stemming from the wind speed estimates within the ServoDyn/ROSCO controller (ROSCO v 2.9.0).
Note: This is for IEA-15-240-RWT-UMaineSemi at 3 m/s steady wind speed. Base is fixed - no Hydro or MoorDyn effects
See below for comparisons of wind speed estimates (WE_Vw parameter) for both old and new versions.
Could you advise on:
-
What parameters are used to compute the wind speed estimates?
-
What parameters should the structural solver pass to ServoDyn/AeroDyn in order for the wind speed estimates to be more consistent between the structural solver running OpenFAST, and OpenFAST running on its own?
Kind regards,
Ashok
Hi Ashok,
The wind speed estimate is determined using the blade pitch, generator torque, and rotor speed.
If the above signals are in agreement, the wind speed estimator should also be in agreement. The structural solver primarily needs to pass the rotor speed into ServoDyn for the wind speed estimate to work properly.
Best, Dan
Hi @Daniel.Zalkind ,
Thanks for the reply.
So, wind speed estimate is dependent on generator torque and not the other way ?
As shown below our blade pitch and rotor speed are in agreement with FAST 4.1.2, but generator torque shoots up at 310 sec.
Rotor thrust
But the wind speed and blade pitch are in good agreement
Also this difference is more prominent in lower wind speed - below rated
When the controller I/O parameters are plotted (avrSWAP array)
These are the parameters that show significant variation
Record 15: Measured electrical power output (W) [SrvD calculation from previous step; should technically be a state]
Record 23: Measured generator torque (Nm) [SrvD calculation from previous step; should technically be a state]
Record 24: Measured yaw error (rad) [SrvD input]
Record 37: Nacelle yaw angle from North (rad)
Yaw error could be ignored as it’s in the range of e-5. We tried with yaw fixed to see if the jitter is causing any issue - but with not effect. Other parameters in the avrSWAP array don’t show much difference.
When the ROSCO debug parameters are plotted we see the difference here
which correspond to
WE_Vm - Mean wind speed component in WSE [m/s]
WE_Vt - Turbulent wind speed component in WSE [m/s]
WE_Vw - Estimated wind speed in WSE [m/s]
WE_lambda - TSR in WSE [rad]
I am unable to understand what is triggering this behavior at lower wind speeds.
PS: One final observation. The wind speed estimate computed by our solver coupled with FAST 3.5.3 (which gives the correct torque and power) is about 1.4m/s at steady state. The wind speed estimate computed by our solver coupled with FAST 4.1.2 (which gives the incorrect torque and power) is about 3.4m/s at steady state. Given that the actual wind speed applied to the model is a constant 3.0m/s, I would expect the wind speed estimate to be close to this value, so if anything the new model should be more accurate. I apologise for so many questions, I am a bit puzzled by the program behaviour.
Thanks,
Ashok
Yes, the torque determines the wind speed estimate, and the wind speed estimate determines the torque. Since there is a filter in the loop, the dynamic effects are acceptable.
Since your rotor speed is the same, and your generator torque is much less, I would guess that your aerodynamic torque is also much less, so I would check that in your solver.
Best, Dan
This is the aerodynamic torque comparison.
Hi @Daniel.Zalkind ,
Thanks for your replies.
The issue is with the Aerodyn input file.
Even when the “Wake_Mod = 1”, OpenFAST is taking DBEMT_Mod into consideration
We had Wake_Mod = 1 and DBEMT_Mod = 2 (not intentional) - but this was affecting the results at low wind speed
When I corrected the DBEMT_Mod = 0 - the results match for our solver coupled with FAST 3.5.3 and FAST 4.1.2
I think it would be better if Aerodyn ignored DBEMT_Mod when Wake_Mod = 1, which is consistent with FAST 3.5.5.
Thanks,
Ashok
Dear @Ashok.Jammi,
As of AeroDyn within OpenFAST v4, we decided that it was much clearer if we introduced the DBEMT_Mod options as a subset of Wake_Mod = 1, given that the various DBEMT options all use BEM. The changes between AeroDyn in OpenFAST v4 and earlier are documented here: 4.1.2. API changes between versions — OpenFAST v4.1.2 documentation.
Best regards,
