Wind grid definition based on FAST.Farm modelling guidance for Mod_AmbWind=3 results in excessively large grid

Wind & Water Inflow Turbulence
1

Dear All,

  1. I am following the modelling guidance in the FAST.Farm documentation to define farm wind boxes for a simulation with Mod_AmbWind=3. It seems that following the guidelines results in huge wind grids that cannot be computed by TurbSim in a reasonable time. For example, for (D=240m, Cmeander=1.9, U=4m/s, fmax=2Hz), the resulting low-resolution grid discretization in TurbSim is: (dT=0.25s, dY=10m, dZ=10m). For a 2x2 wind farm with 4D spacing, the grid dimensions would 1980mx780m, resulting in a 199x79 grid, so a total of 15721 grid points per timestep. Evidently, such a wind file would take an eternity to compute. Hence, my question is the following: what can be done to work around this issue? note that I am using the least conservative values recommended in the modelling guidelines (i.e. upper limits).

  2. Another issue is that I am working with the IEA 15MW offshore turbine and, to calculate the wind grid parameters as specific in the modelling guidelines, some properties of the turbine are needed, namely: fmax and cmax. I cannot seem to find the values explicitly in the documentation of the reference wind turbine. Can someone guide me as to where I can find these values?

Thank you,
Hadi

2

Dear @Hadi.Hammoud,

Regarding (1), I wouldn’t say that TurbSim would take an “eternity”, but I agree that TurbSim can take a while (a few days) for certain conditions. Please note that I calculate DT_Low more like 10 s (although I can see why you’d want to use DT_Low = 0.25 s if you are trying to get it to match DT_High) and dY_Low = dZ_Low = 12 m for the values you are using, which coarsens the discretization a bit. Regardless, I agree that this is a problem, which is why we typically only use TurbSim for small wind farms or a single row of turbines. For large wind farms, it is more practical to run an LES precursor. At this time, inflow generation is more computationally expensive than FAST.Farm simulations. We also have ideas on generating inflow more efficiently that we’ll pursue at some point.

Regarding (2), f_max need not be higher than 2 Hz (which is already 15P) and c_max is about 6 m.

Best regards,

3

Dear @Jason.Jonkman,

My understanding is that DT_Low in the TurbSim input file for the low resolution domain must match DT_High. The DT_Low in the .fstf driver file would however be 10s indeed. Is my understanding sound?

I ran TurbSim with the parameters dT_Low =0.5s, dY_Low = dZ_Low = 12m for a 3x3 square wind farm with 8 rotor diameter spacing. The corresponding wind file took around 1.5 days to generate, which I am willing to accept. However, another issue came up: when running FAST.Farm with the mentioned wind file, a stack overflow error is being thrown and the simulation is being aborted. Any recommendations as to how this problem can be addressed?

Thank you in advance,
Hadi

4

Dear @Hadi.Hammoud,

I agree that the FAST.Farm modeling guidance recommends setting DT_Low = DT_High when using Mod_AmbWind = 3 to ensure that the time-series of the high-resolution domain can be fully synchronized with the time-series of the low-resolution domain. Unfortunately, this recommendation results in a DT_Low that is much smaller than is needed for the wake-meandering calculation of FAST.Farm and more computationally expensive ambient inflow pre-processing. We hope to develop improved inflow modeling methods at some point to eliminate this recommendation.

Regarding the stack overflow, perhaps this is the same known issue reported here: FAST.Farm · Issue #2053 · OpenFAST/openfast · GitHub?

Best regards,