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

Please see update II above

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