Single-axis tracker modeling: True tracking outperforming backtracking despite shading - Expected behavior?

46 views
Skip to first unread message

Loc Nguyen

unread,
Jul 29, 2025, 12:22:17 AMJul 29
to pvlib-python

Hello PVlib community,

I'm modeling single-axis tracking systems in Toledo, OH, and getting results that seem counterintuitive. I'd appreciate your insights on whether this is expected behavior or if there's an issue with my modeling approach.

Setup:

  • Location: Toledo, OH (41.66°N, -83.53°W)
  • Ground Coverage Ratio (GCR): 0.6-0.8
  • Comparing: True tracking (backtrack=False) vs Backtracking (backtrack=True)
  • Both systems use identical equipment and pvlib.shading.shaded_fraction1d for row-to-row shading

Here was what was used for self-shading methodology:

  • Used pvlib.shading.shaded_fraction1d() - Standard PVlib function for row-to-row shading
  • GCR of 0.6 - Creates realistic shading pressure (21.2% average shading)
  • Collector width 3.2m, pitch 5.33m - calculated based on a Canadian Solar module specs
  • Applied shading differently:
    • True-tracking: Gets full shading penalty from aggressive sun-following
    • Backtracking: No additional penalty (pvlib's backtracking already optimizes)

Results:

  • True tracking: Higher annual energy yield despite suffering 21-28% average shading
  • Backtracking: Lower annual energy yield but minimal shading (as expected)
  • Example: At GCR=0.6, true tracking produces ~3.2 GWh vs backtracking's ~3.1 GWh

Questions:

  1. Is this expected for moderate-latitude locations like Toledo? Could the sun-following benefit outweigh shading penalties at this latitude?

  2. Shading application approach: I'm applying calculated shading losses to true tracking but not to backtracking (since PVlib's backtracking algorithm inherently optimizes for shading avoidance). Is this the correct modeling approach?

  3. GCR threshold: At what GCR values would you typically expect backtracking to start outperforming true tracking in similar climates?

  4. Is this shading application methodology correct? I'm calculating the shading that would occur from aggressive sun-following angles, then:

    • Applying it as a penalty to true-tracking systems (which actually use those angles)
    • NOT applying it to backtracking systems (since pvlib's algorithm already avoids those angles)
  5. Does this properly represent how backtracking algorithms work in practice?
  6. In your experience with single-axis tracking systems:
    • At what GCR do you typically see backtracking benefits become significant?
    • Is it realistic for true-tracking to outperform backtracking at moderate GCR values in mid-latitude locations like Toledo, OH?

Code snippet:

# Key insight: Both systems want to use the same aggressive sun-following angles
# True-tracking USES them → suffers shading losses  
# Backtracking AVOIDS them → prevents shading losses (but loses some direct sun capture)

# Calculate the shading that would occur from aggressive sun-following
true_tracking_angles = true_tracking_mount.get_orientation(solar_zenith, solar_azimuth)
potential_shading = pvlib.shading.shaded_fraction1d(...)

# Apply to TRUE TRACKING: Gets full shading penalty
mc_true_tracking = apply_shading_to_system(mc_true_tracking, potential_shading, 'True Tracking')

# BACKTRACKING: NO additional shading (ModelChain already optimized)
# The backtracking algorithm already balances sun-following vs shading avoidance


Any insights on whether these results align with your experience or if there are modeling improvements I should consider would be greatly appreciated!

Best regards,

Loc Nguyen.

kevina...@gmail.com

unread,
Jul 29, 2025, 9:11:33 AMJul 29
to pvlib-python
In general: backtracking is expected to result in greater energy than truetracking, for systems with modules of silicon cells.  So your simulation results are unexpected.

> True-tracking: Gets full shading penalty from aggressive sun-following

Can you describe what "full shading penalty" means, specifically?  This is likely the key to understanding your simulation output.

(As a side note: GCR of 0.60.8 is quite high.)

Kevin

Will Hobbs

unread,
Jul 29, 2025, 10:33:11 AMJul 29
to pvlib-python
You will need to account for the non-linear losses from partial shade in crystalline silicon modules. Others in the community may have more concise overviews, but you could see  https://github.com/williamhobbs/2024_pvpmc_self_shade and  https://www.sandia.gov/app/uploads/sites/243/dlm_uploads/2024/05/2024_PVPMC_hobbs_pvlib_self-shade.pdf (particularly slide 12). 

Note that the orientation of the modules ("portrait" vs "landscape"), the module cell stringing (particularly whether it is an older style module with ~square cells or modern "twin"/"butterfly" module with half-cut cells and parallel substrings), and the number of modules that go across the collector width will all have a big impact on shade losses. The info I shared above does not apply for crystalline modules in landscape, for example. (And a related aside - your collector width of 3.2 m seems unusual. I would expect something in the range of 2-2.3 m for 1 module in portrait or 2 in landscape. Is the tracker setup with 3 modules in landscape?)

Will

Reply all
Reply to author
Forward
0 new messages