Tag Archives: pvwatts

Optimizing for Time of Use – Trackers vs Fixed Tilt

Most power companies have a tiered rate structure for electricity that makes energy generated during peak demand hours more valuable. In the northern hemisphere, you almost always get the maximum annual energy generation for a PV system by orienting the system due south (unless you have strange weather patterns, like cloudy mornings and sunny afternoons but that’s not typical). But if energy generated in the late afternoon/early evening (typical peak time) is worth significantly more the the power company, you can easily get a net benefit from altering the system azimuth to capture more energy during a specific time of day even though the result is a lower annual energy yield. You’re essentially trading annual energy for energy captured at a specific time of day.

With this in mind, I recently ran a performance analysis using actual time of use data for a large scale project, and the results were somewhat surprising.

First, the plots of annual energy vs. system azimuth (180 degrees is due south) for horizontal single axis trackers and fixed tilt PV systems:

Fraction of annual energy delivered versus system azimuth angle for single axis tracker and fixed tilt PV systems.

Fraction of annual energy delivered versus system azimuth angle for single axis tracker and fixed tilt PV systems.

Both systems deliver their respective maximum annual energy when the system azimuth is 180 degrees, but the overall effect of the azimuth rotation is quite small, even for large rotations of 20 degrees or so. There’s also some skew to the data due to the weather at the particular location I’m using. I should also point out that the single axis tracking system produces about 18% more energy at this location.

If we take the Time of Use factor (a value ranging from 0.6 to 2.5 depending on season and time of day) and multiply it by the hourly system output for each hour over the course of a year, we get some interesting results:

Annual Energy scaled by the Time of Use factor versus system azimuth angle.

Annual Energy scaled by the Time of Use factor versus system azimuth angle.

First, the fixed tilt system will deliver its greatest number of dollars per year when installed with an azimuth of 200 degrees (20 degrees West of South). Second, the single axis tracking system benefits very little from an azimuth rotation, and what little benefit there is occurs in the opposite direction (East of South). This is because the tracking system’s panels are already pointed to the West in the late afternoon, in a great position to capture sunlight during the period of peak demand. It’s a little counterintuitive, but rotating the tracker axis (the North-South axis) away from the sun actually points the panels more directly at the afternoon sun.

So to summarize, the tracking system produces 18% more annual energy, and doesn’t need any site-specific optimization of the install to maximize the benefit based on the Time of Use factors.

Adding a real tracking algorithm to PVWatts

The web version of PVWatts doesn’t take into account the effect of one row of panels/trackers casting a shadow on another, and neither does it account for backtracking in the morning and evening to avoid shading. Essentially, you are modeling the performance of a single tracker.

NREL has a page devoted to derate factors here which provides a rough approximation for a shading derate based on GCR (ground coverage ratio), but in reality the affect of backtracking is dependent on location.

With this in mind, I modified the PVWatts source to calculate the correct incident angle (function incident2) for a horizontal single axis tracker given a GCR, and ran the simulation for a number of GCR’s and locations. Here is a sample result:

Derate factor versus GCR for 3 different locations

Derate factor versus GCR for 3 different locations

This shows the actual derate factor you can expect as a function of GCR for 3 different locations. Clearly, they are NOT all the same! At a GCR of 40%, there’s a 1.4% difference in energy lost between San Diego and Salt Lake City.

With small changes like this I’m getting closer to a model that accurately predicts real world performance.

Measured inverter efficiency curves

Thanks to the California Energy Commission we can see what a real inverter efficiency curve looks like, and compare it to the pvwatts model.

It turns out that the pvwatts model doesn’t match reality very well. The pvwatts nominal efficiency of 92% is well below the average of current inverters, and the 4th order polynomial is a rather poor fit to the shape of the efficiency curve.

The plot below shows the measured efficiency curve for a SatCon PVS-135 (green) and the pvwatts model (blue). Clearly there’s quite a bit of room improvement.

I’ve created a log function to model the inverter and plotted that in red. Substituting the improved model in pvwatts calculations results in about a 4.5% increase in annual energy.

Even if you don’t know what inverter will be used in a particular case, just increasing the nominal efficiency inside pvwatts from 92% to something around 95% seems reasonable given the test data on the CEC site.

Inverter Efficiency Curves

Inverter Efficiency Curves

pvwatts inverter model

This is a plot of the pvwatts inverter model. Nominal efficiency is 92%, but if the input power is between 10 and 100%, a 4th order polynomial is used to calculate efficiency, and convert dc power to ac. If this is accurate (I haven’t yet found any efficiency curves published by inverter manufacturers), then there are some clear implications for string sizing.

pvwatts inverter model

pvwatts inverter model

Under the hood of pvwatts

One of the projects I’m working on right now involves getting under the hood of pvwatts, the solar performance prediction software from the National Renewable Energy Laboratory.

Just about everyone in the solar energy world is familiar with pvwatts, but how many of them have actually had a chance to examine the source code? I’m just digging into it now, and I’ve already found several areas that could use some improvement. Considering how widely accepted this calculator is, the code is quite a shock. The algorithms make sense, but the implementation is a bit frightening.

More to come.