Implement ANTS-2D bifacial irradiance model

[kandersolar]

• [ ] Closes #xxxx
• I am familiar with the contributing guidelines
• I attest that all AI-generated material has been vetted for accuracy and is in compliance with the pvlib license
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

@AdamRJensen, @cwhanse, and I have a paper describing a new bifacial irradiance model called ANTS-2D. It is similar to pvlib's infinite_sheds model, but extended to allow:

• a discretized module surface (for, e.g., cell-level irradiance values)
• a discretized ground surface, with variable albedo
• sloped terrain, in the fashion of pvlib's existing functionality in that area
• the Perez transposition model, in addition to Hay-Davies and isotropic
• computation of ground-level irradiance (for agriPV)
• fast computation by using analytical integrated view factors instead of burdensome numerical integrals

Details available open-access here: https://doi.org/10.1109/JPHOTOV.2026.3677506

This PR is rather large. To summarize:

• Add g0 and g1 parameters to the view factor functions in pvlib.bifacial.utils. These are analogous to x0 and x1 in vf_row_sky_2d_integ and extend the functions to subset the ground surface.
• Change vf_ground_sky_2d_integ to use Hottel's crossed-string rule instead of burdensome numerical integration. This makes the npoints and vectorize parameters unnecessary.
• Change some signatures in pvlib.bifacial.utils to be cleaner with the new calculations.
• Minor edits in pvlib.bifacial.infinite_sheds to accommodate the utils changes
• Create pvlib.bifacial.ant2d, which houses the model itself and uses the new utils functionality.

Let me know if it would help reviewers to split it up and review separate PRs, starting with utils.

[echedey-ls]

Some first impressions; also, you may want to link to it in other bifacial "See also" sections.

[cwhanse]

I'm OK reviewing the whole PR, if we can do it in a sequence of smaller review bites.

[cwhanse]

I'm not persuaded that tracker_rotation and surface_tilt are interchangeable. When axis_tilt is not 0 the rotation angle is not the same as the angle from horizontal. In this case, the 2D geometry being considered is in the plane perpendicular to the tracker rotation axis, not perpendicular to the ground. Does that matter?

Also, with tracker_rotation as the input, this public function relies on context outside the scope of the function: axis_tilt and axis_aximuth are needed to know what tracker_rotation is. If we need the input to be tracker_rotation then maybe consider making this function private.

[kandersolar]

I'm not persuaded that tracker_rotation and surface_tilt are interchangeable. When axis_tilt is not 0 the rotation angle is not the same as the angle from horizontal. In this case, the 2D geometry being considered is in the plane perpendicular to the tracker rotation axis, not perpendicular to the ground. Does that matter?

I think tracker_rotation is correct here:

• Adding g0 and g1 (rather than implicitly hardcoding them as 0/1) means that we can't assume symmetry around the ground midpoint anymore. That means that we need to distinguish east- and west-facing rotations of the same tilt, so a signed quantity like tracker_rotation is needed.
• The VF must be calculated from the ground's point of view. When axis_tilt is nonzero, that means the ground surface is tilted too (the model assumes that the tracking axis is parallel to the ground surface). In the reference frame aligned with the ground, tracker_rotation is the required surface_tilt analog.

Also, with tracker_rotation as the input, this public function relies on context outside the scope of the function: axis_tilt and axis_azimuth are needed to know what tracker_rotation is. If we need the input to be tracker_rotation then maybe consider making this function private.

Yeah, I guess it is a little awkward. Making the function private seems a shame, since it's useful in other contexts. Would noting the geometric link between tracker_rotation, g0, and g1 be a sufficient alternative? g0 and g1 are documented using left and right, so maybe something like:

    tracker_rotation : numeric
        Tracker rotation angle.  Positive rotations indicate raising the
        row's right edge.  [degree]

By the way, we are talking about vf_ground_sky_2d_integ, but the existing vf_ground_sky_2d signature has the same issue (tracker rotation input, but no axis tilt/azimuth): https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.bifacial.utils.vf_ground_sky_2d.html

[cwhanse]

" (the model assumes that the tracking axis is parallel to the ground surface)"

This is a key assumption and constraint. I think users may assume that axis_tilt allows for a tracker to have its rotation axis elevated at one end relative to the ground surface.

[cwhanse]

With this constraint, I agree that tracker_rotation and surface_tilt are interchangeable.

[kandersolar]

d3679fe adds notes on this point.

[cwhanse]

Replace surface_tilt or not, pending outcome of comment about tracker_rotation

[williamhobbs]

Is there a reason that pvlib.irradiance.perez_driesse is not an option? That would be useful to include if it's compatible.

[kandersolar]

Is there a reason that pvlib.irradiance.perez_driesse is not an option? That would be useful to include if it's compatible.

The only reason is that I did not think to include it in the reference paper, so including it here would be going beyond the reference. If no reviewers object to that in this case, I'd be fine adding it in (and maybe documenting it as an extension).

[williamhobbs]

I'd be fine adding it in (and maybe documenting it as an extension).

That sounds great to me!