Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linearization of OC4-Semi in OpenFast3.0 #812

Closed
blueblueyaro opened this issue Aug 17, 2021 · 13 comments
Closed

Linearization of OC4-Semi in OpenFast3.0 #812

blueblueyaro opened this issue Aug 17, 2021 · 13 comments

Comments

@blueblueyaro
Copy link

blueblueyaro commented Aug 17, 2021

Dear all,
I am trying to obtain a linearized state space model of OC4-Semi WT in OpenFast 3.0 for LQI controller design. I want to verify the steps and there are also some questions. As initial attempt, I want to get a SISO model (blade pitch as input and generator speed as output) for collective pitch control for power regulation.

  1. I followed the steps in 5.6.2. Linearized models for one simulation (manually) in the document and also refferred to Linearization of the model #738 and then I got .lin files 1 to 36 (OP: wind 18m/s, Torque 43093Nm, blade pitch 0.26rad). The DOFs I chose were FlapDOF1, DrTrDOF and GenDOF. ComHydro and ComMooring were swithed off.

  2. I used GetMats_f8.m in matlab-toolbox-main and 1.lin to 36.lin for postprocessing, then I got AvgAMat, AvgBMat, AvgCMat, AvgDMat, etc. as the result.

Questions:

  1. As this is an offshore case ( # 25 ), do I need to include more DOFs in the ElastoDyn file and also ComHydro and ComMooring in .fst file? Can I say that the DOFs I choose depending on my control target?
  2. In the .lin file, there are 66 inputs in total, among which No.4,5,6,9 are all about blade picth (the first three are pitch command for each blade and the last one is collective), which one should I choose for this SISO system? Or is there other preprocessing to define the inputs?
  3. I noticed that in the Technical report named Advanced Control Design for Wind turbines Part I (2008),in this case AvgMats were postprocessing before design the controller. According to the report, these matrices correspond to the state matrices A,B,C,D, and the script in appendix B calculated Amod by AvgAMat. What is the exact relationship between them? Or there is other script for the transformation that I didn't find? This doc also mentioned Bd, Dd matrices while I didn't find in my result.

Is there any step I did by mistake? Thanks for your answer very much.

@jjonkman
Copy link
Collaborator

Dear @blueblueyaro,

Your approach sounds fine. Here are my answers to your questions:

  1. You can include as many DOFs as you want/need, which I agree would depend on the control target. The more states you have, the high-fidelity the linear model is, but the more difficult it will be to control everything. If you enable the platform DOFs, then you'll need to enable HydroDyn and MAP++ (full system linearization functionality with MoorDyn is also coming soon).
  2. It sounds like you want to design a collective blade-pitch controller, so, the collective pitch input (# 9) is what you need.
  3. I'm not sure I fully understand your question, but for a three-bladed wind turbine, typically you'd apply the MBC3 transformation before azimuth averaging. Also, the generator azimuth state is typically eliminated from the state-space matrices after applying MBC3 and azimuth averaging by further post-processing, as discussed on our forum--see: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1903.

I hope that helps.

Best regards,

@blueblueyaro
Copy link
Author

Dear jjonkman,

Thanks for your detailed reply. Your answer helps me and now I have some new questions.

  1. According to your third answer, MBC3 transformation should be carried on before azimuth averaging. What can I get after azimuth avg? Are they aforementioned such as AvgAMat?

  2. Chapter 5 in User's Guide for MBC3 shows how to execute MBC3, and I follow it. When I went to step 2 (mbc3,m), there is an error that my variable RotTripletIndicesOutput is empty.
    image
    image
    This variable has been generated in Get_Mats by the following function.
    image
    How can I deal with it?

  3. I know that individual blade pitch control needs MBC transformation, does collective pitch control also need it?

  4. As for my last question yesterday, I may not clearify it enough. In Appendix B in the Technical report, the script shows
    image
    image

  5. When I include ComHydro into linearization, my MATLAB crashed, do you think that caused by my computer performance or MATLAB itself? I thought you may have ever run it successfully.

Thanks again.

BR,
Yaro

@jjonkman
Copy link
Collaborator

Dear @blueblueyaro,

Here are my answers to your questions. I would also suggest that you review the corresponding posts on our forum, where the linearization process has been discussed many times: https://wind.nrel.gov/forum/wind/.

  1. MBC3 transforms the rotating states of a model into the nonrotating frame. Azimuth averaging eliminates the small amount of periodicity that remains after applying MBC3. The azimuth-averaged MBC3-transformed matrices are named MBC.AvgA, etc. by the fx_mbc3.m script.
  2. You should be running fx_mbc3.m for compatibility with the linearization files generated by OpenFAST. It doesn't sound like you are doing that.
  3. A collective pitch input is not in the rotating frame, and so, does not need the multi-blade coordinate transformations applied to that input.
  4. I'm not familiar enough with the report you mention to know what theAmod that you are referring to is, but as I said, what I recommend that you do is apply MBC3, azimuth average, and then eliminate the generator azimuth state, as discussed on our forum.
  5. Can you clarify what is happening? Again, are you running fx_mbc3.m compatible with the linearization files generated by OpenFAST?

Best regards,

@blueblueyaro
Copy link
Author

blueblueyaro commented Aug 24, 2021

Dear jjonkman,
Thanks for your answer, and sorry for my late reply.

  1. I used to be using the old version of script of mbc3. When I apply the new one fx_mbc3.m, my problem was solved, and then a controller implemented. Thanks again!!!

  2. Platform Motion Linearization
    Then I am trying to include more DOFs, and I set the 6 DOFs of platform motion to be TURE. The error shows below.
    image

Then I turned VSContrl from 1 to 0, and I got this
image

How can I deal with this? The time step is 0.0125 and NlinTimes is 36 now.

  1. When I include CompHydro , MATLAB crashed. I paste the diary below.
    image

image

Is this due to my computer or MATLAB?
Thank you very much !!!

BR,
Yaro

@jjonkman
Copy link
Collaborator

Dear @blueblueyaro,

Regarding (2), when you enable the platform DOFs, are you also enabling HydroDyn and MAP++? Otherwise, the platform DOFs will not be restrained and a steady-state solution will not be found. When VSContrl = 1, what is happening to the time series of rotor speed, etc. before this error is obtained? When you set VSContrl = 0, you must select a generator model; which one have you selected and have you set realistic values for its parameters?

Regarding (3), can you clarify how you running OpenFAST (supposedly through the Simulink interface in MATLAB?) and when this error occurs? I see that you've enabled HydroDyn, but not MAP++, so again, the platform DOFs will not be restrained and a steady-state solution will not be found.

Best regards,

@blueblueyaro
Copy link
Author

Dear jjonkman,

Thanks for your answer.

For [2], according to your reply, CompHydro and CompMooring are necessary for Linearization with platform motion DOFs, so I set them to 1. all the settings are shown below.
image
image
And I am also confused about the VSContrl settings, what should they be?
image
Even I tried several combination of VsContrl and GenModel, MATLAB still crashed.

For [3], I ran openFAST through the interface in MATLAB without changing anything in simulink file, it crashed with the command window like this.
image

I noticed that there is something wrong with the section of output in ElastoDyn and AeroDyn, and my settings are like below.
image
image
In addition, according to the Guide, by setting the OutFmt to “ES20.11E3”, the output files will be written with this high resolution. Is it necessary? Should all the OutFmts be changed synchronously?

Thanks again!!

BR,
Yaro

@jjonkman
Copy link
Collaborator

Dear @blueblueyaro,

The setting of VSContrl etc. depends on what you want to do. Are you computing a steady-state solution via CalcSteady = True? What TrimCase have you set? I understand that you want to design a pitch controller, so, presumably you've set CalcSteady = True with TrimCase = 3; is that correct? In this case, it is common to linearize about a constant generator torque, which you can get by setting VSContrl = 1, VS_RtTq = the constant torque you want in Nm (e.g., 43093.55 Nm is the rated generator torque of the NREL 5-MW turbine) and VS_RtGnSp = VS_Rgn2K = VS_SlPc = some small number greater than zero, e.g., 0.001.

The "nodal output" warnings will not effect the simulation results; you can ignore these warning.

Regarding the setting of OutFmt, this guidance applies to the linearization output, which is generated by the OpenFAST glue code. So, only OutFmt from your OpenFAST primary (*.fst) input file needs to have OutFmt set to a high precision.

Can you clarify what you change between a simulation that runs to completion and a simulation where MATLAB crashes? I'm not fully understanding what you are doing.

Best regards,

@blueblueyaro
Copy link
Author

Dear jjonkman,

Thanks for your answer.

I have solved crash problem by setting RdtnMod from 0 to 2 in HydroDyn ( but the hint in MATLAB is RdtnMod = 0 or 2). Now I am trying to linearize openFast with 2 DOFs (GenDOF and PtfmPDOF) enabled.

For what you asked me last time, I paste my settings below for you to check.
image
image

I still have some questions.

  1. ExctnMod can be both 0 or 2, which one should I choose?
    image

  2. It seems that the system won't converge to a small range, how can I determine the operating point? Can I increase TrimTol? If I choose it manually, which piont should I collect?
    image

Thanks again!!

BR,
Yaro

@jjonkman
Copy link
Collaborator

jjonkman commented Sep 8, 2021

Dear @blueblueyaro,

Just to confirm--you are saying that OpenFAST within MATLAB crashes when RdtnMod = 0, but works as expected with RdntMod = 2? I'm not sure what would cause this. Can you share your complete set of input files?

Regarding your direct questions:

  1. You can set ExctnMod to 0 or 2. Use ExctnMod = 0 if are not interested in how wave excitation impacts the linear model through the linear state-space B and D matrices (through disturbance input terms); use ExctnMod = 2 if you want to include such terms.

  2. I would normally expect damping inherent in the system to result in a converged steady-state solution; I'm not sure what is keeping that from happening in your case. I would first suggest to play around with TrimGain to see if that has an effect on the convergence. It is also pretty clear what the steady-state condition of several of the states and inputs should be, i.e., the mean value of the periodic response you are seeing. You could trying using these values (RotSpeed = ( 1174 rpm )/GBRatio, PtfmPitch = 1.8 deg, and BlPitch = 14.7 deg, all in ElastoDyn) as initial conditions to hopefully converge on a steady-state solution sooner.

Best regards.

@blueblueyaro
Copy link
Author

Dear jjonkman,

Your answer helps me a lot. Thank you very much!

I attach the relevant input files below for you. I think it may caused by RdtnMod=0 while ExctnMod=2 with CompHydroDyn enabled.
LinearizationFile.zip
If you find other mistakes in my input files, please let me know.

Further, I found these states in .lin file, what are they for? And can I exclude them when I rearrange state space model for GenDOF and PtfmPDOF with single input collective blade-pitch?
image

BR,
Yaro

@jjonkman
Copy link
Collaborator

jjonkman commented Sep 9, 2021

Dear @blueblueyaro,

OK; thanks for the files. I haven't had a chance to look at them yet, but thanks for clarifying that the problem is likely caused by the mixture of RdtnMod = 0 with ExctnMod = 2. I'll have to think about this one a bit.

Regarding the HydroDyn states (HD RdtnPtfmP#), these are first-order hydrodynamic states that capture the wave-radiation "memory effect", generated by setting RdtnMod = 2. I'm not sure I understand your question about excluding them and rearranging the model, but these radiation states would be important if the "memory effect" is important (likely only for large-volume floaters).

Best regards,

@jjonkman
Copy link
Collaborator

Dear @blueblueyaro,

I ran your model and confirm that OpenFAST v3.0 crashes with an access violation error when the OC4-DeepCwind semi model is linearized with ExctnMod = 2 and RdtnMod = 0. The linearization works as expected with other combinations of ExctnMod and RdtnMod, including ExctnMod = 0 and RdtnMod = 0, ExctnMod = 0 and RdtnMod = 2, and ExctnMod = 2 and RdtnMod = 2. Sounds like a simple bug in the HydroDyn linearization logic. I don’t see anything in the HydroDyn linearization implementation plan that points to a problem with the combination ExctnMod = 2 and RdtnMod = 0. @andrew-platt is currently debugging this; hopefully he can submit a fix soon.

Regarding your model, the only potential issue I saw in my brief review is that you've specified CalcSteady = True with TrimCase = 3 in the OpenFAST primary input file, but you didn't specify constant generator torque in ServoDyn (instead, you've specified the simple variable-speed controller with both control Regions 2 and 3. My August 30, 2021 post above explains how to specify constant generator torque for this type of analysis.

Best regards,

@andrew-platt
Copy link
Collaborator

The way the code is currently structured assumes that RdtnMod==2 during linearization if there are WAMIT bodies. This should be relatively simple to correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants