Hallo all!
How I can get out (without modifying the FAST code) the relation between the generator torque/power and the actual pitch angle which are used to track the gain of PI-controller.
The idea was to linearize the model on several wind speeds to get different transfer functions, for these working points. An deflection from the working point causes a generator torque deflection. I know the angle defection and the torque deflection so it should be possible to calculate the sensitivity deltaTq/deltaAlpha as like as in 5MW Wind Turbine for Offshore (38060.pdf).
It didn’t work. When i do this my sensitivity function is not monotonically decreasing.
Anyone have an idea how I can calculate this sensitivity function thrue a simulation with FAST?
THX
Harald
Dear Harold,
I generated Table 7-1 from NREL/TP-38060 one wind speed at a time. Here are the main inputs that need to be set different from a time-domain simulation:
*Set AnalMode = 2 in the primary input file.
*Set PCMode = 0 in the primary input file.
*Set BlPitch(K) in the primary input file to the proper pitch angle associated with each wind speed for all blades (K=1,2,3). I.e., set BlPitch to 23.47deg at 25m/s.
*Disable all DOFs except YawDOF in the primary input file.
*Add “RotPwr” to OutList in the primary input file. “RotPwr” is the mechanical output power of the rotor.
*Set StallMod = STEADY in the AeroDyn input file.
*Use a steady, uniform, no-shear, hub-height wind input file in AeroDyn for each desired wind speed from rated to cut-out.
*Set CalcSteady = False in the linearization input file.
*Set NInputs = 1 in the linearization input file.
*Set CntrlInpt = 4 (i.e., collective blade pitch) in the linearization input file.
*Run FAST and–from the .lin linearization output file–record the value of the D-Trnsmt matrix associated with the “RotPwr” output and the collective blade pitch control input. This is dP/dTheta.
These changes should all be clear from the FAST User’s Guide, except maybe the 4th item, where all DOFs are disabled except YawDOF. The reason for this is that “RotPwr” depends not only the applied aerodynamic torque, but also on the acceleration/deceleration of the system DOFs, such as the rotor inertia of the generator DOF. To prevent this dependency from messing up the D-Trnsmt matrix, I chose to disable all DOFs except one DOF (YawDOF) that is not influenced by collective blade pitch perturbations. (You cannot linearize a model without at least one DOF enabled.)
Also note, however, that I computed dP/dTheta using a customized version of FAST. The customized version employs a frozen wake assumption during linearization. The standard version of FAST, found on the website, does not assume a frozen wake during linearization. (Instead, the standard version recalculates the wake for each perturbation.) The frozen wake assumption is more accurate when linearizing just above rated wind speed; it has less of an impact at higher wind speeds.
Best regards,
Hello Jason!
I am also having some trouble calculating and replicating the values in Table 7-1 from NREL/TP-38060 for the blade pitch control PI-gain scheduling values. Just to be absolutely certain about using the correct simulation files and initial parameter options, I downloaded a fresh copy of the NREL 5MW Onshore turbine model from your public domain (wind.nrel.gov/public/jjonkman/) and did exactly the changes as described above.
I ran the linearization of the 5MW model but the dP/dTheta values from the linearization output file (.lin) had an almost constant offset to the values in Table 7-1 from NREL/TP-38060 (see picture below). From my linearization simulation results I got the following values:
- [dP/dTheta (Theta=0deg)] = -1.78E+6 watt7rad (similar 38060 value = -25.52E+6 watt/rad)
- Theta,k = 0,406 deg (similar 38060 value = 6,302336 deg)
I am using FAST v7.00.00a and I am not using the frozen wake assumption. How big of a difference does the frozen wake assumption make to the dP/dTheta values compared to not having it? Or am I doing something else wrong?
Thanks for your help already!
Ville
Dear Ville,
I didn’t save the results I generated without frozen wake, but I recall them looking very much like what you are showing in your plot. So, I suspect that you are doing everything correct–just without frozen wake.
I’ve put an executable of FAST v6.01 with AeroDyn v12.58 modified to apply frozen wake during linearization here: wind.nrel.gov/public/jjonkman/FA … zation.exe. Please note that the frozen wake in this executable is only applied to the DOF states, the rotor-collective blade pitch angle input, and the horizontal hub-height wind speed disturbance. If you need the frozen wake applied to other inputs or disturbances, the source code will not to be modified and the executable recompiled. Let me know if you need to do that.
We plan to add the frozen wake linearization feature as a built-in option in a future version of FAST with AeroDyn.
Best regards,
Hi Jason,
and thanks for your quick reply! I ran the linerization simulations again with the executable you provided above and I got the same results as in Table 7-1 from NREL/TP-38060! So the frozen wake assumption actually makes quite some difference to the output dP/DTheta values after all.
If the frozen wake is not used for assigning the PI-controller gain-scheduling values, the systems actually starts vibrating. Using the [dP/dTheta (Theta=0deg)] and Theta,k values I got above (from linearization analysis without frozen wake), calculating new PI-controller gain values Kp and Ki with formulas 7-18, 7-19 and 7-20 in NREL/TP-38060 document, generating a new DISCON.dll file and simulating with a step response wind from 13 mps to 14 mps with time marching FAST simulation, the generator rpm and blade 1 pitch angles look quite violent 
Thank you Jason and frozen wake,
Ville
Hi Ville,
Thanks for the feedback. I’m glad to hear that it worked for you!
Best regards,
Dear Jason,
I wonder if the frozen wake assumption has found its way into the to the latest FAST-Version v7.01.00a-bjj?
Best regards
Tim
Dear Tim,
Nope, not yet. We plan to include that option in the AeroDyn overhaul we are currently working on.
Best regards,
Hello Jason,
I try to use “executable of FAST v6.01 with AeroDyn v12.58 modified to apply frozen wake during linearization” however I cannot find any input files for this version of software. When I try to do linearization with input files from version 7 it yields the following response: “Invalid numerical input … The error occured while trying to read TStart.”
Is it possible to download somewhere input files for this appropriate version?
Or maybe it is possible to perform it with the newest version of FAST?
Regards,
Sebastian Dziomdziora
Dear Sebastian,
The FAST input files were not changed between FAST v6.01 and FAST v7.01, so you should be able to use the FAST v7.01 input files for the NREL 5-MW turbine available from here: wind.nrel.gov/public/jjonkman/NR … .00-v7.01/.
The FAST v6.01 version you found is the currently the only version NREL has released with the feature for linearizing with frozen wake.
Best regards,
Hello all,
like Harald and Ville I currently also try to calculate and replicate the values in Table 7-1 from NREL/TP-38060 for the blade pitch control PI-gain scheduling values. However in contrast to them I am using FASTv8.16 and have some troubles with the necessary linearization.
Let me first explain what I have done so far:
With the settings mentioned in Jasons and Bonnies TORQUE2016 paper I did three different simulations ((i), (ii), (iii)) based on the input files of the NREL 5MW onshore turbine distributed with the FAST archive. All simulations are done with constant rated wind speed (11.4 m/s) and 0° blade-pitch angle. The differences are in the linearization parameters:
(i) without linearization (Linearize = False in Primary Input File)
(ii) with linearization at t = 0sec (Linearize = True; NLinTime = 1; LinTimes = 0 in Primary Input File)
(iii) with linearization at t = 1sec (Linearize = True; NLinTime = 1; LinTimes = 1 in Primary Input File)
My questions are as follows:
-
When looking at the first few time steps of the time-marching result of (i), I wondered to see some start-up transients in RotPwr (see Fig. 1).
I didn’t expect them, as in the above mentioned paper it is said “As the turbine is modeled rigidly and the only states in the FAST v8 model are of the constraint type, there are no start-up transients and the periodic steady-state solution is calculated immediately”
Do you have an idea what’s the reason for the transients I see?
-
Then I had a look into the time-marching result for simulation (ii), where I saw a steady-state rotor power of nearly 10MW (see Fig. 2).
As this steady-state rotor power is double the rated power, this isn’t really reasonable, isn’t it? Furthermore I was wondering why the steady-state rotor power changes so drastically in contrast to simulation (i) where it is nearly 5.5 MW.
To investigate this problem further I did simulation (iii) and saw that I still have the start-up transients (as in (i) and (ii)), but now the steady-state rotor power reaches again the more reasonable value of 5.5 MW (as in (i)) - see Fig. 3.
Consequently I think doing a linearization (at least when done at t=0 sec) has some influence on the time-marching solution. Is that an expected and desired behaviour? However it could also be possible, that I did or understand something wrong.
I would be glad if you could help me in this issues.
Kind regards,
Paul Schünemann
Dear Paul,
I’m not sure I understand what the issue(s) may be, but I’m a bit surprised by your results. A few comments:
(1) Because of the way FAST initialized, there may be zeros or a moderate spike in the FAST output at time zero, perhaps two time steps, but I don’t know why you are seeing spikes over the first four time steps.
(2) Because of (1), I would normally set LinTimes to be slightly greater than zero to avoid any potential problems right at zero even if I wasn’t expecting start-up transients.
(3) Adding linearization output to FAST v8 should have no influence on the time-series output, as the former does not influence the latter. I would expect no change in the time series from your simulations (i) through (iii).
Best regards,
Dear Jason,
Thank you very much for your quick reply. From reading your comments I think you have a really good understanding of my issues.
Initialisation processes could be a good reason for the zeros/spikes at time zero. I thought about that, too.
Unfortunatly, I also have no idea why there are spikes over the first four time steps.
When you wrote your TORQUE2016 paper, have you had a look at RotPwr and could you remember any spikes?
Concerning your comment (3):
In accordance with you, I would also expect no change in the time series from simulations (i) through (iii). So I was really surprised by the results of (ii), too. However in my opinion the strange results of (ii) must be related to the linearization because the only difference between simulation (ii) and (iii) is in LinTimes (0 vs. 1). All other parameters are the same for both simulations.
For further investigations on that problem I attached a zip-Archive containing my FAST input files for simulations (ii) and (iii). Maybe you (or someone else) can run it and have a look, if he or she can reproduce my results.
I would be very grateful for any further help concerning my problems.
Best regards,
Paul Schünemann
Linearization_Paul.zip (66.3 KB)
Dear Paul,
I debugged your model a bit and confirmed the issues you are reporting. It turns out there is a bug in FAST v8.16 whenever linearization is invoked with FrozenWake enabled – that is, the solution is not correct after the first linearization. Thanks for reporting this issue!
I asked Bonnie Jonkman (who originally implemented this section of code) to look into the problem, and fortunately, the bug was easy to fix. Bonnie has committed this change to the version of FAST on gitub; however, this version has other features that we have not yet been released. You can correct FAST v8.16 by changing only a few lines of code and recompiling. See the following link for the lines that must be changed: github.com/NWTC/AeroDyn/commit/ … diff=split.
Sorry for the troubles.
Best regards,
Dear Jason,
thank you very much for taking the time to debug my model. It’s great to have such a good support here.
Furthermore I’m a bit relieved that I didn’t waste your time with something caused by my misunderstanding oder wrong usage of FAST.
Concerning the gain sheduling problem, do you think it could be a workaround to apply your comment (2) from your Fri Dec 09 post to get the aerodynamic derivatives even with the bugged FAST version? I think you did it in the same way for your Torque 2016 paper and as shown there you got quite good results. Furthermore I think that could be working because when the static equlibrium is reached (due to my plots after approx. 5 time steps) there should be no big difference between using and not using frozen wake. What do you think about that?
What is more there arose some other questions when I looked to the results again:
a) As I did all simulations mentioned in my first post at rated wind speed and with blade-pitch angle = 0° I expected to get rated mechanical power which is 5.296610 MW according to the definition of the NREL 5MW reference turbine (at least in simulation (i) where the bug you reported has no influence). However from my results (as shown in my first post) I get a mechanical power of RotPwr = 5.513 MW.
Do you have an idea what’s the reason for that discrepancy? Is RotPwr the mechanical power or do I look at the wrong output?
b) Does there exist an output parameter in FAST to get the electrical power output of the wind turbine? What’s his name and in which module do I find it?
c) In section 3.2 of your Torque 2016 paper it is said, that the “only states in the FAST v8 model are of the constraint type”, but my .lin files say:
Number of continuous states: 0
Number of discrete states: 0
[b]Number of constraint states: 0[/b]
Number of inputs: 9
Number of outputs: 12
Jacobians included in this file? No
So it seems to be that I don’t have any states not even constraint ones. Is that an expected output of the linearization? (Maybe that’s an easy question, but I’m not yet really deep in the linearization topic.)
Again I would be very grateful for any further help.
Kind regards,
Paul Schünemann
Dear Paul,
Without correcting the bug, you should get accurate linearization results with frozen wake using FAST v8.16 if you (1) linearize after time zero and (2) linearize only once. In our paper, we did (1), but not (2), i.e. we linearized at multiple times. So, our results are influenced by the bug, but as you note, the results were not affected enough to identify the bug.
Here are my answers to your other questions:
a) The RotPwr output of the ElastoDyn module is the mechanical power of the rotor. I expect that you won’t get 5.296610 MW as that result was derived from a model with a flexible rotor and with a version of FAST that is much older (there are some differences between versions, especially in the aerodynamics of AeroDyn v15, and the model discretization has changed a bit).
b) Yes, the GenPwr output of the ServoDyn module reports the electrical power output of the generator.
c) The information at the top of the linearization output files only reports the information contained within the file. You can see the actual constraint states and associated Jacobians if you output the associated module-level information (LinOutJac = True, LinOutMod = True).
I hope that helps.
Best regards,
Dear Jason,
Thanks for your answer. Yes, that helps a lot.
Best regards,
Paul Schünemann
I know it’s an old thread and Sebastian probably finished his thesis a long time ago… But I wanted to reproduce NREL results and ran into the exact same problem.
I solved it by removing the line
1 OutFileFmt - Format for tabular (time-marching) output file(s) (1: text file [<RootName>.out], 2: binary file [<RootName>.outb], 3: both) (switch)
in file NRELOffshrBsline5MW_Onshore.fst. I presume the field OutFileFmt was introduced with v7 and v6 couldn’t make any sense of it.
HTH
Tobi
Dear Tobias,
Yes, the only input file change between FAST v6 and FAST v7 was the addition of input parameter OutFileFmt in FAST v7.02.
Best regards,
Dear Jonkman,
I’ve been working on the PID Gains Scheduling control design for the WindPact 1.5 MW wind turbine. Following the procedure published on nrel.gov/docs/fy08osti/42437.pdf page 32, i built a clásic PID controller and a Gain Scheduling PID controller. As per this document, it should be a difference for several step wind response between the clásic and gain scheduling. Please find below the graphics for each case.
Once explained the situation i have several questions:
- Did i follow correctly the procedure?
- Am i missing something on the diagram?
- Should be there any difference between the graphics?
thanks in advance and regards.
