-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Randomized layout optimization #697
Conversation
Sounds really interesting! The way you describe it, it seems to be some sort of genetic algorithm, where only the strongest contenders survive every iteration and turbine locations are randomly mutated. Looking forward to seeing how this all pans out compared to the existing methods! |
Examples are currently failing due to something with Matplotlib that I don't understand... perhaps it will fix itself, otherwise we may need to put a version specifier in |
I'll have a look |
I think it fixed it, I think in earlier versions of matplotlib you could say |
Thanks @paulf81 ! |
@Bartdoekemeijer , @bayc , any chance you'd be willing to review this PR? |
Add randomized layout optimization
@misi9170 and I have been working on an optimization method which works a little like a particle filter. We used some ideas for parrelelization from @Bartdoekemeijer 's UncertainityInterface so in much the same way it should work parallelized on a computer or hpc with mpi as @Bartdoekemeijer had set up the UncertainityInterface (nice code @Bartdoekemeijer!)
The main idea of the algorithm is to maintain N number of open possible optimal layouts and randomly perturb turbines within the layout. Periodically the candidate layouts are re-sampled such that the best performing layouts are duplicated and the worst are removed.
Some nice features of the algorithm are since it's working are exposed we can order the operations of checks from cheapest (check in bounds, check min-distance) to more expensive (compute AEP) and only compute AEP if viable.
We include the possibility for random jumps in turbine locations to avoid getting stuck in local minima. We believe the algorithm will scale to more cores, and to disconnected layout regions pretty seamlessly but haven't tested yet. It should intrinsically support heterogeneous inflows but haven't tested yet. The algorithm also uses a time limit (rather than convergence test) to decide when to quit, this could be improved later on.
Sharing now, though still in progress to allow easier collaboration and feedback. We include an example 29_test_random_opt.py to show usage
TODO: