After looking at your settings, the only thing that appeared strange to me is that your Z0_Low & Z0_High are set at 0 m. In case you used Turbsim to generate the ambient flow: “When using TurbSim, which cannot generate wind at ground level, Z0_Low should be close to but above ground level.” (I copied from the user guide). But I don’t know if that is the reason of the non-convergence issue.
Best regards,
Hi @Salur.Basbug
Thank you for your reply, but I think it’s not the setting of Z0_low or Z0_High, because my bts wind file is in the height range of 5m-185m, it should not cause non-convergence, as I have successfully run the case before. But I think your suggestion is helpful for me, I will modify this parameter in subsequent series of simulations. This is how I understand it but let’s see how Jason would like to comment.
Best regards,
Dear @Jundong.Wang,
See my response to your related question about the FAST.Farm domains and TurbSim grid regarding the suggested alignment of both: Error with the FF wind array boundaries - #27 by Jason.Jonkman.
But the error you are receiving regarding:
FAST_Solution:FAST_AdvanceStates:B2:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after the maximum number of iterations
is generated by BeamDyn (BD) within OpenFAST. Can your OpenFAST model run in standalone OpenFAST, separate from FAST.Farm? I would first verify that your OpenFAST model can run separate from FAST.Farm before using the model within FAST.Farm. (FAST.Farm just adds an extra layer of complexity; it is always easier to simplify a model when debugging.)
Best regards,
Hi Jason, @Jason.Jonkman
Long time no talk! I am getting back into doing some research, and am attempting to use Fast.Farm. I am trying to use Mod_AmbWind = 3, so am creating my high and low resolution turbulent wind files. I created the low resolution file with a timestep of 5 seconds using the guidance for DT_low found in the user guide. I then extracted the u, v, and w velocity timeseries at the hub height and created a Turbsim User timeseries input file to create the high resolution wind file from. However, since my high resolution wind file needs a timestep of 0.1 s, I am getting an error from Turbsim that “Timestep must be the same as Delta time in the user input file”. Does this mean that my low res file actually needs the high res timestep or am I missing something?
Thanks in advance for any help!
-Gordie Stewart
Hi @Gordon.Stewart,
That’s correct. When we use Mod_AmbWind = 3 (multiple instances of InflowWind) in FAST.Farm, we typically generate the TurbSim wind data for the low-resolution domain with a time step that matches the high-resolution domain for the reason you mention, despite the recommendations suggested by the modeling guidance. You can still use the coarser DT_Low in FAST.Farm so as to not slow down the FAST.Farm solution.
Best regards,
Dear Jason,
You mentioned before that a “Wind Energy journal publication summarizing the development, implementation, and initial verification/validation of the curled wake model” is under review.
Is it possible that I get the manuscript already, even before publication? email: salur.basbug@ri.se
(I’ve also seen the 2021 paper of Martínez-Tossas et al. WES - The curled wake model: a three-dimensional and extremely fast steady-state wake solver for wind plant flows)
Best regards,
Hi Ruiyang,
Do you already know the answer? Can you show me the reply if it’s convenient?
Thanks in advance
Jundong Wang
Dear @Jundong.Wang and @Ruiyang.He,
I’m not sure if Kelsey Shaler, who developed these Python scripts, answered @Ruiyang’s original question. But now that Kelsey Shaler has left NREL, we are in the process of reviewing and improving these scripts. We’ll upload the updated version once these improvements are complete.
Best regards,
Dear @Jason.Jonkman ,
Thanks for your reply, and I have another question：I would like to know how the connection between FAST.Farm and openfast is established when the DT is different? In the user manual it says:
1.“The OF module of FAST.Farm is a wrapper that enables the oupling of OpenFAST to FAST.Farm.This wrapper also controls subcycling of the OpenFAST state updates.” ——What is the result of the loop in the Openfast state? Is the integral value, or the instantaneous value of a few moments？
2.“However, for the purposes of coupling OpenFAST to FAST.Farm, the OF module functions in discrete time and without direct feedthrough of input to output. This is achieved by calling the OF module at the rate dictated by the FAST.Farm time step, ∆t , and by introducing a one-time-step (∆t ) delay of the output relative to the input; this one-time-step delay is not expected to be problematic because of the slow timescales solved within FAST.Farm”—— Maybe it’s because of my lack of knowledge, can you explain to me why there is no input to output feedthrough? Also I don’t understand what role one-time-step (∆t ) delay plays…
Also what part of the Fortran source code can help me understand further?
Thanks in advance
Jundong Wang
Dear @Jundong.Wang,
Regarding (1), this statement is saying that OpenFAST can take much smaller time steps than FAST.Farm because the time-scales resolved in the aeroelastic solve are smaller than the time-scales resolved in the wake meandering.
Regarding (2), a one time-step delay was introduced to avoid an implicit coupling between the modules that would have made the coupling algorithm used by FAST.Farm more complex and slower. The one time-step delay simply means that the wake emanating from a rotor is slightly delayed relative to the aerodynamic loads applied. This is expected to have a negligible effect on the impact of that wake on potential downstream rotors.
Best regards,
Dear @Jason.Jonkman
Thank you very much for your reply, I think I understand the second point, but I still don’t understand the first point.
what is the result that openfast passes to FAST.Farm with a smaller DT? I checked the user manual, and I understand that the result output by openfast to the Farm through the OF module is not a transient value, should it be the result after integration?
Best regards,
Dear @Jundong.Wang,
FAST.Farm will only call OpenFAST at a rate of DT_Low. When FAST.Farm calls OpenFAST, FAST.Farm sends to OpenFAST wind (including wake effects) at a rate of DT_High. Each time OpenFAST is called by FAST.Farm, it will time-integrate DT_Low/DT number of OpenFAST time steps, so, the OpenFAST output is available at a rate of DT. But FAST.Farm will only use the output from OpenFAST at a rate of DT_Low.
Best regards,
Hello everyone:
I’m having some issues with Fast.Farm. I had yaw rate control for each wind turbine in the farm, with the Y-Rate was set to 0.0034906 rad/s (0.2 deg/s). However, in the results of the simulation output, the yaw rate will always be much greater than 0.2 deg/s at the beginning and end of the yaw motion , which also makes the load on the yaw controller very large.
I would like to ask if there is a solution to this problem, or is this actually normal?
Dear Jason
How large a wind farm can FAST. Farm simulate? Is there an upper limit on the number of wind turbines?
I want to simulate the 9 * 3 wind farm based on the 5WM semi, but the operation is not successful. Do you have any suggestions?
Best regards,
Hi Binbin,
The user guide says: “The size of the wind farm and number of wind turbines is limited only by the available random-access memory (RAM).”
So if your case failed, maybe it’s a good idea to check the RAM usage, once you attempt to start the simulation.
Best regards,
Hi NaiZhi,
I would try to ramp-up the yaw rate from 0 to 0.2 deg/s within a few seconds. Maybe that helps avoid the spikes.
Best regards,
Dear @NaiZhi.Guo and @Binbin.Li,
I agree with @Salur.Basbug’s comments.
Regarding the wind farm size, I would also add that if you have more wind turbines than cores/threads on your node, then the OpenFAST parallelization of FAST.Farm is not ideal. You mention that the “operation is not successful”; can you clarify what you mean? What error are you getting?
Best regards,
Thanks for the suggestion, I will try it！
Thank you very much for your answer. I will consider the problem of violating the boundary of wind array.
Best regards,
