Dear Jason,
I am not forcing a slow roll, the only conditions I have enforced are constant pitch (90°) and constant yaw (0°).
I think that for this yaw condition the equilibrium is set by a constant and slow rotation, is it possible?
This would explain the periodic oscillations in all the quantities (expecially the flapwise deflection).
I tried to generate the same plot for a longer simulation time (1000s) and they are pretty much the same (see figure below).
Maybe there is something wrong in the way I fix the yaw angle. I do it by imposing an override value of 0° from time 0 in the ServoDyn file (figure below). Is it right?
Thanks a lot,
Regards,
Matteo
Dear Matteo,
That way of setting the yaw angle is fine. Even simpler you can set TYamManS > TMax and set YawNeut to the desired yaw angle.
What have you set for generator torque? Again, I see a negative rotor speed and negative torque, which presumably is leading to the low frequency flapwise deflection.
Best regards,
Dear Jason,
For the generator torque, I am using the following setup in the ServoDyn file.
So the generator should be turned off for the entire simulation. Am I imposing something wrong?
Anyway, I don’t get why the torque assumes an almost constant value (equal to -0.36).
Best regards,
Matteo
Dear Matteo,
OK, I would guess that the negative generator torque is coming from the trim solution itself, TrimCase = 2. Presumably you want to find a steady-state solution with zero generator torque and zero (or close to zero) rotor speed; is that correct? In this case, I would keep your ServoDyn settings unchanged, but set TrimCase = 3. This will ensure that the generator torque is zero and the blade-pitch angle will be adjusted (but this may be slightly different than 90 degrees) to get the desired value rotor speed.
Best regards,
Dear Jason,
that’s exactly what I am trying to get, a steady-state solution with almost zero rotor speed.
I have tried to change the TrimCase from 2 to 3 but the solution I get is exactly the same. Isn’t the TrimCase used to decide which variable to monitor to check if the solution has reached a steady-state? Hence, the solution shouldn’t be influenced by this setting.
As before, the generator torque is equal to -0.36 and the blade pitch is kept constant at 90°.
I really cannot understand why this isn’t a steady-state solution if the rotor speed is constant. It seems the same condition that occurs in power production when computing the Campbell diagram by linearizing around a constant rotor speed value.
I report here the settings I am using for the linearization, but they seem fine to me.
Best regards,
Matteo
Dear Matteo,
What value of RotSpeed are you trying to achieve; i.e., what is the value of RotSpeed set within ElastoDyn?
Yes, the setting of TrimCase should result in changes to the generator torque (TrimCase = 2) or changes to the blade pitch (TrimCase = 3).
I don’t really understand how you can be getting a nonzero generator torque with TrimCase = 3 and TimGenOn > TMax. Can you share your full ServoDyn input file? Also, what output are you using to plot the generator torque?
Best regards,
Dear Jason,
I figured out that I was addressing to the wrong ServoDyn file.
Now the generator torque is fine and equal to 0 for the entire simulation, while the rotor speed assumes value different from 0 just from the first time-step of the simulation. If I use TrimCase = 2 or 3 I still get the same exact solution (zero generator torque and 90° pitch for the entire simulation). Anyway, a steady-state solution cannot be found.
The value of RotSpeed is equal to 0 in the ElastoDyn file.
Maybe the problem is related to the fact that the yaw angle is not kept constant even if I force a 0 value in the ServoDyn file.
I attach here some of the input files, so you can have a look.
I also attach the new plot of the interesting quantities for the latest simulation with the correct ServoDyn file.
Thanks for your time.
Best regards,
Matteo
Input Files:
mediafire.com/folder/4mr3gk … InputFiles
Dear Matteo,
OK, your solution makes more sense to me now.
Looking back at the theory behind this trim solution, I can see why a steady state solution is not reached in your case. The situation where RotSpeed = 0 is a special case, whereby OpenFAST will disable trim (regardless of the setting of TrimCase) and set NLinTimes = 1. In your situation, a blade pitch of 90 degrees is producing a small amount of aerodynamic torque, which keeps the rotor speed slightly away from zero, and because trim has been disabled, a steady state solution is never found.
You can solve this issue a few different ways:
- Disable CalcSteady and linearize at a specific simulation time (or times) instead (after you feel the solution is sufficiently converged;
- Set RotSpeed to a small but nonzero value and use TrimCase = 3; given the low rotor speed, it may take a long time for the trim solution to reach a steady state, but I suspect that OpenFAST would find it eventually;
- Manually run simulations at a range of blade pitch angles near 90 degrees to find out which one results in zero rotor speed.
Best regards,
Dear Jason,
Thank you very much for your help!
I am now trying to disable CalcSteady and linearize when the solution seems at steady-state.
Then the linearized solution will be used in the Campbell toolbox you provided me, and this should give reliable results on modal damping, right?
In any case there will be a non-zero rotational speed (even if small) so the transformation in MBC should be ok, right?
Furthermore, I was wondering if you can hint me if this is the procedure you have followed to obtain the results described in the paper that I have mentioned some days ago. Maybe you already have an implemented procedure to use to perform the same computation with iced blades and compare the results.
Best regards,
Matteo
Dear Matteo,
Yes, that approach sounds correct.
I don’t recall the approach we used in that paper; Gunjit Bir did most of the analysis for that one.
I have not performed a modal analysis for a wind turbine with iced blades.
Best regards,
Dear Jason,
I have been trying to proceed with the computation without CalcSteady, as you have suggested.
I have used different yaw angles and something strange happens for some of them. Oscillations appears both in the azimuth position (which can be correct) and yaw position (which instead should be fixed by the settings in the ServoDyn file). I attach here an example for yaw angle = -40°.
In these cases, a steady-state solution is never achieved, so the linearization and the subsequent MBC procedure give meaningless results. Do you have any guess on why such oscillations in the yaw position are introduced?
Moreover, I noticed that for some yaw position, the steady state solution is at zero rotational speed (hence constant azimuth angle). In these conditions, is the MBC procedure implemented in the “Campbell toolbox” giving reasonable results? If not, how can I compute the modal damping in such conditions?
Best regards,
Matteo
Dear Matteo,
At certain yaw errors in the idling condition, a known blade-edgewise instability exists, e.g., as discussed in the following forum topic: Designing for yaw errors using FAST - #7 by Jason.Jonkman. When the model is physically unstable, a steady-state solution cannot be reached without adding damping damping to the system during the steady-state solve (e.g., via Bld_Kdmp) or following the other suggestions in the linked forum topic. Alternatively, you could linearize at time zero (before the unstable solution results in excessive motion) to quantify the eigensolution approximately (I say, “approximately”, because the linear model is not fully representative of the underlying dynamics if the system is not in steady state before linearizing).
Yes, the MBC procedure and Campbell toolbox can work for cases where you only output the linearization at one azimuth angle because the rotor speed is zero.
Best regards,
Dear Jason,
thanks for your fast reply!
Regarding the MBC applied to simulations with zero rotor speed, the frequencies and modal damping I get from the campbell toolbox always refers to “regressive”, “progressive”, “collective” modes? How can I interpret these modes if the rotor is not moving?
Best regards,
Matteo
Dear Matteo,
You can think of the “collective” mode as all blades moving in phase and “regressive” and “progressive” as asymmetric modes. Alternatively, when the rotor speed is zero, you could avoid applying MBC3, and instead, compute the eigensolution directly on the raw A matrix. Then, you’ll see the distinct contribution from each blade separately.
Best regards,
Dear Jason,
if I automatically apply the MBC transformation (so I have comparable results for different values of yaw angle), is there any way of recovering the contribution of each blade from the three rotor modes (collective, regressive and progressive)?
Best regards,
Matteo
Dear Matteo,
Well, applying the inverse MBC3 transform returns back the solution with independent blades. You can also use the mode shape visualization functionality of OpenFAST to visualize the independent blade contributions to each mode. Also, in the state-space matrices, you can include contributions from the independent blades in the output (y) vector.
Best regards,