Skip to content

Rethinking pvlib.ivtools #931

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
cwhanse opened this issue Mar 9, 2020 · 5 comments
Closed

Rethinking pvlib.ivtools #931

cwhanse opened this issue Mar 9, 2020 · 5 comments
Milestone

Comments

@cwhanse
Copy link
Member

cwhanse commented Mar 9, 2020

When I proposed pvlib.ivtools I had in mind only the use case of fitting single diode models for PV modules. I expect to see PRs soon with a function to fit the Sandia inverter model (to measured efficiency curves), and functions for the Loss Factor Model. These don't meet the narrow scope of the current ivtools. There are likely other model fitting functions that could be of interest to pvlib users.

#708 refactors ivtools to separate functions into modules sde and sdm for single diode equation and model fitting, respectively. In hindsight, ivtools is too generic, since it doesn't communicate what the module does besides something with IV curves.

An alternate home for model fitting functions, including those in ivtools, might be pvanalytics. But the inverter model fitting code doesn't seem natural there, either, since pvanalytics is primarily being designed for analysis of time-series data from PV systems.

Options:

  • keep pvlib.ivtools, and stick fit_inverter_snl (or whatever it's named) into pvlib.pvsystem.
  • add fitting functions to the code module containing the related model function, e.g., put fit_inverter_snl into pvlib.pvsystem or merge Create inverter.py #886 and add fit_inverter_snl there.
  • create a new module with a broader name than ivtools to contain all model fitting functions, divided up into appropriate modules.
  • refer the two PRs to pvanalytics

Other ideas?

@mikofski
Copy link
Member

mikofski commented Mar 9, 2020

-1 on pvanalytics, IMO generating inverter and PV-module parameters should be the job of pvlib

My personal preference would be to split pvsystem.py out into pvmodules.py and inverters.py, then fit_inverters* and the inverter models would be in inverters.py and ditto for PV-modules. If that's too specific, then PV-modules and inverters could be in components.py which could be a catchall for PV-modules, inverters, trackers, batteries, cabling, xfmrs, etc.

  • IMO pvsystem is too long, Breaking out parts of pvsystem.py? #436
  • pvsystem would still have PVSystem class and some system performance functions like singlediode, max_power_point, etc
  • other component specific functions would be moved to their new homes, such as calcparams*, retrieve_sam, snl_inverter, adrinverter
*-*- pvsystem/
|  \
|   *- pvsystem.py
|   |
|   *- components.py

or another way to split them would be pvsystem/performance.py and pvsystem/parameters.py?

@cwhanse
Copy link
Member Author

cwhanse commented Mar 10, 2020

I'd favor pvmodule.py and inverter.py over the (IMO) too-generic component.py, parameters.py, etc.

@wholmgren
Copy link
Member

+/- 0 on moving the fit code to pvanalytics.

-1 on adding it to existing pvsystem.py.

+1 on breaking up pvsystem.py and uncertain on moving the fit functions into the relevant new modules.

-1 on a pvsystem subpackage at this point in time.

@wholmgren
Copy link
Member

ok to close this @cwhanse?

@cwhanse
Copy link
Member Author

cwhanse commented Aug 28, 2020

yes

@cwhanse cwhanse closed this as completed Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants