Update tracking.py Tracking Misalignment offser for One Axis

[pchinso]

This is a offset parameter as result of this google group thread,
[https://groups.google.com/g/pvlib-python/c/1k3pX76AlnU](Help with Tracking Misalignment for One Axis)

---

additional parameter
offset : float, default 0.0
is an additional angle that causes a delay/advance of the tracking
position over the the ideal true tracker_theta angle before
.calc_surface_orientation
offset. [degrees]

• Closes #xxxx
• I am familiar with the contributing guidelines
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

[cwhanse]

@pchinso I think we want some discussion before considering adding this parameter. I would like to hear if other maintainers think there is broad interest in this capability.

As coded here, offset could be a constant, Series or array of the same length as the input solar position vectors. In these cases, offset has to be known before the tracker calculations are done. Could offset be a function of the ideal tracking angle, and thus offset could be dependent on the tracker angle of rotation? Or could there be a way to use offset to represent a stuck tracker?

[pchinso]

I agree that we should have a discussion on this parameter before moving forward.

The primary goal of introducing this offset is to account for scenarios where the tracker becomes misaligned due to an imprecise tracking system. For instance, in situations where wind exerts a load on the tracker, it may lose its alignment and can either lag behind or advance beyond the ideal positioning.

As it stands, the offset can be defined as a constant, Series, or array that matches the length of the input solar position vectors. This would require knowing the offset value prior to performing tracker calculations. However, I see potential in making offset dynamic—potentially as a function of the ideal tracking angle or influenced by wind loads. This could allow it to adapt based on the current position of the tracker. Additionally, could we explore using offset to simulate situations where the tracker becomes stuck at certain time, position, temperature...

[kandersolar]

I doubt there is broad interest in this capability. I also think that the landscape of tracker issues is broad/diverse enough to require more careful consideration than a simple offset. What real-world effects are we trying to model here? Does a simple offset capture those effects, and if so, where in the tracker modeling workflow should it be applied? I bet it depends on which real world effect the offset is representing, and the code as currently written applies it both too early and too late, depending on the application.

Maybe a gallery example would be a good option here? Something like this page: https://pvlib-python.readthedocs.io/en/stable/gallery/solar-tracking/plot_discontinuous_tracking.html

[adriesse]

A gallery example seems like a good idea.