Dear NREL,
I hope this finds you well.
I recently ran into an error using Mann turbulence for a FastFarm simulation. I am trying to run a test case of two 15MW wind turbines. I am using the Mann model Python toolbox from this link: GitHub - jaimeliew1/Mann.rs: A Mann turbulence generator for Python written in Rust to generate the Mann inflow box. I generated a turbulence field using this toolbox with the following variables: [nx: 1024, ny: 256, nz: 128, Lx: 5115, Ly: 1275, Lz: 635] which are the inputs for the Python toolbox. These values yield a spatial discretization of 5m in all directions.
The toolbox then generated three “.bin” files, U_1234.bin, V_1234.bin, Z_1234.bin. I set up the FastFarm inflow.dat file as shown in the screenshot below. A screenshot of the “.fstf” file as well as the error message from running FastFarm_v3.5.2 are also shared below.
Additionally, is there any recommendation for selecting the low and high resolution discretization for the input file in FastFarm when using the Mann model? Should the discretization in both the low and high-resolution in FastFarm input file match that in the Mann box?
I would greatly appreciate guidance on this.
Kind regards.
InflowFile.dat file screenshot:
.fstf file screenshot:
Terminal error message:
Dear @Abdulbaset.Alazhare.
There was a bug in OpenFAST v3.5.2 that led to some models generating a stack overflow error: FAST.Farm · Issue #2053 · OpenFAST/openfast · GitHub. This will be fixed in the pending release of OpenFAST v3.5.3.
Unfortunately, there is still an open issue that prevents using Mann-based inflow in InflowWind (WindType = 5) with Mod_AmbWind = 3 in FAST.Farm–see: Bug Report: Combination of Mod_AmbWind=3 with WindType=5 in FAST.Farm · Issue #471 · OpenFAST/openfast · GitHub.
Best regards,
Dear @Jason.Jonkman,
Thank you for your reply.
Unfortunately, I am still getting a similar error message despite using the latest version of Fast.Farm (v3.5.3). I am using WindType = 5 & Mod_AmbWind = 3.
Any thought as to why I am still getting a similar error?
Kind regards
Error message:
Dear @Abdulbaset.Alazhare,
The issue associated with the stack overflow error for Mod_AmbWind = 2 or 3 with WindType = 3 should be fixed in the release of FAST.Farm within OpenFAST v3.5.3, but the issue in FAST.Farm associated with WindType = 5 is still open (Bug Report: Combination of Mod_AmbWind=3 with WindType=5 in FAST.Farm · Issue #471 · OpenFAST/openfast · GitHub).
Best regards,
Dear @Jason.Jonkman,
I hope this message finds you well.
I have been running simulations using FAST.Farm with turbulent wind fields generated by TurbSim. Following your recommendation from a previous post, I generate two types of turbulent fields: a large but low-resolution wind field, and a smaller high-resolution wind field for each turbine.
However, for certain average hub-height wind speeds, the time required to generate these wind fields is quite long. I was wondering if there is any way to speed up TurbSim’s wind field generation, or if there is an alternative software that can be used to generate turbulent wind fields more efficiently.
Additionally, are you aware of the Mann turbulent field generator being used with FAST.Farm? If so, how can I use it in my simulations?
Many thanks for your assistance.
Kind regards,
Dear @Abdulbaset.Alazhare,
The computational speed of TurbSim is tied to the underlying spatial-temporal discretization (number of grid points and time steps). TurbSim will run much faster for coarser discretizations. In your case, is it the low- or high-resolution TurbSim domains that is the bottleneck? Are you following the FAST.Farm modeling guidance in terms of spatial-temporal discretization?
FAST.Farm has been used with Mann turbulence using Mod_AmbWind = 2, but not Mod_AmbWind = 3 due to the issue that still needs to be resolved.
Best regards,
Dear @Jason.Jonkman,
Thank you for your prompt response and continued support.
I am currently using the Python Toolbox provided on NREL’s GitHub repository to calculate the spatial step, as outlined in the equation below. For higher wind speeds, the low-resolution wind field is generated very quickly (very coarse discretisation due to the equation below)—sometimes in under a minute. However, for low wind speed, for exanple 7 m/s, it took approximately 3 hours to complete on a system with a Core i7 processor and 16 GB of RAM running Windows. Furthermore, the low-resolution wind field with a wind speed of 3 m/s has been running for over 15 hours and has not yet completed.
The high-resolution wind fields also take considerable time to generate, averaging around 45 minutes per field.
Given that my use case for FAST.Farm involves running a large number of simulations, the current computational time poses a significant challenge to generating the necessary data efficiently, hence my inquiry.
Regarding Mann turbulence, could you kindly provide further guidance on how to generate it and implement it in FAST.Farm?
Thank you again for your assistance.
Best regards,
TurbSim file of low-resolution wind field with 3 m/s wind speed (generated using NREL’s Python Toolbox)
Dear @Abdulbaset.Alazhare,
One way to increase the computational speed is to increase TimeStep in TurbSim. I see that you are using TimeStep = 0.05 s, which is likely far smaller than it needs to be based on the modeling guidance for DT_Low and DT_High.
Regardless, we certainly understand that the generation of low-resolution domain from TurbSim for large wind farms or the high-resolution domain for large wind turbines can be computationally expensive. We have ideas on how to reduce the computational expense of inflow generation for FAST.Farm, but are currently seeking funding opportunities to address these challenges.
Regarding the use of Mann turbulence with Mod_AmbWind = 2, I don’t think I can offer much beyond what is already in the online FAST.Farm documentation. We rarely use the Mod_AmbWind = 2 option, and so, the OpenFAST (python) toolbox has not been developed to support this option.
Best regards,
Dear @Jason.Jonkman,
Thank you for your suggestion. Currently, the default value for fmax, which is used to calculate the time step in the script “Ex3_FFarmCompleteSetup.py,” is set to 10/6, as shown in the screenshot below. This results in a time step of 0.3. I have observed that the TurbSim input files for the test case use a time step of 0.1. Could you please advise on the appropriate time step value to use in this scenario?
For reference, I am working with the 15 MW turbine.
Screenshot of the Python script “Ex3_FFarmCompleteSetup.py”.
Dear @Abdulbaset.Alazhare,
I’m not sure where the 10/6 came from, but that should be sufficient for the IEA Wind 15-MW RWT. A 12P excitation frequency (which should be more than enough range to resolve) for this turbine is 12*7.56/60 = 1.512 Hz, which is less than 10/6 = 1.667 Hz. My guess is 10/6 was used to get a nice round number for DT_High of 0.3 s. As such, you should be able to increase the TurbSim step size to 0.3 s as well.
Best regards,
