-
Notifications
You must be signed in to change notification settings - Fork 156
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
Wind direction heterogeneity #954
Draft
misi9170
wants to merge
39
commits into
NREL:develop
Choose a base branch
from
misi9170:feature/wd-het-2
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
+969
−31
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… sequential_solver.
…ging as proof of concept.
… so that Grid() can have heterogeneous_inflow_config take a default of None.
Note that, finally, the streamlines are used to determine a turbine movement, not to actually calculate the wake profile along the streamline. For this reason, I do not think that this fully addresses the suggestion (for wind speed heterogeneity) by @CaiZhiming-HHU in #851. However, it should expand our ability to model complex terrain by proxy. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
THIS PULL REQUEST IS A WORK IN PROGRESS
(re)Introducing wind direction heterogeneity in FLORIS
In FLORIS v2, there was handling for wind direction heterogeneity. Wind direction heterogeneity was not straightforward to continue supporting in the vectorization effort for v3, and was dropped. This pull request reintroduces a new method for handling wind direction heterogeneity by "warping" the turbine layout mimic the effects of a wind direction change.
This is currently a work in progress, and is missing several crucial steps. I will update this description as those steps are addressed.
Critical pieces still needed:
Setting main wind speed and wind direction according to specified(u
,v
values (i.e., reconciling the turbine ordering based on thewind_direction
with that based onu
andv
)u
andv
are now taken as relative to main wind direction)u
,v
valuesu
,v
values?Other TODO items:
Expand to 3D case (u
,v
as a function ofz
; possibly alloww
specification)z
is provided for speed multipliers (by averaging over z)sequential_solver
andfull_flow_sequential_solver
)HeterogeneousMap
Housekeeping
Methodology
The core idea here for modeling wind direction heterogeneity is that, rather than move the wakes to new locations based on local wind directions, it is easier to move the turbine locations a commensurate amount (warping the turbine layout). After testing several prototypes, the current methodology essentially works by assigning an equivalent wind farm layout for each turbine, based on the wind direction changes occurring in the wake of that turbine. That is, when solving for the wakes, the wind farm has a different layout depending on which turbine in the farm is being evaluated.
Users specify these wind direction changes by specifying the "u" (x-directional,
i.e. west to east) and "v" (y-directional,i.e. south to north) components of the wind (that is, by specifying a 2D discrete velocity field). Streamlines are propagated from the rotor centers, which define the path of the wake center; these streamlines are then used to determine movement distances for the turbines. That is, the layout is warped according to the streamline to achieve the equivalent effect of a curved wake.EDIT: after playing around with this some more, I think we will let "u" be the "along-stream" component, where the direction of the stream is specified by
wind_direction
, and "v" be the "cross-stream" component. That is, u and v are relative to the oncoming wind direction.We intend to submit a paper describing the warped layout methodology, as well as comparisons to operational data, in the coming months.
Examples
Examples, which are a work in progress, can be found in examples/examples_heterogeneity/. The new examples begin with 00x_, for the time being until I have cleaned them up and renamed them.
Running 00x_wind_direction_heterogeneity.py produces
(that is, the downstream turbines' powers are higher in this specific heterogeneous wind condition than in the aligned case)
and
Running 00x_wind_direction_heterogeneity_visualization.py with
viz_by_sweep = False
producesand with
viz_by_sweep = True
producesNote that even once (if) this pull request is completed and merged, wind direction heterogeneity capabilities will likely be a beta feature for some time as we iron out any wrinkles that may arise.
Affected area of the code
The main areas affected by the code are:
There are also other small changes to:
Acknowledgements
Thanks to Paul, Yorgos, Diederik, Raf, Sam, and others for letting me bounce ideas around.