Dear Jason,

Thanks for the informative insights. I kept total number of members to 1 with 34 key points. (Hoping that the number of key points doesn’t effect the simulation time-step. I made sure that the curve is smoother) Order_elem as 4 initially.

In the OpenFAST guide section 4.5.3.4, there is clear description for how to calculate the stiffness and sectional mass matrices. Previously used values are calculated using BLADED. Now I self calculated using excel and implemented the new matrices. The solutions does not coverges even for 0.00001s

And I can’t even perform linearization to calculate natural frequencies cause the solution is not converging. Any guidance on this situation?

Thanks and kind regards

Abhinay Goga

Dear Abhinay,

Well, it now sounds like there may be an issue with your sectional mass and stiffness matrices. To make sure the blade is responding as expected, I would recommend running standalone BeamDyn with the BeamDyn driver (uncoupled from OpenFAST) and make sure simple responses, e.g. applied tip loads, give the expected deflection.

Best regards,

Dear Jason and Bonnie,

The following question is off-topic from this thread. But I haven’t found any relevant threads for standalone BeamDyn driver. From the github repository (github.com/old-NWTC/BeamDyn) downloaded the data. It doesn’t contain any BeamDyn driver binaries directly to use. I tried recompiling with visual studio. Faced with the following errors.

''Error Error running FAST Registry for BeamDyn. T:\Software archive\BeamDyn-master\source\Registry_BeamDyn.txt 1

Error error PRJ0019: A tool returned an error code from “Running Registry for BeamDyn” Project ‘’

Using notepad++ I verified that both registry.bat and .txt files are with windows line endings(CR LF). In a different thread (github.com/OpenFAST/openfast/issues/152) there was discussion about a similar error. I have understood that the error can be cleared out by relocating the following lines somehow.

‘:BeamDyn

SET CURR_LOC=%BD_Loc%

%REGISTRY% “%CURR_LOC%\Registry_BeamDyn.txt” -I “%NWTC_Lib_Loc%” -O “%CURR_LOC%”

GOTO checkError’

After many trail and errors, its still not a success. Any assistance in this regard much appreciated.

Thanks and kind regards

Dear Abhinay,

BeamDyn has been extensively updated in the OpenFAST repository, so, I wouldn’t take BeamDyn files form the old-NWTC archive. I would recommend posting compiling-related questions on the OpenFAST github issues page: github.com/OpenFAST/openfast/issues.

Best regards,

Dear Jason,

Outside the old NWTC library, is there any repository for BeamDyn standalone direct binaries or source code for recompilation? Myself, I wasn’t able to find any other sources.

Thanks and kind regards

Dear Abhinay,

No, NREL has not been releasing compiled Windows binaries of the standalone module-level drivers in OpenFAST.

Best regards,

Dear Jason,

Thanks for the info. I have shared the issue on github. I will recompile the driver myself. As you mentioned old NWTC library is really old (last updated 4 years ago)

When recompiling can I use BeamDyn source file and directories from OpenFAST library, instead of old NWTC ones? What I meant to ask is, will the OpenFAST dependencies source code can be used for standalone model!?

Thanks and kind regards

Dear Abhinay,

Yes, all of the source code and compile scripts for compiling the standalone module-level drivers for BeamDyn and other modules is available in the OpenFAST repository. It is only the compiled Windows executables of the standalone drivers that are not released.

Best regards,

Dear Jason,

Once again thanks for the informative insights. I am able to compile the standalone BeamDyn driver. The balde structure with lesser order_elem say 4, the solution converges even for a time step of 0.01s. As you explained, with the increase in mesh elements (through iterations I verified upto 30) the convergence required a considerably larger time step of 0.002s. So, I can’t understand the reason for extremely larger time step when coupled with FAST even for very less order_elem. Could you please guide me through, how can I verify the possible reasons for such requirements?

Thanks and kind regards

Dear Abhinay,

Are you saying that you can run your simulation with order_elem = 4 with a time step of 0.01 s in BeamDyn standalone and 0.002 s when BeamDyn is coupled to OpenFAST? This difference generally makes sense to me. The BeamDyn module itself uses a stiff integrator (generalized alpha), which allows time steps larger than what is dictated by the natural frequencies inherent in the model (effectively, the high frequencies are numerically damped out by the integrator). While BeamDyn still uses this integrator when coupled to OpenFAST, the time step required by OpenFAST glue code is dictated by the frequencies inherent in the module-level inputs and outputs passed through the glue code. When BeamDyn is coupled to OpenFAST, high frequencies are introduced in the coupling between BeamDyn and other modules (especially ElastoDyn), which dictate a smaller time step requirement.

Best regards,

Dear Jason,

Maybe I wasn’t explaining my self very well.

Standalone beamdyn + order_elem 4 = 0.04s time step (the smallest verified)

Standalone beamdyn + order_elem 33 = 0.002s time step

Coupled to OpenFAST + order_elem 4 = 0.0001s time step

My aim is to reduce the time step so that the total simulation time can be reduced considerably.

Thanks and kind regards

Dear Abhinay,

OK, thanks for clarifying your question; I know understand. But I think I also answered them in prior posts:

- The time steps are dictated by the natural frequencies present, and so, depend on the mass, stiffness, and numbers of degrees of freedom (DOFs);
- Increasing order_elem will introduce additional DOFs and higher-frequency modes that require smaller time step; and
- OpenFAST requires smaller time steps than BeamDyn standalone due to the existence of high-frequencies transferred through the glue code.

So, to reduce the time step requires reducing the highest frequencies either by changing the mass/stiffness or reducing the number of DOFs (order_elem). From prior posts, it is my understanding that you are questioning some of the mass/stiffness values you are using (perhaps leading to higher than expected frequencies, requiring smaller than expected time steps).

Best regards,

Dear Jason,

Thanks for the detailed explanations. I verified the NREL_5MW example files with standalone beamdyn driver and the solution converges for 0.25s (smallest). As explained in the previous post, my model with very less DOFs converges at 0.04s. I am assuming it is the result of high frequencies induced by the mass/stiffness matrices. In another thread you mentioned NREL didn’t compute the matrices using any additional software like BECAS, NuMAD or VABS. But calculated from the NREL 5MW blade profile itself. With your expertise, could you recommend any software among the mentioned or other procedures to compute the matrices? (Opensource if possible)

Thanks and kind regards

Dear Abhinay,

VABS, BECAS, and NuMAD are all great options for sectional analysis. Another is ANisotropic Beam Analysis (ANBA). NREL recently combined VABS and ANBA together through OpenMDAO to support optimization of wind turbine blades in the Structural OptimizatioN and AeroelasTic Analysis (SONATA) framework–see: nrel.gov/docs/fy20osti/76877.pdf.

Best regards,