is it time to move pvmm away from SP and under pvlib?

[mikofski]

Dear @chetan201 , @cwhanse , @shirubana , @kanderso-nrel , @bmeyers , @mdeceglie , @adriesse , and any and all others,

PVMismatch (PVMM) may not the best software, but it is mismatch software that makes it much easier than SPICE to model system IV curves at the cell level by tweaking any cell parameter like irradiance, temperature, series & shunt resistance, short circuit current, dark saturation current, etc. However, if you look at its pulse it appears dead. Its last period of significant contributions was in 2017, when contributions peaked at about 10 commits over a few days. Look at recent commits and there's been only 3 in the past year. Finally here are 4 outstanding PR's that haven't been reviewed and no sign of when they might be merged. What I'm trying to say is that I think this project is dead, or at least it's dead to the public.

So the question is, should we let it die? If so, does it need replacement? Is there a need for a PVMM2? Or another option would be to move it away from SunPower and under pvlib. My vote would be for the latter. According to Joel Spolsky, old code is always better than new code, by its very definition that it's already matured, and he blogged about why its nearly always a bad idea to consider a complete rewrite in "things you should never do, part 1". So I don't think we should let it die, and if a PVMM2 is in the works then I think it should be a fork of PVMM.

Potential talking points

SunPower

If SunPower has any proprietary processes that rely on freezing this particular fork, then they can easily do that either in this fork or from whatever upstream fork evolves. If we decide to fork PVMM -> PVMM2, then they can maintain this older fork, and pull or backport features from the newer one as needed. My point is there is no outcome where SP loses access to the version of PVMM that they depend on or the ability to manipulate their fork any way they want. So this is a non-factor

new fork or old

Ownership of the existing project could be transferred to pvlib or pvlib could create a fork of PVMM. The first option would provide the cleanest history of issues, pull requests, discussions, etc., but there's nothing to stop anyone from forking PVMM and starting their own version. It is BSD3 licensed, so no liability would ever fall on SunPower or any contributor. IE: SP would not be threatened by any forks that start deploying their own versions. The only downside of starting a new version of PVMM from a fork is that the history would be discontinuous and there would always be the confusion of multiple projects. There are several examples of these, some successful (PIL vs. Pillow) but many others not so successful. If necessary, it's something that could be worked out.

pvlib or not

My personal preference would be pvlib b/c it seems the most natural place for PV modeling software to go, but it's up to you all to decide what's best. There aren't very many open source umbrella organizations, so if not pvlib, it could go to DuraMAT or NREL, but both of those can't really take an open source project from the wild. pvlib is unique in it's purely public nature, which is what I think has allowed it to be so successful.

complete rewrite

Quoting Joel Spolsky, that might be:

the single worst strategic mistake that any software company can make: ... rewrite the code from scratch

However, that doesn't mean it's the wrong thing to do. It just might be a tougher road or a harder row to hoe.

Reasons to rewrite

• there are no current pvmm users
• the code is unsalvageable, it doesn't work
• the project is unmanageable, it lacks any testing, docs, or basic adherence to common frameworks, guidelines, or styles

Reasons to refactor

• there's already a body of current pvmm users
• the code is in a good state and works well
• the project is clean and tidy, with good unit testing, documentation, and style conformity

Feel free to add on to this, but I think that we should really look to resolve this within the next 3-6 months. I don't think we should let another year go by without any action on it. I can't see a single reason why we should allow this situation to persist other than no one cares.

If you agree with this move please add your comments below and state your desired outcome. Please forward or @ anyone else you think would be interested in supporting this move.

Thanks,
Mark

[yangangky]

If move PVMM to PVlib, then let pvlib can calculate electrical shading losses easily like PVsyst, I will vote this action.
Up to now, PV module layout is becoming more complicate, like full cell, half cell, shingle cell..., the cell and diode layout of them are really different. If we want to know the exactly power simulation result, the electrical shading losses can not be neglected. Besides, landscape and portrait installation is also need to consider that.

[adriesse]

It would be great to have a similar functionality in pvlib using the single-diode model. I don't know enough about pvmismatch to comment on the options, but I'm guessing the single-diode model would require a rewrite.

In response to Joel Spolsky: There's an exception to every rule.

(Anyway, we're not a software company.)

[mikofski]

Check our Cliff's PR #117 which does exactly that, but when will it be merged? The question is not how to integrate with pvlib python, but whether pvmm can grow better under the pvlib GitHub org?

[shirubana]

rock on. yes of course, alive better than not alive imo but i'm not a previous owner.

[wholmgren]

@mikofski are you proposing 1. forking the project to a repository under the pvlib organization or 2. adding a subpackage to pvlib python?

I thought you were advocating for option 1 but wanted to double check. That's easy and I support that. Option 2 would be harder.

[mikofski]

I meant into pvlib org. IMO best choice would be ownership transfer from SunPower org to pvlib. My 2nd choice would be to fork it.

[wholmgren]

Ok, so there are 3 options on the table:

1. Transfer ownership of sunpower/pvmismatch to the pvlib organization. sunpower/pvmismatch becomes pvlib/pvmismatch. Sunpower also gives/shares ownership of the pypi project to/with pvlib organization admins.
2. Fork sunpower/pvmismatch to pvlib/pvmismatch, then likely rename the project. Release project on pypi under a new name.
3. Integrate the pvmismatch code into pvlib/pvlib-python.

Under any of these scenarios, we can discuss granting maintainer access to someone from Sunpower.

[mikofski]

I think 3 is off the table but there is potentially a 4th option:

4. just start a new project from scratch under pvlib, call it pvlib/pvmm2, perhaps with some copy/paste of anything useful from the original pvmm.

[mikofski]

FWIW I think PVMM falls squarely into the the 1st outcome of "Common approaches that sometimes end badly" in Matthew Rocklin's blog on "Public institutions and OSS" with the current situation being PVMM ending badly. ☹️

[adambgnr]

I think it is a great idea to bring PVMM (somehow) under pvlib. The exposure brought by adding PVMM to plvib would already play an important role in saving PVMM. More people would know about it and more would realize what it can offer, thus more people would consider to contribute to it.

Regarding the rewrite/refactor question: if I follow @mikofski's requirements, then I think this case is much closer to the refactor option:

• it does have a user base: https://pypistats.org/packages/pvmismatch
• the code works. We have used it for several research projects, even compared its results to I-V curve measurements. It can provide reliable results. The limiting factor in accuracy is mostly obtaining detailed input (e.g. exact cell parameters)
• maybe not as tidy and well documented as pvlib, but I don't think it is unmanageable.

Maybe an argument for "rewrite" can be to make the structure and format of PVMM more similar to pvlib's code.

An additional aspect to consider, a bit connected to @yangangky's comment:
I think if PVMM will be part of pvlib, in the long term, it would be worth thinking about how PVMM can be "supplied" with irradiance input. There is not much sense in simulating uniformly lit PV systems with PVMM. For those cases, much simpler and faster models (already existing in pvlib) are more suitable. Currently (as far as I know) it is not really possible to simulate arbitrary shading in pvlib. Therefore a good linkage between solar irradiance simulations (that can take into account shading based on some shading geometry) and PVMM is important. I think NREL's bifacial_radiance can be a good option for solar farms. For PV on buildings, a modest attempt is Pyrano, that combines shaded irradiance simulations with PVMM.

[mikofski]

Wow pyrano looks cool! I had no knowledge of this. Thanks!

[shirubana]

Following up on Ádám --- I think there's an open PR (by me ha!) on an example documenting using different irradiance inputs on the pvmismatch site.

I have functions to call PVMismatch to use input from bifacial_radiance and bifacial_vf. They can be reworked to be on the PVMM side though and be more friendly.

The mismatch for bifacials, at least, can be done with the view factor just as fine as with bifacial_radiance, so I would suggest coupling with pvfactors I think is what is already on pvlib?

[cwhanse]

My $0.03 (inflation adjusted opinions)

I gave up on #117. Honestly, I think PVMM needs a rather thorough re-engineering. You can call that refactoring, or reimplementation, if you'd like. The just-in-time computation in PVMM may have performance advantages but it makes it nearly impossible to reconstruct a PVMM calculation using other code. The PVMM parameter interface is a bit unconventional for most PV modelers. I'm not saying PVMM doesn't produce correct results, just that the way it is constructed is a barrier to extending and integrating PVMM with pvlib-python.

I think the modeling community would benefit from PVMM 2.0, that is built from the ground up to offer options for the diode model, can make use of common diode model parameter sets (from CEC and Pvsyst), and allows options for cell temperature models. I think that both pvlib and PVMM 2.0 would benefit if PVMM 2.0 was part of the pvlib organization.

I don't think that PVMM would be as successful as a module within pvlib-python as it would as a separate package. In my view, PVMM is more of an application built to solve a specific set of problems, rather than a library that prioritizes flexible re-use. There are parts of PVMM that would be great to move to pvlib-python, e.g., functions to sum IV curves for cells connected in series and parallel. Other parts (interfaces to spatially variable irradiance calculators) are better maintained separate from pvlib.

[kandersolar]

I would also lean towards a significant re-write. IMHO Joel's recommendations, which are based on years of commercial software dev, don't always translate perfectly to the scientific/open-source side of software dev. For example I don't see a need to stress about being "beaten to market" by competitors here.

@mikofski is it reasonable to very roughly summarize the current PVMM codebase (or at least the part in pvmismatch_lib) as comprising these three parts?

1. Equations for I-V modeling
2. Python code to coordinate translating inputs to outputs
3. Plotting functions

I think it makes a lot of sense for a PVMM2 to use pvlib for I-V curve generation, meaning (1) would go away. I think (2) is related to the difficulties @cwhanse saw with #117 and why it's hard for me to be confident that #121 doesn't introduce any nasty hidden bugs. I think (3) is fine code that would be easy to re-use in a larger re-write effort, and not necesarily mission-critical anyway. So I think it's worth considering a re-write despite Joel's Netscape story. Or maybe I'm still falling prey to the not-invented-here syndrome Joel warns against...

[mikofski]

I agree that refactoring PVMM would be necessary to play better with others, but I'm not focusing on the how right now so much as the what. TBH we've talked about a rewrite of PVMM or PVMM2 for a few years, but it has yet to materialize. That could be an indication that it's not a pressing concern, but I don't believe that (tho perhaps succumbing to my confirmation bias). I think there is substantially more to PVMM than just 1, 2, and 3 - there is already a small non-zero body of users and downstream projects and an API that would need a proper deprecation cycle. To quit them cold turkey is to throw the baby out with the bathwater. I would say let's agree to either solicit SP to change ownership or consider forking/starting a new project be it pvmm or pvmm2 first, and then we can decide what to do about resolving the tough challenges around integrating with pvlib. Divide and conquer. In the current scenario, we can't advance because no one will review or merge #117 and #121 in a timely manner and the greater public has no transparency into what is going on with pvmm or what its future is.

[cwhanse]

there is already a small non-zero body of users and downstream projects and an API that would need a proper deprecation cycle.

To me, this is an argument for starting over with a new project, rather than evolving PVMM through a series of substantial changes. The existing users continue to benefit while we build a replacement capability.

I stopped work on #117 when it became apparent (to me) that generalizing the diode model would involve a lot of changes to the API, and at that time, the SP maintainer discouraged that.

[mikofski]

the SP maintainer discouraged that.

This is exactly the roadblock I am trying to remove. I think solve this first then the rest will follow. we don't need to decide on a rewrite just yet. Let's resolve ownership and maintenance first, then I think we can tackle the rest of the issues.

rather than evolving PVMM through a series of substantial changes

I think this is unavoidable regardless of whether we restart from scratch, fork, or change ownership. IMO the current state of pvmm cannot persist

[cwhanse]

@mikofski we agree on both of these points.

[chetan201]

@mikofski @wholmgren @cwhanse @adriesse @shirubana @adambgnr @kanderso-nrel @yangangky
Thanks everyone for chiming in. I had a chat with Mark Mikofski today and I think the changes being discussed here are sweeping and will probably require core API changes. It's best that the reincarnation is in a separate repo (perhaps underpvlib) for ease of future maintenance.
I will be happy to list the address of the new repo on the landing page of PVMismatch. Thanks for everyone's patience and contributions to PVMismatch.

[chetan201]

@mikofski
Is there a new repo under development as per discussion above now? I am happy to add it to the landing page for future users' reference.

[mikofski]

no we haven't done nothin. maybe ask @cwhanse . Too busy, but still want to.

[cwhanse]

Same status as @mikofski but there's hope...I've seen an IV curve simulator with cell-level capabilities coming out of FSEC, that the originator wants to add to pvlib. It could provide the backend for a re-engineering of PVMM>