Identify days where system output looks like tracking or fixed #52
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
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.
cwhanse
reviewed
Jun 11, 2020
wfvining
commented
Jun 12, 2020
wfvining
force-pushed
the
daily-orientation
branch
from
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).
cwhanse
reviewed
Jun 15, 2020
wfvining
commented
Jun 15, 2020
Co-authored-by: Cliff Hansen <cwhanse@sandia.gov>
r-squared is not correlation (that is just r).
Closed
|
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
cwhanse
changed the title
cwhanse
approved these changes
Jul 7, 2020
Co-authored-by: Cliff Hansen <cwhanse@sandia.gov>
Pointed out in review that this paragraph is more of a distraction at this point.
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.
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