Point calculations

[rafmudaf]

There has been a bit of discussion around the need for pulling out points from the flow field that aren't associated to a turbine's rotor grid. This was functionality that was available in v2 by passing an array of points to the calculation routine to add to the data structures that held all of the discrete calculation points. In v3, the solver structure was redesigned so that all points were placed in space by a particular type of grid and stored on that object as Numpy arrays. These arrays are directly used to create the rest of the data structures that store things like velocity components, turbulence intensity values, etc. Because of this difference, we can't simply add points to the data structures and iterate through them.

I've prototypes this feature in my fork and you can see the changes here. There, I've added a PointsGrid class that places points in space as given by the user. Then, we can use this directly instead of FlowFieldPlanarGrid in the full_flow_sequential_solver routine. This solver routine already has the infrastructure to do that flow field calculations on the turbine grids and subsequently iterate through a series of points to find their velocities based on upstream turbines. Rather than using a structured grid such as in FlowFieldPlanarGrid, we use an arbitrary series of points. You can test this with the following script.

from floris.tools import FlorisInterface

# Baseline
# 3-turbine farm with turbines at 0,0 630,0 and 1260,0
fi = FlorisInterface("inputs/jensen.yaml")
fi.calculate_wake()
print(fi.floris.flow_field.u_sorted[0,0,:,1,1])  # Print the mid point of the turbine grids

# Test
# Put a point at the mid point of each turbine's grid and check that the velocity matches
floris_dict = fi.floris.as_dict()
floris_dict["solver"] = {
    "type": "points_grid",
    "points_x": [0.0, 630, 1260.0],
    "points_y": [0.0, 0.0, 0.0],
    "points_z": [90.0, 90.0, 90.0]
}
fi = FlorisInterface(floris_dict)
fi.floris.solve_for_viz()
print(fi.floris.flow_field.u_sorted[0,0])

# >>>
# [8.         6.17321315 5.67774542]
# [[[8.         6.17321315 5.67774542]]]

Next steps

While this is a demo of a way to do this, the interface and workflow needs work. Primarily, this method is an adaptation of the visualization routine where the expectation is that the data on the turbine grids is no longer needed. Here, though, I think we should expect that these points are equal in importance to the rotor points and will be used in a very similar way. It's not reasonable to clear the existing data to do these point-calculations only. I think this primarily means designing FlorisInterface so that it supports this sort of point calculation in addition to the typical calculate_wake functionality.

Associated Issues

#420
#425
#585

[rafmudaf]

FYI @paulf81 @bayc @MarcusBecker-GitHub

[misi9170]

@rafmudaf this is looking great! If I'm understanding your thoughts for next steps correctly, you'd like to be able to call this in sequence with a calculate_wake call, so you could do something like:

fi.reinitialize(wind_speeds=[8.0], wind_directions=[270.0, 90.0])
fi.calculate_wake()
extracted_flow_values = fi.get_flow_values(points=[(0.0, 0.0, 90.0), (630.0, 0.0, 90.0), (1260.0, 0.0, 90.0)])
turbine_powers = fi.get_turbine_powers()

without having to redo the calculate_wake() step in between the get_flow_values() call and the get_turbine_powers() call. Is that right?

get_flow_values() is just a dummy name, maybe not the best. In the above, I guess I'm suggesting that the sampling points be passed as a list of (x,y,z) coordinates, but an alternative would be to pass them exactly as the points_grid solver type expects them (3 separate lists of equal length, for x, y, and z locations)?

[paulf81]

Thanks @rafmudaf , this is looking really promising! I think I follow the example above but on your next steps, when you say "the expectation is that the data on the turbine grids is no longer needed", you mean because the rotor-effective velocity is already known, so we know cp/ct for the wake models?

Thanks a lot @rafmudaf for diving in here!!

[rafmudaf]

That's a nice workflow, @misi9170. I think that's the direction we should go. Possible the only new code required is the fi.get_flow_values() part. FWIW we could split up the visualization solver within floris.simulation and create a new API in FlorisInterface so that both are using the same low level code but have different access points to the user. Whereas currently we would have this architecture:

flowchart LR
    A[FlorisInterface.calculate_X_plane] --> B[floris.simulation.floris.solve_for_vis]
    C[FlorisInterface.get_flow_values] --> D[floris.simulation.floris.calculate_wake]
    C[FlorisInterface.get_flow_values] --> E[floris.simulation.floris.calculate_points]

Loading

We could have something like the architecture below. This one seems more complex initially, but the benefit is that it would keep a single pipeline for this sort of calculation within floris.simulation and the implementation for how it's used (i.e. how the data is handled and presented at the highest level) is dealt with that the FlorisInterface level.

flowchart LR
    A[FlorisInterface.calculate_X_plane] --> B[floris.simulation.floris.calculate_wake]
    A[FlorisInterface.calculate_X_plane] --> C[floris.simulation.floris.calculate_points]

    D[FlorisInterface.get_flow_values] --> B[floris.simulation.floris.calculate_wake]
    D[FlorisInterface.get_flow_values] --> C[floris.simulation.floris.calculate_points]

Loading

[rafmudaf]

@paulf81 That part was meant to refer to the point that the visualization function essentially throws away the points at the turbine rotors. For visualization, that's fine. However, I think the general case for calculating arbitrary points will be that the turbine points and the user-defined points are both going to be used in the calling script.

[misi9170]

That seems reasonable to me!

[paulf81]

This all sounds good to me too!