Collect all layout visualization tools in FLORIS

[paulf81]

Collect all layout visualization tools in FLORIS

Presently, tools for interrogating/plotting the layouts existing, sometimes in duplicate, across FLORIS and FLASC, and even within FLORIS, tools were duplicated between visualizations.py and layout_functions.py. The purpose of this pull request are pulling all the tools into one module (layout_functions.py) in FLORIS, and then importing into FLASC. This pull request also seeks to resolve Issue #804 by ensuring all functions accept turbine_names.

In this PR (and companion pull request in flasc (NREL/flasc#174)), functions are all moved to layout_functions.py, and their form and usage is standardized.

A new example (to be re-organized later (23_layout_visualizations is introduced). This example demonstrates the preferred usage of importing the layout_functions module as lf, and calling each function via lf.xxx().

In each case, either a pyplot axes is passed in or else a new one is created and returned. Also in each case, a FlorisInterface object is passed in to get the locations of the turbines.

The functions in layout_functions.py are intended to each implement one plotting action and can be called sequentially to add layers to the plot.

• plot_turbine_points: Plot turbines as points on axis
• plot_turbine_labels: Label the turbines, in default case given FLORIS' 0-index value as a label, but can also accept provided turbine names
• plot_turbines_rotors: Indicate the turbine rotors (including yaw) on a plot. This is usually most useful for indicating turbine position onto flow visualizaitons
• plot_waking_directions Draw labeled lines in-between each turbine and label the distance (in D) and wind directions in which the turbines wake each other.
• shade_region: Add a shaded region to an existing plot, can be useful to identify specific areas, or boundary boxes or phases/farms
• plot_farm_terrain: Use the hub-height information in FLORIS to make a contour plot of elevation

An example plotting script would be:

import matplotlib.pyplot as plt
import floris.tools.layout_functions as lf
from floris.tools import FlorisInterface

fi = FlorisInterface("inputs/gch.yaml")
fig, ax = plt.subplots()
lf.plot_turbine_points(fi, ax=ax)
lf.plot_turbine_labels(fi, ax=ax)
lf.plot_waking_directions(fi, ax=ax)
plt.show()

A small test module is started (layout_functions_test.py).

Finally, as shown in example above, we removed calls to plt.show() from within functions inside layout_functions.py and adopt a convention that this call should be made by user.

Related issue

#804

[paulf81]

@rafmudaf and @misi9170 this is now ready for your review

[rafmudaf]

Heads up the tests are still failing

[paulf81]

Heads up the tests are still failing

Its the examples, that is my bad, I'll get it

[misi9170]

I've added a small, indirectly related bugfix to this PR, introduced in #823: I noticed in a place where fi.reinitialize() was accidentally still being called (with argument layout_x, among others) that the error raised was
TypeError: FlorisInterface.reinitialize() got an unexpected keyword argument 'layout_x',
which is confusing when in fact, reinitialize() has been deprecated.

The solution I have was to allow the empty reinitialize() function (as well as calculate_wake()) to accept (and ignore) arbitrary keyword arguments. Now, the intended
NotImplementedError: The reinitialize method has been removed. Please use the set method. See https://nrel.github.io/floris/upgrade_guides/v3_to_v4.html for more information.
is raised when reinitialize() is called with arguments. Hope that's ok to tack on here.

[misi9170]

Approving this now, but I do think @rafmudaf is right that the name of the file should be something more clearly to do with plotting/visualization than layout_functions.py. I've added a suggestion on that above.

[rafmudaf]

Include test for plot_turbines_rotors

[rafmudaf]

I've added this test, but it would also be good to test plot_farm_terrain.
Also, I think I know the answer to this, but is there a better test available? It's good to run these functions, but as is this is only testing that the inputs are of the correct general data type.

[paulf81]

Yeah, this was a puzzle for me, since they end in a plot, my main thought was just to make sure the functions can run all the way through without erroring. I wasn't sure how to confirm if the plot is "right"

[paulf81]

I can add the test for plot_farm_terrain, then merge you think if I do it tonight?

[rafmudaf]

Yep sounds good to me.

[paulf81]

Ok great, done and merging!