how to organize loss functions

_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]

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

+1

[steve-ransome]

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