Calculation method for the superposition of wake velocity loss

[SSWMC]

I discovered a potential error: when using the Jensen wake model (with the wake stacking method set to fls), after arranging only five equally spaced 5D wind turbines and plotting the flow field, you'll find that the wind speed of the fourth downstream turbine drops below 0, and the wake of the last turbine simply "disappears."

import matplotlib.pyplot as plt
import numpy as np
import floris.layout_visualization as layoutviz
from floris import FlorisModel
from floris.flow_visualization import visualize_cut_plane

fmodel = FlorisModel("examples/inputs/jensen.yaml")
D = fmodel.core.farm.rotor_diameters[0]
layout_x = [i * 5 * D for i in range(5)]
layout_y = [0, 0, 0, 0, 0]
yaw_angles = np.array([[0.0,0.0,0.0,0.0,0.0]])
fmodel.set(
    layout_x=layout_x, layout_y=layout_y,
    wind_speeds=[8.0], wind_directions=[270.0], 
    turbulence_intensities=[0.077],
    yaw_angles=yaw_angles
    )
horizontal_plane = fmodel.calculate_horizontal_plane(
    x_resolution=400,
    y_resolution=200,
    height=90.0,
    x_bounds=(layout_x[0], layout_x[4] + 5 * D) 
)
fig, ax = plt.subplots(figsize=(15, 7))
visualize_cut_plane(
    horizontal_plane,
    ax=ax,
    color_bar=True,
    label_contours=False,
    title="Model Test",
)
turbine_names = ["T1 (Yaw: 0°)", "T2 (Yaw: 0°)", "T3 (Yaw: 0°)", "T4 (Yaw: 0°)", "T5 (Yaw: 0°)"]
layoutviz.plot_turbine_rotors(fmodel, ax=ax, yaw_angles=yaw_angles)
layoutviz.plot_turbine_labels(fmodel, ax=ax, turbine_names=turbine_names)
plt.show()
import warnings
warnings.filterwarnings('ignore')

The code is attached, using only the built-in Floris method throughout. "This is a reproducible error, indicating a significant flaw in Floris's built-in linear wake stacking method, directly affecting the usability of the entire flow field simulation," was my initial thought.
I searched for similar questions on the forum, but it seems there weren't any good answers. Later, while checking the solver input, I found the problem: the wake loss velocity was being multiplied by the free flow as the normalized velocity loss value.
Earlier this year, I had a similar question: because the wake model's velocity loss calculation is normalized, the normalized velocity loss value after the downstream wind turbine is independent of the input velocity. However, to calculate the actual wake velocity loss, a reference value needs to be multiplied. The question at the time was whether the cumulative wake velocity loss of the downstream wind turbine was based on the local rotor velocity of the upstream turbine or the ambient free flow velocity. It seemed that both had reasonable explanations, until I saw the following two articles:
《A momentum-conserving wake superposition method for wind farm power prediction》
《Wind farm power maximization through wake steering with a new multiple wake model for prediction of turbulence intensity》
When the flow distance between upstream and downstream wind turbines is sufficiently close, the rotor speed based on the local speed of the upstream turbine should be used. This was the approach I always used in my solver before using Floris. However, I observed an error today.
Specifically, in the function sequential_solver in florist/core/solver.py (around line 218), the environmental free velocity u_initial_sorte is used to calculate the actual velocity value after the wake superposition.

wake_field = model_manager.combination_model.function(
            wake_field,
            velocity_deficit * flow_field.u_initial_sorted
)

This causes the velocity deficit ratio, which always calculates the actual velocity deficit using the maximum coefficient (free flow velocity), to easily decrease to 0. To demonstrate this, replace flow_field.u_initial_sorted with u_i in the same loop, i.e., the current inflow velocity of the wind turbine :

u_i_full = u_i.repeat(grid.n_turbines, axis=1)
wake_field = model_manager.combination_model.function(
      wake_field,
      velocity_deficit * u_i_full
)

Simultaneously modify the full_flow_sequential_solver :

u_i_single = u_i[:, :, 0:1, :]
x_sort, y_sort = flow_field_grid.grid_resolution
u_i_full = np.tile(u_i_single, (1, x_sort, y_sort, 1))
wake_field = model_manager.combination_model.function(
      wake_field,
      velocity_deficit * u_i_full
)

The following are the results when the local rotor wind speed of the nearest upstream wind turbine is used as the multiplier for the normalized velocity deficit. Although an extremely low value (0.863) is also observed, the flow velocity is successfully calculated for the entire flow field, and no negative values ​​are observed.

To avoid the wake velocity not recovering in time due to the spacing between the turbines, the flow field is recalculated using a 2D spacing. Although extremely low unreasonable values ​​may appear, negative wind speed values ​​will not appear.

This problem only occurs with the linear superposition wake (fls) method, but it raises concerns that similar methods like sosfs might also suffer from this error. This is something users don't want to see, and hopefully someone can solve this problem.

[misi9170]

Hi @SSWMC , thank you for the question! I haven't fully processed it yet, but just wanted to say I'll work on thinking through this and hope to have an answer for you later today.

[misi9170]

Hi @SSWMC,

Thanks again for discussing this and for your thorough investigation of what is happening here. Fundamentally, as you point out, this comes down to a question of whether the (combined) velocity reduction should be applied to the free stream flow or the inflow at the turbine location. I think it’s worth pointing out here that both of these are modeling choices, and both are “wrong” in the sense that they requiring “combining” individual turbine wakes, which of course, in reality, are not separate entities.

In FLORIS, we currently have three combination methods implemented: “FLS”, “SOSFS”, and “Max”. “FLS” stands for “freestream linear superposition”, and thus the deficit is applied to the free stream velocity (not the current turbine’s inflow velocity). Similarly, “SOSFS” is the “sum of squares freestream superposition” model. Finally, in the docstring for the “max” method, it is stated that the deficit is added to the “base flow field”. So, the truth is, all combination models currently implemented in FLORIS are (explicitly) “free stream” deficit models.

I believe the prior discussion that you are referring to is #948 (but please correct me if that’s not what you meant---#817, #1070, #1065, and #988 also cover wake superposition).

When you say that

When the flow distance between upstream and downstream wind turbines is sufficiently close, the rotor speed based on the local speed of the upstream turbine should be used

are you quoting one of the papers you mentioned (Zong and Porté-Agel, 2020 and Qian and Ishihara, 2021), or perhaps from your own studies? I briefly looked over the papers again and didn’t see that statement. I’m not disagreeing; perhaps that is “more correct”; but I just wanted to see what evidence we have to this effect. EDIT: I see now that in Section 2.2 of Qian and Ishihara, 2021), the authors choose to use the "Rotor-based linear sum" method based on prior work by Niayifar and Porté-Agel (2016), which I believe is the method you are proposing here. Is that correct?

Now, although as I pointed out above, the current combination methods in FLORIS are all applied to the free stream velocity, that doesn’t mean that this is the best model. I’m certainly happy to support you implementing a new model that uses the turbine inflow velocities, especially if you have data to support that being an improvement over the existing (free stream) methods!

In terms of the behavior you are seeing that certain turbines can produce zero power (and zero wake): this is expected. If the inflow wind speed at any turbine drops below the cut-in wind speed for the turbine, it will produce zero power, zero thrust, and therefore no wake (this will occur if the inflow velocity is negative, which as you say, is not reflective of reality but can occur in certain models, especially in the near wake, or if the inflow velocity is positive but still below the cut-in speed for the turbine).

A final point I’ll make here is that we are in discussions to make user-provided models easier to implement. This will allow users to replace the entire solver (velocity deficit, deflection, turbulence intensity, and combination model) with something of their own design. This is still a while away, if it does every come, but I think it would help users such as yourself implement their own “changes” to the underlying solver without having to go in and change the FLORIS code. Let me know if you think this would be useful to you.

Hopefully this makes sense and I understood your question---please feel free to correct me if I didn’t!

Best,
Misha

[SSWMC]

Thank you for your detailed and complete answer.

Your understanding is correct. "Wake velocity" is not a physical entity; both methods mentioned above only approximate the evolution of this physical phenomenon, and there is no inherent superiority of one over the other.

Regarding the paper I cited, it is not my own research. I saw relevant explanations in it and drew my own conclusions based on them.
As shown in equation (1.3) in paper Zong and Porté-Agel, 2020 the content within the yellow circle represents the wake velocity induced by WTi under independent conditions.

The subsequent explanation in the text mentions that "In Method A (free-stream wake velocity superposition model), a large wind turbine spacing with weak wake interaction is assumed, such that, during the calculation of individual wakes, the mean wind velocity experienced by the downstream wind turbines can be substituted by the inflow velocity of the wind farm, i.e. $u_0^i≈U_∞,$" and the description in Qian and Ishihara, 2021, which you mentioned in your answer, led me to conclude that "when the flow distance between upstream and downstream wind turbines is sufficiently close, the rotor speed based on the local speed of the upstream turbine should be used." However, I regret to inform you that I currently lack detailed measurement or simulation data for continuous wake interference scenarios involving multiple wind turbines, and therefore cannot provide stronger evidence. Thus, this conclusion is somewhat radical, and it was my mistake.

I'm also pleased to see your thoughts on solvers. I checked my own model's implementation on Floris, and currently, I've defined new custom solvers in solver.py to adapt to my model, such as my_sequential_solver/full_flow_my_sequential_solver. This was indeed difficult at first, due to unfamiliarity with the interfaces between programs and the dimensionality changes of computational variables. However, Floris's clear internal source code offers many valuable lessons, which is beneficial for me, saving me the step of writing my own solver framework. I only need to find a computationally similar model and apply the framework. I'm not entirely sure how you plan to make "changes" easy, but any update that reduces the time cost for users integrating models is definitely a beneficial one.

Finally, I apologize for the potentially biased and unfriendly tone in my question above. This stems from my immature community experience, and I hope you don't mind.

Best regards

[misi9170]

Hi @SSWMC,

Welcome to the community, and no need to apologize! Also, no problem regarding perhaps coming on a bit strong in support of using a rotor velocity, rather than a free velocity, in the models :) In all honesty, even though I haven't spent a lot of time looking at the superposition/combination models myself, using a rotor velocity "feels" more correct (to me) than the free stream velocity when applying a non-dimensional velocity deficit. But as I say, I haven't worked on this much myself, and I could probably be convinced either way! However, we have usually found that using the SOSFS combination model works "well enough" for most of our purposes as NREL---possibly because it (heuristically) accounts for a couple of different effects (see my comment here and also Gunn, 2019). The combination models in FLORIS have been around for quite some time, likely prior to the publication of these articles around 2020, and possibly are due to have some new methods added.

It sounds like you are on a good track with editing the existing solver within FLORIS. That's the best way to make/test changes for now. But yes, the basic idea we are aiming for is that a user will be able to pass their own solver (e.g. my_sequential_solver()) in and have FLORIS run that solver instead of one of the provided solvers (e.g. sequential_solver()). The user will still need to understand the structure of the solver data inputs (farm, flow_field, and grid), so it's definitely still worth your time to get used to the existing solvers! But the end goal is to allow users to more easily try new things out and compare them to the provided solvers side by side, while using the rest of the FLORIS infrastructure for passing around the data and extracting values of interest (like turbine powers and turbine inflow velocities). We are also considering enabling user-defined operation models. Anyway, like I said, it will be a little while before we have this all in place but I'm glad it sounds like something you could use!

Misha

[misi9170]

Hi @SSWMC ,

@paulf81 brought up a good point to add to the discussion here (this one leaning more in favor of using the free stream, rather than the turbine inflow velocity, I think, but really just something to think about).

Far downstream of a wind turbine, we expect the flow to recover to the free stream velocity, not to the velocity of the last turbine. So, let's let turbine $i$ be in the last row of the farm (such that it is operating inside a wake, i.e. $u_i^0 < U_\infty$). Then, according to the model (1.3) from Zong and Porté-Agel, the "wake loss" from this turbine is $u_i^0 - u_w^i(x,y,z)$---that is, the "wake" of turbine $i$ is defined as a deficit below $u_i^0$ (and assuming that $u_w^i(x,y,z)$ approaches $u_i^0$ as $x \rightarrow \infty$). Now, because this wake is subtracted from $U_\infty$, $U_w(x,y,z)$ will still approach $U_\infty$, but the individual wake component $u_w^i(x,y,z)$ only approaches $u_i^0$.

In contrast, the free stream version (1.1) maintains that the individual wake component $u_w^i(x,y,z)$ approaches $U_\infty$ (and, like (1.3), the "combined" velocity of course also approaches $U_\infty$).

As we've already agreed, both are "wrong" because individual wake components don't really exist, but an argument could be made that it "feels more correct" for an individual wake component to itself return to the free stream velocity, rather than to the inflow velocity of the turbine that generated the wake component. (1.3) seems to treat the flow as having a special property exactly at the rotor locations, such that wake components revert to that flow state, whereas (1.1) treats $U_\infty$ as being the fundamental flow upon which individual wakes are defined.

Food for thought! I do think it could be interesting to see how using rotor inflow velocities changes the results we get from FLORIS---my guess is that likely, the wake models themselves would need some recalibration to "balance" the change (but the wake models are hardly perfect themselves, and often benefit from recalibration to specific circumstances).

[SSWMC]

Hi @misi9170

Brilliant reasoning! It took me a while to understand everything. You mean: For a distance $x_\infty$, far downstream of the downstream wind turbine, if we use a method based on "rotor inflow velocity" to calculate the wake velocity at $x_\infty$, the wake component will definitely tend towards $u^0_i$. However, intuitively, the wake velocity at $x_\infty$ should revert to free flow velocity, creating a contradiction. Am I correct in my understanding?

I think your idea is correct. At a distant location downstream of the wind turbine, the "wake" must have the ability to revert to free flow. However, in reality, the arrangement of wind turbines may not allow enough space for the wake of each turbine to fully develop. Modeling the wake of multiple wind turbines is primarily for obtaining the equivalent inflow velocity to obtain the equivalent power of the turbine.

But as I said at the beginning, using "free flow velocity" to calculate the effect of a single wake will definitely lead to an overestimation of velocity loss at closer distances. I'd like to give a contrasting example. Instead of considering the last turbine at an infinite distance, let's arrange the turbines at extremely close 2D intervals. Let's assume that each turbine's velocity loss factor (or normalized velocity loss) at the nearest downstream turbine is 0.4, or even less. This factor decreases by 0.1 for each subsequent turbine. That is, the wake effect of the upstream turbine at the downstream turbine's position is 0.4, 0.3, 0.2, and so on. You can anticipate that if the "free stream velocity" version (1.1) is used to calculate the actual velocity loss, once there are more than three turbines, a negative wake velocity $U_w$ will be superimposed. However, using (1.3) to calculate the actual velocity loss ensures that turbines with low inflow velocities produce lower wake velocity losses. In reality, wind turbine blades are not "walls" that block all the "wind," and there wouldn't be such a close-packed turbine layout.

My point is that, at relatively close distances, using the "rotor inflow velocity" method to handle downstream turbines in strong wakes means that the downstream low-speed turbines won't produce the same "strong" wake loss as the upstream high-speed turbines. This might be because the downstream turbine's rotor blades temporarily have a stronger influence on the airflow than the momentum exchange between the ambient free flow and the wake. (I guess :)

Based on the above analysis, I increasingly feel this is a "polarized" problem, explainable by both methods. Perhaps there should be a "more balanced method" to balance these two approaches at a distance that's neither too close nor too far? However, I haven't seen any relevant information.

[misi9170]

Yes, I see your point regarding the adding wake losses becoming negative in the freestream case, while staying positive (if small) in the inflow case. However, I'm not sure this would always be the case; I'm imagining a (rather trivial) case that looks like:

--> |
--> |  |
--> |

That is, three turbines very close to each other but each seeing the same (freestream), and a downstream turbine that is at least partially waked by all three---I think in this case, since $u_i^0 = U_\infty$ for all three of the upstream turbines $i$, it may still be the case under (1.3) that the inflow velocity down the (near) downstream turbine is negative?

[SSWMC]

Hey @misi9170

Sorry for replying so late..
Let's continue the discussion.

I'm trying to understand what you mean: Three adjacent wind turbines generate wakes that simultaneously act on a downstream turbine. If we let $u_i^0 = U_\infty$, the downstream turbine's wake velocity, calculated using a wake superposition algorithm, would be negative. Is that correct?

I think that with this layout, the current algorithm for full wake superposition (whether "free stream" or "rotor stream") can no longer handle this properly because "several wake streams" are locally acting on the rotor plane of the downstream turbine.

So, I'm sorry, my limited knowledge doesn't know how to handle this situation mathematically. Perhaps we should weight the wake velocity loss values ​​according to the area of ​​influence of each wake stream on the rotor disk?

I reviewed the relevant code for wind turbine grid settings in FLORIS. The solver collects the velocity loss at each grid point on the wind turbine, calculates multiple possible wake effects at these grid points using a specific superposition method, and finally calculates the actual wind speed acting on the turbine, right? The wake model configured by Jensen uses a "turbinie_grid," a grid similar to the "Actuator Disc method." When calculating the actual wind speed, this averages the wind speeds collected at the nine grid points: $\frac{1}{9}\sum_{i=1}^{9}\sqrt[3]{u^3_i} $. This means that if the wake of an upstream wind turbine only acts on one grid point of the downstream rotor disk, the wake effect caused by the upstream wind turbine will be weakened by averaging. Wow, ingenious design! This seems to partially explain the wake interference problem mentioned above.

[misi9170]

Yes, that's correct---and the cubic average is used when evaluating the power output to find the wind speed most representative of the power, which is proportional to the velocity squared. This is also discussed here, if you're interested.