PVLIB's interest in shading loss factor model

[Echedey Luis Álvarez]

Hi PVLIB maintainers!

I'd like to know if the shading loss model proposed here is of interest to PVLIB.

This may be part of my degree thesis with the help of researchers at Instituto de Energía Solar, UPM. Before investing too much time in the implementation, docs and examples I'd like to make sure that this fits the module.

To sum it up, the model takes the amount of shaded "blocks" (cell ranges that have bypass diodes) out of the panel to reduce the output power in proportion.

TIA,

Echedey.

[Will Hobbs]

I'm a user, not a maintainer, but I think this could be useful. 

Here's some GitHub activity related to partial shade, if you have not already seen it:

• https://github.com/pvlib/pvlib-python/pull/1871 (PR to return shaded_fraction from infinite_sheds, useful for shade analysis)
  
• https://github.com/pvlib/pvlib-python/discussions/1880 (discussion on calculating non-linear self-shade loss in c-Si systems)
  
• https://github.com/pvlib/pvlib-python/pull/1725 (PR for new functions to calculate shade losses in thin film truetracking systems)
  

Will

[cwh...@sandia.gov]

@Echedey,

Perhaps. My first question is whether there are alternate shading effect models that are more popular, or that give better results.

The model in the linked paper calculates a factor (Eq. 8 in the reference) that quantifies the fraction of DC power loss due to shading. The factor, and its validation, implicitly assumes one is using the PVWatts model (pvlib.pvsystem.pvwatts_dc) to estimate DC power, so perhaps it might be constrained to be used with PVWatts. One challenge - where would we expect users to get the Nsb values (numbe r of shaded "blocks" in the array)?

Cliff

[Mark Mikofski]

Sounds related to approaches by  Bennet Meyers to reduce dimensionality here:

https://www.researchgate.net/publication/304040339_A_Fast_Parameterized_Model_for_Predicting_PV_System_Performance_under_Partial_Shade_Conditions

And here

https://ieeexplore.ieee.org/document/8521559

[Will Hobbs]

Related to Cliff’s question on where users would get values for Nsb, I only glanced at the paper, and assumed calculating shade geometry was included in there. It does seem like that may need to be part of the new function(s).

--
You received this message because you are subscribed to the Google Groups "pvlib-python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pvlib-python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/f8855ba0-af3a-4560-bdd0-adc541c01b06n%40googlegroups.com.

[Echedey Luis Álvarez]

Thank you all for looking into this!

I think the function in PVLIB should wrap the model to allow for that calculation OFC. I advocate to implement it for row to row shading, since it is the most common case for shade modelling. For near objects creating the shadow, that may be much more complex, just as described in Mark's links.

Lastly, shade factor can already be calculated with PVLIB's internal function pvlib.bifacial.infinite_sheds._shaded_fraction . And now that I've seen PR#1725 (thanks to @Will) I'd like to use it. https://github.com/pvlib/pvlib-python/pull/1725

In this simplified scenario, Nsb would be the rounded up multiplication of the shaded fraction by the number of blocks in the vertical of the panel. I need to grasp and document the blocks: from what I was told there are usually 3 blocks that split the panel along the small side:

+<------- Longest side ----->+
|           Block 1          | ^
|           Block 2          | | Shortest side
|           Block 3          | v
+----------------------------+

In this landscape orientation, if one of this modules is after another one, shade would affect Block 3 for lower SF values. Here we can count 3 blocks in the vertical axis.

And if it were in portrait configuration, shade would affect all blocks the same amount. That is, 1 block in the vertical dimension.

My problem regarding Ntb (total blocks) is that I haven't been able to contrast it with datasheets; even if the number of bypass diodes are mentioned, I've never seen a PV module diagram showing them and I'd like to document it so that anybody knows which values to set. From CECMod and SandiaMod databases I was unable to locate the number of blocks or bypass diodes.

Anyways, I will open a PR in the following days/weeks so I can document all aspects and everybody can check my proposal in depth.

Again, thanks everybody for the insights, I will read those papers more in depth.

Echedey

You received this message because you are subscribed to a topic in the Google Groups "pvlib-python" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pvlib-python/GzZEMxeqLOs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pvlib-python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/CAJDvdRpdt4Qg8r2SRht2h4aHLj5XGF0yau1CYrbDGH9L9s5SRQ%40mail.gmail.com.

[Mark Mikofski]

I really need to read these papers because I have some concerns with this approach.

1. This doesn’t account for split or twin modules sometimes also called half cut cells. Almost all new projects I see, have split modules. These would behave the same in landscape, but would only lose half power in portrait. All modules would still have to carry the same current so the loss affects the entire string but still only half loss compared to traditional modules

2. What is OFC? I’m concerned that this is a constant shade factor. While annual losses might be approximated, Bennet’s work clearly shows that constant shade factors have seasonal biases

I’m not opposed to implementing well documented algorithms, I just hope that the caveats and assumptions are also really well documented. Electrical mismatch is confusing even for experienced analysts, and many pvlib users are just exploring PV for the first time. I want to make sure we don’t mislead them

Sent from my iPhone

On Oct 1, 2023, at 3:42 PM, Echedey Luis Álvarez <eche...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/54bc7d97-7b2f-523f-22a8-55c1814bd30f%40gmail.com.

[Echedey Luis Álvarez]

Good points.

1. I didn't know about them, but at first glance it looks like the number of total blocks and the arrangement is the only thing that changes. It would be 6 for the whole panel, and in my described use case (row to row shading), the number of blocks in vertical in portrait orientation would be 2. As you say, in landscape orientation it will be 3. Thanks for letting me know about that modules, I will document it!

2. I mean that the function I propose has to make that calculation so it can be usable, of course (OFC). The paper does not mention anything about seasonal changes in the shade factor, so other models may be of more interest for day to day calculations.

> I just hope that the caveats and assumptions are also really well documented

Can't disagree with you. Documentation of this model and proposal is key so I wanted to hear all your opinions beforehand. And this kind of conversation is really going to make the results better, so thank you.

Echedey.