Dear all,
I am simulating the NREL 5MW onshore turbine using OLAF. The windspeed is set to 9m/s and the TSR to 7.5. As observed in an earlier (topic, the OLAF simulation reaches Cp = 0.538 at t=30, which I set as Tmax. I have used the recommended settings that were calculated by the Python function.
My next step was to study the effect of yaw. So, I changed nothing but NacYaw, which is located in the ElastoDyn input file. The resulting Cp surprised me; Of course, it is still decreasing, but I do not expect it to go underneath 0.6 if the simulation would have been extended. That being said, it is always above the Cp for the axial flow case.
I deem this unrealistic, thus I am wondering if I overlooked as specific setting that is required for the calculation of a yawed rotor.
For the sake of completeness and ease of discussion I will list the changes I have made with respect to the baseline. Convention used is Setting: baseline setting/changed setting:
5MW_Land_BD_Linear.fst
Tmax: 5/30
DT: 0.0015/0.01
CompElast: 2/1
CompInflow: 0/1
CompAero: 0/2
BDBldFile(1,2,3): …/5MW_Baseline/NRELOffshrBsline5MW_BeamDyn.dat/unused
InflowFile: unused/5MW_Baseline\NRELOffshrBsline5MW_InflowWind_Steady8mps.dat
AeroFile: unused/5MW_Land_BD_Linear\NRELOffshrBsline5MW_Onshore_AeroDyn15.dat
ServoFile: NRELOffshrBsline5MW_Onshore_ServoDyn.dat/unused
Linearize: True/False.
That being said, and possibly even off-topic, I noticed that a 30s simulation takes about 20 minutes on my device. What are the most time consuming subroutines? If it is the wake-wake velocity induction, would it be an idea to use the GPU for that?
Best,
Luc
Dear Luc,
The CP is indeed too high, though the simualtion is not converged. As a first step, set up your simulation according to the following guidelines:
4.2.2.3. Working with OLAF — OpenFAST v3.5.1 documentation
It will also tell you how long the transients are expected to be.
The wake-wake velocity calculation is indeed the most time consuming. OLAF is use a tree-algorithm to speed up the calculation (VelocityMethod=2), and OpenMP parallelization, make sure you use these options to get the most out of it. OLAF also uses a combination of free and frozen wake, which reduces the computational time (make sure you use OpenFAST v3.5.1 to have these features).
Improvements of the tree code, to be more of a fast-multiple method, would be a good option to speed things up further. GPU as well. Another hack can consist in removing vortex elements in the wake (“vortex surgery”).
I hope you results and computational time will improve! Let us know how it goes,
Emmanuel
Dear Emmanuel,
The image I have posted used all the recommended settings, except the total simulation time to reach transient. Nevertheless, I doubt whether this would drop the Cp from 0.65, where it is currently, to the order of 0.4 which is what I expect for the yawed turbine. Simply put, the slope of the Cp curve does not give me that confidence.
For that matter, I also simulated the UAE Phase VI rotor. Again, for axial inflow the results match with literature but when I add yaw, the Cp is significantly higher than for the non-yawed case.
Either I am missing something in the input files (but I do not know what) or there is some bug in the code? Do you by any chance have a full set-up for a yawed rotor including all files such as OLAF, InflowWind, Elastodyn etc… ?
Best,
Luc
Thank you for precising. You might want to compute the power coefficient yourself to make sure you have full control of the area and wind speed used to make the quantity non dimensional. I’m guessing that’s where the issue comes from.
Otehrewise, you can use WrVTK=2 in your OLAF input file, and check that the wake looks phyiscal. If not, maybe you need to adjust the regularization and corespred eddy viscosity. But I’m leaning towards an issue of normalization.
I hope that helps,
Emmanuel
Hi Emmanuel, indeed the issue was the normalization. When using the output “RtAeroPwr” and dividing by the usual yields a power coefficient much more in line with what I would expect.
Thank you,
Luc