dear jason
Thank you for your guidance.
I encounter the following error when I call the .lin file in GetMats,Can guide me?
Index exceeds matrix dimensions.
Error in GetMats (line 56)
RotSpeed = str2num( line(55:68) ); % in (rad/s)
Dear Encieh,
You should use the MATLAB script GetMats_f8.m for FAST v8 rather than GetMats.m.
Best regards,
Dear Jason
Thank you so much for answering
I have another question. How can I choose state’s variables? is it always 30? and about control input,how can i choose some of them?
Dear Encieh,
The states in the FAST v8 linearization output are determined by which structural degrees of freedom (DOFs) you’ve enabled in the ElastoDyn module (15 enabled DOFs = 30 states).
Set LinInputs = 1 in the FAST primary input file to include the standard control inputs and wind disturbances described in Table 3 of the FAST v8 ReadMe file (wind.nrel.gov/nwtc/docs/README_FAST8.pdf) in the linearization output.
Best regards,
Dear Dr. @Jason.Jonkman
I am trying to linearize the 5MW atop the OC3 platform in region 3. I followed the linearization section in FAST user guide ( FAST User’s Guide - Updated August 2005 (nrel.gov)). I also set ‘CalcSteady = True’ in addition to setting ‘NLinTimes = 36’ and ‘TrimCase = 3’. Afterwards, I used mbc3.m routine to get the azimuth-averaged state-space matrices. The linearization itself takes places successfully at the rated rotor speed and the correct collective blade pitch angle corresponding to its steady state value in the non-linear simulation at the steady wind speed of interest. However, I have a problem in the low-frequency region as the DC-gain in bode plot of the open-loop from the collective pitch to the rotor speed in the low frequencies should be constant as shown in this post (5MW FOWT linearization issue - #4 by Joannes.Olondriz), which is not the case. I also tried manual linearization without CalcSteady, and I get the same behaviour. Do you have any idea what might be going wrong?
I included the input files in case you needed to have a glance at them.
Best regards,
Amr
Dear @Amr.Hegazy,
From a quick look at your input files, I see that you have not set a constant generator generator in conjunction with TrimCase = 3 in your ServoDyn input file, which we generally recommend.
Also, have you eliminated the generator azimuth state from the linear model before post-processing, e.g., as discussed in the following forum topic: FAST linearization V7 - Wind & Water / Computer-Aided Engineering Software Tools - NREL Forum?
Best regards,
Dear Dr. @Jason.Jonkman
Thanks a lot for your prompt response.
By
you mean that the generator torque is not constant because I did not set VS_RtGnSp, VS_Rgn2K, and VS_SlPc to 9999.9E-9 in the ServoDyn input file, don’t you?
I missed that detail before, but I modified it now. Then, after MBC transformation, I eliminated the rows and columns in AvgA, AvgB and AvgC matrices that correspond to the generator azimuth state. Now, it looks better, thanks to your advice. I have some other questions though.
-
In the eigSol that results from the MBC transformation, are the natural frequencies and the damping ratios arranged to a certain order that correspond to each of the activated DOFs? If I am not mistaken, I think they follow the same order of DOFs in ElastoDyn input file.
-
I have 4 DOFs activated, but I only get 3 natural frequencies after the MBC transformation, although it is mentioned here Learizing Baseline 5MW Wind Turbine with FAST - #2 by Jason.Jonkman that “The generator DOF results in a rigid-body mode, which in MBC3 shows up as a pair of zero-valued (or near-zero-valued) frequencies with +/- inf damping”. Is there an explanation for that?
-
In HydroDyn input file, I set ExctnMod and RdtnMod to 0, which means that the hydrodynamic contribution is not included in the dynamics matrices, doesn’t it?. To consider their effect, ExctnMod and RdtnMod should be set to 2 instead, right? May you share the *.ss file for the OC3 to serve as a reference, please?
Best regards,
Dear @Amr.Hegazy,
Yes, that is what I meant regarding setting constant generator torque. And I’m glad fixing that and eliminating the generator azimuth state solved your issue.
Regarding your new questions:
-
No, the
MBC.eigSoldata contains the results of the MATLABEigfunction, which are not sorted in a physical way. Only the results with positive imaginary parts (non rigid-body modes with damping < 1) are saved. You can use the cambell_diagram_data.m script and visualization functionality to aid in interpretation of the modes. See the documentation here for more information: GitHub - OpenFAST/matlab-toolbox: Collection of Matlab tools developed for use with OpenFAST. -
The post you are referring to applied to an older version of the MBC3 script. In the current version of MBC3 for OpenFAST in the MATLAB Toolbox (fx_mbc3.m), only the the results with positive imaginary parts (non rigid-body modes with damping < 1) are saved.
-
Sample hydrodynamic state-space files for the OC3-Hywind spar are provided in the respective SS_Fitting (for wave radiation) and SS_Excitation_Fitting (for wave excitation) archives. You can find the SS_Fitting archive here: SS_Fitting | Wind Research | NREL. And I recall sending you the SS_Excitation_Fitting archive via WeTransfer per the following forum topic: WAMIT .ss file.
Best regards,
Dear Dr. @Jason.Jonkman,
Thanks so much for your help!
Regarding the third point, I confirm receiving the archive via WeTransfer. I was just wondering if you can share the *.ss file that you generated using SS_Fitting on the *.1 WAMIT file to serve as a reference to me when I use SS_Fitting myself. I managed to get a reference *.ssexctn file that you shared on this thread Wave Excitation model generation in state-space (*.ssexctn input file) · Issue #397 · OpenFAST/openfast · GitHub.
Best regards,
Dear @Amr.Hegazy,
That is available in the SS_Fitting archive found here: SS_Fitting | Wind Research | NREL.
Best regards,
Dear Dr. @Jason.Jonkman
- I am using OpenFAST v3.0. Whenever I try to linearize with ExctnMod, RdtnMod = 2, the simulation stops and does not continue as shown in the first image. If I set ExctnMod, RdtnMod = 0, the simulation works fine and I get *.lin files, but that does not make sense for a floating turbine since I will be neglecting hydrodynamic wave excitation and radiation in such situation. Then, I used v2.6. to perform the same simulation with ExctnMod, RdtnMod = 2, and it works as shown in the second image. Do you know what might be the reason?
- I was also wondering if the issue reported here ( Obtaining sensitivity of aerodynamic power to rotor-collective blade pitch - Wind & Water / Controls - NREL Forum) would have any effect on the linear models obtained from v3.0? Do you recommend using v2.6 or upgrading to the latest version?
Thanks for your help!
Best regards,
Dear @Amr.Hegazy
Regarding the state-space hydrodynamics, are you saying that OpenFAST v3.0 just stops when selecting ExctnMod = RdtnMod = 2 whereas OpenFAST v2.6 works with these settings? Have you tried upgrading to OpenFAST v3.2; does ExctnMod = RdtnMod = 2 work with that version? I’m not aware of this potential issue, but if the newest version of OpenFAST is stopping when ExctnMod = RdtnMod = 2, can you post the issue on the OpenFAST issues page and share your model: Issues · OpenFAST/openfast · GitHub?
Regarding the AeroDyn linearization reported in Bug report: AeroDyn Write Output Not Appearing in Linearization · Issue #972 · OpenFAST/openfast · GitHub, a fix has been implemented in Fix AeroDyn WriteOutput linearization (and cleanup some code) by bjonkman · Pull Request #1061 · OpenFAST/openfast · GitHub, but this pull request has not yet been merged into the dev or main branches. From the pull request, it looks like it is slated for the upcoming release of OpenFAST v3.4. Until then, the OpenFAST linearization is usable, except for the C and D matrices associated with the write outputs (OutList) of AeroDyn.
Best regards,
Dear Dr. @Jason.Jonkman
Yes, that’s what happens exactly. Initially, that would happen that the simulation stops once it reaches the state-space hydrodynamics as shown in the next image (which was in the previous post too).
Afterwards, I would try to run it again in the command prompt a couple of times getting the same outcome, but at some point I get an error (shown in the next image)
Then, I run it again, and it works normally without resulting in that initialization error. That happened with OpenFAST v2.6, v.3.0, v3.2.1
However, it might be related to the operating system somehow. As, I was trying to run OpenFAST on Windows 11 machine, but when I run it on Windows 10, it runs normally! Do you think it has anything to do with that? As I don’t want to post the issue before being 100% sure.
Regarding AeroDyn lineariaztion, I was interested in getting the aerodynamic sensitivities with respect to the states and the inputs. According to what you are saying, I can’t also rely on OpenFAST v3.2. When I use v2.6 though, the standard inputs from AeroDyn in the *.lin files look like the image below, and fx_getMats.m returns an error as a result.
This doesn’t happen though if I use OpenFAST v3.0 or v3.2.1, but I can’t use them to get the sensitivities in that case. Do you know to solve this problem?
- One final question, if I would like to get the sensitivity of the aerodynamic torque and the thrust force with respect to the states and inputs, which AeroDyn outputs should I use? Are they RtAeroFxh and RtAeroMyh for surge and pitch DOFs?
Best regards,
Dear @Amr.Hegazy,
Regarding OpenFAST stopping, I would never expect OpenFAST to respond differently when ran with the same input file. Are you using the precompiled binary executable provided with the release of OpenFAST or did you compile yourself? Can you share the full message written to the Windows command prompt when executing?
The inclusion of the “NUL” characters associated with the UserProp inputs to AeroDyn in the linearization output files was fixed after OpenFAST v2.6. Regarding the aerodynamic sensitivities, you can get the Jacobians relating the states and inputs to the state derivatives and outputs for everything except the AeroDyn write outputs (those associated with OutList). If you need the AeroDyn linearization fix sooner, you can recompile with the fix found in Fix AeroDyn WriteOutput linearization (and cleanup some code) by bjonkman · Pull Request #1061 · OpenFAST/openfast · GitHub.
Yes, RtAeroFxh and RtAeroMyh are the aerodynamic thrust and torque, respectively.
Best regards,
Dear Dr. @Jason.Jonkman,
Thanks a lot for your thorough explanation.
I don’t expect that either, but I don’t know why it is behaving in such a way.
I compiled it myself, and here is the full message written to the command prompt.
One other thing that I found as well is that I get the error message below when I set InterpOrder = 1.
I don’t know what InterpOrder has to do with all of this.
Regarding the UserProp inputs to AeroDyn, can they be removed from the input vector during linearization?
Best regards,
Dear @Amr.Hegazy,
How do you compile OpenFAST? Have you made changes to the source code?
Do you run into the same issues when you run the precompiled binary executable(s) of OpenFAST for Windows distributed by NREL through the release page: Releases · OpenFAST/openfast · GitHub (i.e., openfast_x64.exe)?
Regarding linearization and UserProp, you can always ignore the rows and columns associated with the inputs you don’t need. To get the linearization file with “NUL” characters to be post-processed by MBC3 scripts by replacing the characters by valid text.
Best regards,
Dear Dr. @Jason.Jonkman,
I compiled it following this page: 3.2.4.4.1. Windows with Visual Studio regression test — OpenFAST v3.3.0 documentation. I didn’t make any changes to the source code.
The issue persists when I use the precompiled executables. Probably, it would be better if you can give it a try if you have time indeed. So, here are my input files. https://drive.google.com/file/d/1XeHwGOzW3jsm4aB7kxS3aGIG54mJz-hJ/view?usp=sharing
I also found something else regarding the *.lin files. I found out that some of the outputs in output vector in the *.lin files look like row 103 in the image. That will not allow the fx_getMats.m to run, and thus fx_mbc3.m. Those outputs are not of any interest since their corresponding DOFs are turned off. I don’t know if you have run into something similar or not. A simple work solution was that I added a few lines to fx_getMats.m script to replace those (**) characters with zeros.
Dear @Amr.Hegazy,
Can you share your input files compatible with OpenFAST v3.2? I’d like to run with the newest version.
Asterisks will appear in an output file if the value to be output cannot be displayed in the specified format, based on input parameter OutFmt in the OpenFAST primary (*.fst) input file.
Best regards,
Dear Dr. @Jason.Jonkman,
Here are the ones for OpenFAST v3.2 InputFiles.zip - Google Drive
Regarding OutFmt, I set it to “ES20.11E3” as you recommended in one of the posts. What would be the setting that would ensure that asterisks never appear?
Best regards,
Dear @Amr.Hegazy,
I downloaded your input files and ran the simulation with the precompiled OpenFAST v.3.2.1 executable for Windows found here: https://github.com/OpenFAST/openfast/releases/download/v3.2.1/openfast_x64.exe. I ran it several times and can’t get the simulation to stop prematurely, I don’t see any issue with InterOrder = 1, I don’t see “NUL” characters in the UserProp input descriptions, and I don’t see asterisks in the HD HydroMzi output, at least for the 5MW_OC3Spar_DLL_WTurb_WavesIrr.1.lin file that I checked. Did you change any of the input files to trigger the issues?
Best regards,