Shadow effect modeling in PV systems.

[dberrian]

I couldn't find in PVlib-Python any thread about shadow effect modeling in PV systems which is very important for energy yield prediction. Do you have any idea about this topic?

[cwhanse]

Currently pvlib-python doesn't include code for near or far-field shading. There are models in literature and some modeling package (e.g., FirstSolar's PlantPredict) are using some of them. pvlib-python is open source, we'd welcome a pull request if you've got a well-documented shading model that could be included.

[cwhanse]

1017 partially meets this request. I would like to see #758 completed and merged before we close this issue.

[kandersolar]

Diffuse and horizon shading are good steps forward but I think adding a model for row-to-row direct shading as well would make it easier to say "yes, pvlib-python models shading". Doesn't necessarily have to be at the level of detail of PVMismatch; there are some pretty straightforward models out there like Thakkar et al. "A simple non-linear model for the effect of partial shade on PV systems" https://ieeexplore.ieee.org/document/5614450, and I used a similar model in a PVSC paper this year (preprint).

[mikofski]

the infinite sheds pr #717 provides row-to-row shading

[cpr-chas]

@mikofski, @kanderso-nrel, we are looking at adding some self-shading to our fork and we'd love to do this in a way that allows us to make a useful contribution to the core project. Is the current expectation that the 'infinite sheds' work will cover this need entirely, or would you want to support multiple models of varying complexity? I think we'd be happy to tackle one of the "pretty straightforward models" with some guidance. What would be most valuable to the project?

From our perspective using an approach that is comparable to SAM's output seems like it would make validation a lot simpler.

[kandersolar]

+1 from me for having multiple shading models available in pvlib. I'd be happy to help with a python version of the SAM model or any other model of interest.

[cwhanse]

@cpr-chas I think pvlib.shading should contain functions for:

• effects-level shading models (e.g., Deline's approach)
• functions that adjust direct and diffuse irradiance for far- or near-field objects, e.g. #758
• detailed, geometric functions that e.g. calculate the shaded area on an adjacent row as a function of sun position and array geometry. These detailed functions should be designed to be able to be used in future pvlib.bifacial functions.

Does the shading model you have in mind fall into one of these categories?

[mikofski]

I'm also +1 for having multiple shading models

[cpr-chas]

@cpr-chas I think pvlib.shading should contain functions for:

* effects-level shading models (e.g., [Deline's ](https://www.researchgate.net/publication/273227488_A_simplified_model_of_uniform_shading_in_large_photovoltaic_arrays)approach)

* functions that adjust direct and diffuse irradiance for far- or near-field objects, e.g. #758

* detailed, geometric functions that e.g. calculate the shaded area on an adjacent row as a function of sun position and array geometry. These detailed functions should be designed to be able to be used in future `pvlib.bifacial` functions.

Does the shading model you have in mind fall into one of these categories?

Right now I only see 3 methods in shading.py, and they seem to be focused on calculating diffuse shading based on geometry. Our short term goal would be to model loss from direct shading as well, also based on geometry.
I'd also like to learn more about your first bullet point, but reading scientific papers isn't my forte so it might take me a while to wade through it.

As for near- and far-field object shading, that's definitely of interest to us, but likely further out. Is PR #758 still active? I don't see any recent updates.

So generally, "yes", but likely in order of 3, maybe 1, then 2.

[cwhanse]

@cpr-chas I wasn't requesting that you tackle all three of those categories, I merely wanted to communicate my perspective on this module's scope, and that design for internal reuse is worth a bit of extra effort. Any contributions to shading.py are welcome and valued.

758 is an orphan that is worth picking up and completing.