-
Notifications
You must be signed in to change notification settings - Fork 67
Home
Rdtools will provide a set of tools for quantifying the degradation of photovoltaic systems and modules. Our goal for Rdtools is to enable consistent and transparent degradation calculations. To this end consensus-building is an integral part of the development process. It is also important that we develop examples in parallel to the tools. We envision Rdtools providing a suite of tools useful both to advanced analysts developing their own analyses and out-of-the-box workflows shown in examples.
Please develop in a separate branch or forked repository, even for small changes. When your changes are ready for consideration, please open a pull request into the development
branch following these guidelines:
- Initiate a pull request and request review from at least one person outside your organization and one person from NREL. (If you are outside NREL, this can be a single reviewer). Reviews may not be necessary for minor bug fixes. Before the review stage, pull requests are also a great way to initiate discussion and coordinate help from other collaborators.
- If your contribution represents an additional capability, please consider including an example notebook in docs.
- Consistent with the goals of Rdtools, it may be useful to build consensus and help others on the team understand how your contributions fit into the analysis workflow.
When the the developers determine that the development
branch is ready to be considered for a release, a pull request should be opened to merge development
into master
. After review and testing, if the pull request is approved and merged, we will issue a release numbered according to semantic versioning. The new version will also be uploaded to PyPI.
Steps 2–5 correspond to a module within Rdtools, not all modules listed below are currently present in the master branch.
-
Raw data is processed by the analyst into a form suitable for Rdtools modules. Not only need the data be brought into suitable format, the data also need to be screened for sensible values (we may add modules for this in the future). Examples include checking the timestamp, power, temperatures are within reasonable ranges (a lot of data loggers when they go offline insert nonsensical values like -9999). Equalizing of time series should be addressed in this step as well, for example if the acquisition frequency switched from 15min to 1min, this can lead to issues.
-
Normalization (normalization.py): This step normalizes the observed performance of the system based on a model (for example the PVWatts model)
- Input:
- Pandas time series of raw energy. Time series should have a well-defined frequency. Note that the calculations are based on energy production as opposed to instantaneous power, but handling of power vs. energy is currently an area of active development.
- Dict of keywords for relevant model.
- Output:
- Pandas time series of normalized energy. (Note that associated insolation time series may be added in future versions.)
- Input:
-
Filter (filter.py): This step excludes data points from the normalized energy time series based on defensible criteria. It is expected that filtering development will not be merged into master until consensus is reached about best practices.
- Proposed filters:
- Inverter clipping:
- Input: Un-normalized AC power/energy, irradiance?, DC/AC ratio?
- Method: Dirk proposed a good solution to remove the highest values in a raw power histogram. One implementation excludes data that is greater than 99% of the 95th percentile in power production.
- Outages and outliers: eliminate points with unphysical or suspect normalized yield
- Input: normalized energy/power
- Method: compute the 3-month rolling median. Exclude points +/- 30% of the rolling median.
- Clearsky: remove cloudy points or days
- Input: measured irradiance, modeled irradiance. Measurement and model must use same mounting configuration.
- Method: detect_clearsky in PVLIB.
- Low irradiance cut-off:
- Input: irradiance data
- Method: exclude points where irradiance is <200 W/m2. The threshold of 200 W/m2 excludes inverter start-up effects without excluding too much winter data.
- Inverter clipping:
- Proposed filters:
-
Aggregate (aggregation.py): This step calculates insolation-weighted averages of normalized and filtered energy data at specified frequency
- Input:
- Pandas time series of normalized energy (need not have well-defined frequency)
- Pandas time series of irradiance or insolation for weighting
- Aggregation frequency
- Output:
- Pandas time series
- Input:
-
Degradation calculation (degradation.py): In this step the degradation rate of the modules or system is calculated
- Input:
- Pandas time series of normalized energy (need not have well-defined frequency)
- Output: Dict including degradation rate in %/year, and the 68.2% confidence interval. Other information is returned in the dict depending on the calculation method.
- Input:
Note that Rdtools is in an early stage and is subject to changes, including in the input/output of functions as we work toward an initial minimum viable product. With the exception of #1, these goals aren’t necessarily in chronological order. Progress may happen in parallel.
- The short-term development goal is to get a functional version of the workflow above, including at least normalization.py, aggregation.py, and degradation.py. The filtering step may take some more time to reach consensus about.
- Reach consensus and upload examples including the filtering step.
- Clearsky workflow: There has been much discussion about using clearsky filtering and modeling. Let’s start by sketching out how a clearsky workflow can be implemented in, or parallel to, the workflow outlined above. Then we can construct the tools and a working example.
- Proposed workflow:
- Normalize with clearsky
- Filter for clearsky points
- Agregate
- Degradation calculation
- Proposed workflow: