tracker algorithms

[wholmgren]

I'm in need of some single axis tracker algorithms that include back tracking. So:

1. Can anybody recommend a reference for a single axis tracker algorithm with back tracking?
2. Does anybody have a Python implementation of a tracker algorithm?
3. Should we add tracker algorithms to pvlib?

The best reference I have so far is a NREL tech report, but it doesn't include back tracking.

[wholmgren]

Turns out that pvlib matlab has a single axis tracker function pvl_singleaxis.m. Should definitely port this. It references

Lorenzo, E et al., 2011, "Tracking and back-tracking", Prog. in Photovoltaics: Research and Applications, v. 19, pp. 747-753. wiley.com

[wholmgren]

Where would this function live? In it's own module, maybe called tracking.py or trackers.py?

[robwandrews]

I think it warrants it's own module: tracking.py is my vote

[wholmgren]

PR #35 added a translation of pvlib matlab's pvl_singleaxis.m. Leaving this issue open for dual axis trackers.

[raphaelvarieras]

Hey all, I'm new to this repository. I did quite a bit of work on tracker algorithms when I was at Solaria/Nextracker and would be happy to be able to contribute. I created this framework in which all tracker systems are essentially just subsets of a hypothetical three-axis tracker with the three Euler angles.

[wholmgren]

Welcome. That sounds interesting. Do your algorithms include backtracking? Any IP/license issues?

[raphaelvarieras]

Yes, I implemented horizontal backtracking for all tracker azimuths if I remember well. I did not do it for tilted tracker, azimuth or dual axis. No IP/license issues that I know of but I will double-check.

[raphaelvarieras]

No IP/license issue confirmed. Should we have a quick call to talk about this?

[wholmgren]

Great. I would prefer to keep things as open on github as possible, though if necessary we can arrange a call if you email me at [email protected]

Some questions to get started:

• Have you looked at the existing single axis tracker algorithm in tracking.py?
• Do you propose to replace that function entirely or add a new one?
• Have you tested the algorithms against each other?
• Would this be best implemented as a collection of functions or as a collection of classes with inheritance?

I think it would be nice to have some good documentation with diagrams/sketches to go along with this.

[raphaelvarieras]

No worries - I just didn't want to burden the repository conversation with matters of branching protocol and things like that...

To your questions:

• Yes, seems pretty straightforward
• I think it would be a good idea to create a new one and being able to compare
• I ran a lot of test back in the days but haven't compared with the current one
• If I remember correctly, I had created a vector class to perform convenient vector normalizations, cross products, and other things needed in the algorithm, and then another class with the actual tracking nuts and bolts.

[wholmgren]

Ok, I would suggest throwing together the basics and submitting a pull request before you get too far. Have you seen the Contributing wiki?

https://github.com/pvlib/pvlib-python/wiki/Contributing-to-pvlib-python

Let us know if something isn't clear there so that we can improve it (or edit it yourself).

[jforbess]

@raphaelvarieras, I don't suppose you have any time to put together a function with your implementation, or maybe send it to me for implementation? I am looking at the single axis tracker clear sky poa curve, and it doesn't look right, possibly due to an incorrect surface_aziumth calculation. I am planning to go through the current code and its reference, but it's always good to see a different implementation.

@wholmgren, this is another example that should be compared to the MATLAB version, and I will work to get that test in place, though I might need someone with MATLAB to run the base case for me. Or I can be the guinea pig to see if it runs in octave. I forget if anyone else has tested it to see.

[wholmgren]

@jforbess what version of pvlib are you using? @mayudong fixed an issue with surface azimuth in #145 and claimed that the results were consistent with pvsyst. This fix was included in 0.3.1. I also reproduced the matlab examples in the tracking notebook, though the comparison was only by visual inspection.

[jforbess]

Hm. I'm using v0.3.3. I will go run the note book example too, thanks.

[jforbess]

The notebook was helpful. Ultimately my issue was due to using the default 'isotropic' instead of 'haydavies' for a diffuse model. Apparently the boost on the shoulders of the day are attributed to some additional poa_diffuse.

[jforbess]

Has anyone worked on a 2-axis tracker algorithm? It doesn't look like there is one in PVLIB for Matlab either.

[cwhanse]

We haven’t. We assume they follow the sun precisely and simply use the ephemeris for tracker pointing. I’d be interested to know if there are intentional variations in 2 axis tracking controls.

[jforbess]

I guess that works, with fairly basic checks for limits of the tracker's mechanical constraints (+/- 120 deg, or whatever).

[deltaorange]

Hey everyone, I have found that the tracking alg for a single axis tracker is reversed . That is, in a given days hours of operation, when compared with pvsyst/sam, is reversed in order. (first time step has sam/pvsyst's last step). Can anyone else confirm?

[mikofski]

Is there any reason for this issue to remain open still? Can it be closed now? AFAIK single single axie tracking is in https://github.com/pvlib/pvlib-python/blob/master/pvlib/tracking.py. Also IMO the NREL tracking paper by bill Marion should probably be referenced in singleaxis

[wholmgren]

We can close it. pvlib python's implementation follows PVLIB MATLAB's pvl_singleaxis.m, including the references section.

[cwhanse]

@mikofski the code implements the algorithm in the reference paper by Lorenza. Although Marion's paper covers the same material, the notation and calculation process is different enough that I don't want to risk confusing future code maintenance by adding references which don't help explain the code.