Skip to content

how to organize loss functions #891

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wholmgren opened this issue Feb 14, 2020 · 8 comments
Closed

how to organize loss functions #891

wholmgren opened this issue Feb 14, 2020 · 8 comments
Labels
Milestone

Comments

@wholmgren
Copy link
Member

wholmgren commented Feb 14, 2020

Originally posted by @cwhanse in #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
Copy link
Member Author

@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.

@wholmgren wholmgren added the api label Feb 14, 2020
@wholmgren wholmgren added this to the 0.7.2 milestone Feb 14, 2020
@CameronTStark CameronTStark modified the milestones: 0.7.2, 0.8.0 Mar 1, 2020
@steve-ransome
Copy link

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
Copy link
Member

mikofski commented Mar 2, 2020

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
Copy link

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

@cwhanse
Copy link
Member

cwhanse commented Mar 17, 2020

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
Copy link
Member Author

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

+1

@cwhanse
Copy link
Member

cwhanse commented Mar 18, 2020

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

@wholmgren
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants