Calculate IV curve for series-connected devices

[cwhanse]

• Closes #xxxx
• I am familiar with the contributing guidelines
• I attest that all AI-generated material has been vetted for accuracy and is in compliance with the pvlib license
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Uses a simplified reverse bias model (vertical asymptote at breakdown voltage), rather than the differentiable model in the bishop88 functions. The simplified model is used for speed and reliability but comes at the cost of some precision for devices with nearly equal short-circuit currents.

[cwhanse]

This is ready for some feedback. Some questions in my mind:

• I'm not sure about the interface. The new function (intended to be public) takes in single diode equation parameters (output from one of the pvsystem.calcparams_* functions) and returns the series IV curve. It does not anticipate "adding" IV curves represented by arrays of current and voltage.
• I intend to add a maximum power point to that curve; that is not yet done. As it is now, this function acts as an alternative for pvsystem.i_from_v (compute an IV curve). The IV curve is returned (rather than Isc, Imp, Vmp, Voc as are returned by pvsystem. singlediode) because this function is intended to feed the next stage: compute the IV curve for parallel strings.
• I've put this is a new module called mismatch. If that's too general (there's also spectral mismatch) this would be electrical mismatch.

[RDaxini]

I am happy to take a deeper dive into the code later, likely next week if that's not too late. I can share some thoughts in response to at least two these questions first though.

• I'm not sure about the interface. The new function (intended to be public) takes in single diode equation parameters (output from one of the pvsystem.calcparams_* functions) and returns the series IV curve. It does not anticipate "adding" IV curves represented by arrays of current and voltage.

Fair point... I don't have anything insightful to add here at the moment but will try to circle back to it.

• I intend to add a maximum power point to that curve; that is not yet done. As it is now, this function acts as an alternative for pvsystem.i_from_v (compute an IV curve). The IV curve is returned (rather than Isc, Imp, Vmp, Voc as are returned by pvsystem. singlediode) because this function is intended to feed the next stage: compute the IV curve for parallel strings.

I'm not sure I follow... pvsystem.i_from_v is a pointwise solver but I thought that this is a curve constructor, so they seem to be completely different? I might be misunderstanding something here from not having gone into the code yet.

• I've put this is a new module called mismatch. If that's too general (there's also spectral mismatch) this would be electrical mismatch.

-1 to this naming. The generality is one downside but I think the collision with pvlib.spectrum.mismatch is a bigger issue. from pvlib import mismatch vs from pvlib.spectrum import mismatch could be problematic. We might want to consider renaming the spectral mismatch module with a spectral clarifier, but that could be discussed separately. electrical_mismatch suggestion solves this but, another consideration: mismatch is a loss, so is it definitely the right thing to name this module after? How about pvlib.circuit or pvlib.ivcurve? These sound to me more linked to what the module does. Not 100% opposed to electrical_mismatch though and certainly open other suggestions. The two I mentioned are just the first two that came to mind.

[cwhanse]

Having worked in the MPP calculation, I'm inclined to refactor this code to more closely parallel pvsystem.singlediode and pvsystem.i_from_v and pvsystem.v_from_i. The purposes are common:

• for pvsystem.singlediode, solve for Isc, Imp, Voc, Vmp, etc. given arrays of diode equation parameters. Returned values are arrays. It is anticipated that the arrays are time series, resulting from application of pvsystem.calcparams_xxxxx to weather time series.
• for pvsystem.i_from_v (or v_from_i), calculate points (could be many) given arrays of diode equation parameters. Returned values are arrays of voltage (current) corresponding to the input current (voltage). Again, it is anticipated that the array's first dimension is time.

Here, the corresponding functions would be conceptually similar. I'll use mismatch for the module name to describe the idea, although I tend to agree with @RDaxini that's not a good choice.

• mismatch.singlediode takes in arrays of diode equation parameters (output from pvsystem.calcparams_xxxx) and returns arrays of Isc, Voc, etc. The difference from pvsystem.singlediode` is the dimensionality; the photocurrent parameter (for example) should be 2D and have dimensions (number of devices in series, number of times). Output is 1d: Isc is the string Isc, and has dimension (number of times).
• mismatch.v_from_i takes in an array of string current (1d) and arrays of device parameters (2d), and returns an array of string voltage (1d).

I hope this is a more clear picture.