Skip to content
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

Add roadmap page to User's Guide sphinx docs #1893

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/sphinx/source/user_guide/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -17,4 +17,5 @@ User Guide
comparison_pvlib_matlab
variables_style_rules
singlediode
roadmap
faq
153 changes: 153 additions & 0 deletions docs/sphinx/source/user_guide/roadmap.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,153 @@
.. _roadmap:

pvlib Roadmap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pvlib Roadmap
pvlib wish list

=============

**Last revision: October 2023**

This document outlines a "wish list" for advancing pvlib-python, focusing
on gaps in functionality and other code-related areas of improvement.

Achieving these improvements will depend on community contributions.
Therefore, it's not reasonable to set forth a timeline for this roadmap
to be completed.
For a more concrete plan of short-term additions to pvlib, please see
the `milestone page <https://github.com/pvlib/pvlib-python/milestones>`_
on GitHub.

Additionally, an idea being listed here is no guarantee that it
will ever be added to pvlib, nor is omission from this page an
indication that an idea is not of interest. This roadmap is an update
of previous roadmaps based on requests from users:

* `2023 pvlib-python user meeting notes
<https://github.com/pvlib/pvlib-python/wiki/2023-pvlib-python-user-meeting-notes>`_
* `2022 pvlib development roadmap
<https://github.com/pvlib/pvlib-python/discussions/1581>`_
* `2019 pvlib-python development roadmap
<https://github.com/pvlib/pvlib-python/wiki/2019-pvlib-python-Development-Roadmap>`_


Core modeling capabilities
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Core modeling capabilities
Core simulation capabilities

--------------------------
The core functionality of pvlib is its library of model functions,
organized by the various conceptual steps of a PV system performance
simulation. pvlib has robust modeling capability in many of these topic
areas, but coverage in some areas is poor or nonexistent. Here is a
partial list of modeling areas that could be improved:

* Improved inverter performance models (power factor, off-MPP operation,
thermal derating, MPPT voltage range)
Comment on lines +39 to +40
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Improved inverter performance models (power factor, off-MPP operation,
thermal derating, MPPT voltage range)
* Improved inverter performance models (power factor, off-MPP operation,
thermal derating, MPPT voltage range) and impacts of off-MPP operation on module temperature.

* DC-DC optimizer performance models
* Transformer models
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Transformer models
* Transformer models (e.g., efficiency models such as described here: [https://www.linquip.com/blog/efficiency-of-transformer/#:~:text=Similar%20to%20an%20electrical%20device,efficiency%20%3D%20output%2Finput).](url))

* Electrical mismatch functionality
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since (one type of) shading is listed as a separate point, perhaps it's worth clarifying this with an example or two? Sounds vague by itself

eg. (just a suggestion/idea)

Suggested change
* Electrical mismatch functionality
* Electrical mismatch functionality (e.g. bypass diode protection)

* Improved snow loss models, in particular for bifacial and tracked systems
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC from the May 2023 PVPMC, one of the Sandia presentations talked about multijunction/tandem modelling goals for PVPMC as a whole(?)
Also, on the subject of irradiance, the spectral effect on the calculation effective POA irradiance was highlighted in the github wiki 2023 user meeting notes. I think this area still needs work, especially if/when multijunction modelling functionality is added

Suggested change
* Improved snow loss models, in particular for bifacial and tracked systems
* Improved snow loss models, in particular for bifacial and tracked systems
* Multijunction device modelling

* Shade models: row-to-row, external (e.g. trees), horizon
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Shade models: row-to-row, external (e.g. trees), horizon
* Shade models: row-to-row, external (e.g. trees), horizon, including 3D terrain effects

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inter-row shading for specific technologies, e.g. CdTe, half-cut etc.?

* Degradation: we can at least provide the trivial linear model, and

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linear or exponential.

add more sophisticated predictive models as they become available.
* More sophisticated single-axis tracker models, e.g. split-boost backtracking,
rotation discretization, stow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rotation discretization, stow
rotation discretization, stow (based on wind speed?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think stow should be just a boolean series, then the user can set the criteria themselves, e.g.,

..., stow=df['wind_speed']>25, ...

* Bifacial irradiance modeling beyond the relatively basic models currently
available in pvlib. Irradiance nonuniformity, varied terrain and albedo,
racking shade, and other effects are not accounted for in the current models.
* Updated parameter libraries, e.g. the CEC PV Module database

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about parameter translation? CEC -> X model?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modeling tandem configurations?

Note that published models may not exist for some of these enhancements,
models would need to be developed and published before pvlib can
provide a reference implementation.


Auxiliary modeling capabilities
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Auxiliary modeling capabilities
Broader modeling capabilities

-------------------------------
Increasingly, pvlib is gaining functionality outside of the typical
modeling workflow, for example parameter estimation/fitting, converting
parameters between similar models, and clear-sky detection.
These kinds of methods are not usually implemented in other
performance modeling software, meaning providing pvlib implementations
is of significant value. However, making progress here is also somewhat
constrained by the small number of existing published methods that can be
implemented.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
See :issue:`1877`.


System simulation
-----------------
pvlib's :py:class:`~pvlib.pvsystem.PVSystem` and
:py:class:`~pvlib.modelchain.ModelChain` classes connect the individual
model functions together to provide coherent system simulations.
However, not all of pvlib's models are accessible with these classes.
For example:

* Bifacial irradiance models
* Internal, external, and horizon shading
* Soiling loss models

In addition to more comprehensive integration of pvlib's model functions,
the scope of these high-level capabilities could be expanded:

* Multi-inverter systems
* Geographic and electrical coordinate systems, to enable more detailed modeling
* "out-of-code" model specification (e.g. configuration files)


Data I/O
--------
:py:mod:`pvlib.iotools` provides functions to import
weather datasets, horizon profiles, component specifications,
and other external data. Expanding this capability by
adding functions for additional data sources is of significant interest.
:py:mod:`pvlib.iotools` would also benefit from further standardization
(``map_variables``, etc) and more documentation.

See :discuss:`1528` for a detailed plan for :py:mod:`pvlib.iotools`.


Speed improvements & benchmarking
---------------------------------
The value of improved computation speed is growing over time
as pvlib is increasingly used in commercial APIs, large-scale
research studies, and high-resolution timeseries simulations.
However, benchmarking and improving the runtime of pvlib's codebase
has received only sporadic and unfocused attention so far.
Establishing a comprehensive set of speed (and potentially memory)
benchmarks would be a good place to start. Identified bottlenecks
should be reviewed and made more efficient if possible. If not,
then alternative models could be implemented for cases where
speed is the priority.

As accelerator tools like Numba continue to mature, they should be
evaluated for potential use in pvlib. Although fast runtime speed is
desirable, it must be weighed against code maintainability and portability.

For modeling topics where runtime can be significant (e.g. solar position),
the relevant User's Guide documentation section could include speed
comparisons.


Documentation
-------------
pvlib's documentation is overdue for a revision, with a focus on
strategic organization. See :issue:`329` for a specific proposal.

Within that framework, better "getting started" tutorials are needed.
However, the scope should probably stick to pvlib usage. PV modeling in
general is better left to other projects like the
`PVPMC website <https://pvpmc.sandia.gov/>`_ or the
`conference tutorials <https://pvsc-python-tutorials.github.io/>`_.

The gallery of examples could be significantly expanded as well.
An aspirational goal could be for every public function to be used
in at least one gallery page.

Additionally, it would be nice to have a project website (pvlib.org?)
with scope going beyond code documentation.
Comment on lines +141 to +142
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would this be different from the GitHub and ReadtheDocs site?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be nice to have a website that unites all the pvlib community and projects (pvlib-python, pvanalytics, etc.)

And giving people the website https://pvlib-python.readthedocs.io is kinda rough... pvlib.org would be an important step for pvlib in my opinion



API cleanup
-----------
Some parts of pvlib's API should be cleaned up before version 1.0
is eventually released. Examples of such cleanup include migrating some code
from :py:mod:`pvlib.pvsystem` to :py:mod:`pvlib.pvarray` and renaming
parameters with inconsistent names.

Taking stock of changes needed before 1.0 is the first step. Then,
actually implementing the changes will likely require deprecation periods.
1 change: 1 addition & 0 deletions docs/sphinx/source/whatsnew/v0.10.3.rst
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ Testing

Documentation
~~~~~~~~~~~~~
* Create :ref:`roadmap` page. (:pull:`1893`)


Contributors
Expand Down
Loading