Pvlib-python: how to organize loss functions

[wholmgren]

_Originally posted by @cwhanse in https://github.com/pvlib/pvlib-python/pull/764_

junk drawer of loss models.

Nice metaphor.

Editorial: Let me just state that I think the PVsyst-style "loss diagrams" do somewhat of a disservice, by applying the term "loss" to quantities of energy that couldn't have been generated in the first place. An example that's not a loss (IMO) is "temperature loss"; the physical reality is that cells are less efficient at higher temperature and hot air happens. There's only a "temperature loss" if the PV system could operate at lower temperature but doesn't.

If we follow the modeling process diagram, which is a guide not a rule, a module dc_losses could contain functions for wiring and mismatch losses, but not soiling, since soiling applies to irradiance not DC current. Debatable whether snow_coverage is an effect on DC current or on irradiance.

It seems that pvlib will have multiple modules soiling.py, snow.py, mismatch.py or dc_losses.py etc. at some level, and the question is about grouping these modules into a losses folder, or not. @wholmgren's question suggests we should agree on a list of these modules, and maybe it will become more clear where to place them.

Here's an attempt to list categories for functions that could be broadly termed losses using my view of that term:

• irradiance reflection (iam.py)
• soiling
• snow
• shading (could overlap with DC losses)
• mismatch (cell to cell and module-to-module variation, also irradiance variation?)
• DC wiring
• inverter MPPT efficiency (not part of the current inverter models, but could be)
• tracker accuracy
• grid support functions (e.g., use of reactive power as voltage control)

[wholmgren]

@cwhanse @mikofski @kanderso-nrel I suggest we discuss organizing losses here. The funky author attribution above is because I tried to use the (new to me) github feature of creating a new issue from a comment.

[steve-ransome]

Hi Will, I tend to be about looser on definitions about what losses are and am perfectly happy to accept a temperature loss. For example under a given irradiance, ambient and windspeed the temperature could be affected by things that can be changed such as insulating the back of a module, putting fins on or even water cooling. Similarly there are losses due to the series resistance of a module and shunt resistances, neither of which we can do much about but they are losses nevertheless. The Loss Factors model identifies about 12 losses to do with the module IV curve and physical parameters.

[mikofski]

The Loss Factors model identifies about 12 losses to do with the module IV curve and physical parameters.

IMO it would be really awesome if we could get the LFM in pvlib.

[steve-ransome]

I'm working on it at the moment ! I hope to talk about it and demonstrate it in Salt Lake City

[cwhanse]

It seems that pvlib will have multiple modules soiling.py, snow.py, mismatch.py or dc_losses.py etc. at some level, and the question is about grouping these modules into a losses folder, or not.

Are we able to decide a way forward on this question, i.e., to keep losses.py with losses.soiling.py, or should we discard losses.py in favor of soiling.py, snow.py, etc.?

Deciding is the roadblock to merging #764

[wholmgren]

or should we discard losses.py in favor of soiling.py, snow.py, etc

+1

[cwhanse]

Hearing no votes for retaining losses.py, we'll remove it and add modules specific to each loss category, as PRs are provided.

[wholmgren]

Seems that this has been resolved. See #306 #925 for more on LFM.