-
Notifications
You must be signed in to change notification settings - Fork 30
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
Identify days where system output looks like tracking or fixed #52
Conversation
Need to add curve fitting functions to an internal module that can be used by other parts of pvanalytics (system.py, for example). Will probably find other things down the line to put in that module. Also includes a start on the labeling code which will resample by day, and apply an _is_sunny() predicate to determine whether the curve fit was good. Then we can apply the usual tricks for expanding those truth values out to all the timestamps on 'sunny' days.
simple tests that operate on GHI data from pvlib
Need to convert index from datetime to integers (minute of day) for curve fitting to work.
only handling datetime indexes for now, may need to be updated later to handle int64 indexes (i.e. for data that has already been grouped by minute)
Test doesn't pass yet, but the basic structure of the algorightm from PVFleets QA is in place.
Adds a comment to help me track and reconcile the differences (also help me track what needs to be implemented still)
Adds the pre-filtering steps for low power from the original PVFleets code, need to figure out the tests that are failing now. Because of the extra filtering step the perturbed days (which have just a constant value in the tests) are now eliminated and are not set to False in the output from either function. Might be able to fix it by setting a fill value in the reindex operation.
This will give flexibility for handling systems where the tails caused by stuck trackers appear at other times (later/earlier in the day). Might be possible to pass other datatypes, need to check the pandas.Series.between_time() documentation.
Change how data is grouped/resampled to work around pandas bug (issue is #25411). This bug causes curve fits to fail because data gets shifted across midnight. Abstracts the pattern for fitting curves only if some predicate is satisfied. If the predicate is not satisfied then the fit is assigned an r^2 of 0.0.
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'm still looking into the calculation and description of r^2 in this code
d28fe86
to
0bed003
Compare
No need to do use Currying, can just pass extra parameters to the apply() function.
The purpose of filtering low power is to exclude night, early morning, and late afternoon/early evening from the curve fitting process. Instead of filtering data by value, these times can be exclueded using the `daytime` mask.
Positive mean is used to exclude days with low power (i.e. overcast days), so we should only look at the daytime values.
Change scope of expensive fixtures to 'module' and reduce the number of data points by 75% (change from 15 minute data to 1 hour data).
If the maximum value on a day is less than `peak_min` then the fit is 'failed'
This is the only way to test this execution path (non datetimeindex passed to fitting functions).
This function does not fit a general quartic, it is restricted to quartics with a perticular shape. Hopefully the name will make people think twice about what their needs are before using it in the future.
Should make the function more flexible by allowing alternative methods for excluding problematic times (for example based on solar zenith).
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 one is getting close, see what you think about some of the docstring suggestions
Co-authored-by: Cliff Hansen <cwhanse@sandia.gov>
r-squared is not correlation (that is just r).
Wondering if
|
More accurate representation of what the parameter is for.
Make the description match the description of the same parameter for `tracking_nrel`. Avoid the use of ambiguous and inacurate word 'sunny'.
Rewrote this in an attempt to capture the limitations and use cases for these two functions. The most important thing to capture is that the negation of the fixed mask is not equivalent to days when the tracker is not working. Suggest combining the two funcitons to get at days where the tracker is stuck.
This tests the claim made in the documentation that stuck trackers can be identified as 'fixed' using `orientation.fixed_nrel`.
This function will be needed in the system module as well. Putting it in a utility module for grouping data ('util._group') so it can be reused elsewhere.
Matches the original PVFLeets constants
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.
some docstring rewrites but I think this is ready to merge
Co-authored-by: Cliff Hansen <cwhanse@sandia.gov>
Pointed out in review that this paragraph is more of a distraction at this point.
Introduces two functions that fit curves to power or irradiance data for each day to determine whether that day matches the expected profile of a fixed or tracking system (parabolic or quartic respectively).
Closes #51