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,
Thanks for the feedback. I’m glad to hear that it worked for you!
I wonder if the frozen wake assumption has found its way into the to the latest FAST-Version v7.01.00a-bjj?
Nope, not yet. We plan to include that option in the AeroDyn overhaul we are currently working on.
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?
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.
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.
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).
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.
Linearization_Paul.zip (66.3 KB)
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.
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.
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.
Thanks for your answer. Yes, that helps a lot.
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.
Yes, the only input file change between FAST v6 and FAST v7 was the addition of input parameter OutFileFmt in FAST v7.02.
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.
I’m sorry, but I’m not sure I know how to respond to your question. What have you changed between the “Classic PID” and Gain-Scheduled PID" response curves?
I’m sorry if i didn’t make it enough clear. The difference is that PID clasic is the normal way of control and GS PID is a PID controller with a gain scheduling factor. What i tried to explain is that i realize they have the same behavior. In nrel.gov/docs/fy08osti/42437.pdf mentioned that GS PID should have almoust the same response for a wide range of step wind velocities.
Which is the correct approach for testing this controllers?
I hope this to be more clear than former question.
Yes, I would expect the effect of gain scheduling to be more prominent for conditions away from the operating point used to set the gains for the controller without gain scheduling. That said, the report you linked to is not a report I was involved in writing; you may want to contact the lead other (Alan Wright) for additional guidance (Alan does not regularly check this forum).
As always so helpful. Thanks a lot and i will try to contact Alan Wright inorder to solve this doubt.