Old v7 simulink model to new v8 difficulties

All,

I am doing research on controls systems to limit vibrations, we have been building simulink models for a few years and have a lot of work put into it. We have a couple models that were made with v7 of FAST on what I believe was a 32-bit matlab program. Now that we are updating everything(we already updated the .fst and .dat files) we are trying to get the .mdl file to run and produce the same results as we get on the earlier version. I have made a couple of necessary adjustments, such as changing out the FAST function block, and redefining the variables we pick from the OutList.
We have been able to get the same results for our no gain and low gain Torque controller, but when we try our high one it goes unstable every time. I have tried reducing the timestep, and that gave us a little more stability, and also tried every integration method in simulink and found out Euler is best for stability. Even with these measures I was only able to get the gain up to 30 whereas in the v7 model it was 100.
My question is- Is there anything I need to look for that might be causing this? I read the readme file and I don’t think any of those changes between 7 and 8 apply to me.
Thanks

Hi, Justin.

Have you tried using a different extrapolation order in FAST? I have seen a couple of models where linear interpolation/extrapolation (InterpOrder=1) gives good results when quadratic interpolation/extrapolation (InterpOrder=2) goes unstable.

You may also want to see if adding a correction step (NumCrctn=1) in FAST helps with the stability problem.

Bonnie,
Thank you very much for your suggestions. I had really high hopes because I remember when converting .fst files v7 to v8 InterpOrder was one thing that had changed. However, I tried all the combinations between InterpOrder and NumCrctn, and none of them helped the stability noticeably. Can you think of any other reason it would be doing that?

Dear Justin,

The “Modeling Tips” section of the FAST v8 ReadMe file offers some general steps for solving numerical stability problems: wind.nrel.gov/nwtc/docs/README_FAST8.pdf. It sounds like you’ve already tried some of these steps.

The biggest change between the FAST v7 and v8 interfaces to Simulink is related to how the structural states are integrated. In FAST v7, Simulink integrated FAST’s structural states; in v8, FAST integrates the structural states and Simulink only integrates the states outside of the FAST block. I’m not sure if this is the cause of the numerical instabilities of your model, but I would suggest that you simplify the model (e.g. disable modules and eliminate DOFs) to isolate the problem.

Best regards,

Ok, I’ll be sure to give that a try. One question we had that may be related is about the updateairfoils.m file. Do we have to run that? If so, do we have to run that before or after the convertFAST7to8 file? Could that cause instability?
Thanks

The updated airfoil files are only if you are converting from AeroDyn v13 or v14 to AeroDyn v15. If you use AeroDyn v14 in FAST v8, you don’t need to run the updateairfoils.m conversion script. Unfortunately, I don’t think that is the cause of the instability you are seeing.

Bonnie,

The previous messages were about a 5 MW model and we are continuing to work on it, we also have a 750 kw model. We successfully converted all the files (we think) and have it running in simulink, however we are getting different results. The biggest difference is that in the old version we have a disturbance and we see the shaft oscillate for about ~10-15 seconds while decaying, and in the new version it only oscillates for about 6 seconds. I have checked all the parameters I could and it doesn’t seem like anything is different (I looked especially at damping ratio).
The differences between the old and new model, besides the obvious FAST function block change, are in the old version we were running it with a v6 fast file, and in matlab 2013b: and in the new one it is a FAST v8 file and matlab 2016b. I think the versions of aerodyn are compatible though. Since we have been having different dynamics with both of the turbines, that makes me think something changed with one of the programs in how it computes things. I know you have mentioned that FAST 8 integrates stuff with simulink and v7 integrates stuff with matlab (or vice versa) is there any other possibilities of change? Also, could you explain how the differing integration methods of simulink vs. matlab affect the model?

Thanks

Dear Justin,

The different integration schemes between Simulink in FAST v7 and internal to FAST for FAST v8 should not cause significant differences in the response.

To isolate the problem, I suggest that you compare the responses from your FAST v6 model to your upgraded FAST v8 using the standalone executables (uncoupled from Simulink). I would expect minimal differences between these responses if the models have been converted from FAST v6 to FAST v8 properly, unless you are enabling features of FAST v8 that were previously unavailable in FAST v6.

Best regards,

Jason,

When you say use the “standalone executables”, what exactly do you mean? We can try to run it without simulink, instead using visual studio.

“standalone executable” refers to the .exe file produced when you compile the full FAST code (e.g., FAST_Win32.exe or FAST_x64.exe, which were compiled with the FAST_Prog.f90 driver program in Visual Studio). For comparison, when your run Simulink, it uses a different driver, which calls the FAST_Library DLL (compiled with FAST_Library.f90 instead) .

Jason’s just trying to isolate the problem to know if your basic model get converted properly, without possible differences from MATLAB and/or your controller in the mix.

Jonkmans,

We have done what you said, using the standalone executables run through the command prompt for both of our own models. Good news/bad news they both matched when comparing RotTorq and GenTq, we thought these to be the most relevant, do you think we should look at any other variables in particular? This must mean our conversions went through but also that there is a problem with simulink/matlab/the compiler. Our 750 kw turbine has a gearbox, transmission line, and generator modeled all in simulink, so there are definitely some areas for complication. Can you tell me which variables/parameters are the most important to look at when using and having complications with these items? I am really struggling to figure this out.
Thanks

Dear Justin,

For the comparison of the results using the standalone executables, I would scan through a variety of outputs including deflections and loads–just to see if the overall response is correct. If this is the case, it would appear that the FAST v6 was converted to FAST v8 properly and the problem is likely in your Simulink model. I’m not sure I can offer much advice on that, but in these situations, I would always try to simplify different parts of the model to debug.

Best regards,

We have two questions. This first deals with trying to get matching simulation results between a
FAST V7 turbine model and a V8 model of the same turbine. We can send you the files
involved in each model if you would like us to do that. The main difference between the two
responses is that oscillations in the LSS torque damp faster in V8 compared to V7 under the
same excitation. We checked that the DrTrDOF was false in both models. In the simulations,
the two responses are very close with the only difference being the rate of decay of torsional
oscillations.
The second question involves the conversion of the ipt file for the same model. The V7 turbine
model includes tower shadow which is specified according to the AeroDyn v13 Addendum.
When converting this file to V8, the ipt file will not convert correctly. When attempting to
execute the V8 model, errors in the ipt file prevent execution. Where there were 4 lines in the
V7 ipt file to specify the tower shadow, there are only 3 lines in the corresponding V8 ipt file.
The original 4 lines are:

NEWTOWER TwrShad -INSTEAD OF 0.0 TwrShad- Tower-shadow velocity deficit (-)
True TwrPotent- Calculate tower potential flow (flag) INSTEAD OF 9999.9
False TwrShadow- Calculate tower shadow (flag) INSTEAD OF 9999.9
"AeroDyn_Tower.dat" TwrFile - Tower drag file name (quoted string)

The 3 lines in the new ipt file appear to be the AeroDyn v12 description of the tower shadow
effect. The three lines are:

NEWTOWER" TwrShad - Tower-shadow velocity deficit (-)
9999.9 ShadHWid - Tower-shadow half width (m)
9999.9 T_Shad_Refpt - Tower-shadow reference point (m)

In order to get the V8 simulation working, I copied the 5 lines of the document “Using the New
Tower Feature of AeroDyn 14” and pasting these in place of the 3 lines provided by the V7 to
V8 conversion. The five lines are:

NEWTOWER TwrShad - “NEWTOWER" to request the new tower model.
True TwrPotent - Calculate tower potential flow (flag)
False TwrShadow - Calculate tower shadow (flag)
"AeroDyn_Tower.dat" TwrFile - AeroDyn tower file name (quoted string)
True CalcTwrAero - Calculate aerodynamic drag of the tower at the ElastoDyn nodes.

This produced a simulation that executed to completion. However, the damping was incorrect as
specified above. Also, the results were unchanged if CalcTwrAero was specified as False.
Your help on this will be greatly appreciated.

Wouldn’t you know, We’ve been working on this for days and the day after we ask, we’re able to get it working. We no longer need help with the matching simulation question, although our answer does bring questions, and we still can’t figure out the aerodyn conversion file.
In version 8 we were able to get matching results by messing with integrators until we got one that worked. For the same model, we started using ode23t and a timestep of .0025 I think, and when I switched integrators in simulink, I tried about 5 others. These went unstable: ode113, ode45, ode4 for timesteps that I had now shrunk to .0005s, however, the ones that did work were: ode23t, ode15s, and ode23tb, which was the one that gave us the correct results for this model, as well as the other model we were trying to match.
Why was there such a discrepancy between integrators? Does it have to do with how “stiff” they are? For future problems are we to just guess at integrators until we find one that we like?
Also for reference, I tried ode23t with the timestep of .0005s to see if it was just the timestep that needed to be changed, but that didn’t change the incorrect result from the larger timestep, a change of integrators was, in fact, needed.
Thanks