I am trying to run IEA-15-240-RWT-UMaineSemi.fst but getting following errors.
- I have downloaded IEA-15-240-RWT-UMaineSemi from GitHub - IEAWindTask37/IEA-15-240-RWT: 15MW reference wind turbine repository developed in conjunction with IEA Wind
- I am using OpenFast 3.4.1
I have checked the error and found differences in inflow files in Openfast 3.4.1 and UmaineSemi folder
I require guidance and help in resolving this.
It looks like you are using input files compatible with OpenFAST 3.5 while running OpenFAST v3.4.1. InflowWind input
VelInterpCubic was added in OpenFAST v3.5.0, as well as other inputs. The input file changes with each version of OpenFAST are documented here: 4.1.2. API changes between versions — OpenFAST v3.5.1 documentation. Unless you have a strong reason to use an older version, I recommend upgrading to the newest version of OpenFAST (currently v3.5.1, which uses the same input files as v3.5.0).
Thanks for the detailed response.
I tried it with FAST 3.5.1 but it had some other errors popping up. I dig into the errors and found that
. CompSeaSt added as a flag in v3.5.1 which is not present in IEA-15-240-RWT-UMaineSemi
. SeaState.dat available as a separate file in v3.5.1 but in IEA-15-240-RWT-UMaineSemi SeaState parameters are part of IEA-15-240-RWT-UMaineSemi_HydroDyn.dat
I want to help on these:
- If I accommodate all the changes and get the IEA-15-240-RWT-UMaineSemi executing and generating results, how can be I sure that the results I get will be correct.
The SeaState module of OpenFAST will be released in OpenFAST v4.0; it is not included in OpenFAST v3.5.1. If you have an OpenFAST primary (.fst) input file with
CompSeaSt and a SeaState input file, you must be using input files compatible with a newer version of OpenFAST than v3.5.1. Unless you have a strong reason to use this newer version, I suggest using v3.5.1.
Thanks @Jason.Jonkman for looking into it.
I am just referring to the error messages I was getting when trying the IEA-15-240-RWT-UMaineSemi with OpenFast 3.5.1
I just wanted to know that while converting IEA-15-240-RWT-UMaineSemi files for OpenFast 3.5.1, I simply add the lines to appropriate files, on correct lines (as per the order required by OpenFast 3.5.1).
How will I verify that the results generated after following 4.1.2. API changes between versions — OpenFAST v3.5.1 documentation and getting a error free execution are correct?
I agree with your statements generally, but again, SeaState is not included in OpenFAST v3.5.1. I would guess that your input files are for a newer version (like the dev branch).
To ensure that OpenFAST is running properly, you can execute the r-test.
Thanks for the response. I will first try to make appropriate changes to IEA-15-240-RWT-UMaineSemi in order to get error free execution of the IEA-15-240-RWT-UMaineSemi.fst on OpenFast 3.5.1.
You were right regarding presence of CompSeaSt in .fst and SeaState.dat file. These doesnt belong to openfast 3.5.1.
I was following the instructions as per 184.108.40.206.1. Windows with Visual Studio regression test — OpenFAST v3.5.1 documentation and was always getting SeaState file in offshore cases folder i.e. r-test\glue-codes\openfast\5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth, 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti etc.
I have found that if I skip “220.127.116.11.1.1 (e) git checkout dev” in the above link, and just proceed to 18.104.22.168.1 (f) and onwards, there are no SeaState file in offshore cases folders.
Also, now I am able to have openfast execution for for IEA-15-240-RWT-UMaineSemi.fst “terminated normally”
I have one query. What value for TrimTol is sufficient for computation of linear model?
I am trying to linearize 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti with the following settings:
I executed the simulation for 3000sec resulting in following error
I tried different TrimTol values and found linearmodels with TrimTol 0.1
The time response of rotor rpm is similar and convergent for all TrimTol cases.
I would think the default
TrimTol of 0.001 should generally be sufficient for most models. By increasing
TrimTol, you can likely find a steady-state solution quicker, but the solution may not be converged as well. You can always plot the time series to see if the convergence is sufficient.
Thanks @Jason.Jonkman for the response.
I have checked the timeseries and it seems to be attaining steady state.
However, the variation in RPM at steady state is 0.007 RPM which might be the reason that no linear model is being generated with a TrimTol of 0.001.
Can you suggest anything to reduce this oscillation.
With TrimTol = 0.001, the time series plots
I agree that the model is converging. Regarding the oscillations in
RotSpeed, do you have the drivetrain torsion degree of freedom enabled (
DrTrDOF = TRUE)? If so, I would guess the oscillation is coming from that mode, which appears to have very little damping, and thus, would take a long time to damp out. Disabling
DrTrDOF (if that is OK for this case) is likely a solution to that. Increasing
TrimTol is likely also sufficient to avoid the long wait.
Thanks @Jason.Jonkman for the response.
I have done the suggested changes and results have improved in terms of
. RPM oscillation reduction, and
. Convergence time
I was only able to use TrimTol = 0.01, since the pattern in RPM was not getting reducing below this.
However, the overall pattern seems to be having good convergence.
I am trying to find linear models for 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti for Above Rated case. The time series response of non linear simulation is convergent.
However the linear model is unstable.
The simulation completes in a normal way and .lin files are generated
I execute postproLin_OneOP.m and get mbc_data.AvgA, mbc_data.AvgB, mbc_data.AvgC, mbc_data.AvgD
When I make transfer function with these matrices in MATLAB
sys = ss(mbc_data.AvgA,mbc_data.AvgB,mbc_data.AvgC,mbc_data.AvgD);
On executing damp(sys), to analyse the poles and damping of poles, I am getting an unstable pole.
I am having no idea as to why this is happening.
The rigid-body mode of the generator state, which has no (or little) stiffness (from aerodynamics), can result in +/- unity damping. You can eliminate this mode by either disabling the generator degree of freedom before linearization (GenDOF = FALSE) or by removing the generator-azimuth state (while keeping the generator speed state) after linearization. This topic has been discussed several times on this forum, e.g., see: Interpretation of state vector - #8 by Judith.Hess.
Thanks for the response.
I have gone through the provided link and it was quite helpful.
I now have a stable transfer function in above rated case.
I am facing problems in linearization of IEA 15-240-RWT-UMaineSemi on OpenFast 3.5.1 and would require help.
I am executing linearization for below rated case i.e.
Wind Speed = 10m/s
Rotational Speed = 6 rpm
I am getting a lot of unstable poles in linear models.
Linear Model States description
Linear Model Damping in Matlab
The time series plots of the above mentioned linearization are stable and converging