Estimating PV system characteristics

[AdamRJensen]

Would it be of interest to have an algorithm for infering PV plant characteristics from historical data (perhaps this already exist)?

See for example the work by @YvesMSaintDrenan: https://hal.archives-ouvertes.fr/hal-02286805

Abstract : The aim of this work is to develop an algorithm that can utilize historical PV power measurements to establish the parameters of a physical model for power production. The chosen approach consists in evaluating the parameters of a PV model that maximize the likelihood that simulations match with power measurements. The proposed method offers advantages beyond the standard approaches used for the simulation or prediction of PV power production, as it makes maximum use of the information typically available on a PV plant (plant description and measurement history). Furthermore, an interpretation and control of the algorithm output is made possible. The performance of the proposed approach has been evaluated and analysed using measurements from two PV plants. It is shown that the proposed approach may identify the orientation angles of a PV module to within an accuracy of less than 2° in optimal cases. Situations were also found with a difference between the estimated and actual angles of 5°, for which the estimated parameters lead to better simulation/forecast accuracy than the actual ones as they balance the systematic error of the chosen PV-model.

[cwhanse]

@AdamRJensen yes. There are some capabilities in pvanalytics\system.py, and other relevant functions in pvanalytics.features.orientation. It would be cool to collect various algorithms here so that accuracy and reliability can be compared, and improved.

[kperrynrel]

@AdamRJensen, @kanderso-nrel and I are working on validating some of the existing functions in PVAnalytics for estimating tilt and azimuth (we put together a validation set for testing the algorithms). Let me know if you want to be involved in this; we can add additional algorithms to the mix.

[williamhobbs]

I like this idea. I can think of a few use cases:

1. Forecasting (and "nowcasting") for grid operation purposes where all the relevant specs for lots of PV plants are hard to know.
2. Running detailed performance engineering analyses (RdTools PLR, real-time expected energy modeling, etc.) on plants where parameters like DC:AC ratio and GCR can vary a lot within a plant, often on an inverter-by-inverter basis, and mapping scanned as-built drawings to data historian tag names is not always perfect.

[YvesMSaintDrenan]

Hi, I would be very happy to share and compare my scripts. I think it can be a useful contribution because it has been developped to be very robust to shading, plant outage... and has been successfully applied to hundreds of PV systems.
@kperrynrel Can you share the validation dataset so that I can adapt my code to the data format and validate the results? By the way, do you know the open data frome the IEA PVPS task 13 (https://osf.io/vtr2s/) ?

[kperrynrel]

@YvesMSaintDrenan I can provide a few public data sets that include system characteristics (lat, long, azimuth, tilt, etc) along with several years of time series data if that would work for validation? In terms of the IEA PVPS task 13 data, I didn't work specifically on it but I recognize the NREL systems and can provide the system ID's and associated data via the DOE Open Energy Data Initiative (OEDI) if you'd like (https://data.openei.org/submissions/4568).

[cwhanse]

@YvesMSaintDrenan We can start with a notebook. My guess is we can refactor that over time to bring steps in the workbook out into functions that can be re-used elsewhere. We always thought we would add workflows (notebooks, scripts, etc.) to this library; yours would be the first.

[YvesMSaintDrenan]

Thanks @kperrynrel and @cwhanse ! if you share the public PV dataset, I will prepare a jupyter notebook.

[kperrynrel]

Hey @YvesMSaintDrenan as the data sets are relatively large, I uploaded them to the DuraMAT Datahub:
https://datahub.duramat.org/dataset/pv-system-characteristic-validation-data-set
Data can be called directly from the datahub into Python/Jupyter via the following command (this an example with one of the CSV's):

import pandas as pd

file_url = ('https://datahub.duramat.org/dataset/05ef4db2-11d0-4acf-93f5-ad6372ae294b/'
            'resource/80988b5f-a9d3-4ff9-b8e4-6ddef8f8bd9f/download/system_1432.csv')
df = pd.read_csv(file_url, index_col=0, parse_dates=True)

There are 8 systems with AC power and irradiance data, where available, and an associated metadata file containing the az/tilt info, latitude-longitude coordinates, and the time zone that the data is presented in. Let me know if you need additional info for running the notebook. Thanks!

[YvesMSaintDrenan]

Thanks @kperrynrel ! The data looks very good! I will prepare the notebook illustrating the module orientation estimation.

[YvesMSaintDrenan]

Hi,

Just a short update on the preparation of the notebook. An accurate time reference is very important for estimating the orientation of the modules of the PV system. I found some issues on the temporal reference that needs to be taken into account in the PV data you shared:

as a result, I am now preparing two notebooks: the first for checking the time reference of PV data and the second one for the estimation of the orientation.

[kperrynrel]

Hey @YvesMSaintDrenan before doing the Duramat upload I did run a DST checker on all of the sample sets with the metadata provided, and corrected DST-time zones to non-DST time zones via the following routine:

tz_conversion_dict = {'America/New_York': 'Etc/GMT+4',
                      'America/Los_Angeles': 'Etc/GMT+7',
                      'America/Chicago': 'Etc/GMT+5',
                      'America/Phoenix': 'Etc/GMT+7',
                      'America/Indiana/Indianapolis': 'Etc/GMT+5',
                      'America/Denver': 'Etc/GMT+6'}
df.index = df.index.tz_localize(system_info['timezone'], ambiguous=True,
                                nonexistent="shift_forward")
if system_info['timezone'] in list(tz_conversion_dict.keys()):
    df.index = df.index.tz_convert(tz_conversion_dict[system_info['timezone']])

If you don't convert time series with DST to their non-DST equivalent, you'll get the data shifts such as the ones you show above. Even though I do believe the data is presented in the correct time zone (from when I checked), perhaps in my case the best option would be to convert all the data to its non-DST equivalent so that the conversion is not required like in the code above.

[YvesMSaintDrenan]

Hi @kperrynrel ;

Thanks for the information. Here is the current version of my notebook (work in progress...) if you want to give it a try: https://cloud.minesparis.psl.eu/index.php/s/T4unMyc9WtAxRjV

@kperrynrel : do you think we can find shortly where the temporal reference issue is coming from? Alternatively, I may fix the issue manually.

[kperrynrel]

Hey @YvesMSaintDrenan apologies on this taking a few weeks to get done, but I just went ahead and removed DST from all of the time series on the Datahub entry (https://datahub.duramat.org/dataset/pv-system-characteristic-validation-data-set). I also removed the time series associated with system 1201 as it was pretty sparse. I do include graphics visualizing the time zone for each data stream, shown here:

All time series datetime indices are also represented tz-localized. Give this new data set a try and let me know how it goes.

[YvesMSaintDrenan]

Hi, I prepared a first draft showcasing the potential content of the notebook. You should have received an invitation to see the first draft. I need to write some text to explain the different steps but if you already have comments, I would be happy to have your feedback on this preliminary version.

[williamhobbs]

Related to this, having a way to verify plant location with pvanalytics\system.py could be useful. A friend of mine* recently thought they found a bug in another software tool when it was flagging daytime intervals as nighttime, and it turns out they simply copy/pasted the wrong lat/lon.

Let me know if this would best be submitted as a separate issue.

*(ok, it was me)

[cwhanse]

I think inferring tilt, azimuth, latitude, longitude are all of a piece.

[williamhobbs]

This work by Danner and de Meer looks interesting, not sure if it's been mentioned: https://doi.org/10.1186/s42162-021-00176-2 (Location and solar system parameter extraction from power measurement time series, Energy Informatics, Open Access, "Source code is available via request to the authors")