Parallelize `YawOptimizationScipy` and `YawOptimizationSR` `optimize` methods across wind speeds/directions

[achenry]

The optimization procedure, in particular the YawOptimizationScipy, would be much faster if parallelized across all available cores, given passed argument parallel to optimize method. Would require instantiating copies offmodel' for each run.

See https://github.com/achenry/floris/blob/feature/mpc/floris/optimization/yaw_optimization/yaw_optimizer_scipy.py for working example. Warning, may not work if each optimize method is run in outer run in multiprocessing context.

[Bartdoekemeijer]

Hi @achenry, take a look at the parallel_floris_model interface, https://github.com/NREL/floris/blob/01115bf89645aa0aefc1a2f5db35078bfe17896e/floris/parallel_floris_model.py#L456

That does serve your needs?

[misi9170]

We could look into adding a method for scipy optimization to the ParallelFlorisModel too---either by creating a new function similar to _optimize_yaw_angles_serial() for scipy optimization or by allowing the user to select between optimization routines in _optimize_yaw_angles_serial().

[achenry]

A few thoughts...

1. It might be more helpful to use the same FlorisModel, but pass a parallel flag to the optimize methods, to facilitate switching easily between sequential and parallel operation for debugging
2. For use with kestrel/HPC, need a working example including bash_script (I have these).

[misi9170]

For Floris v4, the hope was to have both the UncertainFlorisModel and the ParallelFlorisModel be drop-in replacements for the FlorisModel; that is, the FlorisModel would not take optional parallel or uncertain arguments, but rather the line fmodel = FlorisModel(...) could be simply replaced with fmodel = ParallelFlorisModel(...) / fmodel = UncertainFlorisModel(...) to run in parallel or uncertainty, respectively.

Although we achieved this for the UncertainFlorisModel, we didn't end up getting to this for the ParallelFlorisModel---the user interface is still different for the ParallelFlorisModel than the FlorisModel. We do hope to address this (make a parallelized drop-in for the FlorisModel, which hopefully parallelizes the run() method) in a future release. I think this would be similar to what you're after?

To your second point: since bash scripts are quite platform-specific, and many FLORIS users are not using Kestrel/NREL HPC systems, we haven't included bash scripts in the past. However, I think that could be reconsidered if it's possible to make a bash script that is general. Otherwise, we could include sample code bash code somewhere in the documentation.