Impact of grid point density and location

[UnderMou]

Hello everyone.
I'm studying the Floris in order to use it in a wind farm layout optimization problem and I came across this issue regarding the TurbineGrid class, more precisely in the construction of 'disc_grid'.

By using the default value for the radius_ratio = 0.5 (line 185), does it mean that the turbine_grid_points (default on gch.yaml file to turbine_grid_points = 3 for the 02_visualization example case) will generate coordinate points to be used by the wake model only in a inner disk of the rotor with radius = 0.5 * rotor radius, right? i.e.: y values of [-0.5rotor_radius, 0, 0.5rotor_radius] and z values [Hub Height - 0.5rotor_radius, Hub Height, Hub Height + 0.5rotor_radius], being disc_grid a meshgrid of these arrays, right?

In my case, I'm intending to use more points, turbine_grid_points: 5 ...Would evaluating the grid points within this "inner disk" impact the results of the layout optimization problem underestimating the wake effects on regions of the rotor which radius position excedes 0.5*rotor radius? Would you recommend setting this radius_rate value to 1.0 or something like that when using more points?
I don't know if I made myself very clear. I hope so.

Thanks in advance!
I also would like to thank all the team for providing this incredible framework.

Best regards.

[rafmudaf]

Hi @UnderMou,

You're correct, the radius_ratio does restrict the grid points used in the wake model to a half-radius disc. @paulf81 do you recall the reason for using 0.5? I do not recall the reasons that led us to stick with the half-radius, but I suspect it will also answer whether there's a real impact on the optimization problems.

Is there a reason for using a 5x5 grid on the rotor area instead of the 9x9 grid?

Thanks for getting in touch @UnderMou!

Rafael

[UnderMou]

Hello @rafmudaf ,

Would you recommend using a 9x9 grid on rotor area on a wind farm optimization problem? actually I don't recall if there was a specific reason or reference why I picked up a 5 points resolution grid. I'm still setting the simulation/optimization stuffs, so I might change for a 9x9 grid if it is more appropriate.
Thanks for the advice!!

Yesterday I think I made a mistake on wondering if a 1.0 radius_ratio would be better ...
Since the velocity on each turbine is evaluated as an average value of the grid points, I think setting a radius_ratio greater than ≈0.7 would let some grid points (the corners) relying outside the swept area of rotors and then impact on averaged velocity, power output and the whole wind farm performance during the optimization... I tried to better explain my point in the figure below. Do you think that is reasonable?

Thanks again for the support @rafmudaf .
AndersonMR.

Original figure picked up from: Stanley, A. P. J., Roberts, O., King, J., and Bay, C. J.: Objective and algorithm considerations when optimizing the number and placement of turbines in a wind power plant, Wind Energ. Sci., 6, 1143–1167, https://doi.org/10.5194/wes-6-1143-2021, 2021.

[rafmudaf]

Ah @UnderMou thanks for pointing out this figure. The algorithm for setting these points does a "fit" of rotor area. In this case, if radius_ratio is 1.0, then the four corners of a 3x3 grid are outside of the rotor area. In FLORIS v2, the wake calculation was done at these points but it was then filtered out for the power calculations. I agree that using a value of 0.7 for radius_ratio is the best option. This brings up a question of whether we should have a radial distribution of points rather than imposing a square grid on a circle. If you're interested to try this out, the grid is constructed with np.linspace in the grid module.

As for the point density and impact on the solution, I'm working on characterizing this further but there's a good discussion in #499. I'll update this thread again soon.

[UnderMou]

Hello @rafmudaf ...
Yeah... I thought about that and I was wondering on trying to contribute to floris on this question regarding the radial distribution. I'm not as certain if by doing that would affect other parts of the code (I mean break some other stuff).

I'll try to implement this contribution as soon as I can and then report it here.

Thanks again.