Large oscillation of RPM above rated

Wind & Water Computer-Aided Engineering Software Tools
1

Hi all, thanks for accepting me to the forum

I have just downloaded the binaries of the OpenFAST 2.2.0 version, and the first thing I am trying is to run the regression tests. I have started with the 5MW_Land_DLL_WTurb tests, except that instead of turbulent wind I am running a steady wind of 12 m.s-1 (and no other modification).

I am plotting the RPM, and I expect it to reach the rated rpm after some transients. It indeed reaches 12.1 rpm, but the transients seem to last longer than I would expect. I have compared the OpenFAST results to those obtained with another software (Ashes), the results are shown below:

img.png
img.png966×491 17.9 KB

I am not yet trying to figure out whether one or the other software is producing more accurate results for this particular case. Ideally, before working on that, I would like to make sure I am using FAST correctly by benchmarking my results against other results produced with OpenFAST. Does anyone know if it’s possible to access the results (as time series) of the nightly tests?

If not, my hypothesis is that the blades have a very large moment of inertia around the blade pitch axis, which causes an overshoot and large oscillations in the pitch angle (see figure below, only results with OpenFAST) and therefore in the RPM.

img2.png
img2.png950×488 18 KB

Any comments/thoughts on this? Can I find the moment of inertia of the blades around the pitch axis somewhere? Or maybe the OpenFAST results are just fine and those oscillations are to be expected?

Thanks a lot,
Loup

2

Dear Loup,

Just a few comments:

  • To test that you’ve compiled and are running OpenFAST correctly, I normally recommend that you run the OpenFAST regression test suite (r-test). The baseline r-test results generated by NREL are saved in the r-test repository. Please find documentation here for how to run the r-test and compare your results with baseline: openfast.readthedocs.io/en/mast … index.html.
  • The test 5MW_Land_DLL_WTurb uses ElastoDyn to model the blades, not BeamDyn, and in ElastoDyn, I would not expect the blade-pitch response to be impacted by the blade inertia about the pitch axis.
  • I can’t say I’ve run your particular simulation, but I would generally expect a long start-up transient if the rotor speed and blade-pitch angles are not initialized properly. For a land-based turbine, I generally recommend initializing the rotor speed and blade-pitch angles to be their expected mean values for the mean wind speed simulated. From your results, it looks like the rotor speed is initialized and settling out at 12.1 rpm, but it looks like the blade-pitch is initialized to 0 and settles out to 2.5 degrees; I would recommend initializing the blade-pitch to 2.5deg for this case to minimize the start-up transient.

I hope that helps.

Best regards,

3

Hi Jason, nice to read you :slight_smile:

Thanks a lot for your help, that is very useful. In reply to your comments

  • I tried to run the regression tests, and finally managed to get some results after a couple of attempts. Most results fail with a tolerance of 1e-3, but the plots seem to indicate that major differences between local and baseline only occur at the beginning of the simulation. The image below is one example, illustrative of what I have been seeing for other output.

Annotation 2020-03-13 115257.png

I assume there might have been some code changes between the release of OpenFAST v2.2.0 and the current baseline results? In any case, I’m happy enough with the comparison.

  • Good point, I hadn’t thought about that. Agree that with ElastoDyn the inertia about the pitch axis won’t affect the results

  • Yes, the blade pitch was initialized at 0, because that’s what I was doing in Ashes as well (so the RPM comparison between the 2 software was done with the same initial conditions, for pitch and RPM). But at this stage I think I can live with this, especially if that doesn’t strike you as wrong.

Thanks again for your reply,
Loup

4

Dear Loup,

Yes, I’m not too happy with the pass/fail criteria currently used in r-test From my experience, very minor changes to the source code or compile settings result in many cases “failing” even though the time-series solution appears nearly identical, and certainly within engineering accuracy. I believe Rafael Mudafort is working to improve the pass/fail criteria, but I’m not sure as to the status, as I’m not directly involved in that.

Otherwise, I’m glad you are not getting the results you expect.

Best regards,