[bfs2021]

Problem

pvlib.scaling.wvm returns an entirely NaN output for a layout with one coordinate pair. See #2895 for the full report, including the float-precision analysis (0.29 * 100 == 28.999...-style rounding is a separate symptom of the same rounder).

Root cause

With a single position, scipy.spatial.distance.pdist returns an empty distance array, so n_pairs = 0 and the effective-size objective has two roots (x=0 and x=1). The optimizer converges to n_dist = 0, which makes the Eq. 6 denominator 2 * sum(rho) + n_dist equal to zero — dividing by zero yields NaN for every timescale, and the reconstructed signal is all NaN.

Fix

_compute_vr now returns a variability reduction factor of 1 for every timescale when positions contains a single site. Per the WVM equations, one site has no pairwise correlations and therefore no variability reduction, so wvm passes the input signal through unchanged — the behavior the issue describes as expected.

Testing

• test_compute_vr_single_site: _compute_vr with one position returns all ones for every timescale.
• test_wvm_single_site: wvm with one position returns the input signal unchanged (previously all NaNs).
• pytest tests/test_scaling.py → 18 passed (16 existing + 2 new), Python 3.12, Windows.

Fixes #2895

Checklist

• Closes BUG: scaling.wvm returns all NaNs for a single-site layout #2895
• 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
• Adds a "what's new" entry in docs/sphinx/source/whatsnew/v0.16.2.rst (:issue:2895, :pull:2896, by :ghuser:bfs2021)
• New code is fully documented. (no public API change; the single-site early return is commented in code with a link to this issue)
• Pull request is nearly complete and ready for detailed review.

[github-actions]

Hey @bfs2021! 🎉

Thanks for opening your first pull request! We appreciate your
contribution. Please ensure you have reviewed and understood the
contributing guidelines.

If AI is used for any portion of this PR, you must vet the content
for technical accuracy.

Finally, be sure the PR description includes the PR
checklist,
and complete the items you are able to.

[kandersolar]

I haven't checked the bug fix yet, but at least the what's new entry can be edited

[kandersolar]

Suggested change

	contains a single site (:issue:`2895`, :pull:`2896`) by :ghuser:`bfs2021`
	contains a single site (:issue:`2895`, :pull:`2896`)

[bfs2021]

Both whatsnew suggestions applied (fe02197) — the credit moved to the Contributors section and the bullet now ends with the issue/pull references.

On the test (windows-latest, 3.14, conda) failure: both attempts died while building the environment, not in the test suite — micromamba.exe exits with 0xC0000005 (access violation) and the activation step then can't find test_env. That's the same env-setup crash other PRs have hit on this runner; a rerun should clear it.

Note: the run also confirms the "If AI is used for any portion of this PR, you must vet the content" note — this PR was developed with AI assistance and I've vetted the change and its tests.

[cwhanse]

I think we should use this PR to clarify the positions input. Although the current code parses a list (or array) of lists, e.g. positions=[[x1, y1], [x2, y2], ...], that ought not to be encouraged, since the downstream function scipy.distance.pdist` is looking for a 2d array of shape (N, ndim) where ndim is the number of coordinates for each point (2 in our case). The comment is also a little unclear regarding what a position means.

[cwhanse]

Match the docstring of wvm

[bfs2021]

Thanks for the review — applied in 8f64f86:

• positions is now documented as an (N, 2) array of (x, y) coordinates in both wvm and _compute_vr, which is the shape pdist consumes, and the wording says what a position is (easting/northing of the PV systems in meters).
• The guard is len(pos) == 1 now. An empty array falls through and produces an invalid result on its own, as you noted — left out of scope here.

tests/test_scaling.py passes (18/18).

[cwhanse]

thanks @bfs2021