Dear all
I am a beginner and currently encounter some issues while using software. If anyone can answer them, I would be grateful.
I have previously run some numerical examples using FASTv7.02.00, running TEST07 to analyze a steady wind of 12 mps. I have analyzed RootFxb3, RootFyb3, RootFzb3, and RotPwr at the root of the blade, and obtained some very regular images. As shown in the figure below, the values are periodically vibrating.
Recently, I tried to use the latest version of openfast 3.4.1 to perform the same analysis, but the results were significantly different. The fluctuation amplitude of the data was significantly reduced, and the data was not changing periodically.
(1)work condition 1
12mps steady wind yaw=0 pitch=0 Other parameters remain unchanged
(2)work condition 2
12mps steady wind yaw=30 (YAWDOF=FALSE) pitch=0 Other parameters remain unchanged
The difference between RootFyb3 and RootFzb3 is very small (no image is given), and the difference between RootFxb3 and RotPwr is too large (as shown in the figure above)
Why does this difference occur? Which software should prevail.
Dear @Lin.Ding,
FAST v7 is no longer used or really supported by NREL. I would only use FAST v7 if you have some strong reason to–such as you need to match results from an older study. For new users, I would recommend starting with the newest release of OpenFAST.
It is hard to comment on your OpenFAST results without knowing more about your simulation set up (structural degrees of freedom enabled, aerodynamic options enabled, control options enabled, etc.). You also have blank y-axes on some of the plots, which makes them difficult to interpret.
Best regards,
Thank you very much for your reply!
There was a bug in my drawing , so I uploaded the drawing again.
At the same time, I upload the OPENFAST input file for Condition 2 (except for the yaw angle, the other settings are the same for Condition 1 and Condition 2)
Why does OPENFAST data vibrate so violently compared to the results obtained by FAST.
(1)work condition 1 12mps steady wind yaw=0 pitch=0
(2)work condition 2 12mps steady wind yaw=30 pitch=0
The following is a link to my input file
https://s30.aconvert.com/convert/p3r68-cdx67/ar5au-5qoom.html
https://s30.aconvert.com/convert/p3r68-cdx67/ak3u6-kim3t.html
https://s30.aconvert.com/convert/p3r68-cdx67/aajv2-edxor.html
https://s30.aconvert.com/convert/p3r68-cdx67/aa73l-1rcnv.html
https://s30.aconvert.com/convert/p3r68-cdx67/avjok-xsniq.html
Dear @Lin.Ding,
It is hard for me to guess why there are spikes showing up in your RootFxb3 and RotPwr outputs from OpenFAST without knowing more about your simulation set up. And the links to your input files appear to be broken, so, I can’t review your files.
Best regards,
Sorry, I didn’t notice the timeliness of the link. I attached a link to github
Best regards,
Dear @Lin.Ding,
Looking briefly at your files, I notice the following:
- I would guess the spikes are the result of a very narrow tower shadow in this downwind rotor model; you could check this by disabling the tower shadow by setting
TwrShadow = 0 in the AeroDyn v15 input file.
- I would guess the spikes are showing up irregularly because the output time step is much coarser than the actual simulation time step; you could check this by setting
DT_Out = DT = 0.005 s in the OpenFAST primary (.fst) input file.
- It looks like you have blade and tower bending degrees of freedom enabled in ElastoDyn; you could check their contribution to the response by disabling these DOFs in ElastoDyn.
- It looks like you have unsteady aerofoil aerodynamics enabled in AeroDyn; you could check this influence by setting
AFAeroMod = 1 in AeroDyn v15.
Best regards,
Dear Jason.Jonkman
Thank you for your response. I set AFAeroMod=1 in AeroDyn v15. The data oscillates regularly. Does this mean that the unsteady airfoil aerodynamic model cannot be used for TEST07?
Best regards,
Dear @Lin.Ding,
It has been many years since I looked at this test of the AOC 15/50 turbine and I don’t recall how the unsteady airfoil aerodynamics parameters for this model were set and if adjustments are needed. Did you play around with the other items from my prior post (TwrShadow, DT_Out, ElastoDyn DOFs) and decide that only the AFAeroMod = 2 is causing issues?
Is there a particularly reason you want to simulate the AOC 15/50, or would other example wind turbine models provided by NREL meet your needs?
Best regards,
Dear @Jason.Jonkman
The data will not oscillate unless AFAeroMod=1 is set. Other settings do not smooth the data. Other wind turbine models can meet my simulation requirements.
Best regards
Dear @Lin.Ding,
I think you meant to type “the data will not oscillate unless AFAeroMod = 2 is set”; correct?
I’m not sure what you mean when you say “other settings do not smooth the data.”
You mention that “other wind turbine models can meet [your] simulation requirements”; can you clarify what type of model you need? Would the more widely used NREL 5-MW baseline wind turbine or IEA Wind 15-MW reference wind turbine meet your needs? If so, I suggest switching to one of those models.
Best regards,
Dear @Jason.Jonkman
the data will not oscillate unless AFAeroMod= 2 is set.
NREL 5-MW baseline wind turbine can meet your needs.
Best regards,
1 Like
Dear @Jason.Jonkman
Now I am doing a model-based analysis and I have some problems with the selection of wind documents. In the inflowwindow module, I set windtype=2 and call NoShr_ 12.wnd wind documentation. But running OpenFAST results in an inability to read the wind file. Why and how do you solve this problem?
Best regards，
Dear @Lin.Ding,
You’ve only received a warning, not an error, and your simulation completed as expected.
As of OpenFAST v2.5 and newer, the upflow angle was added as an optional ninth column in the uniform wind file in the following pull request: InflowWind Updates by bjonkman · Pull Request #578 · OpenFAST/openfast · GitHub. Not including this column will assume the upflow angle is zero, as stated in the warning message.
Best regards,
Dear @Jason.Jonkman
Thank you for your reply, I mistakenly thought inflow = 0. Now I know what is going on.
Best regards,
Dear @Jason.Jonkman
I want to study the effect of different pitch angles (e.g. pitch angle =-8 degrees) on the load performance of wind turbine blades based on TEST18. So I set a constant wind of 11.4 m/s, set BlPitch=-8 degrees in the ElastoDyn module, set PCMode=0 BlPitchF=-8 degrees in the ServoDyn module, and run OpenFAST with a lot of error messages. Why was it okay to run TEST07 this way before?
Best regards,
Dear @Lin.Ding,
I have not run your specific test case, but the NREL 5-MW baseline wind turbine (from Test18) has much more flexible blades than the AOC-15/50 wind turbine (from Test07). I’m not surprised that running off-design conditions can result in issues such as a tower strike.
Best regards,
Dear @Jason.Jonkman
I’m sorry for replying to your message so late. May I ask how I can reasonably solve this problem. My current research goal is to analyze the load on blades at different blade pitch angles under rated wind speed. However, due to program errors, I am unable to obtain relevant data for analysis.
Best regards，
Dear @Lin.Ding,
What do you mean by “solving [the] problem”? Do you mean redesigning the rotor so that a tower strike is avoided under off-design conditions? Or do you simply what to avoid triggering an error when a tower strike occurs? For the later, you could eliminate the tower aerodynamics in AeroDyn, in which case AeroDyn will not check the tower-strike condition and will prevent the tower-strike error.
Best regards,
Dear @Jason.Jonkman
What I mean is to avoid the tower strike. I set TwrPotential=0 in AeroDyn, and tower strike errors can be avoided, but some warning messages were reported.I uploaded the input file on Github
Best regards，
Dear @Lin.Ding,
This warning has been discussed many times on this forum. Again, you are simulating an off-design situation, so, I’m not surprised you are running into trouble. In this case, OpenFAST may not be producing realistic responses because the loading is so severe that unrealistically large blade deflections are obtained and ElastoDyn is not set up to support such large deflections.
Best regards,
