Optimize yaw in parallel for larger wind parks

[PGebraadYW]

Hi there,

I have been trying parallel execution with 16 workers (just the cores available on my laptop, see some specs below) for a wind farm > 100 turbines, expanding on the example of 12_optimize_yaw_in_parallel.py. I noticed that it struggles with parks of 100 turbines or larger. What is your experience with it?

Pieter

[paulf81]

Thanks for the question! I don't have a ready answer but I believe the deepest dive done on this question was done by @RHammond2 and found this was fundamentally a memory issue, but perhaps we can look at this again in v3.4 and see what we can find. @rafmudaf any thoughts?

[RHammond2]

That's correct, essentially as you scale the number of turbines you can expect your run time to degrade significantly because of the memory usage required for expanding that inner dimension.

[Bartdoekemeijer]

How long does it take for your optimization to complete, approximately?

For what it's worth, I have successfully used the parallel computing interface for well over 100 wind turbines for both AEP evaluations and yaw optimizations without problems. My local machine has an i9-11950H with 64GB RAM. Though, I do tend to move towards our HPC for 100+ turbine wind farms.

If you're looking to speed things up, you could try:

1. Optimizing the yaw angles for a single wind speed only. Kanev et al. suggests that the optimal yaw angles are not very sensitive to the ambient wind speed, so you could optimize for a wind speed of 8 or 9 m/s and apply those yaw angles for the entire region 2.
2. You could reduce the number of turbine grid points in the input file. I do suggest you do a sensitivity study before you do this, but this may speed up your optimization by a factor 3-4.
3. You could reduce the number of Serial Refine passes and evaluations. Typically, we use Ny_passes=[5, 4], like so, but depending on your yaw optimization limits you could reduce this, e.g., to Ny_passes=[7]. Again, it's worth doing a convergence study.
4. You could try the concurrent parallel computing library recently included in Feature: Add concurrent library to ParallelComputingInterface #667. I haven't noticed a massive speed-up, but this may be different for your machine.

[PGebraadYW]

Hey @Bartdoekemeijer ! Good chat with some FLORIS veterans here :)

• Yes in my particular case with 1) it is feasible also without the parallelization, in 6h. With parallelization with 16 workers it is 1.5 h.
• Re 3) I think I will have to read up on the Serial refine method. Thanks!
• From my experience with @jaredthomas68 in the old days, and the years in between, it is worth also to use (auto-generated) analytic gradients, perhaps finally combined with the Serial Refine method it could be a winning combination?

[misi9170]

To throw another (very new) option into the mix, we've recently been implementing @pjstanle 's geometric yaw optimization (original repository here and details here). This is a very rough first pass optimization approach that relies only on the layout of the wind farm and the wind direction (calculating yaw angles using a Jensen-like model based only on the next turbine downstream).

To be clear, a final yaw optimization (using serial refine, which is considerably faster than the scipy.minimize method, as @Bartdoekemeijer points out) would likely be needed. However, if you're just wanting to get a rough idea, this method should be very fast.

The geometric yaw optimization is currently in a pull request (#681) if you want to take a look. We plan to merge it into the develop branch imminently. It should be treated as a beta code; but if you have any feedback, we'd be happy to hear your thoughts.

[jaredthomas68]

@PGebraadYW, I think @bayc and others have looked at using auto-differentiation in the current version of FLORIS but have been limited by the capabilities of the automatic differentiation (AD) packages available in Python together with the attributes of the mathematical models in FLORIS. I would be interested in finding a solution here so that FLORIS provides exact, and efficient, derivatives. Our previous work on AD for FLORIS used models written in Fortran and wrapped in python so we could use Tapenade for AD. We have done similar successful work in Julia, but with a single language using pure Julia as Julia has excellent AD capabilities. I believe the current FLORIS has moved completely away from the two-language approach we used before, so Tapenade is no longer applicable because Tapenade requires the source code to be in either Fortran or C.