Calculation of flow field for AEP analysis

[JarneVB]

Hi there!

I'm doing a more in-depth analysis of how the theoretical wake models are implemented in Floris. Before comparing wake models, I wanted to see how the power of one turbine is calculated. When I use get_farm_aep() for a layout with just 1 wind turbine, for wind direction = 220 and wind speed = 9, the values of the flow_field.u that are used in the underlying power() function are:
[[[[[8.54809264 8.96430468 9.25664171]
[8.54809264 8.96430468 9.25664171]
[8.54809264 8.96430468 9.25664171]]]]]

I can't figure out how this flow_field is calculated based on the free stream velocity of 9m/s and why there should be 3 values.
I used the Jensen model, but II thought this should be irrelevant as the power should just be looked up in the interpolated Cp table, as the turbine is not in the wake of any other.

Thank you in advance for the help!

[Bartdoekemeijer]

Can you share an example script for us to reproduce this problem?

[JarneVB]

So the basic version of the script is :

from floris.floris.tools.floris_interface import FlorisInterface 
fi_jensen = FlorisInterface("floris/examples/inputs/jensen.yaml")
fi_jensen.reinitialize(layout_x=[0], layout_y=[0], wind_directions=[220], wind_speeds=[9])
fi_jensen.calculate_wake()
SR_NOJ_1wswd = fi_jensen.get_farm_AEP( freq= [[1]], turbine_weights=None) / 1E9

Then when I add print(self.floris.flow_field.u) in def get_turbine_powers() in floris_interface, I get these values for the velocities that are given to def power():

[[[[[8.60577421 9.00233493 9.28528014]
    [8.60577421 9.00233493 9.28528014]
    [8.60577421 9.00233493 9.28528014]]]]]

Then in turbine.py you have def power() and there the average of these velocities is taken:

>Compute the yaw effective velocity
    pW = pP / 3.0  # Convert from pP to w
    yaw_effective_velocity = ((air_density/ref_density_cp_ct)**(1/3)) * average_velocity(velocities) * cosd(yaw_angle) ** pW

but the average of these three values add up to 8.964463 instead of 9m/s, which is the given free stream velocity.

It's not really a problem I think, but I was just wondering why this method is used.

[rafmudaf]

@JarneVB This is a consequence of the shear law profile in FlowField.initialize_velocity_field. You can get a sense for this if you change the wind_shear input to 1 so that the shear profile is linear. In that case, the velocity is 0 at the ground since z_sorted is 0, and it is the input wind speed at hub height since z_sorted equals reference_wind_height. In fact, there's a unit test that demonstrates this effect and uses it to ensure that this function is operating correctly: https://github.com/NREL/floris/blob/main/tests/flow_field_unit_test.py#L42.

[JarneVB]

Thank you, this is very helpful! Just one more question, if I understand it correctly, the three velocities are the one at the bottom of the turbine diameter, at the hub height and at the top of the turbine diameter. Why is the velocity at the hub height not exactly 9 m/s, when my reference_wind_height is set to the hub height? Is this just a rounding error?

[rafmudaf]

@JarneVB I think I have an explanation, but please let me know if this is off.

In #600 (reply in thread), you point out that the velocities on the rotor grid do not average to the input wind speed. This is partly due to the wind shear being nonlinear. If you set wind shear to 0.0, all velocities should be the same. If you set wind shear to 1.0, they should form a straight line as a function of height. In both of those cases, a simple average should be the input wind speed.

However, another point worth noting is that the Turbine.average_velocity function used in Turbine.power represents the average as the cube root - mean - cube of the velocities at the rotor grid. @paulf81 @bayc can you help recall the reason behind this method for the average velocity rather than a simple average (np.mean)? I see that I made this change way back in FLORIS v1.0, but sadly I didn't add any context to that commit. We also had a similar question during the v3 development as seen here, so this would be great to document.

[JarneVB]

Thank you! This was all very helpful!