You've probably got the email, but docs are failing with:

Extension error:
Here is a summary of the problems encountered when running the examples:
Unexpected failing examples (1):
    ../../examples/agrivoltaics/plot_agrivoltaics_ground_irradiance.py failed leaving traceback:
    Traceback (most recent call last):
      File "/home/docs/checkouts/readthedocs.org/user_builds/pvlib-python/checkouts/2559/docs/examples/agrivoltaics/plot_agrivoltaics_ground_irradiance.py", line 145, in <module>
        unshaded_ground_fraction = pvlib.bifacial.utils._unshaded_ground_fraction(
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    TypeError: _unshaded_ground_fraction() got an unexpected keyword argument 'surface_azimuth'

Also, I think this deserves a whatsnew 👀
Nice improvement.

My opinion is that it's bad practice to use internals in public-facing examples.

Agreed. We should consider making that ground shaded fraction function public.

Closing as it's nicer to use phi instead of tan_phi. Will pursue a similar refactor in a later PR.

You’re gonna hate this, but you could memoize tan_phi in a class and reevaluate lazily as needed when inputs update. Crazy right. So over the top. But maybe…?

You’re gonna hate this, but you could memoize tan_phi in a class and reevaluate lazily as needed when inputs update. Crazy right. So over the top. But maybe…?

Easily hatable TBF 😆

The easiest option relies on python's lru_cache wrapper. At least this one, and I'm convinced many others too, use a hashmap (plain map in python) where input variables hash->cached return value. Numpy arrays can't be hashed, as they are mutable (plus CPython's default hash implementation is way too basic to work in this case). Also, if you want to bypass this with your suggestion (or other approach, like a wrapper), you would need to check the values of an array matches the values of a stored copy of the array in the cache. So you would end up consuming another significant amount of time.

I'm onboard with Kevin on this approach hehe. Thou that was a good concern @mikofski :)