Improve pvlib.tracking.singleaxis docstring

[adriesse]

Describe the bug The docstring for pvlib.tracking.singleaxis does not explain what the calculated tracker angle is based on. At the very least it should say that it minimizes AOI and thereby maximizes DNI use.

Additional context In retrospect, I think the backtrack default should have been False but that may be more controversial.

[bandish1304]

I will be working on this issue...

[kadheer]

Hi! I'd like to work on this issue. I'll:

1. Rename the coordinate from "times" to "time" in read_ecmwf_macc()
2. Add validation tests to ensure proper time decoding
3. Update documentation/examples accordingly

Before proceeding, could you confirm:

• Is there any backward compatibility consideration?
• Should we deprecate "times" or change it directly?
• Any preferences for test implementation?

Looking forward to your guidance! @kandersolar @adriesse @wholmgren

[kadheer]

Hi maintainers, I was looking to work on #2314 but noticed the read_ecmwf_macc function and corresponding file seem to have been removed from the codebase. Could you please clarify:

1. Is this issue still relevant?
2. If so, where should the fix be implemented?
3. If not, should this issue be closed?

As students working on a timed project, we'd appreciate your guidance on how to proceed. @kandersolar @adriesse @wholmgren

[echedey-ls]

@kadheer

This issue is not about read_ecmwf_macc, it is about pvlib.tracking.singleaxis. Where did you read about that? I haven't seen any issue open nor closed regarding that renaming.

This issue is about a docstring improvement (please re-read the first comment above), you are welcome to work on it. I guess @bandish1304 has given up on this one (is that right?). And please, if you are required to do a number of contributions or this one does not match any criteria you've been tasked with, write to us in the mailing list or open a discussion with your plans/doubts.

[kandersolar]

if you are required to do a number of contributions

Please also keep in mind that open-source software projects are not obligated to facilitate such assignments, and that their maintainers usually have full-time jobs elsewhere and may have very different working hours than you do :)

[bandish1304]

Hi Kadheer...sorry I just saw your email right now. You can work on this issue if you like. I already close this issue from my side but you can work on this one if it's open. It should be totally fine. Thankyou

---

From: Echedey Luis @.> Sent: Tuesday, June 17, 2025 2:44 AM To: pvlib/pvlib-python @.> Cc: Bandish Patel @.>; Mention @.> Subject: Re: [pvlib/pvlib-python] Improve pvlib.tracking.singleaxis docstring (Issue #2314)

[https://avatars.githubusercontent.com/u/80125792?s=20&v=4]echedey-ls left a comment (pvlib/pvlib-python#2314)https://github.com/pvlib/pvlib-python/issues/2314#issuecomment-2979681875

@kadheerhttps://github.com/kadheer

This issue is not about read_ecmwf_macc, it is about pvlib.tracking.singleaxis. Where did you read about that? I haven't seen any issue open nor closed regarding that renaming.

This issue is about a docstring improvement (please re-read the first comment above), you are welcome to work on it. I guess @bandish1304https://github.com/bandish1304 has given up on this one (is that right?). And please, if you are required to do a number of contributions or this one does not match any criteria you've been tasked with, write to us in the mailing listhttps://groups.google.com/g/pvlib-python?pli=1 or open a discussion with your plans/doubts.

— Reply to this email directly, view it on GitHubhttps://github.com/pvlib/pvlib-python/issues/2314#issuecomment-2979681875, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BEFLTCUAMTAJQIMNY2WWGLT3D7POZAVCNFSM6AAAAABS4DWQYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNZZGY4DCOBXGU. You are receiving this because you were mentioned.

[cwhanse]

@kadheer I do not think this issue is appropriate for someone who doesn't already have experience with PV systems. I think it would be frustrating for both the submitter and the maintainers if a PR devolves into a group writing and editing conversation.

#2394 is available, I think; the associated PR #2401 appears to be abandoned.

[kadheer]

@cwhanse I will be working on the #2934 issue then. I do understand the repo requirements. and if the issue is not been resolved that could help the maintainers know the new findings as per the research.