You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It is not particularly related to a problem, but rather a nuisance. Whenever I want to set up a wind farm with more than one turbine type, I feel like I am "hacking" the FLORIS object. Currently, the process goes something along these lines:
I create one FLORIS .json file with the locations and turbine properties for every wind turbine type
I load all .json files and combine the floris objects by updating the layout and then the turbine properties:
layout_x = []
layout_y = []
turbine_cpct = []
turbine_hh = []
turbine_D = []
for fi in fi_list:
# Wind farm layout
layout_x.extend(fi.layout_x)
layout_y.extend(fi.layout_y)
# Turbine properties
num_turbs = len(fi.layout_x)
t0 = fi.floris.farm.turbines[0]
turbine_cpct.extend([t0.power_thrust_table] * num_turbs)
turbine_hh.extend([t0.hub_height] * num_turbs)
turbine_D.extend([t0.rotor_diameter] * num_turbs)
fi = deepcopy(fi_list[0])
# Copy default turbines to new layout locations
fi.reinitialize_flow_field(layout_array=[layout_x, layout_y])
# Update turbine properties
for ti in range(len(fi.layout_x)):
fi.change_turbine(
[ti],
{
"power_thrust_table": turbine_cpct[ti],
"rotor_diameter": turbine_D[ti],
"hub_height": turbine_hh[ti]
}
)
This also makes it more difficult to track the specified_wind_height. Ideally, FLORIS could simply tell the user to specify an explicit specified_wind_height whenever more than one turbine type is used.
Describe the solution you'd like
Ideally, the .json would simply allow a variable number of turbine types. Then, one would then need another input in the json in either each turbine field or farm specifying which turbines belong to which turbine type.
Describe alternatives you've considered
I now have a practice where I create a class for these types of wind farms, wherein I contain all these operations. That way, I can still simply call a wind farm using a single command and get a floris object in return.
The text was updated successfully, but these errors were encountered:
Thanks for this feature request! I have a feature in the works for allowing better definition/changing of turbine Cp/Ct curves. When I submit that pull request, I will be sure to add you as a reviewer and we can make sure that it has the functionality you are looking for.
I'm currently doing the same thing as @Bartdoekemeijer - more than happy to spend some time casting an eye over the feature... or do shout if you need help actually defining that JSON structure (it can make for a slightly awkward schema doing multiple turbines, each with multiple operating modes, but I've done similar a couple of times already so might have some useful elements)!
Is your feature request related to a problem? Please describe.
It is not particularly related to a problem, but rather a nuisance. Whenever I want to set up a wind farm with more than one turbine type, I feel like I am "hacking" the FLORIS object. Currently, the process goes something along these lines:
This also makes it more difficult to track the
specified_wind_height
. Ideally, FLORIS could simply tell the user to specify an explicitspecified_wind_height
whenever more than one turbine type is used.Describe the solution you'd like
Ideally, the .json would simply allow a variable number of turbine types. Then, one would then need another input in the json in either each
turbine
field orfarm
specifying which turbines belong to which turbine type.Describe alternatives you've considered
I now have a practice where I create a class for these types of wind farms, wherein I contain all these operations. That way, I can still simply call a wind farm using a single command and get a floris object in return.
The text was updated successfully, but these errors were encountered: