Hi everyone,
I am working on the linearization of the DTU10 MW model for the gain scheduled control. We did the following steps, but can not reproduce the oscillation of rotational frame responses (e.g. the blade root bending moment in X).
 Linearized at a number of the wind speed/pitch angle operating point with the blade 1st flapwide, tower 1st foreaft, generator DOFs activated.
 At each operating point, we linearize the model at different azimuth angles.
 ‘fc_mbc’ function to read the ‘*lin’ files
4）Select the MBC_avgA/B/C/D with the generator angle DOF removed;
 Use the gainscheduled procedure to reproduce the OpenFAST simulation;
I understand that after the MBC, the ABCD has been transformed into the nonrotating frame. Is this means we only need to make the inverse mapping to the originally rotating output channels? Or there are some other correct solutions.
In addition, I had additional questions for the linearization:
 For the latest OpenFAST, does the ‘NAzimStep’ still be available? Or other alternatives other than specifying the linearization time moments.
 The FAST v8 seems to use only several seconds for linearization, but the OpenFAST needs several minutes for a single linearization process. I am wondering this is due to the change in OpenFAST code or some other factors?
Thank you!
Dear Xiangping,
Yes, I agree with your process, and yes, you’d need to apply the inverse MBC transform to obtain outputs back in the rotating frame of reference.
Here are my answers to your direct questions:
 In OpenFAST, NLinTimes replaces NAzimStep. When calculating a steadystate periodic operating point before linearization (CalcSteady = True), LinTimes is ignored, and instead, the periodicity is found and linearization is performed based on azimuth angles in (360 deg)/NLinTImes steps.
 I would not expect the linearization process itself to take more time in OpenFAST than FAST v8 for a model of similar setup (in terms of number of states, inputs, outputs, and analysis nodes) (or did you mean FAST v7?). The new steadystate periodic solve was introduced in OpenFAST (and does not exist in FAST v8), which may take some time to solve.
Best regards,
Dear Jason,
Thank you for your reply to the direct questions.
Also, for the linearization and MBC, I have two detailed questions:

I understand we need the inverse MBC to go back to the rotating frame. We use the gain scheduled procedure to reproduce the fast simulation using a series of linearized models at multiple wind velocity/pitch angle operating points. If I do the inverse MBC to the linearized model response, it’s just a small perturbation around the OP and after adding the OP, the oscillation is pretty small. I may take some wrong operation here. DO you have some suggestions on how to do this correctly?

The MBC is designed for taking the dynamics of three blades as a whole to the nacelle or tower. In this way, if we only want to reduce the FAST responses (both on rotating and nonrotating), do we need to do the MBC and inverse MBC? Or we can use the windspeed/pitchangle/rotorazimuth as the OP for linearization and schedule the model based on these three parameters?
Thank you again!
Dear Xianping,
I’m sorry, but I don’t really understand your questions.
Best regards,
Dear Jason,
Sorry about that. Thank you for your patience. I try to explain them in detail here.
 We linearized the model at 23 input operating points (23 combinations of wind speed (V_op), generator torque (T_op), and pitch angle (Beta_op)) based on the working regions of the DTU 10 MW model. At each operating point, we got 11 A/B/C/D on different rotor Azimuth angles and after the MBC, we have the MBC.avgA/B/C/D. Using the 23 MBC.avgA/B/C/D, we use the wind speed (v), generator torque (T), and pitch angle (Beta) as the inputs (U) and do interp(V_op, P_schedule,v) using current v, where P_schedule is the interpolated data for A/B/C/D and operating point data, i.e., As, Bs, Cs, Ds, X_ops, U_ops, and Y_ops. Using these scheduled model (As, Bs, Cs, and Ds) and updated parameters, we do the simulation in Simulink using X_dot=AsX+Bs(UU_ops); Y_delta=CsX+Ds(UU_ops). Then, we use the Y_ops+inverse_MBC(Y_delta) as the output. This generates a pretty smaller oscillation than the FAST simulation.
I may take some wrong operation here. Do you have some suggestions on how to do this correctly?
 Can we use the 23 11 statespace models (A/B/C/D) from the FAST directly for the Simulink simulation? The A/B/C/D and operating points in this way is interpolated using the wind speed and azimuth angle. Then, do the simulation: [i]X_dot=AsX+Bs*(UU_ops); Y_delta=CsX+Ds(UU_ops)[/i] and then, also Y_ops+Y_delta.
I hope this can clarify my questions. Thank you!
Dear Xianping,
OK, thanks for clarifying. I now understand what you are doing. Just a few comments:
 Normally simulations are run separately about a given mean wind speed. So, I’m not sure I understand why you are interpolating the state matrices or operating points based on wind speed. Instead, I would expect that, for example, you’d use the matrices and operating points derived from 16 m/s for turbulent wind input with a mean wind speed of 16 m/s. I’d be concerned that interpolating the state matrices means that your linear system is no longer time invariant and the timeintegration of linear states, which represent the perturbation of states about the operating point, is not correct (e.g., you never use X_ops).
 Presumably you need the azimuth angle to calculate inverse_MBC(), but you’ve eliminated the azimuth state from the linear model. Are you tracking the azimuth angle separately (just for the purpose of calculating inverse_MBC()) by timeintegrating the generator speed operating point plus generator speed perturbation? Again, I would think this would only work if you the generator speed operating point is fixed for a given simulation.
 I would think you’d apply MBC to each of the 23*11 state matrices and operating point values and azimuthaverage these to result in 23 separate state matrices and operating point values.
Best regards,
Dear Jason,
Thank you for your insights.

We try to get a fully linearized model. The aim is to use the model to evaluate the power generation and fatigue efficiently for the controller tuning. Surely, your suggestion is good and convenient to operate at a specific operating point each time.

Yes, in this way, the generator speed needs to be used to integrate the azimuth angle. Since the OP is also interpolated, tracking the generator speed output (interpolated OP + perturbation estimated by statespace model) may be feasible.

We will try this.
Thank you again, and we will try different ideas. After that, I will give the feedback here.