OC4 DeepCWind Eigenanalysis/Static Equilibrium/Free Decay tests

Hello everyone,

I am trying to reproduce with FAST v8 the tests from the OC4 DeepCwind semisubmersible floating wind turbine, as presented in the “Offshore Code Comparison Collaboration Continuation Within IEA Wind Task 30: Phase II Results Regarding a Floating Semisubmersible Wind System” here attached, load cases page 5.

As you will see, I am confused, even after reading the FAST user guide, and looking for answers on the forum. My questions may be trivial for you, sorry about that, but I hope it will be trivial for me soon as well.

I know the questions are numerous, maybe I should make different posts, but I know you cannot necessarily answer to all of them, as it takes some time. I am sorry for the inconvenience.

  1. The sole purpose of Eigenanalysis test (load case 1.1) is to find all the natural frequencies (motions, structural) at once, is that right? Is there a simple example I could find to understand easily how to do it? If not, where in the simulation results can I read those natural frequencies? Do I have to use the “eianalysis.m” Matlab file found in the installation directory? Do i have to activate the Linearization (just Linearize = True, ?) ? Could we also do that with Free Decay tests (load cases 1.3.X): FD for surge will tell us the natural frequency for surge, heave for heave, etc. ? Should the system stabilize at a steady position in this load case that has no load but gravity and buoyancy?

  2. The sole purpose of the Static Equilibrium test (load case 1.2) is to find the static equilibrium position of the system (just asking the obvious to be sure there is no other use)? Could we also do that with Free Decay tests (load cases 1.3.X): FD for surge will tell us the static equilibrium surge position when stabilized, heave for heave, etc. ?

  3. Eigenanalysis (load case 1.1) and Static Equilibrium (load case 1.2) both work without wind (CompAero = 0, CompInflow = 0, right?) nor waves (just WaveMod = 0, right?). For those 2 load cases, are all DOFs really enabled as written in the table page 5 (platform, blade flapwise/edgewise modes, drivetrain, generator, yawing system, tower fore-aft/side-to-side modes)? What about the initial conditions? Should they all be equal to 0 for those 2 tests, since we can know the static equilibrium position only after the equilibrium load case 1.2?

  4. Then, what is the difference between those 2 tests if they share the same simulation parameters?

  5. Concerning the natural damping of the system, in which tests do you compute it (Eigenanaysis, Static Equilibrium, Free Decay?), and how to you obtain it exactly?

  6. I have performed Free Decay tests for surge, heave, pitch and yaw, to find their natural frequencies and their equilibrium position. I have found:

  • 0.021 PtfmSurge (inital displacement: 15m)
  • 0.009 PtfmHeave (initial displacement: 5m)
  • 0.08 PtfmPitch (initial displacement: 5°)
  • 0 PtfmYaw (initial displacement: 5°)
    Does it seem correct, or not at all?

Thank you, sorry again for the length, but it would help me a lot.

Have a nice day,

Bertrand
NREL - Offshore Code Comparison (2014).pdf (3.41 MB)

Dear Bertrand,

Here are my answers to your questions:

  1. A similar question was asked and answered in the following forum topic: http://forums.nrel.gov/t/the-frequency-component-of-flapwise/1730/4. The new linearization functionality for floating offshore wind turbines mentioned in the post dated Nov 02, 2018 has now been submitted as a pull request into OpenFAST–see: github.com/OpenFAST/openfast/pull/350.

  2. Correct, but there is only one static-equilibrium position in the absence of external loading from wind and waves, so, only one simulation is required.

  3. Correct. It is always best to perform an eigenanalysis about an equilibrium position, so, load case 1.2 is really a prerequisite of load case 1.1.

  4. The difference is regarding which outputs are being reported for the code-to-code comparisons.

  5. The linearized natural damping can be derived directly from the linearization analysis / eigenanalysis. Free-decay tests are often used to derive the linear and quadratic (viscous) damping (via the so-called p-q analysis of the free-decay time series response).

  6. No, these natural frequencies do not look correct (assuming you are reporting values in Hz). The natural frequencies of the OC4-DeepCwind semisubmersible are reported in Figure 3 of the paper you attached.

Best regards,

Dear Dr. Jonkman,

Than you very much for the accurate answers. Also, for the question 6, the results shown were not natural frequencies but the equilibrium position, though I have to say my question was quite unclear… :unamused:

Thank you again!

Dear Dr. Jonkman,

For better understanding of FOWT, I am running Test25 (5MW_OC4Semi_WSt_WavesWN) for free decay of the platform and eigenanalysis of the system, and comparing the simulation results with the one given in https://drive.google.com/drive/folders/0B0KGNSHvXXgCS3h3ZkZxX1lxVTA?resourcekey=0-YV1BDAvLf4sVYs5eYPNg-A

Except for heave, there is discrepancy in magnitude for surge, and in frequency for pitch and yaw. Here only the DoFs for platform is enabled, CompInflow=0, CompAero=0. The default RdtnMod was 1, I had to change it to 2 to get a better match in magnitude for surge and yaw, but it did not help with frequency. I am wondering if the difference is caused by different version of FAST, as the data online was created with FAST 7.03 in 2013, while I am using OpenFAST v3.0.0. If not, what could be the cause.

For eigneAnalysis, I followed the steps discussed in the forum, linearization->MBC3->campbell diagram. I have difficulty to extract natural frequency for the platforms and drivetrain. I couldn’t find any value close to LC1.1 data.


It seems I cannot upload the excel sheet for the campbell diagram, sorry for the low quality snapshots. The case is r-test/5MW_OC4Semi_Linear with 0rpm, CalcSteady=False, TrimCase=2 (I tried CalcSteady=True, it’s not working). Please kindly help to check if my interpretation of frequency of tower and blade in the table is correct, and what could go wrong with the platform.



Best regards,
Xiaoqin

Dear @Xiaoqin.Zhang,

Just a few comments:

  • Certainly there are have been many changes to FAST/OpenFAST between FAST v7 and OpenFAST v3, but is hard for me to say what specifically is causing the differences you are showing. You’d probably need to step through the results from intermediary versions to answer that. See the related discussion in the following issue on the OpenFAST github page: Diffrences in free-decay response OpenFAST v2.3 - v3.0 · Issue #1022 · OpenFAST/openfast · GitHub.
  • If the state-space-based wave-radiation model is well fit, then the state-space and convolution methods should give consistent results. If these two methods are not giving consistent results, you may want to improve the fit. FAST v7 only supported the convolution method. I would normally only use the state-space method for linearization purposes, or to check that the state-space method to be used for linearization is accurate relative to the convolution method.
  • I’m not sure I understand what your linearization question is and/or can’t comment without knowing more about your simulation set up.
  • What do you mean when you say CalcSteady = TRUE is not working? Please note that given the low floater natural frequencies of the OC4-DeepCwind semisubmersible, it may take a long time for steady-state solution is reached, unless the initial conditions are set close to the steady-state solution.
  • Please note that TrimCase is only used when CalcSteady = TRUE.

Best regards,

Dear Dr. Jonkman,

Thank you for your response.

  1. The linearization I posted was for 5MW OC4 DeepCwind at 0 rpm. By CalcSteady = TRUE not working, I mean when I try to run the simulation with CalcSteady = TRUE, it crashes with the error below:

where both PCmode=0 and VSContrl=0, RdtnMod=2, the linearization parameters are given as:

image

For 12rpm case with TrimCase=3 and VSContrl=1, I got same error message.

  1. If state-space and convolution methods do not give consistent results for free decay, how to check if state-space is accurate or not and how to improve the fit? Actually when I run case LC2.1 for regular wave and no air, RdtnMod=1 or 2 gives similar platform translation.

Best regards,
Xiaoqin

Dear @Xiaoqin.Zhang,

Regarding (1), it looks like the trim solution cannot find a periodic steady state by the time the simulation reaches TMax. When this happens, I would review the resulting time series to see if the solution looks like it is converging or not, e.g., what does the time series of RotSpeed look like? If the solution looks to be converging, increasing TMax should solve the problem. If the solution does not look to be converging, I would suggest changing TrimGain to see if that helps.

Regarding (2), you’ll know that the state-space model is not a good fit if it doesn’t give similar results to the convolution method. In this case, it is likely necessary to improve the fit by rerunning SS_Fitting (SS_Fitting | Wind Research | NREL). It could be that the fit is good for some simulations and not for others, depending on the sea state and other conditions simulated.

Best regards,

Dear Dr. Jonkman,

thank you for your fast response.
I am trying to adjust TrimGain and use larger TMax to get a converged solution, but so far no success.

One more question, regarding the simulation data provide in Simulation Results, there are two sets of data for OC4 for some load cases, e.g. regular wave LC2.1, there are IST_FAST_OC4_21.txt and IST_FAST2_OC4_LC2.1.txt, the former CodeName is FAST 7.02 and the later is FAST2, may I know what’s the difference between these two? When I compare my platform translation with these two, I get big discrepancy with FAST 7.02 for surge but a better match with FAST2 and a big difference for yaw. The other four DOFs are in good agreement. Is the FAST2 result reliable? For load case 2.1, I suppose there is no yaw.

Regards,
Xiaoqin

Dear @Xiaoqin.Zhang,

Regarding the trim solution, what does the time series output of RotSpeed look like for various TrimGain settings?

The OC4 Phase II results you are referring to were generated by the Instituto Superior Técnico (IST); not NREL. I’m not sure (and it is not explained in the OC4 Phase II report: https://www.nrel.gov/docs/fy14osti/61154.pdf), but I’m guessing the labels “FAST” and “FAST2” refer to different settings used by IST in two different FAST v7 models. The FAST v7 results submitted by NREL are labeled NRELFAST_OffshrBsline5MW_OC4DeepCwindSemi.txt.

Best regards,

Dear Dr. Jonkman,

From the simulations that I have done, TrimGain does not affect RotSpeed. I used different TrimGain for 0.01, 0.1, 1, 10 100 and 1000, they all give the curve below for RotSpeed=0. Even I run the simulation for 50,000 seconds, it still shows “unable to find steady-state solution”, I suppose this is due to the small TrimTol=0.001. I need to run it even longer to reach steady-state.

Here I have a question, to generate linearized data at “LinTimes”, CalcSteady=False has to be enforced. Then how does CalcSteady=True help me to find the equilibrium state in the linearization process?

Best regards,
Xiaoqin

Dear @Xiaoqin.Zhang,

Regarding the trim solution, I’m not sure I fully understand what is going on here, why different TrimGains result in the same solution, and why it is taking so long to converge. (The results appear to be converging after 10000 s, but this is an exorbitant amount of time.) Given that you’re targeting RotSpeed = 0, what InflowWind, AeroDyn, and ServoDyn options have you selected?

What do other outputs such as blade deflection, tower deflection, and platform displacement look like during the trim solution?

When CalcSteady = False, the linearization is forced at user-specified times (LinTimes), even if the solution is not in steady state. When CalcSteady = True, the linearization will only occur after a steady state is reached (and LinTimes is ignored).

Best regards,