Add “is it true tracking” Boolean output to singleaxis

[williamhobbs]

Is your feature request related to a problem? Please describe.
It would be nice to be able to easily identify periods where trackers are in backtracking mode vs regular (true) tracking mode.

Describe the solution you'd like
A Boolean timeseries output from the singleaxis function.

Describe alternatives you've considered
One option is running singleaxis twice, with and without backtracking, and looking for differences. Or comparing with idea angle from shading.projected_solar_zenith_angle.

Additional context
This would be helpful when, e.g., setting tracker position error thresholds/tolerances that depend on tracking mode, where error in the direction of not causing self shade is more tolerable than error in the direction of causing shade.

Related, it would also be helpful to be able to differentiate AM vs PM backtracking, for similar reasons. That may be too much to add here, though. [edit: as Adam pointed out below, AM vs PM can easily be inferred from rotation angle.]

See this Google group thread for some discussion: https://groups.google.com/d/msgid/pvlib-python/ea0e5e62-6cd5-4a7c-bf7d-08c625fa51c6n%40googlegroups.com?utm_medium=email&utm_source=footer

[AdamRJensen]

Related, it would also be helpful to be able to differentiate AM vs PM backtracking, for similar reasons. That may be too much to add here, though.

Couldn't this be inferred from the rotation angle (positive vs. negative)?

[williamhobbs]

Related, it would also be helpful to be able to differentiate AM vs PM backtracking, for similar reasons. That may be too much to add here, though.

Couldn't this be inferred from the rotation angle (positive vs. negative)?

Ah, yes!

[williamhobbs]

Would this be as simple as updating this

pvlib-python/pvlib/tracking.py

Lines 202 to 203 in 86a367b

	out = {'tracker_theta': tracker_theta, 'aoi': aoi,
	'surface_azimuth': surface_azimuth, 'surface_tilt': surface_tilt}

to this?

    is_truetracking = np.where(tracker_theta == omega_ideal, True, False)

    out = {'tracker_theta': tracker_theta, 'aoi': aoi,
           'surface_azimuth': surface_azimuth, 'surface_tilt': surface_tilt,
           'is_truetracking': is_truetracking}

[AdamRJensen]

Even simpler

    is_truetracking = tracker_theta == omega_ideal

[cwhanse]

The flag you want is already in the function, as the variable temp.

pvlib-python/pvlib/tracking.py

Line 164 in 86a367b

temp = np.abs(axes_distance * cosd(omega_ideal - cross_axis_tilt))

True tracking if temp >= 1.

pvlib-python/pvlib/tracking.py

Line 174 in 86a367b

with np.errstate(invalid='ignore'):

[williamhobbs]

@cwhanse, if we use temp, will intervals that get clipped by max_angle potentially be flagged as truetracker when they shouldn't be?

I'm assuming that intervals that are clipped to the max rotation angle should not be flagged.

[cwhanse]

@cwhanse, if we use temp, will intervals that get clipped by max_angle potentially be flagged as truetracker when they shouldn't be?

I'm assuming that intervals that are clipped to the max rotation angle should not be flagged.

Ah, good point. I agree, max/min rotation should not be flagged as true tracking.

[kandersolar]

A more general alternative: return a "state" key with values "true-tracking", "backtracking", "max angle" etc.

[williamhobbs]

A more general alternative: return a "state" key with values "true-tracking", "backtracking", "max angle" etc.

I like this. I would end up with something like this anyway after post-processing the boolean output.

This might also help with the NaN at night issue, #2539. There could be a nighttime state value of "night stow" or similar.

[cwhanse]

"state" key with values "true-tracking", "backtracking", "max angle" etc.

While I'm not opposed to this, if we are headed in this direction, we should consider formal enumerations rather than context-dependent strings. In OpenAPI, at least, I see patterns where enumerations are integers with explanatory strings (like the HTTP error codes). This pattern encourages use of the enumeration in other contexts, such as for fault classification.

E.g.,

TRACKER_STATES = {0: "true-tracking", 1: "backtracking", ...}

And to over-complicate the original request, here's a list of tracker states that we compiled in a conversation with 3E, Array and NexTracker. (I note that "max angle" did not appear, hmmm....) Not all of these are relevant for weather-to-power modeling, but it's not hard to imagine wanting many of these to label periods in the output of a more sophisticated steering algorithm than the current singleaxis function:

Unknown
Tracking_True
Tracking_Diffuse

Backtracking_Shade
Backtracking_Energy

Stow – Wind
Stow – Snow
Stow_Hail
Stow - Flood
Stow_Night
Stow_Passive
Parked
Maintenance
Fault
Testing
Off
Tracker deviating
Custom

[adriesse]

Somehow, it's never as simple as it first appears! :)

[williamhobbs]

@cwhanse, I agree with your overall idea. If we're going to do it, make sure we do it right...

That said, I don't know how to pick the right amount of robustness/complexity.