Skip to content

2019 pvlib python Development Roadmap

Jump to bottom Edit New page
Kevin Anderson edited this page Oct 18, 2023 · 1 revision

pvlib python development roadmap (2019)

Authors: Cliff Hansen, Will Holmgren

pvlib python is a set of documented functions and classes for simulating the performance of photovoltaic energy systems. This page defines features and capabilities to be implemented in the next few versions.

Development Philosophy

Why has pvlib python been successful? We believe the following aspects contribute to pvlib's success and should be sustained and protected.

  • Supports and is supported by the PVPMC.
  • Provides a flexible set of core functions that implement popular models.
  • Assists with and simplifies PV system modeling by means of PVSystem and ModelChain objects.
  • Follows a well-thought out description of the modeling process (the PVPMC modeling steps diagram).
  • Requires consistent docstrings with emphasis on including references to original publications.
  • Provides data import capabilities (specifically TMY and forecasts) that attract users.

In addition, the pvlib project is actively managed and welcomes submissions, so that users have confidence that issues will be addressed, code will be maintained, and new capabilities can be added.

Specific user needs

What major items is pvlib python missing? What use cases does pvlib python implement in an awkward manner or fail to address?

  • pvlib lacks a comprehensive PV system data model. The current data model identifies modules and inverters, and assumes the arrays are homogenous (i.e., same tilt and orientation, all strings are equal). It does not describe electrical topology or physical layout. Model parameters for various aspects of a system could be better organized.
  • pvlib lacks a comprehensive set of PV system loss models. For example, there are no options for DC wiring losses, mismatch losses, snow or soiling losses.
  • pvlib documentation is overdue for a thorough revision.
  • pvlib could provide more options and functions for bifacial PV system modeling, including irradiance models, PV system models, and loss models. Currently, one function is provided that wraps pvfactors, a separate package that calculates rear-surface irradiance.
  • The association between steps in the modeling process and the location and use of functions in pvlib could be clarified and made more consistent. For example, functions in pvlib could be easier to locate if the code is refactored into modules that align with the modeling process steps in the PVPMC diagram.

Engaging more users

How can pvlib capabilities be more effectively communicated, in order to sustain the project, and to attract and recognize contributions?

  • Active advertising. Create and maintain a list projects/capabilities that use pvlib. Encourage use of the pvlib logo. Create a “powered by pvlib” icon that others could easily use. pvlib stickers could be passed out at poster presentations.
  • Interoperability with other projects. pvlib development can encourage and prioritize greater interoperability with other open-source projects: CASSYS, SAM, and projects with specific purposes such as PVMismatch and pvcaptest
  • Regularly survey users to get specific feedback on this roadmap, and update the roadmap at each major release.

weather resources

The pvlib.iotools package provides convenient access to weather file formats and providers. Here's an incomplete list of some of the providers, many of each have already been implemented in pvlib.iotools already. Please add more formats and providers as needed.

The next level

Solar power modeling is really a small part of a much larger model. More and more, solar + storage, GIS, grid integration, and other system level modeling are becoming more important. This list of goals represents the next level of pvlib development that encapsulates the complete solar power model.

  • Energy storage & storage -- Dispatch algorithms, degradation, charge and discharge rates, time of day and net-energy metering, load-shifting, voltage & frequency regulation, and demand-response charges
  • Load data integration -- there are sources of load data that can be used in system-level models
  • Long term degradation and other losses -- provide a mechanism for loss-tree accounting
    • reactive power, availability, and curtailment
    • DC & AC collector losses
    • transformer load/no-load efficiency
    • snow & soil models #577
  • Inverter temperature and elevation dependence #85
  • Port of Sandia grid-connected PV inverter model parameter generation #886
  • Uncertainty -- Monte Carlo and/or linear combinations to find p90 level of exceedance
  • Spectral mismatch using SMARTS and NREL Bird Simple Spectral model SPECTRL2
    • port of NREL SPECTRL2 FORTRAN or spreadsheet implementations
    • SMARTS wrapper #857
  • Synthetic generation of high frequency weather data, or hourly data from monthly
  • GIS support -- incorporate and read USGS, ESRI, and SRTM data

Technical vision for next major releases

v0.8

  • Refactoring API.
    • Cleaning up the existing API will allow us to build on a better foundation.
    • Refactor to better follow the modeling steps diagram: iam.py, transposition.py, etc.
    • When easily done along with the above refactoring, edit variable/function names for consistency. * Don't over do it in 0.8.
    • Expand and follow https://pvlib-python.readthedocs.io/en/stable/variables_style_rules.html
  • Other development
    • Fix the reported issues with single axis tracking (reported for PVLib Matlab).

v0.9

  • Continued refactoring API

  • New models

    • Add models for irradiance and DC current loss mechanisms: local shading, snow, soiling, mismatch, DC resistance.
    • Add a bifacial modeling module, or perhaps make bifacial.py in its own repository.

  • ModelChain refactoring or alternative. Some options:

    • Refactor ModelChain into a base class and child classes that implement specific use cases. Don’t repeat the mistakes of the early SAPM and Singlediode versions of the ModelChain!
    • Write task graphs using a framework such as dask.
    • The Solar Forecast Arbiter's pvmodel functional design pattern could be extended.
    • Explore Mark Campanelli’s plug-in idea

  • Other development

    • Improve consistency of function input/output types. Remove code like “if isinstance(data, pd.Series): return pd.Series(result)”. Ideally, these type conversions should become unnecessary as numpy and pandas become more friendly. They currently prevent use of different data structures such as ndarray with ndim > 2, xarray, dask, etc.
    • Replace DataFrame output with tuple, dict, or dict-like structure that can handle arbitrary input.

  • pvlib family of projects

    • Create a family of projects under the pvlib organization, for use cases other than predicting PV system output: forecasting, analysis of PV data, model fitting/parameter estimation.

v1.0

  • PV system data model to better represent system/string/module/cell structure and topology, and to accommodate variation in equipment parameters within a system.

  • Documentation: Overhaul the pages that have accumulated and design a website from the outside down.

  • Testing

    • Unify test CI into azure (or new github services)
    • Performance benchmarking (maybe airspeed velocity on a VM on UA’s Arbiter server?) https://github.com/pvlib/pvlib-python/issues/419
    • Review tests to ensure physical validity (many test outputs are copy/paste and only protect against unanticipated code changes)
Add a custom footer
Add a custom sidebar
Clone this wiki locally