Question about whether a small `DT_Low` can limit the actual wake-propagation length specified by `NumDFull` / `NumDBuff` in FAST.Farm v5

[xiaomi4356]

Question about whether a small DT_Low can limit the actual wake-propagation length specified by NumDFull / NumDBuff in FAST.Farm v5

Dear OpenFAST / FAST.Farm developers,

Thank you very much for maintaining FAST.Farm and for the helpful discussions in previous GitHub issues. I am currently trying to understand a wake-plane truncation behavior in FAST.Farm v5, and I would appreciate your advice.

I am running a two-turbine FAST.Farm case with the turbines aligned approximately with the main inflow direction. The turbine spacing is about 5D. I am using the polar wake model, with the following relevant wake-dynamics parameters:

Mod_Wake      = 1
RotorDiamRef = 125 m
dr           = 5.0 m
NumRadii     = 40

NumDFull     = 20
NumDBuff     = DEFAULT = 5
C_Meander    = DEFAULT = 1.9

Based on my understanding of the FAST.Farm v5 input file, NumDFull = 20 and NumDBuff = 5 should mean that the wake of each turbine is propagated over approximately
(20 + 5)D = 25D

which, for RotorDiamRef = 125 m, corresponds to

25 * 125 m = 3125 m

where the first 20D is the full wake-propagation region and the last 5D is the buffer region.

However, when I use a relatively small low-resolution time step, for example

DT_Low = 0.4 s

the wake length observed in ParaView seems much shorter than 25D. The wake appears to be truncated or to suddenly shorten at a relatively short downstream distance, as if some wake planes were being removed before the wake reaches the distance specified by NumDFull + NumDBuff.

In some cases, the log file also reports warnings such as

The number of wake planes of turbine exceeded the allowed number.
Excess plane(s) removed

and sometimes also messages like

wake plane has overtaken wake plane . Offending wake plane removed. Reduce f_c to prevent planes from passing each other

My current understanding is the following.

Although the old NumPlanes input has been replaced in FAST.Farm v5 by NumDFull and NumDBuff, the code still seems to use an internally estimated maximum number of wake planes. For Mod_Wake = 1, I understand from previous discussions that this number is approximately

N_max ≈ 15 * (NumDFull + NumDBuff) / C_Meander

For my case,

NumDFull + NumDBuff = 25
C_Meander = 1.9

so

N_max ≈ 15 * 25 / 1.9 ≈ 197

At the same time, since a new wake plane is added every DT_Low, the approximate distance between adjacent wake planes can be estimated as

Delta_x_plane ≈ U_adv * DT_Low

where U_adv is an average wake-advection speed.

If I assume $U_adv ≈ 8–10 m/s$, then for DT_Low = 0.4 s the wake-plane spacing is roughly Delta_x_plane ≈ 3.2–4.0 m

Therefore, the actual wake-propagation length that can be supported by the maximum number of wake planes would be approximately

L_realizable ≈ N_max * Delta_x_plane
             ≈ 197 * (3.2–4.0)
             ≈ 630–790 m

This corresponds to only about 5D–6D rather than the intended 25D specified by NumDFull + NumDBuff.

If DT_Low = 0.2 s, then the wake planes become even more closely spaced, and the estimated realizable wake length becomes even shorter, roughly around 2.5D–3D.

This estimate seems consistent with what I observe in ParaView: even though the input file specifies a target wake-propagation distance of 25D, the wake appears to be truncated or shortened after only a few rotor diameters when DT_Low is small.

I would like to ask whether this interpretation is correct.

More specifically:

1. In FAST.Farm v5, can a small DT_Low cause the wake planes to become too densely spaced, so that the internally allowed maximum number of wake planes is reached before the wake propagates to the distance specified by NumDFull + NumDBuff?

2. If so, does DT_Low have not only an upper bound from the modeling guidance, but also a practical lower bound related to the maximum number of wake planes?

3. For a given NumDFull, NumDBuff, RotorDiamRef, and approximate wake-advection speed, is it reasonable to check whether
   L_realizable ≈ N_max * Delta_x_plane is larger than L_target = (NumDFull + NumDBuff) * RotorDiamRef in order to determine whether the chosen DT_Low is too small?

4. If I want to keep a relatively small DT_Low, for example 0.4 s, what would be the recommended way to avoid wake truncation? Should I increase NumDFull significantly to indirectly increase the internal wake-plane limit, or is it better to use a larger DT_Low and keep a smaller DT_High for the high-resolution inflow around the turbines?

5. Could a large value of f_c further increase the risk of wake-plane overtaking or plane removal? In other words, should f_c also be reduced when this behavior is observed?

In short, my main question is:

Can a small DT_Low in FAST.Farm v5 make the actual wake-propagation length much shorter than the target distance specified by NumDFull / NumDBuff, because the wake planes are generated too densely and the internal maximum number of wake planes is reached too early?

If yes, is there a recommended criterion to choose DT_Low, or a recommended way to ensure that

N_max * Delta_x_plane >= (NumDFull + NumDBuff) * RotorDiamRef

so that wake truncation can be avoided?

Thank you very much for your time and help.

Best regards,
xiaomi

[jjonkman]

Dear @xiaomi4356,

See a related discussion here: #3330.

The derivation of the equation that estimates the maximum number of wake planes (15 * ( NumDFull + NumDBuff )/ C_Meander, from #3330, 18 * ( NumDFull + NumDBuff )/ C_Meander) assumes you are using a DT_Low that follows the modeling guidance (C_Meander * RotorDiamRef / ( 10 * V_Hub ), with a safety factor of 1.5. You haven't stated what wind speed (V_Hub) you are simulating with, but assuming it is around 10 m/s, this translates to a DT_Low of about 2.4 s, which is much larger than the value of 0.4 s you are using (by a factor of 6). Thus, the estimated maximum number of wake planes is too low for your case. The workaround is to increase increase DT_Low closer to the modeling guidance or increase NumDFull beyond what you actually want.

To answer your specific questions:

1. Exactly.
2. Yes, it is better to say that the modeling guidance provides a recommended value of DT_Low. Using a DT_Low much lower than the recommend value will add computational expense with no real benefit in terms of increased accuracy of FAST.Farm.
3. This check is difficult because FAST.Farm does not intrinsically know the value of V_Hub in all cases, given that FAST.Farm supports different wind data formats, including from a high-fidelity precursor simulation that doesn't require a fixed mean wind speed.
4. As I mentioned, it would be better (more computationally efficient) to increase DT_Low to a value that is close to that recommended by the modeling guidance.
5. Yes, we generally recommend reducing f_c if you routinely get warnings about wake planes overtaking another.

Best regards,