Enhancement to Townsend monthly snow loss model for engineering workflows

[shethkajal7]

Is your feature request related to a problem? Please describe.
The current pvlib.snow.loss_townsend implementation is very useful, but there are several practical engineering situations where additional optional functionality could improve applicability for feasibility-stage PV modeling and PVsyst monthly soiling workflows.

In practice, users often need to account for bifacial systems, tracker configurations, multiple parallel source circuits, and situations where only total snow-event counts are available instead of the number of days with at least 1 inch of snowfall.

Describe the solution you'd like
I would like to propose an enhancement to the Townsend monthly snow loss workflow for discussion.

The intent would be to preserve backward compatibility while optionally extending the model to support:

1. bifacial PV adjustments using front/rear contribution,
2. tracker-oriented guidance for equivalent tilt and slant length,
3. optional multiple parallel source-circuit correction (M = 0.75),
4. handling of total snow-event counts when ≥1 inch snowfall-event data are unavailable.

These updates reflect more recent engineering guidance from Tim Townsend beyond the original 2011 publication and have already been prototyped externally in a research/web-tool setting. I would be happy to adapt the implementation to pvlib conventions and maintainer preferences.

My plan would be to first submit a small pull request focused only on the snow model, tests, and documentation. Any dust/soiling functionality would be proposed separately later.

Describe alternatives you've considered
An alternative is to keep these calculations external to pvlib in standalone tools, though integrating optional enhancements into pvlib may improve reproducibility and accessibility for practitioners already using the Townsend monthly snow model.

Additional context
Before beginning implementation, I wanted to ask whether maintainers would be interested in this direction and whether they have preferences regarding API design or architecture.

[cwhanse]

hello @shethkajal7 enhancements to this model are very welcome.

Are the updates described in a referenceable document? Without that, I'm cautious about proceeding.

[shethkajal7]

@cwhanse Thank you for the quick response.

Yes, there is a referenceable source describing the updated engineering guidance:

Townsend, T. and Previtali, J. (2023). A Fresh Dusting: Current Uses of the Townsend Snow Model. In Photovoltaic Reliability Workshop (PVRW) 2023 Proceedings: Posters, ed. Silverman, T. J. Dec. 2023. NREL/CP-5900-87918.

Available here: https://docs.nlr.gov/docs/fy24osti/87918.pdf

The updated formulation is described on page 18, including guidance on bifacial systems and additional implementation considerations beyond those in the original 2011 publication.

I have also previously worked with Tim Townsend on a Python implementation of these updates in an external research/web-tool setting, so I would be happy to help translate the methodology into a PVlib-compatible implementation with tests and documentation if there is interest.

[cwhanse]

There is interest, and we welcome your contribution!

[shethkajal7]

Thank you! I appreciate the encouragement.

I’ll begin putting together a focused contribution to the snow model enhancements, including tests and documentation, and aim to keep the scope limited and backward-compatible.

One architectural question before I begin: would you generally prefer these enhancements as optional additions to the existing loss_townsend() function, or as a separate extended Townsend function? I want to align with PVlib conventions before implementation.

[cwhanse]

Optional additions are preferred over a new function. New kwargs can default to None to keep the current model available. If the addition is basically using the old model with different parameter values, then perhaps we just describe that in the docstring. I haven't read the paper so I can't give any specific guidance yet.