pvlib v1.0

[cwhanse]

I'd like to know: what features, improvements, or fixes are desired for pvlib to decide it has reached v1.0?

Version 1.0 indicates a level of stability and maturity. Although pvlib-python is now 11 (maybe 12?) years, and in wide use, we stick with v0.XX because as maintainers we see all the flaws.

My $0.02:

• reorganize the documentation pages, in particular, the User Guide and the API Documentation. Overhaul of readthedocs documentation #2224
• complete the renaming of parameters that is underway e.g. Adopt dni_clear variable name for clearsky DNI #2274

[mikofski]

I would like to see a full model chain validation either with commercial operating projects and/or major software like PVsyst, SAM, Plant Predict, SolarFarmer, etc. where the output is hourly energy at the revenue meter. IMHO an ideal validation would compare hourly aggregated values for a year at the module surfaces, the DC inverter input, AC output, the POI & other points in the loss tree. What components are missing to do this comparison? Off-MPP operation? Reactive power? Temperature / elevation inverter derating? Dynamic AC collector losses?

[adriesse]

While I am an strong advocate of validation, this might be going a little too far. On the one hand, it should be possible to validate the features that are already there using simpler system configurations; on the other hand, it's not the job of the pvlib implementers to do that.

Also, as @wholmgren writes below, if the building blocks are validated then the model chain may not need it as much. Where you need the whole model chain validation more is with other software where you can't reach inside. I've been an advocate of that activity for a long time too!

[mikofski]

My point is that pvlib does not have a complete model chain yet. I cannot use pvlib to get the results that would match revenue meter output like I can with PVsyst or other commercial software. The validation isn’t strictly necessary to me, but I would like to see pvlib simulate a complete PV system from sunlight to the grid before it reaches v1. That’s my 2-cents

[adriesse]

@mikofski perhaps this is where our views start to diverge somewhat. I still see pvlib primarily as a toolbox that facilitates people building their own diverse and specialized model chains. I am ok with a basic model chain being offered as a starting point, but would not go further than that.

[wholmgren]

I'd only want to complete the API changes before 1.0. In addition to parameter renaming, we've previously discussed refactoring of several modules (e.g. irradiance.py and pvsystem.py).

I don't think pvlib requires any new features or validation before 1.0. The validation is in the original references for each step of the model chain. And there is not a canonical model chain in pvlib to test. I'd also remove modelchain.py before 1.0 but I don't think that will be a popular opinion.

[adriesse]

I'd also remove modelchain.py before 1.0 but I don't think that will be a popular opinion.

Perhaps I should disqualify myself here because I've never used the model chain, but I think this is an idea worth exploring. I have been tempted on multiple occasions to suggest a split where the package pvlib contains base functionality (akin to numpy) and higher-level stuff like model chain lives in a separate package on top (akin to pandas or scipy).

[mikofski]

I could get behind this. Even though I’d like to see the missing components and functions in pvlib, they are not strictly necessary to get to v1. If I understand correctly, v1 implies we have a consistent unbreakable API. If that’s true then maybe I would also move to eliminate any APIs that won’t live until v2. For example, I’m okay with removing modelchain.py but like Anton maybe my vote shouldn’t count because I don’t use it. I also don’t think it’s necessary to wait until after refactoring to remove pandas if the actual API isn’t changing only internals.

[cwhanse]

I'd also remove modelchain.py before 1.0

Interested to hear your reasons for wanting to discard modelchain.py

[echedey-ls]

In a similar sense to @wholmgren's and @adriesse thread, I'd say that:

• pvlib-iotools may make for another side-package to allow for shorter and more frequent updates. APIs change enough that these wrappers may get obsolete too fast, and having it in another package could ease updating and tracing when things go bad, without waiting for breaking-change releases of core pvlib.
• I dislike (personal taste) the use of OOP such as in Location, Array, PVsystem, Mounts, ... . I would prefer yet another refactoring and namespacing of things rather than a layer of abstraction that may add a little complexity. Disclaimer, I don't use pvlib as much and this is my opinion as dev and time-to-time user.

[mikofski]

Separating iotools seems smart. I’m fine with classes like Location and I’ve come around to using some of them frequently. As in the Julia thread, I’m not concerned with production performance because to me the pvlib library represents the baseline, so applications can reimplement as needed. I do request that we delegate to low level functions even though the hierarchy can create some glut, I want to be able to hit low level functions without creating objects

[echedey-ls]

Yup, I rushed typing Location, when it is the one that accomplishes its objective. The lack of changes that has been made to it is a good indicator of its stability. I can also live with it.

[jsstein]

I support moving to v1.0 this year, if possible. I think it is time. I hope to be able to help with some of these tasks too. Should we develop a transition plan document with a punch list of tasks that is specific enough for individuals to start working towards this goal and crossing off accomplishments as they are completed? I think that might help organize all the ideas generated in this discussion. My GitHub skills are not quite up to the task to start such a document.

[cwhanse]

Let's consolidate this conversation with several others (feel free to add links here): #2345

I would like to get to a list of actions that, when complete, indicate readiness for 1.0. Suggestions from the discussions are listed below.

Please Reply with a comment, listing the actions that you see as necessary for pvlib 1.0. Also, list those actions that you oppose for pvlib, in any version. The complement of these two sets are those actions which you regard as optional.

Also, in your reply please add actions that aren't in the list below, that you see as necessary.

The scope of an action is vague, at this point. Once we agree on the actions, we can convert each to an Issue, link any related Issues or Discussions, and work out the detailed scope.

Finally, please spread the word or collect opinions from your colleagues who may not watch this repository.

1. Overhaul pvlib-python documentation
2. Finish parameter renaming
3. Complete refactor of code modules
4. Addition of component models so that a ModelChain runs from sun to grid, accounting for all (required? desired? significant?) effects.
5. Remove modelchain.py
6. "v1 implies we have a consistent unbreakable API." Remove any APIs that we don't think will survive to v2.
7. Move pvlib.iotools to its own package
8. Refactor PVSystem, Array, Mount objects
9. Replace pandas with polars
10. Replace pytz with python's zoneinfo
11. Add type hints
12. Retire functions that use pyephem (Skyfield is preferred now over pyephem)
13. Apply an autoformatter to all of pvlib

@PhilBrk8 @markcampanelli

[wholmgren]

Truly necessary:

• None - The only thing we lack is the courage to type git tag v1.0.0 and continue on with a vision for pvlib 1.x and 2.0! In retrospect I wish had tagged it 6 or 7 years ago.

Necessary (if only for building the courage):

1. Finish parameter renaming that is already roughly agreed to
2. Complete refactoring that is already roughly agreed to

Oppose:

1. "v1 implies we have a consistent unbreakable API." - the sooner we get to v1 the sooner we have 3 digits of semver to better communicate API changes
2. Replace pandas with polars - pvlib should become more agnostic to data types, not just change to the flavor of the year. I am optimistic that the Data APIs Consortium will continue to progress and make this relatively feasible in the next year.

[adriesse]

Necessary:

• Clarify and agree on the meaning/significance/expectations of v1.0
• Finish the discussion on whether and when certain parts of pvlib (iotools, modelchain, others?) should become separate packages. If there is agreement, and it is not too onerous, then I think it makes a lot of sense to do it at or before v1.0

Oppose:

• Replace pandas with polars. I agree with @wholmgren on becoming less reliant on pandas.