Kevin Anderson

I think I'm inclined to call this not a bug, or at least "won't fix" on the pvlib side. The example is only one ulp away from returning a positive...

> One would expect aoi_projection to be exactly equal to 0 when the module is perfectly orthogonal to the sun. Mathematically yes, but what I'm saying is that I don't...

If the goal is to have `aoi_projection(a, b, a+90, b) == 0` (which I remain unconvinced _should_ be a goal) then yes. But it doesn't address the original bug report...

Rounding the projection won't change its sign, so if the signs are identical (and thus inconsistent) between the front- and rear-side projections like they are in the example at the...

> should this be solved in that side? Yes, I think so. I've opened https://github.com/pvlib/solarfactors/issues/6 to track it. Feel free to take a look and I'll be happy to help...

I think I agree that this is an error in pvlib's implementation. For fixing the error, instead of verbose logic to keep track of missing values, I think we can...

I am surprised that the runtime difference is only ~2x! Have you compared runtime with pvlib's numba-based SPA function (I guess single-threaded, to be apples-to-apples?). In general I often daydream...

I browsed through the list of available stations for Denmark as an example and saw only partial overlap with what ACIS makes available, so I think #1767 does not make...

> Only pvlib.spa.calculate_deltat has a hyperlink. Unless I'm mistaken, the calculation in `calculate_deltat` is not actually part of the SPA, despite living in `spa.py`. I wonder if it should be...

My thinking is that (with the possible exception of `pvlib.tools`) functions should either (1) have a stable interface and be fully documented in the sphinx docs, or (2) be an...