Visualization Library

[rafmudaf]

FLORIS has a practical library for a variety of visualizations we typically produce. As part of an effort to design a more cohesive floris.tools package, I'm looking at the visualization routines to identify general ideas as well as inconsistencies. This package has been developed over many years without a high level direction, so many of the tools have gone through a series of changes and there are still remnants of past decisions. My goal is to identify the general functionalities and practical routines, add consistency to the implementation and API's, and establish a framework that can build on the existing tools.

CutPlane

This is a class used to store the velocity-components on a the full-flow grid-types used for plotting 2d wake profiles. This is the backbone of many of the flow field visualization routines.

CutPlane contains a resolution attribute that was primarily used in visualization.visualize_cut_plane to create the point-mesh for plt.contour. #578 switched the Pyplot method to plt.tricontourf and this no longer uses CutPlane.resolution. That attribute was then only used in visualization.visualize_quiver. I tried removing the resolution attribute entirely and noticed that it's required in visualization.visualize_quiver only to reshape the data from flat to 3d. Now my question is whether this data needs to be flattened initially or can it be stored in the shape as given. @paulf81 do you have insight here? Is the "flat" arrays in CutPlane a legacy decision or is it still required?

[paulf81]

Thank you for checking @rafmudaf, I did build these up over time, and if I'm being very honest I always write the 2d-mesh style plots through a process of trial-and-error so I'm positive there can be a lot of out-of-date or not-needed code still in. I would say anything that ultimately produces the same visualization, and with more readable consistent code would be an improvement!

[rafmudaf]

Ok, sounds good. I removed the flat commands everywhere but then realized that a pandas.DataFrame requires flat arrays, so it immediately didn't work. I like the structure of CutPlane in that it holds all the data of the grid-type used. Maybe it's good as it, and I was too deep in a rabbit hole. Nevertheless, I'll keep thinking about it and as it related to the other visualization routines, and I'll update this discussion as needed.

[paulf81]

sounds good to me!