hello,Jason
I have a problem about the prebent blade.I want to calculate the long prebent blade in my FAST model,I want to use the BeamDyn originally,but the convergence problem occured when i use the beamdyn,I have to give up the beamdyn option,I choose the ElastDyn to calcualte the blade dynamic. But i want to use the Aerodyn15. In aerodyn15,We must input the parameter like BlCrvAC , BlCrvAng and so on .As I know,the ElastDyn can calculate the blade without prebending. But aerodyn15 calculate the aerodynamic load by the prebent blade we define.
Is it reasonable to use the ElastDyn and prebent Aerodyn15?
How did the two moudle work about the prebent blade ? Could the ElastDyn calculate the blade by prebending in aerodyn15?
Convergence error happended frequently when I use BeamDyn.Do you have some good advices about how to build own prebent blade BeamDyn model in order to avoid the convergence problem. To be honest ,the converagence problem is boring.
Best regard
Ruiliang.Wang
Dear Ruiliang,
The mesh-mapping functionality of FAST permits each module to have its own statial discretization and spatial extent. This functionality allows one to transfer motions and loads between ElastoDyn, which assumes an initially straight blade, and AeroDyn v15, which permits the modeling of precurved and preswept blades. See the following papers for more information on the mesh-mapping functionality of FAST: nrel.gov/docs/fy16osti/63203.pdf.
There are several topics on this forum that have discussed how to set up BeamDyn to model precurved or preswept blades e.g. see: pre-bended & sweep blade simulation with BeamDyn &aerodyn 15 - #4 by Jason.Jonkman. Have you already followed this advice? Also, which version of FAST are you using? There have a been a number of improvements in BeamDyn and AeroDyn in the upgrade from FAST v8.16 and OpenFAST v1.0.0 and newer.
Best regards,
Hello,Jason
It help me a lot .I am using OpenFAST-1.0.0.Recently I am trying to recompiling OpenFAST by VS2013 and IVF2013.I do nothing changed,But error happened like below
错误 27 error PRJ0019: A tool returned an error code from "Running Registry for InflowWind" Project
错误 28 error #7002: Error in opening the compiled module file. Check INCLUDE paths. [FAST_SUBS] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 39
错误 29 error #6683: A kind type parameter must be a compile-time constant. [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 31 error #6592: This symbol must be a defined parameter, an enumerator, or an argument of an inquiry function that evaluates to a compile-time constant. [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 32 error #6975: A kind-param must be a digit-string or a scalar-int-constant-name [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 33 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 45
错误 34 error #6457: This derived type name has not been declared. [FAST_TURBINETYPE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 48
错误 35 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 50
错误 36 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 51
错误 37 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 52
错误 38 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 58
错误 39 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 164
错误 40 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 169
错误 41 error #6404: This name does not have a type, and must have an explicit type. [PROGNAME] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 64
错误 43 error #6632: Keyword arguments are invalid without an explicit interface. [FLAG] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 67
错误 44 error #6404: This name does not have a type, and must have an explicit type. [TURBINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 70
错误 46 error #6363: The intrinsic data types of the arguments must be the same. [MOD] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 117
错误 47 error #6362: The data types of the argument(s) are invalid. [TRIM] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 118
The “Running Registry for InflowWind” error happened in the FASTlib,and others in FAST.
but I can compile FAST8.16 normally.
Can you give me some suggestions?
Best Regard
Ruiliang.Wang
Dear Ruiliang,
It looks like the FAST Registry didn’t run. Are you using the Visual Studio project provided with OpenFAST v1.0.0?
Best regards,
hello,Jason
Yes, I’m using the the Visual Studio project named FAST.vfproj in vs-build folder provided with OpenFAST v1.0.0 what i download from github relases.
Best Regard
Ruiliang.Wang
Dear Ruiliang,
You are showing errors 27-47; what are the errors 1-26?
Did you try closing the Visual Studio project, reopening it, and try compiling again?
Best regards,
Dear Jason.
The whole errors and warnning are displayed below
警告 1 warning C4101: “q”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\data.c 141 1 FAST_Registry
警告 2 warning C4101: “tmp2”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\misc.c 186 1 FAST_Registry
警告 3 warning C4013: “getpid”未定义；假设外部返回 int D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\misc.c 419 1 FAST_Registry
警告 4 warning C4013: “getpid”未定义；假设外部返回 int D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\registry.c 38 1 FAST_Registry
警告 5 warning C4102: “normal”: 未引用的标签 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 267 1 FAST_Registry
警告 6 warning C4101: “is4d”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 66 1 FAST_Registry
警告 7 warning C4101: “found”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 61 1 FAST_Registry
警告 8 warning C4101: “xstr”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 65 1 FAST_Registry
警告 9 warning C4101: “x”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 65 1 FAST_Registry
警告 10 warning C4101: “newdims”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 63 1 FAST_Registry
警告 11 warning C4101: “len_of_tok”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 64 1 FAST_Registry
警告 12 warning C4101: “toktmp”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 63 1 FAST_Registry
警告 13 warning C4101: “ii”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 64 1 FAST_Registry
警告 14 warning C4101: “newdims4d”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 63 1 FAST_Registry
警告 15 warning C4101: “wantstend”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 66 1 FAST_Registry
警告 16 warning C4101: “newname”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 63 1 FAST_Registry
警告 17 warning C4101: “wantsbdy”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 66 1 FAST_Registry
警告 18 warning C4101: “toktmp”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 282 1 FAST_Registry
警告 19 warning C4101: “q”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 281 1 FAST_Registry
警告 20 warning C4101: “ii”: 未引用的局部变量 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 283 1 FAST_Registry
警告 21 warning C4018: “<”: 有符号/无符号不匹配 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-local\fast-registry\src\reg_parse.c 623 1 FAST_Registry
警告 22 warning : derived data type Ver of type progdesc is not passed through C interface D:\Software\openfast-1.0.0\openfast-1.0.0\vs-build\MAPlib\CUSTOMBUILD MAP_dll
警告 23 warning : derived data type PtFairDisplacement of type meshtype is not passed through C interface D:\Software\openfast-1.0.0\openfast-1.0.0\vs-build\MAPlib\CUSTOMBUILD MAP_dll
警告 24 warning : derived data type ptFairleadLoad of type meshtype is not passed through C interface D:\Software\openfast-1.0.0\openfast-1.0.0\vs-build\MAPlib\CUSTOMBUILD MAP_dll
警告 25 warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失 d:\software\openfast-1.0.0\openfast-1.0.0\modules-ext\map\src\mapapi.h 1 1 MAP_dll
警告 26 warning C4005: “NDEBUG”: 宏重定义 D:\Software\openfast-1.0.0\openfast-1.0.0\modules-ext\map\src\simclist\simclist.c 74 1 MAP_dll
错误 27 error PRJ0019: A tool returned an error code from "Running Registry for InflowWind" Project
错误 28 error #7002: Error in opening the compiled module file. Check INCLUDE paths. [FAST_SUBS] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 39
错误 29 error #6683: A kind type parameter must be a compile-time constant. [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
警告 30 warning #8586: Implicit type is given to allow out-of-order declaration. Non-standard extension. [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 31 error #6592: This symbol must be a defined parameter, an enumerator, or an argument of an inquiry function that evaluates to a compile-time constant. [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 32 error #6975: A kind-param must be a digit-string or a scalar-int-constant-name [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 33 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 45
错误 34 error #6457: This derived type name has not been declared. [FAST_TURBINETYPE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 48
错误 35 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 50
错误 36 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 51
错误 37 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 52
错误 38 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 58
错误 39 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 164
错误 40 error #6683: A kind type parameter must be a compile-time constant. [INTKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 169
错误 41 error #6404: This name does not have a type, and must have an explicit type. [PROGNAME] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 64
警告 42 warning #6931: Fortran 2003 does not allow this assignment statement. ['FAST'] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 64
错误 43 error #6632: Keyword arguments are invalid without an explicit interface. [FLAG] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 67
错误 44 error #6404: This name does not have a type, and must have an explicit type. [TURBINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 70
警告 45 warning #6187: Fortran 2003 requires an INTEGER data type in this context. [N_TMAX_M1] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 111
错误 46 error #6363: The intrinsic data types of the arguments must be the same. [MOD] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 117
错误 47 error #6362: The data types of the argument(s) are invalid. [TRIM] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 118
错误 48 error #6404: This name does not have a type, and must have an explicit type. [NUM2LSTR] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 118
错误 49 error #6362: The data types of the argument(s) are invalid. [TRIM] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 118
错误 50 error #6404: This name does not have a type, and must have an explicit type. [ABORTERRLEV] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 121
错误 51 error #6404: This name does not have a type, and must have an explicit type. [ERRID_SEVERE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 121
错误 52 error #6363: The intrinsic data types of the arguments must be the same. [MIN] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 122
错误 53 error #6404: This name does not have a type, and must have an explicit type. [NEWLINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 123
错误 54 error #6054: A CHARACTER data type is required in this context. [NEWLINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 123
错误 55 error #6404: This name does not have a type, and must have an explicit type. [ERRID_NONE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 153
错误 56 error #6404: This name does not have a type, and must have an explicit type. [DBKI] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 44
错误 57 error #6054: A CHARACTER data type is required in this context. [NEWLINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 173
错误 58 error #6054: A CHARACTER data type is required in this context. [NEWLINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 173
错误 59 error #6837: The leftmost part-ref in a data-ref can not be a function reference. [TURBINE] D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 179
错误 60 Compilation Aborted (code 1) D:\Software\openfast-1.0.0\openfast-1.0.0\glue-codes\FAST\src\FAST_Prog.f90 1
I try for many times ,I think there are something wrong in VS setting? Do I need special setting in VS tool?
The “引用的局部变量” is unreferenced local variables.
Best Regard
Ruiliang.Wang
Dear Ruiliang,
What is reported in the Output window in Visual Studio when you try to compile?
Best regards,
Dear Jason and all,
Currently I am working on an onshore turbine with prebent rotor using ElastoDyn+BeamDyn. For the convergence issue, I kept the glue code time step as 0.0001 and its taking a humongous amount of time. Is there any possible ways to reduce the simulation time while coupled with BeamDyn?
When I tried to simulate an entire power production DLC, some of the simulations are aborting in the middle due to convergence. Could it be solved by changing NRMax input from default(10) to a higher value?
Thanks and regards
Abhinay Goga
Dear Abhinay,
The small time step requirement is driven by frequencies transferred between BeamDyn and ElastoDyn. The only way to increase the time step is reduce that very high frequency in some way, e.g. by reducing the stiffness (are all stiffness values specified realistic or are some made up and artificially high?) or eliminating the structural DOFs that result in the very high frequency, e.g., dropping order_elem.
I would suggest identifying the troublesome high frequency through an OpenFAST linearization analysis to understand the source of the problem. This should provide insight on how best to solve it.
I generally don’t touch the BeamDyn inputs in the SIMULATION CONTROL section of the primary input file. It may be that the time step is indeed higher than it should be and reducing the time step further would solve the problem.
Please note that there is a known issue in BeamDyn associated with blades with prebend. Until this bug is fixed, I would use caution interpreting the results of a BeamDyn model with a prebent blades.
Best regards,
Dear Jason,
Thanks for the insights. I will use caution while working with BeamDyn. Could you please explain or guide me to a thread where I can learn more about this bug that you mentioned. My present aim is to work with a prebent blade. The Stiffness matrix of the blade sections are well defined as well as the axis inputs for the prebent curve are adjusted for a smooth curve.
I will follow your suggestion for switching of the DOFs in ElastoDyn. I am relatively new to linearization analysis. After the initial linearization, there are certain .lin files containing Linearized state matrices. Using matlab I calculated eigen frequencies for the resulting matrices. Is there any material where can I understand how to analyze the results for identifying the troublesome frequencies for my setup? Your guidance is always well appreciated.
Kind regards
Abhinay Goga
Dear Abhinay,
The known issues in BeamDyn are summarized well in the following issue on the OpenFAST github site: github.com/OpenFAST/openfast/issues/366.
There have been many discussions about how to interpret the results of linearization analysis, both here on this forum as well as on the OpenFAST issues page: github.com/OpenFAST/openfast/issues. I would suggest searching for “linearization”, “MBC3”, “Eigenanalysis”, and/or “Campbell”.
Best regards,
Dear Jason,
I am facing exactly the same issue of convergence for some simulations, with OpenFASTv2.3.0 and a time step of 0.0001s
‘‘FAST_Solution:FAST_AdvanceStates:B1:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after
the maximum number of iterations
FAST encountered an error at simulation time 324.34 of 650 seconds.
Simulation error level: FATAL ERROR
Aborting OpenFAST.’’
Correct me, if I am wrong. Through linearization I obtained state matrices. Considering: Mod(A-lamda*I)*X=0 , I have obtained eigen vector. Using FFT, I can obtain natural frequencies, right? In your previous comment you mentioned ‘dropping order_elem’. Did you mean to reduce the value in BeamDyn input? Currently, I am using a value of 4.
I am not sure, if I understand you correct or not. In the thread ‘BeamDyn - Solution does not converge after the maximum number of iterations · Issue #366 · OpenFAST/openfast · GitHub’ you mentioned that for linearization analysis parked/idling is sufficient. But to calculate the operational frequencies the turbine needs to be in operational condition, right?
Thanks and kind regards
Abhinay Goga
Dear Abhinay,
Yes, you can obtain the natural frequencies both through an eigenanalysis and through FFT of the time series, but it is typically far easier to obtain all of the natural frequencies and damping and to interpret the eigenmodes through an eigenanalysis. (With an FFT analysis, you’ll need to ensure that the modes get excited and it is often difficult to interpret and to quantify the damping level.)
A value of OrderElem = 4 is already quite low, so, I’m a bit surprised such a small time step is required. Are all of the mass and stiffness values in your BeamDyn model set to physically correct values?
Calculating the natural frequencies in a parked/idling condition is more straightforward than in the operational condition and should provide insight into which modes are introducing high frequencies and the associated time-step requirements. Certainly the natural frequencies during operation will differ a bit, with some frequencies increasing and some decreasing with rotational speed due to, e.g., centrifugal stiffening. But I would analyze the parked/idling condition before moving to an eigenanalysis in an operational condition.
Best regards,
Dear Jason,
With the insights from previous threads on Natural frequencies, using MBC3 script I have calculated the natural frequencies. Parked DLC with exclusion of Aero and Inflow(Only Elasto, Beam and Servo activated), and the linearization performed for debug (all inputs, outputs & inclusion of Jacobians).
But I am not completely sure what I am looking at. Could you please explain anything from the results that I attached.
The damping coefficients are of the order of -03 and blade distributed properties for the assigned sections are relatively correct. I understood that because of a certain bug in BeamDyn, when the blades experience edgewise loads the resulting forces near the tip section are inaccurate. But I would very much like to increase the time step from 0.0001 to at least 0.001. Any guidance in this direction is very much appreciated.
Thanks and kinds regards
Abhinay Goga
Natural frequencies.txt (1.85 KB)
Der Abhinay,
All you’ve attached is the list of natural frequencies. Are these in Hz or rad/s? You’ll need to examine the eigenvectors (and/or visualize the mode shape) to properly interpret the result. The runCampbell.m script can be used to generate an XLS or CSV file to aid in interpretation.
Best regards,
Dear Jason,
The attached natural frequencies are in Hz. With your suggestion, using the runCampbell script I did linearization for 4 operating points. (LinearizationPoints_Servo file considered from example directory) The Campbell plot script is running but not producing any results. Here in the following attaching the csv files for Operating point 1,2 and Mode number table. Any insights to figure out the high frequencies, thereby to reduce the time step for simulation would be very much appreciated.
Thanks and kind reagards
Abhinay Goga
Campbell_Point01.csv (2.61 MB)
Campbell_ModesID.csv (975 Bytes)
Campbell_Point02.csv (4.78 MB)
Dear Abhinay,
A natural frequency of 128 Hz would imply a time step requirement of DT = 1/(10*128) = 0.00078 s. However you likely have many modes of higher frequency than that, which are not showing up in your CSV file because they are above critical damping. Regardless, these modes may be requiring a smaller time step.
Regardless, your results don’t really make sense to me given how you described your BeamDyn model. You said you were using order_elem = 4, which would imply 5 finite-element nodes (the root being fixed to the hub), which means the CSV file should show BeamDyn modes associated with finite element nodes 2-6. However, your CSV shows that the highest finite element node is 17. Are you sure you are not using order_elem = 16? Or perhaps you are using multiple finite elements / members (member_total > 1)? Reducing the number of finite elements / members and/or reducing order_element will result in a lower range of natural frequencies, which should allow for the use of a small time step.
Best regards,
Dear Jason,
As you mentioned, I used member_total 4 in the previous simulations with 34 key points (kp_total). After your comment, I tired with member_total 1, and the simulation runs with 0.0003s (previously it was 0.0001).
What could be the possible reason for such very high frequencies? Blade structural properties in BeamDyn_Blade? Or any other input parameters in FAST setup?
I am not entirely sure, if my understanding is correct. For a simulation (BeamDyn included), does FAST calls for blade inputs from both ElastoDyn blade file and BeamDyn_Blade file, then compare or perform something for convergence between ElastoDyn and BeamDyn? If so, then the inputs for the both files need to be similar right?
Thanks and kind regards
Abhinay Goga
Dear Abhinay,
In general, I recommend running BeamDyn with one member (one finite element) and with a sufficiently high element order (order_elem = 5-8) to obtain convergence (“p” refinement instead of “h” refinement). A lower order_elem will allow for lower time steps. Higher order_elem will introduce higher frequency modes that require a smaller time step. The blade structural properties (mass and stiffness) also plays a large role in the natural frequencies and time-step requirement.
When BeamDyn is enabled (CompElast = 2), the blade-related inputs in ElastoDyn (DOFs, initial conditions, tip radius , tip masses, blade nodes, blade files, blade outputs) are not used; instead, these come from the BeamDyn-related inputs.
Best regards,