Dear All,
I am trying to model my own tidal turbine blade using AeroDyn and BeamDyn using openfast v4.1.2 on windows. From the simulation run, I have obtained the error log:
How may I resolve this?
Thank you for your assisstance.
Regards,
Ariff
Dear @Ariff.Alzakri,
I imagine that you started with the OpenFAST r-test example of the floating RM1 turbine (presumably this one: r-test/glue-codes/openfast/MHK_RM1_Floating at main · OpenFAST/r-test · GitHub ) and you modified it to accommodate the details of your own tidal turbine blade; is that correct? Can you clarify what you changed relative to the r-test example?
Best regards,
Dear @Jason.Jonkman,
Thank you for your reply.
It has been a while since I have been editing the simulation setup from the r-test model as I was previously using OpenFAST version 3.5.3, and have just recently started using the latest version of v4. I have managed to model the turbine coupled with elastodyn successfully using v3.5.3 and have just recently started using BeamDyn using v4.1.2.
Though I am not able to provide a clear answer on the changes I have made from the r-test, these are the setups that I think could potentially provide error and changes I made transitioning to the latest format:
Previous model
AeroDyn
ElastoDyn
openfast v4 model
AeroDyn
BeamDyn & ElastoDyn
Thank you for your guidance.
Regards,
Ariff
Dear @Ariff.Alzakri,
Does your OpenFAST v4.1.2 model run as expected when CompElast = 1 (ElastoDyn only) rather than CompElast = 2 (ElastoDyn + BeamDyn)?
Best regards
Dear @Jason.Jonkman ,
Attached below is the trial run when I do set CompElast = 0, failure still occurs however there is mention of PitchAxis column in the blade distributed properties. would this be the cause of problem?
Thank you.
Best regards,
Dear @Ariff.Alzakri,
So, the program exception does not seem related to BeamDyn. I assume it is coming from AeroDyn. I would suggest isolating the specific change you made to the AeroDyn file that is triggering this error.
FYI: You should able to eliminate the PitchAxis warning by removing that column from table of distributed blade properties in the ElastoDyn blade data file.
Best regards,
Dear @Jason.Jonkman ,
Thank you for your guidance, I have edited the AeroDyn inputs and found the issue was that I was considering TwrPotent = 1 when I was not modelling the tower.
I conducted a test run using BeamDyn within openfast as shown below:
To run the test I needed a time step of 0.0001s for it to converge, which resulted in 20 mins real time for 2s of run time. Is this to be expected when using coupled beamdyn, and is there a way to improve computational time?
Thank you.
Best regards,
Ariff
Dear @Ariff.Alzakri,
I’m glad you resolved the program exception error. Can you clarify: had you set TwrPotent = 1 with NumTwrNds = 0 and now setting TwrPotent = 0 solved the issue?
BeamDyn often needs smaller than desired time steps to converge, but a DT = 0.0001 s with NumCrctn = 5 will certainly mean long simulation times. Are the mass and stiffness you are using in BeamDyn set to reasonable values? Do you need 5 correction steps?
We’ve developed a new tight coupling algorithm that will be released soon in OpenFAST v5 that will allow for much larger time steps and faster simulation times when BeamDyn is enabled. You can track the developing and use the draft version through the dev-tc branch of OpenFAST within its GitHub repository.
Best regards,
Dear @Jason.Jonkman ,
Yes, the TwrPotent was equal 1 when NumTwrNds was 0, and setting TwrPotent to 0 resolved the program exception error.
On the point of beamdyn having reasonable mass and stiffness properties, could I ask for some guidance regarding this and how I may approach to evaluating my beam model as my current knowledge is fairly limited. Would conducting a modal analysis be a suitable evaluation method?
I have used precomp to get the 4x4 properties that it calculates and I am using a calculation method provided in WISDEM to estimate the shear stiffness values from precomp properties, though I am still in the midst of understanding the calculations.
I look forward to the release of OpenFAST v5 and greatly appreciate the hard work of the developers in making this possible.
Best regards,
Ariff
Dear @Ariff.Alzakri,
Thanks for clarifying regarding TwrPotent. We’ll get that issue fixed.
Does the mass distribution and bending stiffness match those of the corresponding ElastoDyn model for the RM1 turbine? BeamDyn requires additional mass and stiffness terms not used by the ElastoDyn blade model (inertias; axial, shear, and torsion stiffness; and offsets/coupling terms) and if these terms unrealistically high, this may demand unreasonably small time steps.
Best regards,
Dear @Jason.Jonkman ,
Thank you for your guidance on the previous matter.
From the previous advice of checking the NumCrctn, I have conducted simulations on the impact of this parameter. Some of the results are attached below:
May I ask on what is the parameter affecting on the numerical side and how do I determine the appropriate correction steps? from what I see, NumCrctn = 4 provides the most unstable calculations whereas NumCrctn = 2 and 6 provides the same output.
Thank you.
Best regards,
Ariff
Dear @Ariff.Alzakri,
OpenFAST solves implicit loose coupling between modules during time advancement using a prediction-corrector scheme , and NumCrctn is the number of correction steps (with NumCrctn = 0 being a prediction step only). Normally there is a balance between DT and NumCrctn, and you can get by with increasing DT if you also increase NumCrtn. I would normally not increase NumCrctn above 2, but rather, reduce DT, and often with many models using a small enough DT with NumCrctn = 0 is sufficient. I’m a bit surprised that solutions would be the same for different nonconsequtive values of NumCrctn, but perhaps this suggests DT is too large or that stop_tol in BeamDyn is set too large for your case?
The new tight coupling scheme in OpenFAST v5 has an improved algorithm that should allow for larger time steps and faster simulation times when BeamDyn is enabled.
Best regards,