Processing OpenFast linearization output

[Srinivasa.Ramisetti]

Dear Jason,

Thanks for the information. In fact, I did tried several things like a) using TMax and DT values similar to the pull373 branch input parameters used in 5MW land mode shapes case. With TMax=5600 and Dt=0.001 the simulation runtime is long. Except for the results of the 1st tower FA, all other values do not match with previous results (please see the attachment for the figure). Furthermore, simulations for some rotor speeds have aborted (see below for the output from openfast with the fatal error). I tried to rerun the aborted cases to double-check if there is any problem. I think the simulation aborts at the last timestep when the linearization has started as the steady state solution is not found. b) I have seen here in the forum that researchers used previous versions of fast with larger timestep like 0.0125s and smaller simulation time of 240s to get the right results. However, if I use DT>0.002 I see convergence errors and simulation aborts without reaching the linearization step c) I have also tried using the dev branch to see if I get any better results with simulation time like 1000s and Dt = 0.001 but the simulation aborted at after ~620s with a fatal error. In all these cases I was using CompElast and CompServo flags ON. Why is this difference between openfast and previous fast versions? Could you please suggest any reasonable values that can work for generating the Campbell diagram with the OpenFast dev branch?

2. Yes, I was initially using only the Matlab script to automatically generate the Campbell diagram without copying data from MBC3 output. But since I was not seeing the correct results, I started using the excel sheet manually copying the MBC3 output to cross-check.

3. Regarding the NLinTimes and Lintimes. In all cases except 0 rpm when NLinTimes=1, Is it right the runcampbell script does some averaging to produce the Campbell diagram?

OpenFAST-v2.3.0-223-g862d753d
Compile Info:
- Compiler: GCC version 7.1.0
- Architecture: 64 bit
- Precision: double
- Date: May 19 2020
- Time: 10:03:26
Execution Info:
- Date: 06/24/2020
- Time: 09:11:15+0530

OpenFAST input file heading:
FAST Certification Test #18: NREL 5.0 MW Baseline Wind Turbine (Onshore)

Running ElastoDyn.
AllBldNd section of ElastoDyn input file not found or improperly formatted. Therefore assuming no
nodal outputs. --> Premature EOF for file "./NRELOffshrBsline5MW_Onshore_ElastoDyn-4.dat"
occurred while trying to read BldNd_BladesOut.
Running ServoDyn.

FAST_InitializeAll:ED_Init:ED_SetParameters:AllBldNdOuts_ValidateInputData: Number of blades to
output data at all bladed nodes (BldNd_BladesOut) must be between 0 and 3.

Time: 0 of 5600 seconds.
Time: 3805 of 5600 seconds. Estimated final completion at 09:51:58.
Time: 5600 of 5600 seconds. Estimated final completion at 09:52:01.
Unable to find steady-state solution.

FAST encountered an error at simulation time 5600 of 5600 seconds.
Simulation error level: FATAL ERROR

Aborting OpenFAST.

CD-2.jpg (90.47 KiB) Viewed 1619 times

Regards
Srinivasa

[Jason.Jonkman]

Dear Srinivasa,

Here are my answers to your questions:

1. The use of BeamDyn generally requires a small time step; DT=0.001 s is what NREL decided was appropriate for a numerically converged solution. You won't be able to increase this without disabling model features (e.g., disabling degrees of freedom or reducing the order of the finite element in BeamDyn). Simulations using DT = 0.0125 s likely used ElastoDyn to model the blades, not BeamDyn. I'm not sure why you want to use BeamDyn instead of ElastoDyn to model the blades, but switching to ElastoDyn will speed up the simulations a lot. From your screenshot, it looks like perhaps you already switched to using BeamDyn?

Your results are looking OK for the tower mode; I also see the 1st blade flapwise collective, regressive, and progressive modes in your figures (although these are labeled incorrectly in your plot), which look correct up to 10 rpm. I would assume that the steady-state solution is not converged at the 12 and 14 rpm speeds, or perhaps the labels are not shown correctly at these speeds (you'll have to manually identify the modes at each speed).

3. Correct. The runCampbell.m script calls MBC3, which azimuth-averages the matrices after applying the Coleman transformation at each azimuth step and before performing the eigenanalysis.

Best regards,

[Srinivasa.Ramisetti]

Dear Jason,

Thanks for your clarification on the simulation time and the timestep. There was no particular reason to use BeamDyn. I started using the test case 5MW_Land_ModeShapes from pull373 branch where BeamDyn was used by default. I did not change it assuming the case was already tested based on the discussions in the forum. Yes, I did switch to ElastoDyn with TMax=10000s and DT=0.00625. However, some of my simulations (rotor speeds=8, 10 rpm) are still aborting with fatal error (Unable to find steady-state solution). I think TMax=10000 s is sufficient enough to reach steady state. I am unable to understand why the simulation fails for these two speeds. Do you think TMax should be further increased?

I think runCampbell script has also some issues identifying the modes correctly because it does not produce the same results as the manual approach to generate the Campbell excel sheet from the MBC3 output.

[Jason.Jonkman]

Dear Srinivasa,

Which sample OpenFAST model are you using (can you send me a link to the file on github)? The test I see uses ElastoDyn: https://github.com/OpenFAST/r-test/blob ... Shapes.fst.

I'm sure TMax = 10000 is more than sufficient to reach a periodic steady-state. What settings have you defiined in the "Linearization" section of the OpenFAST primary input file? You should be able to tell from looking at the time series if the solution is converging towards a steady state or not; what does the time series of the response look like?

The runCampbell.m does not identify the modes for you; it simply runs the many OpenFAST simulations, post-processes the linearization output files using MBC3, and gathers the data into the MS Excel spreadsheet. It is still up to the user to properly identify the modes.

Best regards,

[Srinivasa.Ramisetti]

Dear Jason,

I got the 5MW_Land_ModeShapes case files from links available at https://github.com/OpenFAST/openfast/pull/373. The link for the case file is https://github.com/bjonkman/r-test/blob ... ModeShapes. However, now I see the link is not working anymore. I think this could be due to some recent updates within OpenFAST github repositories.

I can see 5MW_Land_ModeShapes.fst available at https://github.com/OpenFAST/r-test/blob ... Shapes.fst and using ElastoDyn. Also, I did use this test case from the above link but I still get the error saying steady-solution not found. Maybe the code from pull request 373 has some issues running this test case for rotor speeds 8 and 10 rpm?

Please see attached the fast, elastodyn, and servodyn files that I used for 8 rpm rotor speed.

See below for the my settings in the "Linearization" section:
true Linearize - Linearization analysis (flag)
true CalcSteady - Calculate a steady-state periodic operating point before linearization? [unused if Linearize=False] (flag)
3 TrimCase - Controller parameter to be trimmed {1:yaw; 2:torque; 3:pitch} [used only if CalcSteady=True] (-)
0.0001 TrimTol - Tolerance for the rotational speed convergence [used only if CalcSteady=True] (-)
0.001 TrimGain - Proportional gain for the rotational speed error (>0) [used only if CalcSteady=True] (rad/(rad/s) for yaw or pitch; Nm/(rad/s) for torque)
0 Twr_Kdmp - Damping factor for the tower [used only if CalcSteady=True] (N/(m/s))
0 Bld_Kdmp - Damping factor for the blades [used only if CalcSteady=True] (N/(m/s))
36 NLinTimes - Number of times to linearize (-) [>=1] [unused if Linearize=False]
30, 60 LinTimes - List of times at which to linearize (s) [1 to NLinTimes] [used only when Linearize=True and CalcSteady=False]
1 LinInputs - Inputs included in linearization (switch) {0=none; 1=standard; 2=all module inputs (debug)} [unused if Linearize=False]
1 LinOutputs - Outputs included in linearization (switch) {0=none; 1=from OutList(s); 2=all module outputs (debug)} [unused if Linearize=False]
False LinOutJac - Include full Jacobians in linearization output (for debug) (flag) [unused if Linearize=False; used only if LinInputs=LinOutputs=2]
False LinOutMod - Write module-level linearization output files in addition to output for full system? (flag) [unused if Linearize=False]

ofiles.zip

(9.32 KiB) Downloaded 57 times

Thank you,
Srinivasa

[Jason.Jonkman]

Dear Srinivasa,

The "Linearization" section you included in your forum post differs from the "Linearization" section in your attached zip archive. Which one are you using?

TrimCase = 3 doesn't really function when you disable aerodynamics (because changing the blade-pitch in this case doesn't effect the torque), as it appears that you have in your attachment. TrimCase = 2 should still work, and settle out on zero torque for all speeds without aerodynamics. If you've done this, and it is still not converging, I would suggest plotting the time series to see what is going wrong.

Best regards,

[Srinivasa.Ramisetti]

Dear Jason,

Sorry for the confusion. At the moment I am using the linearization section present in the fast file in the attachment. The fast file in the zip file fails with the fatal error.

Please see attached the rotor speed time series for the first and last 1000s. I see that for the first 1000s the rotor speed is fluctuating around 8 and for time series between 1000-9000s it is fluctuating slightly above 8.005. In the last 1000s the rotor speed drops from 8.05 to 7.975.

ws-4.png (20.65 KiB) Viewed 1584 times

ws-4-last1000.png (14.68 KiB) Viewed 1584 times

Regards,
Srinivasa

[Jason.Jonkman]

Dear Srinivasa,

It appears that there is not enough damping in the system to reach a steady state and I'm not sure I understanding what is happening at 10000 s. Reducing TrimGain may help to reduce the oscillations. That said, the solution is likely sufficiently converged by 200 s, so you can probably stop it there (increasing TrimTol a bit). Without aerodynamics, it is likely also fine to disable the trim solution altogether (TrimCase = 0) and simply linearize after 200 s or so.

Best regards,

[Srinivasa.Ramisetti]

Dear Jason,

As you suggested I have tried with TMax=200s, TrimTol=0.01, TrimCase=2 (there is no option to set TrimCase=0), and TrimGain=100. This time the simulation for rotor speed=10rpm finished without any problem. But for the rotor speed=8rpm, I still keep getting the same problem. So I reduced the TrimGain to 80 and increased the TrimTol to 0.1. This time the simulation completes without any errors. However, I have to check if the linearization results with these settings are still reliable.

Regards,
Srinivasa

[Jason.Jonkman]

Dear Srinivasa,

Sorry, I meant CalcSteady = False rather than TrimCase = 0.

Best regards,

[Srinivasa.Ramisetti]

Dear Jason,

Just to clarify. If CalcSteady = False, then I need to set LinTimes from 200s. Is it okay to choose any 36 (NLinTimes) for LinTimes starting from 200s?

Regards,
Srinivasa

[Jason.Jonkman]

Dear Srinivasa,

Correct, but you'll want to set the LinTimes such that you cover a full rotor revolution of the rotor over NLineTimes steps, i.e.:
deltaT = (60 s/min)/( RotSpeed*NLinTimes ) where RotSpeed is in rpm
LinTimes(1) = 200 s (or whatever is needed to be in steady state)
LinTimes(2) = LinTimes(1) + deltaT
LinTimes(3) = LinTimes(2) + deltaT
etc.

Best regards,