-
Notifications
You must be signed in to change notification settings - Fork 157
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
Convert turbulence intensity from single value to n_findex length array #782
Conversation
@paulf81 I was just cleaning up the plotting a bit for example 35, and noticed that the rear turbine power doesn't vary very smoothly with TI: Is that expected? If not, it's likely not an issue with this PR per se, but something we may need to look into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should revert some of the legacy files to turbulence_intensity
to avoid confusion about forward compatibility; also, I'm not sure whether we need a v3 to v4 input file converter now or whether we should raise a less generic error if users still have turbulence_intensity
on their input files
@@ -112,7 +112,8 @@ flow_field: | |||
|
|||
### | |||
# The level of turbulence intensity level in the wind. | |||
turbulence_intensity: 0.06 | |||
turbulence_intensities: | |||
- 0.06 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only change so far to the floris input files from v3 to v4 (that turbulence_intensity
, a scalar, changes to turbulence_intensities
, a list). When running the new code with an v3 input file, the generic error gets raised:
AttributeError: The initialization for FlowField was given extraneous inputs: ['turbulence_intensity']
Is that OK, or do we need either a converter to convert v3 models to v4 (similar to what we now have for v3-style turbine models) or a more explicit explanation of the change in the error raised?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both sound good to me, we could add a specific error for when turbulence_intensity is provided, and maybe (with a seperate issue) prepare a converter?
I think this looks like the near-wake boundary in GCH, which is has this sharp change, my guess is that length of the near wake depends on TI so we cross it and transition from linear to gaussian wake |
That would make sense. Is there also another more subtle kink at about 14% TI, or am I imagining that? |
There might be an inflection there, but I don't 'have a ready answer if so... |
examples/35_sweep_ti.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to point out that we're adding more and more example. This one and 36 are both fairly short and simple, and I could see them easily being consolidated into one, worked into one of 4 through 6, or being included in the Getting Started notebook. In any case, these should be described in the examples listing in the documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh definitely, I don't think the examples should stay as they are now, but reconsolidated in a separate pull request, but I was saving that effort until nearer the end when all the tools are ready. Examples 35 and 36 will be folded into the earlier examples but for now I just wanted to produce some temp example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me. I'm OK for this to be merged, with the understanding that there may be some to do items left for later PRs:
- possibly raising a specific error if
turbulence_intensity
is specified in the input yaml, and/or creating a converter to write new v4 yamls - consolidating/removing the examples, which can happen when we propagate the TimeSeries and WindRose data structures more thoroughly through the examples
- creating an issue for that
min
operation in the YawOptimizerBase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I'd suggest creating issues or at least project board cards for the points @misi9170 listed before merging so we don't lose track of them.
Thanks guys! I can do those new issues before merging, ok for you @rafmudaf ? |
This makes the if-statement match the comment above it. By removing a couple of levels if indentation due to the if-statements, the full condition is more clear
d4cd35d
to
2f84b5c
Compare
@rafmudaf @ejsimley @misi9170 @bayc I've added an issue and several project cards to track the issues not fully resolved by this pull request. Issue #791 Have put these all toward the end of the process because I believe they are best done after other actions are completed. But it's important we not forget so including these here. |
Convert turbulence intensity from single value to n_findex length array
This pull request builds on Pull Request #775 , and is intended to address Issue #778 and by extension issues #666 and #713. It converts turbulence_intensity (float) to turbulence_intensities (np.array). Further it enables turbulence_intensities to be specified:
Or to be generated via helper functions within the WindRose and TimeSeries objects. In more detail:
All tests passing.