This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Static input file format inhibits flexibility #140
Comments
|
Great. I totally support this idea. |
|
While I am generally supportive of the proposal, we chose against it in the past due the large amount of work involved. Not only does the input-file processing within OpenFAST have to change, but all of the scripts that run batch simulations of OpenFAST must change. Of course, such an endeavor does not have to done at one time, but can be tacked on a module-by-module basis. |
|
Dear all, Currently, I am struggling with stand-alone BeamDyn input files( Dvr_5MW_static.inp, Static_BeamDyn_input_5MW.inp, 5MW_Blade_IEC.inp). I wonder if you could help me to change the length of the blade in the input file and also I wanted to know the difference between nodes and number of key points on member(kp_total). because for instance I want to consider 6 nodes on the member and then applying load on each node. Regards, |
|
Dear Pouria, I suggest you read the following threads that explains the differences between keypoints, FE nodes and quadrature points used in BeamDyn: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1525 Best Regards, |
|
Dear Jelmer, Thank you for you response. the links that you sent were useful. now I am just wondering how is it possible to change some parameters such as length in addition to the stand-alone BeamDyn input files. Kind regards, |
|
Dear Pouria, the driver input file for the stand-alone version only contains the parameters on how you want to load the blade and how the blade is oriented. The BeamDyn Primary input file contains the parameters for the SFEM-solver and the reference axis of the blade. The blade length is defined by the length of the reference axis, set by the key points. The Blade input file contains the cross-sectional structural and mass properties of the blade. https://openfast.readthedocs.io/en/latest/ Best regards, |
|
Dear Jelmer, Thank you for your time and consideration. actually I'm new to it and thank you in advance for your understanding. Actually, I don't understand this error. Kind Regards, |
|
Dear Pouria, The keypoints determine the (possiblu curved) reference axis of the blade. This blade cross-sectional properties are defined at stations along this reference axis. The distance along the reference axis from the root of the blade to each station is normalized between 0 and 1 (station_eta) in the BeamDyn blade input file. The inputs to BeamDyn are documented in greater detail in the online BeamDyn User Guide and Theory Manual: https://openfast.readthedocs.io/en/master/source/user/beamdyn/index.html. Best regards, |
|
Dear Jason, Thank you for your good explanation. Kind Regards, |
|
Dear @Pouria-AZD, I think we'd need to see your input files to help debug the problem. It is difficult to guess what the problem might be. Please attach your files. Best regards, |
|
Dear @jjonkman, Here are the Input files. Kind regards, |
|
Hi Pouria, I could only see screenshots in the zip file, could you send the input file as a text file as well? Maybe the number of stations does not match. As a quick check you could try using only |
|
Hi @ebranlard , with station_total=2 by defining only eta=0 and eta=1 in the input file this error occurred " Load may be too large, BeamDyn will attempt to solve with additional steps. Maximum number of load steps reached. " ---------------------- BLADE PARAMETERS -------------------------------------- 6.789350E+02 0.000000E+00 0.000000E+00 0.000000E+00 0.000000E+00 -1.154189E-01 1.000000 1.031900E+01 0.000000E+00 0.000000E+00 0.000000E+00 0.000000E+00 -5.346274E-01 |
|
Dear @Pouria-AZD, I agree with @ebranlard that your original model likely has more than 14 stations where the distributed mass and stiffness data are defined even though your input file had station_total = 14 (but it is difficult to confirm without the text-based input). When switching to station_total = 2, the trapezoidal quadrature you are using (quadrature = 2) is very coarse, causing the new issue you are seeing. When using station_total = 2 with quadrature = 2, you should set refine to a sufficiently large value to sufficiently resolve the blade (e.g., refine = 20). Best regards, |
|
Hi Pouria, As mentioned by Jason, I'd recommend checking the syntax of your previous input file that had 14 stations. If you experience further problems, feel free to post another issue on github since we are side-tracking from the topic of the current thread. If you start another issue, please mention the version of BeamDyn (it seems you are using an older version of BeamDyn) and don't hesitate to send the full inputs files. |
|
Dear all, By the way, I have a new problem that is in the output file(.sum) of stand-alone BeamDyn where there is no displacement for the beam!
I run it with no problem but the main problem is in the output file and I'm wondering why in the section of initial displacement, initial rotation and initial velocity the values are 0.0! This summary information was generated by BeamDyn (v1.01.04, 26-Jul-2016) on 17-Jun-2019 at 10:10:14. Initial position vectors Initial rotation vectors Quadrature point position vectors Sectional stiffness and mass matrices at quadrature points Quadrature point number: 1 Quadrature point number: 2 Quadrature point number: 3 Quadrature point number: 4 Quadrature point number: 5 Quadrature point number: 6 Quadrature point number: 7 Quadrature point number: 8 Quadrature point number: 9 Quadrature point number: 10 Quadrature point number: 11 Quadrature point number: 12 Quadrature point number: 13 Quadrature point number: 14 Initial displacement Initial rotation Initial velocity Initial angular velocity |
|
Could you attach your primary input file? It looks like your keypoints are defined with the the primary beam axis in the x-direction, but BeamDyn is expecting the the primary beam axis is in the z-direction along |
|
Dear @andrew-platt , False Echo - Echo input data to ".ech" (flag) |
|
I noticed you are using a very old version of BeamDyn (v1.01.04, 26-Jul-2016). In the last 3 years BeamDyn has gone through a very extensive rewrite . I suggest you start with the latest version as we no longer support the older version. |
|
Dear @andrew-platt , But it is still running with the old version containing some errors: Running BeamDyn Driver (v1.00.02, 5-Apr-2016) BD_ReadDvrFile:Invalid numerical input for file "Dvr_5MW_Static.inp" occurred while trying to Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: |
|
The input file on |
|
You will need to pull the latest version of OpenFAST and recompile before you use the new input files. I suggest you pull from the latest dev branch.
From: PouriaAmouzadrad <notifications@github.com>
Reply-To: OpenFAST/openfast <reply@reply.github.com>
Date: Tuesday, June 18, 2019 at 8:39 AM
To: OpenFAST/openfast <openfast@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [OpenFAST/openfast] Static input file format inhibits flexibility (#140)
Dear @andrew-platt<https://github.com/andrew-platt> ,
Yes you are right actually v1.00.02, 5-Apr-2016.
I have already changed the Input files considering the ones on this site: https://openfast.readthedocs.io/en/master/source/user/beamdyn/appendix.html#bd-input-files
But it is still running with the old version containing some errors:
Running BeamDyn Driver (v1.00.02, 5-Apr-2016)
linked with NWTC Subroutine Library (v2.09.00, 23-Jul-2016)
BD_ReadDvrFile:Invalid numerical input for file "Dvr_5MW_Static.inp" occurred while trying to
read t_initial.
BD_ReadDvrFile:Invalid numerical input for file "Dvr_5MW_Static.inp" occurred while trying to
read InitInputData%gravity(1).
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7faeceb9cd4a
#1<#1> 0x7faeceb9bf7d
#2<#2> 0x7faece0bb05f
#3<#3> 0x560ee9b04b4e
#4<#4> 0x560ee9a369a0
#5<#5> 0x560ee99e6a64
#6<#6> 0x560ee9a75f22
#7<#7> 0x560ee9a6ebed
#8<#8> 0x560ee9a7058b
#9<#9> 0x560ee9a76146
#10<#10> 0x7faece0a82e0
#11<#11> 0x560ee99b2f69
#12<#12> 0xffffffffffffffff
Erreur de segmentation
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#140?email_source=notifications&email_token=AAPSHBAN2GAWOQV6LWESKVTP3DXRVA5CNFSM4FFIVRP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX63F5I#issuecomment-503165685>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAPSHBEJ5EFW3ZIZYBIV7VLP3DXRVANCNFSM4FFIVRPQ>.
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
The current input handling in the NWTC Library expects a mostly static input file format (I say "mostly" because at least one example of a dynamic input file format exists in
beamdyn_driver). This means that any new feature which needs input will cause a breaking API change and, therefore, requires a new major version number according to the rules of semantic versioning.It has been proposed to implement a more dynamic input system with a flexible syntax and default values where appropriate (something dictionary based, yaml, json, etc). This would allow backwards compatibility when new features are introduced and enable simpler restructuring of the input file.
The text was updated successfully, but these errors were encountered: