pvlib development roadmap

[cwhanse]

@pvlib/pvlib-core and (at) everyone:

Several years back, @wholmgren and I proposed a development roadmap from v0.7. While perhaps too ambitious in scope, the roadmap helped focus efforts and many of those objectives have been achieved. Thanks to all who contributed with either code or comments - both are valued.

At the 2022 PVPMC workshop we heard from a group of users and contributors that it's time for a new roadmap. We intend the new roadmap to identify both short- and long-term development objectives. Short-term objectives are generally those for which no new information is needed; long-term objectives generally require a new approach or method to be identified or developed. We hope the roadmap will show where you can contribute in a meaningful way.

Our first task is to invite your comments on this draft roadmap. Please try to comment by 11/15/2022, and thanks for your input.

Short-term objectives:

1. Improve documentation pages. See discussions define/improve documentation structure #329 Consider creating an FAQ page in the User Guide #1546 Port notebook tutorials to rst with doctests #120 doc: describe modeling steps #60. This is a large task which could be broken into phases.
2. Address and close numerous issues related to IV curve calculations and functions: Test singlediode() implementations using a "gold" function and data set #411 Docstring for pvsystem.calcparams_xxx are inconsistent with function code #716 ENH: calcparams_pvsyst should output d2mutau and vbi #516 ENH: model pvsyst thin-film recombination for CdTe and a:Si in pvsystem.singlediode() #517 ENH: allow user to specify the scaling of singlediode ivcurve-pnts or a specify an array, series, or sequence #418 BUG: WIP: inconsistent broadcasting of outputs from singlediode methods in #409 only #416 fit_sdm_desoto fails with certain valid inputs #1014 Return dictionaries instead of tuples #959 Inconsistent parameter name in fit_sdm_cec_sam()? #958 Allow user to set tol and maxiter for singlediode newton method #1249 Improve error handling in sdm.fit_ and sde.fit_ functions #1235 IV curve fitting #1228 Auxiliary equation for PVsyst shunt resistance may be incorrect #1094 Trouble figuring out how to run IV gold standard test cases in pvlib #1578 Sample consistent currents when creating IV curves with pvlib.pvsystem.singlediode #1496
3. Improve tutorials and documentation for the "I'm new to PV modeling and pvlib, how do I start?" audience.
4. Extend pvlib.clearsky.detect_clearsky to include the Bright-Sun algorithm Add BrightSun clear-sky detection method #1061 and new work that addresses detecting clear-sky conditions in time-averaged and tilted-plane data (preprint).
5. Add Deline model for loss due to irradiance non-uniformity.
6. Add ohmic loss model.
7. Add capability to read PAN and OND files.
8. Add capability to use SMARTS from pvlib.
9. Output ground irradiance from bifacial irradiance models.
10. Add LCOE calculations. Perhaps this is a long-term objective since nothing in pvlib currently has a financial unit.

Long-term objectives:

1. Obtain pvlib.org
2. Add models for: DC-DC optimizer efficiency, inverter efficiency at non-unity power factor,
3. Migrate cell/module/string mismatch capability from pvmismatch into pvlib-python.
4. Add capability to adjust output for the time-resolution of the input data. For example, when using hourly irradiance it is common to compute solar position at the midpoint of each hour (or at the midpoint of the daylit portion of sunrise/sunset hours). There are also methods to adjust model output (hourly power/energy) to account for subhourly effects such as transitory inverter clipping.
5. Add capability to export model parameters and/or data in formats used by other modeling systems.
6. Extend detect-clearsky functions to label conditions with more resolution than clear/not clear; e.g., overcast, partially cloudy, etc.
7. Add snow loss models for bifacial and tracked systems.
8. Consider adding geographic and electrical coordinate systems. These coordinates would be needed if pvlib is to provide more detailed shading/bifacial/mismatch models.

[wholmgren]

1. Data model to support multiple inverters, integrating with ModelChain
2. Transformers #1269
3. Energy Production Modeling and Provenance #96, perhaps for now simply developing openpvspec and interfacing with pvlib

@cwhanse we have pvsystem.dc_ohmic_losses so perhaps you mean to suggest #1069?

[adriesse]

It could be helpful to also try to articulate some higher level things like vision, mission, strategy and such. The previous roadmap had little bits of this.

@cwhanse I seem to recall you were trying to get feedback specifically from industry users. Did that provide any relevant insights?

[cwhanse]

@adriesse is that a vote to update the current roadmap wiki page? I'm OK to do that, although I don't know how much attention that page gets.

[adriesse]

No, just a suggestion to discuss these higher-level things. They could influence the feature wish-list and prioritization.

[cwhanse]

I haven't gotten much specific feedback from industry users. Many I spoke with at RE+ don't use pvlib directly; they will use it to prototype or as a guide, then implement (often) in a different language.

[adriesse]

I was going to click on the sad emoiji, but that doesn't appear to be an option. :(

[kurt-rhee]

As an industry user of pvlib my very selfish feedback on the pvlib roadmap posted above:

Short term objectives:

• No comments

Long term objectives:

• Migrating pvmismatch would be helpful for my team
• I have a set of functions that I have written which set the sun position depending on the context of what I am trying to calculate, for example I would like to midpoint of the timestamps when calculating what angle to use for true-tracking and I use the endpoint in order to determine what angles I need to use to avoid shading through the entire timestep. Having the ability to calculate where in the timestep the calculation is occuring would make my code less verbose.
• I like SolarFarmer's approach to the JSON MNT file and would love for it to be implemented across the industry.

[kandersolar]

I have not expressed this publicly, but I would like to further develop the SAT capabilities of pvlib.tracking, including:

• Additional methods of determining the "ideal" rotation as alternatives to the astronomical method currently hardcoded in singleaxis. One example is the optimization for diffuse conditions offered by several tracker manufacturers.
• Additional methods of determining the backtracking position as alternatives to the simple gcr and cross_axis_tilt method currently implemented. One example is the "split-boost" method for modules with half-cut cells as Aron Dobos discussed at the recent PVPMC meeting. Another is terrain-based shade avoidance akin to NexTracker's TrueCapture which would require the new coordinate system and data model @cwhanse mentioned.
• Methods of modeling the real-world behavior of adjusting position in discrete steps along the lines of the discretized tracking gallery example. At least two discretization schemes are used by trackers today (constant time increment, constant angle increment).
• Miscellanea: systems with different "as-programmed" and "as-built" GCRs; wind stow logic; energy consumption of the tracker motors

Several of these items do not have any suitable reference in the literature that I'm aware of, so writing and publishing those would have to come first. In addition to more clearly defining each step, some thought is needed about how best to combine them into a coherent modeling workflow. A bonus objective is to develop this in coordination with the SAM team so that the two projects are modeling trackers consistently with each other. @mjprilliman has expressed interest in this previously, although progress has stalled since then due to lack of time on my end. Regardless this is on my personal aspirational roadmap for pvlib, so I bring it up here.

[kurt-rhee]

I would love to help with the terrain based shade avoidance section if helping does not conflict with the commercial interests of my employer.

[AdamRJensen]

An overview of the possible development for the iotools (including PR and issue references) can be found in this discussion: #1528

The main ideas are:

• Improve consistency (variable mapping and returning a tuple of data, meta)
• Add additional functions (e.g. for accessing ERA5, NASA POWER, horizon profile data)
• Somehow move to only having read/get functions (having the read function do the job of the parse function)
• A sub-page dedicated to introducing the iotools, providing an overview of what datasets and formats are available

[mikofski]

• IAM that supports AR coating like Fresnel #1501 arc glass
• clipping off-mpp operating point calculation #1178 off mpp inverter
• Transformers #1269 transformers

[adriesse]

Would it be useful to identify criteria for prioritization? Or do feature ideas simply wait in the queue until a volunteer comes along?

[cwhanse]

Would it be useful to identify criteria for prioritization? Or do feature ideas simply wait in the queue until a volunteer comes along?

Yes. My coarse setting: short-term means we have enough information and mostly need someone to work the issue; long-term means a desired feature that may require locating papers in literature or new work to be able to implement it.

As for prioritization - I haven't thought about sequencing these items or about sorting the short-term list by anticipated release version.

[adriesse]

How about expected benefit to different user groups as a criterion? E.g. this capability is sorely needed by industry and no other software can do it yet, vs. commercial software already does this so pvlib should too, vs. this is a core capability for that area of research.

[mikofski]

seconding/emphasizing this issue as significantly important to me: Add models for: DC-DC optimizer efficiency, see #1588