Dear Dr. @Jason.Jonkman,
Thanks for your reply. I will be waiting for the new release. Thanks.
Regards
Dear Dr. @Jason.Jonkman,
I have one query regarding the turbsim tool;
(1) Is there a method or recommended approach for parallelizing TurbSim simulations across multiple CPU cores or nodes? Iām interested in exploring options to speed up simulation runs by leveraging parallel processing capabilities. Any insights or best practices would be greatly appreciated. Thanks
Very Respectfully,
Muhammad Abdullah
Dear @Muhammad.Abdullah,
Iām not aware of any effort to parallelize TurbSim and donāt know how much work that would be to develop.
Here is a link to an older topic that discusses the CPU time expected with TurbSim simulations as you increase the number of points: TurbSim CPU Times .
Best regards,
Dear Dr. @Jason.Jonkman,
I hope this message finds you in good health. I was conducting a study to compare polar and curl method within the FAST.Farm, the FAST.farm works perfectly for polar wake mode, however, it gives following error with curled-wake mode,
Everything is kept same (dr, fc etc.) except for wake mod. Can you please help me figure this out? is there anything to be taken care of for curled wake model?
I truly appreciate your valuable time and consideration. Thanks.
Very Respectfully,
Muhammad Abdullah
Dear @Muhammad.Abdullah,
Have you looked at the wake, e.g., using the visualization functionality of FAST.Farm? I would guess the switch from the polar to the curled has resulted in the curled wake being numerically unstable wake if you have not adjusted DT_Low accordingly, which must be smaller for the curled wake than for the polar wake, as discussed in the FAST.Farm modeling guidance: 4.2.15.6. Modeling Guidance ā OpenFAST v3.5.3 documentation.
Best regards,
Dear Dr. @Jason.Jonkman,
Thanks for your response, Yes, it resolved the issue, I do not know how was I skipping this parameter from the documentation.
I have another query; I was going through your recent article named āInvestigating the interactions between wakes and floating wind
turbines using FAST.Farmā, in which you have reduced the cut-off frequency (near to resonance frequency of surge motion) to remove some non-physical steaks in the downstream of a wind turbine. By doing so, indeed,it is reducing dynamic influence of floater motions on the wake.
My thesis focuses on the studying wake meandering for different floaters (basically checking dynamic influence of floaters on wake behavior), therefore, I do not want to reduce the fc than recommended one in the documentation. My query is; as you have run the simulations in 3.4.1 version of FAST.Farm, I am using 3.5.1 version, does 3.5.1 version has already capable enough to deal with the issue (like in 3.5.1 version some improvment have been made to deal with the issue of these non-physical steaks? or it is same as of version 3.4.1),
Note: I am using curled wake mode, I have already visualized the animation of my simulations, there are still some nonphysical steaks with v3.5.1, but in early few time steps), can you suggest me something? I truly appreciate your valuable time and suggestions. Thanks.
Very Respectfully,
Muhammad Abdullah
Dear @Muhammad.Abdullah,
No, unfortunately we donāt have a solution yet for this issue in FAST.Farm whereby floater motion can results in unphysical streaks in the wake if f_c is set too high. Iād first suggest playing around with f_c a bit to see if you find a balance between accounting for FOWT motion in the wake effect and an acceptable level of streaks.
Best regards,
Dear Dr. @Jason.Jonkman,
Thanks for your previous response, I have following two more queries;
(1) I am running two different wind conditions; (1) 8 m/s (2) 14 m/s and some different wave conditions for study the impact of floater motion on the wake meandering. For 8 m/s, simulations are perfectly running with all the wave conditions.
However, when I study the 14 m/s (indeed the different file for 14 m/s has been generated using turbsim) with different wave conditions; I am getting an error.
1st wave conditions; Hs = 1.5 m and Tp = 8.0 sec (works fine with 14 m/s)
2nd wave conditions; Hs = 2.5 m and Tp = 9.5 sec (it does not work for 14 m/s), it is giving the following error;
I have gone through similar topic already discussed on the forum; FAST.Farm - #178 by Younes.Oudich (note; in this discussion, the simulation was failing when waked flow of turbine 1 was reaching to turbine 2, but in my case, simulation has run already completed more than half of the total time for simulation)
Moreover, n this topic, two things are highlighted to tackle with such issue; (1) different ServoDyn files for different wind turbines (I already have this), (2) performing modeling of turbine blades using elastodyn instead of BeamDyn, I did not completely understand this; does this mean I need to replace the BeamDyn files in the .fst file (as highlighted in the below figure),
(2)
The documentation for Fast.FARM has following recommendations;
for wake_mode =2, 3
-
dr < D/10 (12.6 for NREL 5MW)
-
DT_Low < dr/2*Vhub
in your this article; āInvestigating the interactions between wakes and floating wind
turbines using FAST.Farmā, you have used dr = 13 (for curled wake model) and DT_low of 3.0 seconds (I hope I am not wrong). If following the recommendations of documentation to achieve the numerical stability of the simulations; DT_low for your studied wind conditions should be as; for 8 m/s ā 0.8125 seconds, for 11.4 m/s ā 0.5702 seconds and for 18 m/s ā 0.3611 seconds or less than these values. How was numerical stability achieved using DT_low of 3 m/s? As in my simulations; I am studying 8 m/s and 14 m/s (if i keep same DT_low for 14 m/s as of 8 m/s (0.75), the simulation becomes unstable).
I truly appreciate your valuable time and consideration. Thanks.
Very Respectfully,
Muhammad Abdullah
Dear @Muhammad.Abdullah,
Regarding (1), is the controller responding properly such that the blade pitch angles and rotor speed are reasonable for the inflow wind speed the rotor is seeing?
Regarding (2), Iāve asked a colleague to respond.
Best regards,
Dear Dr. @Jason.Jonkman,
Thanks for your reply. (1) Yes, initial blade pitch angle for all the three blades and rotor speed have been set accroding to the corresponding wind speeds.
(2) I would like to hear when your fellow responds.
I truly appreciate your valuabel time and consideration.
Very Respectfully,
Muhammad Abdullah
The value of DT_Low used in the cases discussed in that paper is a funny thing because it was actually a mistake when I generated the input files. My plan was to rerun everything with the correct DT_Low, but instead I decided to rerun a smaller subset (about 15 cases across different sea states and wind conditions) and, to my surprise (and relief!!), the results were very similar. I guess the current recommended values for the curled wake model are probably too strict, so we might need to work on establishing new recommended values.
I am not sure why your simulations become unstable, but you can find the input files of one of the cases I analyzed in the following link 3turb_FF - Google Drive
Note that because I am analyzing hundreds of cases, I had to manually copy files from different folders. I think I copied the right ones but please let me know if you have difficulties running those cases.
Best,
Lucas
Dear @Lucas.Carmo,
Thanks for sharing the detailed information and files, I will definitely check these and inform accordingly. I truly appreciate your valuable time and consideration.
Very Respectfully,
Muhammad Abdullah
Dear @Lucas.Carmo,
I am writing this to inform you that yes simulation and informtion was accurate and worked smooth. And, it can be said that rule for DT_Low etc. are not very strict for the Curled Wake Model. I truly appreciate your valuable time and consideration. Thanks
Regards,
Muhammad Abdullah
Dear @Jason.Jonkman,
I have run the simulations for NREL-5MW and IEA-15MW successfully using 3.5.1 version of FAST.FARM.
(1) However, I also have to run simulations for DTU-10MW; unluckily, I do not have openfast files as of version 3.5.1, and I have files for openfast version of 3.2.1. The simulations for openfast using 3.2.1 version are working smoothly. However, when I use FAST.FARM, it is giving me this error;
Although, I am using true values for DT-Low-VTK, which can be seen here;
So, basically, my question is; do we have different style of FAST.Farm ā.fstfā for version 3.2.1 compared to 3.5.1? I am unable to find the FAST.Farmās .fstf file for the version of 3.2.1.
(2) Additionally, I tried to convert my openfast files from 3.2.1 version to 3.5.1 as per the instruction available on openfast github, and then run the FAST.Farm using 3.5.1 version, it is not giving the error as it was giving with 3.2.1 version of openfast file, however, sadly, with this 3.5.1 version, the MoorDyn becomes unstable.
So, I have two solutions; either change the MoorDyn and run the simulations with 3.5.1 version files of openfast, otherwise, go with the (1) which means try to figure out the issue with .fstf file so that I can be run with openfast files of version 3.2.1.
I truly appreciate your valuable time and consideration. thanks.
Very Respectfully,
Muhammad Abdullah
Dear @Muhammad.Abdullah,
Regarding (1), the changes made to the FAST.Farm input file (as well as OpenFAST input files) with each release are documented here: 4.1.2. API changes between versions ā OpenFAST v3.5.3 documentation. You can find examples of input files formatted with each release in the r-test: Releases Ā· OpenFAST/r-test Ā· GitHub.
Regarding (2), can you provide more information on the MoorDyn instability you are seeing? Certainly MoorDyn changed a lot between OpenFAST v3.2 and v3.3 with the introduction of MoorDyn v2 in v3.3. Regardless, I would generally recommend upgrading to the newest version of the OpenFAST/FAST.Farm, currently v3.5.3.
Best regards,
Dear @Jason.Jonkman,
Thanks for your reply.
Regarding (1), Thanks for sharing the information of API changes between different versions.
Regarding (2), The instability for the moorings was related to initialization. It says like there are NaN values encountered while initializing. However, luckily, I was able to resolve the issue and now everthing is working fine with Fast.FARM version 3.5.1.
Regarding 3.5.3 version of Fast.FARM, in the early days when this version was released, I checked running my Fast.FARM simulations using v3.5.3; at that time it was giving me the error of stack overflow. Same was the case with version 3.5.2, therefore, I was shifted to v3.5.1.
I do not know either there is still the same error with v3.5.2, and v3.5.3 or not.
All in all, I truly appreciate your valuable time and consideration. Thanks.
Regards,
Muhammad Abdullah
Dear @Muhammad.Abdullah,
There is a known issue causing a stack overflow error on some FAST.Farm simulations, but Iām not sure which versions of FAST.Farm this bug is tied to and what conditions trigger the error. If you have any insight in this manner, please post in the open issue: FAST.Farm Ā· Issue #2053 Ā· OpenFAST/openfast Ā· GitHub.
Best regards,