Campbell diagram

[tchatte3]

Dear openfast team,

I am wondering if there is any reference I could be pointed to regards to creating a Campbell diagram in openFAST. Sepcifically, I was looking at a Campbell diagram in the Bladed software and would like to create something similar in openFAST. I understand, I should be starting from the linearization analysis in openFAST, but I am not sure how to compute the frequencies of the various DOF's of interest in the linearization analysis? Should I be using just the PSD's from a time-series of the DOF's ? Any help or guidance regarding this matter would be extremely valuable.

Best Regards,

[ebranlard]

Hi,

We typically run the linearization using a set of matlab scripts (compatible with Octave). The scripts write a set of openfast input files for different operating conditions, run fast, postprocess the linearization files using a Campbell transformation, and then perform a plot. Before plotting, a manual identification of the modes is typically necessary.

I'm currently working on updating these matlab scripts. If you want, you can clone my fork of the matlab-toolbox repository:

    https://github.com/ebranlard/matlab-toolbox

You can try running the script Campbell/example/runCampbell.m. It's only an example, but hopefully by reading the comments you can adapt it to your needs. I hope to merge this into the official matlab-toolbox repository in the coming weeks. I'd recommend doing the linearization without a controller at first (CompServo=0, GenDOF=False) to get familiar with the process.

We are also in the process of doing different updates on the linearization functionalities of OpenFAST (soon we'll have a trim option to automatically find periodic steady states, instead of running for a long time), so things will likely change, but hopefully the matlab scripts will not be affected significantly.

Feel free to report issues in my matlab-toolbox repository since this is not an official release yet.

Emmanuel

[tchatte3]

@ebranlard Thank you very much for pointing me to right direction. The matlab-toolbox would certainly be helpful in this regard.

[tchatte3]

Hi @ebranlard, I am currently facing some issues with the MATLAB-toolbox for Campbell diagram. I was able to fix a few myself, but I am stuck at the final one. I am using MATLAB 2019b

The code fails in postproLinearization() specificially in campbellData2TXT>ShortModeDescr routine. For ShortModeDescr, seems the array is going out of bounds. This is the specific error:

Index exceeds the number of array elements (14).

Error in campbellData2TXT>ShortModeDescr (line **)
Desc = CD.Modes{i}.DescStates(CD.Modes{i}.StateHasMaxAtThisMode);
(inside routine DescCat = ShortModeDescr(CD,i) )
This is happening because CD.Modes is trying to access max(nModesKeep) = 15 in the for-loop.

Any suggestions/guidance on how to overcome this issue?

##############################################################################
Another follow-up question. If I have say 4 operating points (decided by wind speed, rotor rpm & blade pitch: 4 such unique lists avaiable) can I just perform 4 linearization analysis just ar t = 0 (without allowing the systems to evolve in time)? In which case is there any necessity of invoking the controller? Would the controller do anything?

Any guidance would be really helpful, as I am completely new to this field.

Best Regards,
Tanmoy

[tchatte3]

@ebranlard I was able to do a work-around by just running loops from 1 to NModesKeep-1.

Best Regards,
Tanmoy

[ebranlard]

I've submitted a small change that I hope will fix the issue you saw.
ebranlard/matlab-toolbox@d5a06bd

Even at constant rpm (without controller and generator) you need time for the simulation to reach a steady state, since you will likely have transients at the beginning of your simulations. You need time for the tower top deflections, blade deflections, shaft torsion to reach an equilibrium position. These transients will be present with or without a controller.

With a controller on, you also have to wait for the balance between generator torque and rotor speed to take place. You also need to use the simple controller and not the DLL. It's usually more work, that's why I suggested to do linearization without the controller first.

OpenFAST can do linearizations at any time, but for a Campbell diagram, you do want a periodic steady state to be reached.

[tchatte3]

@ebranlard Thank you for the detailed guidance. This is really helpful. I will use your new merge.

PS: The fix you suggested works great. A minor point, with variable nModesKeep, I had to do the initializations

MFreq = zeros(nModesKeep,nOP); 
MDamp = zeros(nModesKeep,nOP);
MDesc = cell(nModesKeep ,nOP) ;

with a temporary nModesKeep = 20, which will later get updated in the for loop

for iOP = 1:nOP
    CD=CampbellData{iOP};
    nModesKeep=min([length(CD.Modes), 20]);
    for i = 1:nModesKeep
        DescCat = ShortModeDescr(CD,i);

Best Regards,
Tanmoy

[tchatte3]

Hi @ebranlard - - A followup question, is there a way I can cotrol the number of output modes to be dumped in the Campbell summary. From the description and the getCampbellData.m it seems that the modes can be collected from the output Channels in the module files we are using. However, when I look at the summary files I see 17 modes and their frequency/damping information are outputted independent of the number of the output channels in Elastodyn/Servodyn say.

When I am comparing with another software Bladed" I see that modes like Rotor 1st edgewise collective" exists, but for the matlab toolbox I see only progressive and regressive modes, but no collective modes. Is there a way to tap those extra variables from the toolbox, or they need to be added as matrices for eigenfrequency analysis separately?

Best Regards,
Tanmoy

[ebranlard]

Hi, Thanks for the updated tip above, I'll include that.

The number of modes is related to the number of states of your system, typically half. When you use ElastoDyn you'll typically have between 12 and 17 modes based on which DOF are activated. You can see the states listed in a .lin file. The matlab code attempts to perform an identification of the full-turbine modes, based on which states are excited, which is quite a difficult task, which is why this is typically done manually for now. If you use BeamDyn you will have more modes, but the identifications will be quite difficult. We are currently working on some visualization, but the process is quite involved.

The first collective edgewise mode is usually combined with the drive train torsion, since the collective edgewise motion of the blades will induce torsion of the shaft. This is why it doesn't appear.

I hope that helps,

Emmanuel

[tchatte3]

@ebranlard Thank you. Yes, I was seeing that the .lin files the number of continous states is 30 X 30 matrices, so it does make sense. So, is there a way to decouple the edgewise collective mode from the drive train torsion? Or any rule of thumb to compute the frequencies of edgewise collective from the drivetrain torsion mode?

Best Regards,
Tanmoy

[ebranlard]

Your edgewise collective frequency will be close to the individual blade edgewise frequency but will increase with increased rotational speed. You could run with a fixed drivetrain (GenDOF=False, DrTrDOF=False) to get these frequencies out at different RPM.

[tchatte3]

@ebranlard , OK this makes complete sense, Thanks a lot.

Best Regards,
Tanmoy

[tchatte3]

Hi @ebranlard : A follow up question related to the interpretation of the modes in the Campbell analysis. (CampbellDataSummary.xlsx)

I read the mode shapes signed magnitudes, but I believe I am not interpreting them correctly. For the NREL 5MW turbine case, when I am using No Servo for operating points for OP: 3 mps wind speed, the .xlsx file says that mode number 2 corresponds to Tower F-A mode 1, @ wind speed 3 mps.

However, when I look at

Mode 2 signed magnitude in column H, I guess this is the mode max state for the different degrees of freedom and not really the mode shape. I guess, to properly extract the mode shapes I need to tap out the Eigenvalue_save vectors from the eigenanalysis in the tool-box, is that correct?

Best Regards,

[ebranlard]

Hi @tchatte3,

I think your interpretation is correct, but the thing that can be confusing is that the first column lists states. When using EalstoDyn these states have an easy interpretation since they correspond to the amplitude of a shape function, and each shape function induces some predefined displacements on each node of a body, in a single direction. If you were running Beamdyn, you'll have hundreds of states for the blades, each representing a displacement in x y or z of a node of the blade. In this table, you'll have hundreds of lines, and you'll see that the states that corresponds to x-displacements of the blade nodes have a strong amplitude (indicating some flapping of the blade).

What you can read from the table is that, for this mode 2, there are some important flapping amplitudes and tower fore-aft amplitude. This is likely expected for what we call the "tower fore-aft mode" of the full structure. Given the low frequency, we can identify this as a tower mode, and not the 1st collective or the 2nd collective flap. I personally like to look at the "Summary.txt" file to identify the modes. It is usually not enough, and you need to look at the continuity from one operating point to the next.

We are currently working on some mode shape visualization (#373), and we'll release this soon. This process requires to run OpenFAST twice, so it is more involved and ressource-heavy. You can try compiling this version, and using the matlab script "runCampbell_Trim.m" in my repository. You will need "paraview-python" if you want to generate avi files. Otherwise, you can open the vtk files using a regular paraview software.

You can find some documentation below, but this is out of sync with my version of the matlab-toolbox. My version of the matlab-toolbox basically tries to automate the steps mentioned in the documentation. You can read it to see what's happening behind the scene, but you won't need to follow the steps mentioned or download any of the files:
https://github.com/OpenFAST/r-test/blob/pullrequest/bjonkman-linear/glue-codes/openfast/5MW_Land_ModeShapes/vtk-visualization.md

I'd appreciate your feedback on running the script "runCampbell_Trim".

Thanks

[tchatte3]

Hi @ebranlard , thanks for the detailed response. This is indeed very helpful. I see, ok I will checkout #373 and use the runCampbell_Trim option that you suggested.

Best Regards,
Tanmoy

[tchatte3]

@ebranlard A follow-up question. Looking at the Campbell Summary txt file.

01 ; 0.203 ; 0.0054 ; ED 1st tower SS -
02 ; 0.211 ; 0.0852 ; ED 1st tower FA - ED 1st FLAP coll. - ED 1st FLAP cos -
03 ; 0.335 ; 0.6231 ; ED 1st FLAP sin -
04 ; 0.401 ; 0.5116 ; ED 2nd FLAP sin - ED 1st EDGE coll. - ED 1st tower FA - ED 2nd FLAP cos - ED 2nd FLAP coll. - ED 1st FLAP cos - ED 1st FLAP sin - ED 1st FLAP coll. - NoMax -
05 ; 0.463 ; 0.4544 ; ED 1st EDGE sin - ED 1st EDGE cos - ED 2nd FLAP coll. - ED 1st FLAP coll. - ED 2nd FLAP sin - ED 2nd FLAP cos - ED 1st FLAP cos - ED 1st FLAP sin - NoMax -
06 ; 0.655 ; 0.0141 ; ED 1st EDGE coll. -
07 ; 0.663 ; 0.0136 ; ED 1st EDGE cos - ED 1st EDGE sin -
08 ; 0.815 ; 0.0112 ; ED 1st tower SS - ED 2nd FLAP coll. - ED 2nd FLAP sin - ED 2nd FLAP cos - ED 1st FLAP sin - ED 1st FLAP cos - ED 1st EDGE sin - ED 1st EDGE cos - NoMax -
09 ; 0.958 ; 0.1891 ; ED 2nd FLAP cos -
10 ; 1.064 ; 0.1754 ; ED 2nd FLAP coll. -
11 ; 1.105 ; 0.1639 ; ED 2nd FLAP sin -
12 ; 1.447 ; 0.0347 ; ED 2nd tower FA -
13 ; 1.561 ; 0.0174 ; ED 2nd tower SS -
14 ; 0.000 ; 0.0000 ;
15 ; 0.000 ; 0.0000 ;

The lines were -NoMax is; would that really mean that the modes are kind of coupled, and there is particularly no -dominant mode for that particular mode-number, e.g., mode 05 and 08. How to interprete that? Any guidance?

PS: I am planning to run the Trim version of Campbell this weekend and see how that works for me.

Best Regards,

[ebranlard]

Hi, your interpretation is correct, the "NoMax" flag is to indicate that the column "State has max" (as seen in the Excel file) is all False. In that case, the 8 first states descriptions are written, sorted in order of their intensity. It's not easy to interprete.

• Sometimes the first description is the right one, but not always..
• You can look at the damping value, when the value is large, it usually indicates a flap mode (due to aerodynamic damping).
  (In your example Mode 5 is likely a flap mode).
• You can compare with the frequencies you obtained at other wind speeds/rotor speed. You can expect the collective frequencies to increase with rotor speed, and the cos and sin to split on both side of it. Once you start having a diagram with some modes identified, you can more or less guess some of the "trends" of the modes and identify the modes accross wind speeds that way. This is difficult when frequencies are close, but then the damping is helpful (it shouldn't jump too much from one point to the next)..
• Sometimes, some modes are hard to interpret without visualizing them, or even when visualizing them due to strong couplings (probably like your mode 8). You can attempt to use the visualization functionality that comes with the latest dev of openfast (and the trim, which is optional).
  Thanks for your patience, this is definitely not an easy process.

[tchatte3]

@ebranlard Thanks for corroborating the hypothesis. It is helpful. Yes, indeed I have several OP's / wind speeds which I can compare for Freq. vs Speed and Damping vs Speed.

Related to trim option in openfast and that available as a wrapper in your matlab-toolbox. Should the Wr_VTK be set to 1?
I also am retricted to use windows for openfast simulation. Is the latest windows openfast binary available? (corresponding to #373)

Best Regards,
Tanmoy

[ebranlard]

The matlab script runCampbell_Trim should take care of setting Wr_VTK to 3, when vizualization is requested. Hopefully the comments in the script will guide you, and you can have a look at https://github.com/OpenFAST/r-test/blob/pullrequest/bjonkman-linear/glue-codes/openfast/5MW_Land_ModeShapes/vtk-visualization.md to know what's going on (or should be going on) behind the scene.

I don't think we provide binaries for dev versions so you would have to compile it. Let us know if that's an issue.

[tchatte3]

@ebranlard Thanks. OK, I will try to see if I can compare openfast in windows. I will go ahead and set Wr_VTK = 3 and run the trim option.

Thanks for all these valuable feedback.
-Tanmoy

[zz17635]

Hi:

Thanks for the useful discussion. I have some questions regarding eigenanalysis here:

1. suppose that I'm now having a result of "mode 8" like shown below. Should I identify the mode as the 1st blade edge mode (collective) or as a generator mode, or a drivetrain mode?
   

2. Do you use damped or undamped frequency for plotting a Campbell diagram?

Many thanks

[ebranlard]

Hi @zz17635, drive train torsion and edgewise collective go hand in hand in a "fixed-free" situation (fixed at the generator side, and free on the rotor side). It is clearly a combination of drivetrain torsion and edgewise, but I think we usually refer to it as "1st drivetrain torsional mode".

Regarding your second question, we use the natural frequency. You can find a matlab and python script called plotCampbellData here, both take the excel file generated by the matlab script as input (the python script call also read the csv files if this option was used instead). I tend to use the python script when manually identifying the modes.

[zz17635]

Thanks for the explanation @ebranlard. ya.. I should take a closer look at the posts above. You mentioned previously, sometimes the modes can be hard to interpret. I'll go with "1st drivetrain torsional mode" then.

For the plotCampbellData script, I had a go on the Matlab one for the .lin file generated from the r-test example "5MW_Land_ModeShapes", and got the following error message:

Index exceeds matrix dimensions.
Error in Plot_CampbellData (line 93)
CampbellPlotData.lineLabels = txt(2: nLines+1, 1);

What might be the problem? If I understand it right from the comments in fx_mbc3.m, campbell_diagram_data.m and Plot_CampbellData.m, I would already have (the data for plotting) a Campbell Diagram, by running the following lines in Matlab? and the content of the excel file should look like the one I posted above, right?

[mbc_data] = fx_mbc3('5MW_Land_ModeShapes.1.lin');
BladeLen = 61.191;
TowerLen = 85.410;
[CampbellData] = campbell_diagram_data(mbc_data, BladeLen, TowerLen,'MBC3_transformed_data.xlsx');
[num,txt,CampbellPlotData] = Plot_CampbellData('MBC3_transformed_data.xlsx','Modes_Data','Campbell Diagram');

By the way, I'm also getting the following warnings from the "fx_mbc3()" function, I'm guessing it's no big deal as all 3 blades sheared one same input file. But does it matters?

Running mbc3 (v2.0, 29-Jan-2018)
Rotating channel "ED OoPDefl1, (m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED IPDefl1, (m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED TwstDefl1, (deg)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED BldPitch1, (deg)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED Spn2MLxb1, (kN-m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED Spn2MLyb1, (kN-m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED RootFxb1, (kN)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED RootFyb1, (kN)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED RootFzb1, (kN)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED RootMxb1, (kN-m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED RootMyb1, (kN-m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Rotating channel "ED RootMzb1, (kN-m)" does not form a unique blade triplet. Blade(s) not found: 2 3
Multi-Blade Coordinate transformation completed

Another thing is, I found an old post by Dr. Jason Jonkman back in 2011, where he provided a CampbellDiagram.xls spreadsheet for extracting Eigen information etc. Within the file, I found an example of Campbell Plot looks like below. I noticed that the frequencies of each mode are set to be not dependent on the rotor speed. Is it a legitimate simplifying approach for wind turbines? If so, I presume it'd be OK if I manually identify each mode required on the Campbell Diagram (as I have shown for the "1st drivetrain torsional mode" above) and plot the corresponding undamped frequency values as horizontal lines on Campbell Diagram and call it a day?

The third thing - very sorry for my clumsiness and the long message - after I went through the r-test "5MW_Land_ModeShapes" (from which the result above was obtained), I intend to practice the mode shape extraction procedure for a monopile offshore wind turbine, based on the r-test example: "5MW_OC3Mnpl_DLL_WTurb_WavesIrr".

as I turned SubDyn feature ON (CompSub=1) and ran the analysis, the following error message showed up, which seems to indicate SubDyn does not yet support linearisation?

"FAST_InitializeAll:FAST_Init:ValidateInputData:Linearization is not implemented for the any of
the substructure modules. "

On the other hand, if SubDyn is turned OFF, of course the model is then not connected properly to the seabed or indeed anything , and error messages regarding "SkewedWakeCorrection" and "small angle assumption" show up.

Does this mean, based on the current OpenFAST, it is not yet possible to perform a linearisation + mode visualisation for a monopile-OWT?

Sorry if the stuff I mentioned is considered basic. I really appreciate your help..

[ebranlard]

Hi,
I'm writing some quick answers below:

1. I'm not quite sure what's happening here, there could be some inconsistencies in the versions or maybe the script needs further tuning. I've slightly modified the script in my own branch of the matlab-toolbox. Maybe you can try that plotting script instead.

As for the triplets, these warnings are not an issue, and can be discarded. You need the same sensors for the three blades to perform the mbc of that sensor. But for the linearization and Campbell diagram you don't need these sensors (only the states, which are always included in the .lin file).

2. The post you mention might have been an example. The frequencies will change with RPM (in particular the blade ones) . The python script I mentioned in my previous post will plot the Campbell diagram as function of WS or RPM based on the command line argument. Both plots are relevant. The RPM plot should show quasi linear split of frequencies. The RPM plot will not show what's happening above rated since the RPM is constant. Above rated, modes may vary slightly due to pitching and change of aerodynamic loads.

3. Linearization with SubDyn and HydroDyn is currently being implemented. It might be available in a couple of months, then you'll be able to do the monopile linearization, but right now it is not supported.

I hope that helps,
Emmanuel

[zz17635]

Thank you Emmanuel.
Thats great! Sounds like the python script might be a good place to start, I'll have a go on that

[tchatte3]

Hi @ebranlard I am writing regarding some interpretation issues in the Campbell analysis. Nat freq. vs wind speed plot. I was trying to compare my results against commercial Bladed software simulations for our turbine model and was observing some discrepancies. We tried to create almost similar model in Bladed to the level of fidelity in openfast (e.g., having 2 flapwise bending modes, 1 edgewise bending modes and removing torsional mode coupling in blades, + rigid foundation in tower etc)

Because of mode coupling issues, I am not trying to cherry-pick any of the modes and label it, but rather using a single color and plotting all the frequencies vs wind speeds for modes 1-14 and trying map it with the Bladed Campbell diagram.

These analysis are with MBC transform (fixed frame of reference) switched on.
Tower 1st modes seem OK, 2nd modes are quite off (23% difference). Blade edgewise modes seem to show similar trends somewhat and so is the Flapwise modes in general. Flapwise Backwird whirl/ Regressive modes looks fundamentally different. Especially, the modes look fundamentally different beyond rated speed.

I know this is a detailed question, but wondering if you can sense any potential fundamental reasons for the discrepencies of the Campbell diagram plots. In general, do you recommend any bounds on the discrepency errors in Campbell diagram.

Any help or suggestion?

Best Regards,
Tanmoy

[jjonkman]

Hi @tchatte3,

Just a few comments:

• Have you ensured that the operating points are the same between OpenFAST and Bladed? For a proper comparison, you'll want to ensure that the rotor speed and blade-pitch angle at each wind speed are the same between OpenFAST and Bladed; you'll also want to ensure that the solution is in a periodic steady state before linearizing.
• Are you linearizing at a number of azimuth steps (e.g., 36, in steps of 10 degrees) around a full rotor revolution before applying MBC3 and azimuth averaging?
• Are you outputting the linearization data with enough precision from OpenFAST (OutFmt = "ES17.9E3") to ensure that the eigenanalysis is numerically correct? This is very important if your model uses BeamDyn to model the blade structural dynamics, but may also help with ElastoDyn.
• You haven't mentioned how the damping compares, but to capture proper aerodynamic damping, you should ensure that frozen wake is enabled in AeroDyn (FrozenWake = TRUE) when linearizing.

Best regards,

[ebranlard]

My runCampbell scripts should automatically take care of the two last point, but you can double checked that it did so.
If you are not using the trim solution, you might have to look at the time series to see whether the linearization occurs at a periodic steady state, and increase the time where linearization occurs.

[tchatte3]

@jjonkman @ebranlard Thanks for these detailed inputs.

@jjonkman I am using my own modified version of Campbell code originally gloned from @ebranlard repo, so yes outputfmt and FrozenWake = True is ensured. I am indeed running the simulations for a long time [tested for 300 secs , 500 secs] and azimuth averaging for 36 sectors.

The bladed model that I showed was indeed tuned such that the OP points with Bladed are inputted in openFAST .csv file for Campbell run. But, while writing this I quickly tested my openfast to dump out the OP's with a PI controller that I am using and I see there is difference in the above rated conditions.

So, thanks for pointing that out and I would take that as a starting point with OP conditions.

[tchatte3]

@ebranlard, @jjonkman I had quick follow up question related to interpretation.

I was intermediately doing Campbell analysis with the wind turbine in Parking condition/rotor-locked to get rid of the controller when comparing against Bladed software.

I am using the MATLAB Campbell tool from @ebranlard 's repository.

I am using following op points. Blade pitch = +90 deg, wind speed = 0, rotor rpm = 0.0

For Nat. Freq. in Hz, I get the following error margins.

Modes	Error %
Tower, FA 1	-1.958 %
Tower, SS 1	-0.969 %
Tower, FA 2	-12.622 %
Tower, SS 2	-23.699 %
Edg Cos 1	+6.679 %
Edg Sin 1	-0.434 %
Edg Coll. 1	+46.106 %
Flap Cos 1	+0.302 %
Flap Sin 1	-2.119 %
Flap Coll. 1	+ 7.44 %
Flap Cos 2	- 6.85 %
Flap Sin 2	-12.004 %
Flap Coll. 2	+6.668 %

I almost never get the Edge Collective mode correctly whether or not the Drive train DOF is turned ON or OFF.

While the Nat Freq. is still "qualitatively acceptable", the damping seems quite off.
Tower Damping < 1% [1st and 2nd FA, SS modes]
Blade Damping ~ 70-100%

Any thoughts related to why these discrepancies are occuring? Any guidance?

In general, for Campbell practice, I have apriori knowledge of what time it takes to reach steady state with some buffer~ 100 secs. Additionally, I would increase the sim Time 2,3 5 times that time and perform Campbell analysis to see if the frequencies are influenced somehow. They are not.

PS: The results do not change if I switch off/on the drive-train frequency.
But the drive-train frequency in openfast and Bladed are also significantly off, by 50-60%. Do not know if that can shed light on the discrepancies.

Kind Regards,

[jjonkman]

@tchatte3,

Regarding the natural frequencies, the biggest differences between your OpenFAST and Bladed models appear in what you call collective edge and side-to-side direction. Perhaps these are related to how you are treating the generator in each model. Is the generator parked (GenDOF = False in ElastoDyn) or idling--i.e., a fixed-free or free-free boundary condition of the drivetrain, and is this set the same in each model?

I would expect higher damping in the blades than in the tower and more damping flap/fore-aft, than edge/side-side. But I'm not sure I can comment explicitly on your results. How do these compare between OpenFAST and Bladed? Do you see similar levels of damping between the two models when you disable aerodynamics?

Best regards,

[tchatte3]

@jjonkman

Campbell Parking Analysis

Blade pitch = 90 deg, Wind speed = 0, Rotor rpm = 0, Blade azimuth = 180, gravity = 0.

I am suspecting something is amiss with the generator model as well. Yes, when Campbell parking mode is considered I am using GenDOF = False. Additionally, I tried setting DrTrDOF to both True/False but it has insignificant influence on the edgewise frequencies [on the third place of decimal]. Right now I am only tuning it through Elastodyn DOF's. Is this the correct way you would recommend?

I can check how the Generator model is defined in BLADED.

Regarding Damping, I made fixes to the tower model.
Major observations: The damping ratio for blades/tower are 1 - 2 order of magnitude lower in openfast compared to BLADED. [Fundamentally different]

Regarding your comment : "I would expect higher damping in the blades than in the tower and more damping flap/fore-aft, than edge/side-side. But I'm not sure I can comment explicitly on your results. How do these compare between OpenFAST and Bladed?"

I can confirm that for BLADED software, but that is only marginally true for openFAST. Eg in openfast damping ratio of Tower FA, mode 1 = 0.0041, and Tower SS, mode 1 = 0.0040. And, Flapwise damping is not greater than edgewise damping in openfast. While, it may be argued that the mode identification in the matlab wrapper might be incorrect, still the values are off by orders of magnitude.

Campbell Power Production Analysis

In general I am attaching the Damping ratio trends vs wind speeds for the full Campbell run.

There is a similarity of trends but still quanititatively a lot of difference can be observed.

Your suggestion related to disabling the aerodynamics is very insightful, may not be easy in BLADED as is in openfast. I will definitely give it a try.

Best Regards,

[jjonkman]

@tchatte3,

I now see that you've specified zero wind speed, so, I guess you are only looking at still-air drag for the parked case. For this caes, have you set WakeMod = 0 in AeroDyn so as to disable the wake calculation altogether? (The AeroDyn wake models are only valid for operational conditions.) For the operational case, you should use WakeMod = 1 with FrozenWake = TRUE.

Best regards,

[tchatte3]

@jjonkman

I did not. But, when I set WakeMod = 0, [FrozeWake = TRUE], I do not see any differences in the results in the blade/tower modes.

Best Regards,

[ebranlard]

H @tchatte3
As Jason mentioned, you can try to run without aerodynamics (turning off AeroDyn, or, setting AirDens~0, which might work for Bladed) focusing only at WS=0 . This way you only get structural damping out from the linearization. If you see several order of magnitudes differences (factor 100 or 2pi) in damping between the two models, then maybe there is a difference of convention between the damping definitions (the damping in ElastoDyn are damping ratios in percent).

If you see big differences in frequencies, something could be off in the mass or stiffness definition (we also likely don't have the same capability than Bladed for the inertia and masses of the nacelle/shaft/generator and hub).

For the drive train torsional mode, you can adjust the stiffness and damping of the shaft DTTorSpr, DTTorDmp(the damping there is in "physical" units).

To go in further details, you can also do linearization with only the blade being flexible, in bladed and openafst, and try to match the frequencies and damping.

Best regards,

[tchatte3]

Hi @ebranlard, Thanks for the suggestions, they are very insightful.

i) I will check, if the bladed damping ratio is defined differently than openfast. Problem is that there is not a consistent multiplicative bias, i.e., they are not consistently off by a factor of 100 or 10/(2pi)

ii) Turning of Aerodyn in openfast I see minimal changes in Nat. frequency response.

iii) Will look into the blade mass/stiffness definition. I agree with your suggestion regarding the capability.

iv) DTTorSpr, DTTorDmp looks like a good starting point.

v) Will also try for blade only frequencies.

Thanks again for these suggestions, gives me a good starting point.

Best Regards,

[tchatte3]

@ebranlard @jjonkman I am closing this channel, as my issues are all resolved now. Thanks for all the help.

[ncepulibei]

When I set compelast = 2, compinflow = 1, and comaero = 2, I get the following result graph, in which it seems that there are unrecognized modes. Why is this? How can I solve it

[jjonkman]

Dear @ncepulibei,

Which version of OpenFAST are you using?
Are you running an OpenFAST model provided by NREL or one you made yourself?
Is the solution in steady-state before linearization?
Are you using a high precision for the linearization output, e.g. OutFmt = "ES17.9E3" or "ES20.12E3"?
Do the linearization results make sense when using ElastoDyn only (CompElast = 1)?

Best regards,

[ncepulibei]

@jjonkman The version I use is Openfastv2.4.
Model is NREL5MW.
It should have reached a steady state before linearization, otherwise the linearization result will not come out, right?
I set OutFmt = "ES17.9E3"
When I set CompElast = 1, the result is very good. But when setting CompElast = 2, as I said before, some modals cannot be recognized

[jjonkman]

Dear @ncepulibei,

I know that NREL is debugging an issue associated with the linearization of BeamDyn that seemed to have been introduced between OpenFAST v2.3 and v2.4, so, reverting back to v2.3 may improve the BeamDyn linearization results. But I'm not intimately involved in this debugging, so, I'll let others (e.g., @ptrbortolotti or @ebranlard) comment if I spoke incorrectly.

OpenFAST allows you to linearize a model at any point in time, but the linear system is most useful (and able to predict a representative eigensolution) only when the model is in steady state. Enabling CalcSteady is an automated way to ensure that the solution is in equilibrium before linearizing.

Best regards,

[ncepulibei]

@jjonkman OK. I will try version 2.3.Thank you.
Best wishes