Feature/provide frequency #123
Conversation
|
Maybe an idea @misi9170 you had was a pre-processor to generate the table, we can pass in an FI wind rose or a table, plus the ws_min/max/step and project so that it will line up with what energy_ratio expects? |
There was a problem hiding this comment.
Overall, looks good Paul. Just a few comments.
I didn't follow this statement, though: "A potential gotcha is for example the user specifies ws_min =0, ws_step = 1, then the bins will be 0.5, 1.5 etc., maybe we can provide helpful warnings?" What is the problem with this case?
|
Something I had before was a 2D interpolant function that would take the wind direction and wind speed, and would return the frequency of occurrence. This way, you could calculate the energy ratios using a 20-year-equivalent wind rose even with a smaller amount of data. I thought the interpolant function was particularly helpful because it's agnostic to the binning options chosen. That code snippet is here: flasc/flasc/energy_ratio/energy_ratio.py Line 45 in 88330a7 Is this more or less what you want to reproduce now with Polars? Sorry for being late to the conversation. |
This sounds really nice Bart! Right now I'm just assuming you are passing in a dataframe with the same ws/wd bins identified as in the data. But I like your suggestion, what if for simplicity though we handled this option as a new feature in a separate pull request? I can see expanding on this capability as we go, |
Sounds good! |
Ok opened Issue #125 to capture this idea / plan |
|
Ok @ejsimley / @misi9170 @Bartdoekemeijer I think this is now ready to merge from my perspective if 1-2 of you could provide a review. Thank you! |
Yeah, agreed, just documenting our discussion from today---let's do that, but create a separate PR for it. |
Done! Created Issue #126 |
|
@paulf81 Working on creating an extra part of the energy_ratio examples to specify |
|
@paulf81 Have now revamped how df_freq is computed if it is not passed in, passed that through to the Output object, added option to overlay the frequency on the wind direction count plot and shown how to use it in Smarteole examples. Overall looking good to me, going to approve. |
There was a problem hiding this comment.
This looks good to me! Sorry for the delay in reviewing. Just a few small documentation comments, and some questions/ideas that aren't necessary to address now.
One thing to fix, though, is that there is an error in the "Comparison assuming no wind direction uncertainty/variability in FLORIS" section of the example 06 notebook.
|
|
||
|
|
||
| # Enforce that each ws/wd bin combination has to appear in all dataframes | ||
| .filter(pl.count().over(bin_cols_without_df_name) == num_df) |
There was a problem hiding this comment.
maybe not important to address now, but really we just want to make sure each ws/wd bin combination appears in both data frames for each uplift pair right, not all data frames in the case where there are more than two?
There was a problem hiding this comment.
I think this implementation is the most general, say you want to compare a data partioned into 3 stability types, this checks that each type has at least one point in the used bins. I think it's a fair qualifier.
Could be ready to merge
Feature or improvement description
This pull request enables the bin weighting in the energy ratio calculation to come from an externally provided pandas dataframe of weights, rather than necessarily the count of points in the binned data. The assumed implementation provides a dataframe with ws/wd columns matched to the labels inferred from ws_min, ws_step, wd_min etc.,
I had originally assumed that if this table was passed in then the ws/wd bins/edges could be inferred from this table. But in the process of writing the tests realized that an edge cases of single ws or wd might make a challenge here (although solvable) so went back to basically this table just has to match what is otherwise provided by the ws_min etc., parameters. A potential gotcha is for example the user specifies ws_min =0, ws_step = 1, then the bins will be 0.5, 1.5 etc., maybe we can provide helpful warnings?
Otherwise seems to work as is but wanted to maybe use the pull request to discuss how we best handle some of these finer points.