How does ETB simulate demand reduction from solar PV?

If a user enters in monthly summary data when creating their Energy Use Profile, then we assume the kW demand values entered for each month occur in each and every interval for that month, which will result in little to no demand reduction from solar PV. Therefore, we are only able to simulate demand reduction from solar PV if the user imports interval or Green Button Data. Here is our methodology for doing that:

1. Usage data standardization: we create a 365-day profile of 15-minute intervals, which is 35,040 data points. We do this regardless of what granularity (60, 30, 15-min) you had your original data in, or the import method you used (interval or Green Button Data).
2. Solar PV data standardization: the user selects which solar production calculator they want to use, and/or inputs their PV array(s) design specifications – to create an “8760 File”, which is 1-year of 1-hour solar production data. We then disaggregate this 60-min data into 15-min data intervals using a curve smoothing polynomial regression. Now we have a 35,040 data point file, similar to the standardized usage data file.
3. Simulation: we overlay the solar production file on top of the usage file to create a (35,040 data point) “net usage” file for the year. We then simulate every day of the year to determine what the post-solar kW demand values will be in each billing cycle. Basically, we’re finding the worst 15-min interval in the “net usage” file for each billing period, which is the post-solar kW demand value. Depending on the rate schedule that the user selects, we may need to find multiple post-solar demand values, like NC (non-coincident) demand, peak demand, On-Peak demand, Mid-Peak demand, etc.
4. Data qualification & visualization: to qualify the data we output interactive charts in the ‘Demand Profiles’ section of the proposal, which displays the pre-solar and post-solar demand values, and the day and time they occurred for each billing period.

This methodology absolutely does account for the intermittency of solar, because the solar production calculator uses TMY (typical meteorological year) data when creating their “8760 Files”. TMY weather data is basically specially selected data to represent typical or average weather for a location, which is generated from a data bank of roughly thirty years. The data that gets selected presents the range of weather conditions for the location in question, while still giving monthly and annual averages that are consistent with the long-term averages for the given location. So basically, the hourly data that the TMY model outputs does indeed account for variance. It reflects the fact that there will be good solar days, bad solar days, and everything in between. This is clearly illustrated in the visualizations of the solar production data, in the ‘demand profiles’ section of our proposal.

We believe our methodology is mathematically sound and simulates a realistic estimate of demand reduction from PV. We acknowledge that our demand reduction estimates will vary (sometimes significantly) against actual demand reductions measured on a monthly or annual basis. But over the course of a 20 or 30 year period, our software should do a reasonable job of approximating average demand reductions from PV, which is what we’re trying to do. Note: we will be publishing a white paper that studies actual kW demand reductions occurring in the field from operational systems, versus our methodology.