`calc_surface_orientation` returns a 1-element array for `surface_azimuth` when `tracker_theta` is scalar (regression in 0.15.1)

[kdebrab]

Describe the bug
Since 0.15.1, pvlib.tracking.calc_surface_orientation returns surface_azimuth as a shape-(1,) array when tracker_theta is a scalar, while surface_tilt is still a scalar. In 0.15.0 both were scalars.

This looks related to #2747, which was also a shape regression in this function from #2702. #2749 fixed the 2-D case in 0.15.2, but the scalar case is still present in 0.16.1.

To Reproduce

import pvlib
pvlib.tracking.calc_surface_orientation(-30, 0, 180)

pvlib 0.15.0:

{'surface_tilt': np.float64(29.999999999999993), 'surface_azimuth': np.float64(90.0)}

pvlib 0.15.1 through 0.16.1:

{'surface_tilt': np.float64(29.999999999999993), 'surface_azimuth': array([90.])}

Expected behavior
For a scalar tracker_theta, surface_azimuth is a scalar, consistent with surface_tilt and with 0.15.0.

Versions:

• pvlib.__version__: 0.16.1
• pandas.__version__: 3.0.6
• numpy.__version__: 2.5.3
• python: 3.12

[markcampanelli]

This type of issue happens to be something I'm trying to address in pv_workflows, which can be viewed as a wrapper around pvlib's (and similar libraries') "algorithm" functions to make the interfaces rigorous and consistent and ready for production-quality and parallelizable computational workflows.

At this point pv_workflows has adopted the Python Array API. In this case where numpy is the array-API implementation, pv_workflows should (eventually, when this function's abstraction is implemented) return a zero-dimensional numpy.ndarray, i.e., numpy.array(90.), and specifically neither 90., numpy.float64(90.), nor numpy.array([90.]). This result should be guaranteed to be compatible with downstream computations. (That's the goal at least! 🙂)

Also, pv_workflows includes units on everything that has units. If you specify unsupported units, YOU GET REJECTED! 😂 For example, Angles object values natively support both radians and degrees. However, one has to remember to convert appropriately in the implementations, and there's a helper method for that.

I already caught a couple bugs in my implementations by range checks built into many of the object-value initializers.

UPDATE: Supporting reference from array-api-strict: "There are no distinct “scalar” objects as in NumPy. There are only 0-D arrays."

[cwhanse]

Thanks @kdebrab for reporting.