I just started using FAST and would like to understand how to control the integrator. First I would like to know if the integrator used in FAST is a fixed step integrator?
If I plot results like rotor torque (RotTorq) I do notice that the result stays constant over a time longer then the selected integration time step (DT). In sections where the results change quite rapidly I do got visible stairs. I selected for DT = 0.001 and got for DecFact = 20. At my results I do got constant sections of t = 0.1s. I expected the sections not to be longer than my output step size of t = 0.02s. For DTAero I used the same value as for DT. I expected that the FAST integrator will do a defined step for every DT. But to me it looks like that the integrator got his own step control. Is there something what I can do to control the integrator precision or do I use the simulation control somehow wrong?
Thank you in advance.
FAST uses a constant-time-step integrator. I’m not sure I understand what your concerns are about things staying constant. To best see what is happening, set DecFact to 1 so you see every step.
DTAero should be an integer multiple of DT. A rule of thumb I use is that I like to have at least 200 time steps per revolution. If your turbine is variable speed, I’d use the fastest likely rotor speed to compute that.
I also recommend you start at some large time step and do runs with smaller and smaller time steps until the answers quit changing appreciably. Of course, this number you get will depend on the case you run. For instance, you will need smaller time steps higher wind speeds if you have a variable-speed turbine. As you enable/disable degrees of freedom, this will also have an impact on the choice of time step.
There is no way to control integrator precision.
To add to what Marshall said, FAST uses a 4th order Adams-Bashforth-Adams-Moulton predictor-corrector fixed-step integrator. This integrator is initialized over the first few steps with a 4th order Runga-Kutta integrator. Marshall gave a good rule-of-thumb for choosing the aerodynamic time step. When choosing the structural step, a good rule-of-thumb is that the time step (input DT) should be set less than or equal to one over ten times the highest full system natural frequency. That is, in equation form:
DT <= 1 / ( 10 * <highest full system natural frequency in Hz )
The full system natural frequencies can be found by running a FAST linearization analysis (AnalMode = 2) about the initial conditions. See the Linearization chapter of the FAST User’s Guide for more information.
There are several reaons why one could see long periods of time with no change in output:
*The solution could be in equilibrium.
*A controller could be defining output discretely.
*The response could be changing with smaller precision than the precision used for output (FAST input parameter OutFmt).
I hope that helps.
Hello Marshall and Jason,
Thank you for your quick response and the detailed information regarding to the integrator
and how to estimate a valid step time to run a wind turbine model with FAST.
So far I didn’t spend much attention to the FAST input parameter OutFmt.
I just used the standard value given by an FAST example not aware of the meaning of that parameter.
I just can recommend the following site
to study the right use of the input parameter OutFmt.
I messed up my selected integrator precision with a smaller output precision.
Thanks for your help.
I recommend using “ES” instead of “E” as “E” wastes a character of output on a “0”. You can get an extra digit of precision with the same field width.
I am interested, in using Discrete Time step, solver for FAST simulation studies.
Hence want to modify the integrator used in S_Function of FAST from continuous one to discrete one.
Does anyone has tried that before ?.
Thanks In advance for your reply and valuable inputs!
Thanks & Rgerads
In Simulink, the FAST S-Function simply sets up the equations of motion for the aero-elastic wind turbine system (generalized F=ma), calculates the accelerations (a), and relies on Simulink to do the time integration. I’m sure there is way to set this up in discrete form instead of continuous form, but I have never tried it myself. Perhaps someone else following this topic can offer advice.
I am conducting some research using FAST and I am interested in the characteristics of the solver. I see that FAST uses a 4th order fixed time-step solver, what are the advantages of this compared to a variable step solver? Does the AeroDyn module use another solver for the aerodynamics side of things? Other aerodynamics codes I have used (mostly CFD) use variable step methods in their solvers for stability reasons. I cant seem to find much information on the AeroDyn solver and its development, any information or help would be much appreciated.
Thank you in advance
The systems of differential equations of motion in both FAST (for the structural dynamics) and AeroDyn (for the generalized dynamic wake, GDW) are integrated using a 4th order Adams-Bashforth-Adams-Moulton (ABAM) predictor-corrector fixed-step-size multi-step integrator. The integrator in FAST is initialized over the first few steps with a 4th order Runga-Kutta integrator. In AeroDyn, BEM solutions over the first few steps are used to initialize the further integration of the GDW solution. AeroDyn’s dynamic stall model also has an integrator, but the solution is implemented with indicial response functions. More information on AeroDyn’s solution process is described in the AeroDyn Theory Manual: wind.nrel.gov/designcodes/simula … Theory.pdf.
The ABAM integration method has the advantage that it is explict (as opposed to implicit), converges, is stable, and is of high order. It is numerically appropriate for the system of equations that are being solved in FAST with AeroDyn. I have not heard of a case where the FAST with AeroDyn solution was poor due to the integrator (except as a result of a poor choice in time step, which is typically easy to identify because the code crashes).
That said, we’d like to look at alternative integration methods, including variable-step methods, in the future. Where this may have the biggest advantage in computational speed is on small turbines that have a very large range in rotor speed (larger time steps can be used when the rotor speed and system natural frequencies are smaller).
I am trying to interface electrical model of grid+generator+converter to “mechanical model/s-function” using simulink Interface. The electrical system requires mimimum time step of 0.0001seconds, while mechanical subsystem requires mimium time step of 0.0050 seconds. In view of this, I am trying to introduce the rate transition block between electrical system and mechanical system (S-function block). When I carry out this excercise, I get an error message. One option is to simulate the system at time step of 0.0001 seconds but it reduces the speed of simulation drasticly. Any easy way out ?, Looking forward for your views.
Thanks & Regards
I have no experience doing what your trying to do, so, I’ll let someone else answer your question.
However, I am curious as to what error message you are getting. Can you post the message in a response?
I have worked a little bit with FAST / Simulink. I am by no means an expert on either but as Jason mentioned in his post, knowing the error message would help. It would also help if you can post a snapshot of your implementation of the Rate Transition. Have you tried using the Automatic Rate Transition feature of Simulink? Without knowing anything about your model, its hard to say if this would work or if it did whether it would have any adverse effects on the results. You may have already looked at it, but in case you have not, Matlab does have a pretty good explanation in its Real-Time Workshop Help file about “Handling Rate Transitions”. Hope this helps.
First of all sorry for delayed reply (I was out of station).
Also thank you for your replies, I checked all options and based on the observations and error rectification process followed by me, it seems
I have no option but to use time step of 5e-5 seconds, with solver : Fixed step , Rk-4th order. The model developed allows me to check the effect of grid contingencies such as LVRT or single phase fault on the gearbox. This model requires power system blockset on top of existing basic building blocks of simulink.Right now I am in the process of enabling electrical system trip settings, If you are interested in the model please let me know I can send you across the simulink file along with m file.
my e-mail id is : firstname.lastname@example.org.
Thanks & Regards
Can anyone please send me the file “Eigenanalysis.m”, which is reported on page 43 of FAST user’s guide. I am requesting this file because I could not able to locate it in the folder CertTest, which I downloaded recently from website (may be problem with my archive).
Thanks & Regards
I think they no longer supply the “Eigenanalysis.m”. Please refer to the addendum to fast users guide that was published with the new release http://wind.nrel.gov/designcodes/simulators/aerodyn//March312010UpdatesAndNewAeroDynInterface.pdf, page 6.
I’d like to follow up on Rupert’s question about variable time-stepping to get clarification on the following:
Does the ABAM explicit integrator used in FAST insist that a fixed time-step be used?
In other words, is it possible (through modification to the source code) to change the time step of AeroDyn (or other modules for that matter) during a simulation and still expect a valid solution?
Thanks in advance,
Please note that Rupert’s question (and my answer) applied to FAST v7, which was the version of FAST available at the time. The time-integration in FAST v8 differs a lot.
In FAST v8, each module with continuous states has its own time-integrator. The ElastoDyn module allows for explicit RK4, AB4, and ABM4; the BeamDyn modules uses an implicit generalized-alpha, etc. None of the modules currently use a variable time-step integrator, but this is certainly something that could be added in the future. One difficulty in this may be that the FAST driver (glue) code calls all modules at the same fixed (glue-code) time step. Currently, FAST allows modules to have time steps be integer time-step divisors of the glue-code time step, but does not allow for modules to have time steps (for time-integration) larger than the glue-code time step.
I can see it would be a difficulty with respect to ensuring that all FAST modules are called at the same glue code time step.
Apart from this though, do you think that if I were to increase or decrease the time step of the AeroDyn standalone driver mid-simulation I would still expect a valid solution? Or does the theory behind the AeroDyn integrator forbid changing the time step in this way?
The unsteady airfoil aerodynamics model of AeroDyn v15 employs a discrete-time update, which requires a fixed time step. There are no other integrators in AeroDyn presently, so, I would think a time-varying time step would be OK when unsteady airfoil aerodynamics are disabled.