Hi,
Recently I’ve been trying to work with FAST on Simulink and I’m having some critical issues.
As far as it seems, on Simulink FAST is working like [outputs, qdotdot] = FAST_SFunc(q, qdot, inputs) where q is wind turbine states; and inputs are generator torque, yaw and blade pitch. The problem is, under some circumstances, this FAST_SFunc(…) doesn’t give a constant output given a constant (q, qdot, inputs). qdotdot varies over first 2 timesteps of the simulation, and then it settles. The conditions under which this behavior occurs are:
- When the simulation is being run for the first time on a instance of MATLAB.
- Consistent with the first condition, when ‘clear FAST_SFunc’ is called anytime. Or simply ‘clear all’ and ‘clear functions’ do the same thing, which are quite common.
What I deduct from this is FAST_SFunc has some internal states other than the turbine states q and qdot. Can you tell me what are those internal states?
I’ve been running into a bunch of problems like 2 consecutive same turbine simulations not resulting same outputs and some others; but this is the fundamental odd behavior. I discovered this while trying to have FAST linearized model and FAST nonlinear model match for small perturbations about trim conditions, probably I’ll post something about that in a few days too. I’m attaching 2 screenshots for the qdotdot output and the Simulink model that I’m using. If you need more information, code or file please just let me know.
Thanks in advance,
Hi Ahmet,
Your understanding of how FAST in Simulink is working is correct, except that the simulation time is also an input to the FAST_SFunc (even though it is not directly passed into the block). That is, [outputs, qdotdot] = FAST_SFunc(time,q,qdot,inputs).
The FAST_SFunc does have internal variables that are saved between calls–mostly in the AeroDyn routines; perhaps also in user-defined routines that have been enabled. Is CalcAero enabled in your test model? To identify the exact problem in this case, I’d have to play around with your model. If you’re still having problems, e-mail the model to me.
Best regards,
Hi Jason,
I’ve tried to e-mail you but it seems the e-mail address that I got from NREL Research Staff webpage is outdated or wrong. I’ll attach the file here.
The model that I’m using is basicly the model from CertTest folder, test 14, slightly modified. The modifications that I remember are:
-Enabled CompAero
-Disabled YawDOF
-Changed Gravity value
-Changed DTTorDmp, drivetrain torsional damping constant
The matlab file that I included(problem1.m) to reproduce the problem and the simulink model should be pretty self-explanatory. You might need to change folders in the .fst and .ipt files, other than that running matlab script should be enough.
Also there is a second problem that can be kind of related to having internal states again I believe, I’m including another matlab file to reproduce that problem too(problem2.m). I explained the problem in the beginning of that file as comments in that file, I’m copy/pasting it:
The problem is FAST not working as expected when ‘clear FAST_SFunc’ isn’t called before simulation. Here how it goes:
-Calling ‘clear FAST_SFunc’ to have a clear start
-Running the simulation, stopping it let’s say at 50sec.
-Not calling ‘clear FAST_SFunc’
-Loading back the fist initial conditions before the first simulation, running simulation, but for a longer time to see problem in detail, let’s say 100sec.
-Now in this simulation system shows a weird behavior for he first 50s, and just after that it starts doing what it’s expected to do, slowing down rapidly, pretty much matching the first simulation
If you try calling ‘clear FAST_SFunc’ just before the second simulation, everything runs smoothly, system behaves normal.
Kind regards,
Arda
FAST_Test_Arda.rar (30.7 KB)
Hi Arda,
I’ve finally had a chance to look at your model a bit. Sorry for the delay.
We discovered the root of the two problems. Both problems are related to the logic in AeroDyn.
In problem 1, the problem is that the BEM (EQUIL) iteration needs time to converge over the first few time steps (the number of steps will depend on the value of ATOL).
In problem 2, AeroDyn keeps track of the previous time AeroDyn was called to determine if it needs to calculate aerodynamic forces. (AeroDyn needs to do this to prevent problems with its own internal time integrator.) So, when you run the model the 2nd time (without clearing the S-Function), AeroDyn does not compute new aerodynamic loads until after 50 seconds (the last time it has in memory).
The FAST S-Function was not designed to be run multiple times without clearing it in between runs. We’ve tried to put in logic to “catch” users from doing this, but you managed to find a way around our logic 
. We will be a bit more clever in our next release of FAST to prevent users from doing this in the future.
With regards to my e-mail address, the address is correct on the staff webpage. I suspect our firewall blocked the e-mail due the attachment.
Best regards,
