Backtracking in v1.15.2013

Hi,

I was wondering if something is wrong with the backtracking algorithm in the latest version of SAM or if I am misinterpreting how it is used. It seems that for one axis tracking, the energy harvest does not change properly with changing ground coverage ratio. For example, with a system ROM of +/-45 degrees, you get the same energy harvest no matter what the GCR or if backtracking is enabled or not. Looking at the hourly data it seems as though backtracking never takes into affect but if you look at where the sun is (azimuth and zenith) and look at the given GCR you should be backtracking (I tried this with 100%,, 50%, 33%, and 25% GCR). The system tracks up to 45 degrees and just stays there. Also, if you change the ROM to say 70 degrees then you do see backtracking start to take affect up to a point but then the system goes back to 70 degrees towards the end of the day - is this because the AOI on the panel is getting too high that the transmission losses start dominating the loss so better to go back to tracking than try and avoid shading?

Also - is there a reason that GCR and row width are not available as variables under the parametric simulations?

Sincerely,
Tamir Lance

UPDATE:

Hi Paul - I think I can confirm that the backtracking algorithm is not behaving as expected. I have attached a spreadsheet showing the comparison of yearly dc output data for the following array:

18 panels per string x 96 strings in parallel (TSM-305PA14A)
1 SC500CP-US inverter from SMA
Phoenix location
GCR: 0.67, 0.5, 0.4, 0.33, 0.29, 0.25
ROM: 45,60,70
With and without backtracking (GCR being used for backtracking only)

I have also done the same analysis as best as I could using the latest version of PVSyst (beta v6.01) and as well as a corrected analysis of the SAM output using python (commented code as well as code output is attached).

The correction analysis was done using a dataset I generated using SAM whereby I calculated the hourly energy output for the system above assuming a fixed tilt system where I change the tilt by 0.1 degrees from -70 to 70 using an azimuth of 90 and 270. This in effect simulates a N-S oriented one axis tracked system that is stuck for the entire year at the given angle. Using python and the pyephem module I can calculate the average hourly roll angle and correct for backtracking. Then I read off the corresponding energy harvest for that angle for that hour. This corrected data set matches pretty well (better than using the direct SAM output) with the PVSyst output (while the overall absolute value differs the relative difference between different ROM at the same GCR does agree better). Please look at the attached and let me know what you think. I used the NOCT model for array performance but I got similar results when using the array dimensions for the thermal model as well.

UPDATE II:

Thanks Paul,

I uploaded the SAM model I was using which, given the parameters shown, I believe would represent a horizontal single axis tracked system in phoenix with a +/- 45 degree range of motion and a ground coverage ratio of 33% (row width/(Space between edges of adjacent rows + row width)). Also, in this case, I am doing all my comparisons assuming there are no losses in the system (i.e. all the loss factors are set to 1). This first time I ran the data I found that the losses in PVSYST and SAM did not match but the total result was close by coincidence. I wanted to remove this uncertainty so made all the losses zero in both software packages

I also found out a few more things since I last ran the simulations so I included the updated results here as well as an updated version of the python code.

1) PVSYST uses meteonorm data (from 1990 apparently) so it should never quite replicate the SAM TMY2 data although it gets surprisingly close

2) PVSYST calculates the incident angle modifier (IAM) to account for transmission loss as the angle of incidence changes on the panel. They use the ASHARE model with a b0 = 0.5. I tried to replicate this in my python code by modifying the input energy given by SAM based on the angle of incidence on the panel for the given sun position and tracking angle). What I realized later was that PVSYST also applies the IAM to the diffuse and albedo reflection part of the input radiation whereas my python code applies the same IAM to the entire radiation but doesn't account for the different angles of the diffuse, beam, and albedo radiation. This accounts for some of the discrepancy. In the spreadsheet above I calculate the energy harvest for PVSYST for four scenarios: without backtracking and with b0 = 0, without backtracking and b0 = 0.5, with backtracking and b0 = 0, and with backtracking and b0= 0.5. A b0 = 0 would be no Tlosses

3) I also realized later that in my python code I calculate the angle of the sun for a particular hour as the average position over the course of the hour calculated on a minute by minute basis whereas PVSYST and I think SAM use the angle at the middle of the hour. This could also lead to some discrepancies).

Let me know if any more information is needed. For now I do the following to try and get accurate results:

a) Calculate the energy harvest using PVSYST with all the default loss factors (wiring, transmission, AC) except for LID and module quality which I ignore
b) Calculate the energy harvest with SAM with no backtracking and the same loss factors (except for glass transmission which doesn't seem to be accounted for)
c) Calculate the ratio of the net AC energy harvest
d) Rerun SAM using the ratio calculated in step C as an artificial percent of annual output performance adjustment

This allows me to use SAMs sophisticated financial model since that is lacking in PVSYST. Hopefully, you have some feedback. Thanks

Tamir

Hi Tamir,

Thank you for the additional details.

Would you mind attaching a copy of the .zsam file you used to generate the SAM results? I'd like to be sure I understand how you defined the relationship between the two SAM inputs for backtracking (Row Width and Space Between Edges of Adjacent Rows) and the GCR (ground coverage ratio) you use in your method. (Your script defines a variable E2Emax which appears to be related to, but not the same as SAM's space between edges of adjacent rows.) You also use a ROM (range of motion) value, which appears to be similar to SAM's Tracker Rotation Limit, but it is not clear from your Python script if it is the same.

By the way, I think you pointed out in a separate correspondence that the backtracking inputs are not available as parametric variables. Thank you for pointing that out. We will fix that in the next version of SAM.

Best regards,
Paul.

Please see update II above

Dear Tamir,

Thank you for the details to help clarify your question, and for pointing out the potential problems with SAM's backtracking algorithm.

In general, the algorithm does affect the system's total annual electricity production. For example, increasing the space between edges of rows results in an increase in annual electricity.

There are two things about the way SAM's Flat Plate PV model represents backtracking that are causing the results you observed:

1. For an array with 1-axis tracking and no backtracking, SAM does not model row-to-row shading. That means that comparing cases with and without backtracking will not show the benefit of backtracking. The system without backtracking can use all of the absorbed solar energy and therefore generate more electricity over a given period of time than the system with backtracking that loses some of the solar energy to shading by neighboring rows.

2. For 1-axis tracking without backtracking, SAM calculates the ideal axis rotation angle for each hour based on the angles between the sun and the array. If the ideal rotation angle is less than the limit you specify, SAM uses the ideal angle for the tracker rotation angle, otherwise it sets the tracker rotation angle to the limit. When you model the 1-axis tracker with backtracking, SAM only applies backtracking to the hours when the tracker was not at its limit in the no backtracking case. That may explain why your backtracking results in SAM are different from your calculations and the results of PVSYST. This may be appropriate because of IAM and transmittance losses as you suggest -- we are investigating this and will address any problems in the next version.

I've attached a PDF file to your original post that explains these points using graphs and tables in case my explanation here is not very clear.

Finally, thank you for pointing out that the backtracking variables were not available for parametric analyses in SAM 2013.1.15. The update released March 7, 2013 should address that issue among others.

Best regards,
Paul.

Hi Paul,

Thank you for including the additional simulation options - that should be a big help for anyone trying to understand the design space around ROM and GCR. Also - thank you for posting that pdf I think that makes what is going on more clear.

Regarding comment 1. I only included the comparison to backtracking and no backtracking to illustrate what I saw was a problem in that they gave me the same output, at least for 45 ROM. This means that SAM was not indeed performing backtracking as I had envisioned it. On page 2 of your PDF you show a change of energy harvest with decreasing GCR as you would expect but I don't know what width of tracker you are using in conjunction with the space between edges. Assuming you are using 2m as I did in my example then you are showing the increase of energy harvest going from 89% GCR to 40% GCR. Based on your chart you do not see an increase of energy harvest with GCR beyond 50%. I think that the energy harvest should continue to grow indefinitely although at a decreasing rate and approach what you would asymptotically approach what you get if you had no backtracking and no row to row shading.

Regarding comment 2: Based on how you do backtracking I can see now where the discrepancy occurs. Backtracking as I believe should occur for every hour that shading would occur if backtracking were not present. In this case a system would start backtracking as soon as shading begins and would go all the way back to zero rotation angle as the sun continues to drop on the horizon. At some point there is diminishing return as the AOI on the panel starts to exceed the useful range due to transmission losses in the glass increasing rapidly beyond ~50 degrees. However, if you simply stop backtracking once the ideal angle becomes greater than the ROM then you unfairly boost the apparent output of low ROM systems if you also do not account for row to row shading. This would make it appear that a low ROM system can continue to gather energy it would not be able to harvest in real life due to shading. From the data it seems like SAM does not account for row to row shading even when backtracking is enabled but the ideal rotation axis is beyond the ROM - correct?

For now I think we can consider this closed. We get different results because your backtracking algorithm differs from mine (and PVSYST). I think the easy fix as you suggest is to continue to allow the system to backtrack throughout the entire day. This should be the case because backtracking by definition means that the system is staying within its ROM. I think this is more realistic than allowing/calculating row to row shading since that is unlikely to be a system configuration of choice for developers and will be complex to model (although you do have it for fixed tilt systems). I can't think of a reason why someone would prefer shading over allowing the system to continue to backtrack. This should produce more energy vs shading even if the transmission losses are increasing as you backtrack later in the day. I would be more than happy to continue discussing this and provide any help I can to help improve later versions. I am glad we were able to get to the bottom of this

Hi Tamir,

The new version of SAM has an improved algorithm for modeling self-shading for PV arrays with 1-axis tracking. We tried to address some of the issues you raised in your comments.

On the PV Subarrays page, we added two new inputs for each of the four possible subarrays: The Shading mode for 1x trackers allows you to choose how you want SAM to model shading for one-axis tracking, and the Ground coverage ratio input (GCR) replaces the two row spacing inputs from previous versions.

The shading mode options are:

Self-shaded models the array with no backtracking, but does estimate losses from self-shading caused by shading of modules in one row by modules in neighboring rows based on the GCR value you specify. This is an improvement over previous versions of SAM that assumed that rows in arrays with one-axis tracking were ideally spaced to have no self shading.

Backtracking adds backtracking to the self-shaded option, and adjusts the tracking angle to minimize shading.

None uses the approach of the previous versions of SAM. Because this option does not account for any self-shading, it tends to overestimate the array's production. We included this option to allow for comparison between the different options to see the effect of the self-shaded and backtracking options, and for comparison between results from this version and older versions of SAM.

The new GCR input only accepts values between 0.01 and 0.99 (0.01 < GCR < 0.99). If you specify a value outside of that range, the Beta version generates a simulation error.

You can run a parametric study on the GCR to see its effect on the array's output (with the self-shaded or backtracking options enabled).

If you have time to take a look at the Beta version, we would really appreciate any comments or suggestions. You can download the Beta version from the Downloads page .

Best regards,
Paul.