Ideal PV devices are not supported

[markcampanelli]

One cannot define resistance_series = 0 or resistance_shunt = numpy.inf as "ideal" device parameters in pvlib.pvsystem.singlediode(). See the error below for example.

Is this feature valued enough for me to make a PR that adds this capability?

Input:

import sys
print("Python version: %s.%s.%s" % sys.version_info[:3])

import numpy as np
print("Numpy version: " + np.version.version)

import scipy as sp
print("Scipy version: " + sp.version.version)

import pvlib

i_ph_A = 2.13643772
i_rs_A = 2.10905501e-05
n_mod_V = 9.91331584
r_s_Ohm = 3.63866316
r_s_Ohm = 0.
g_p_Mho = 2.45880685e-03

pvlib.pvsystem.singlediode(i_ph_A, i_rs_A, r_s_Ohm, 1./g_p_Mho, n_mod_V)

with output:

Python version: 3.6.1
Numpy version: 1.12.1
Scipy version: 0.19.0
/Users/markcampanelli/anaconda3/lib/python3.6/site-packages/pvlib/pvsystem.py:1943: RuntimeWarning: divide by zero encountered in true_divide
  I = -V/(Rs + Rsh) - (nNsVth/Rs)*lambertwterm + Rsh*(IL + I0)/(Rs + Rsh)
/Users/markcampanelli/anaconda3/lib/python3.6/site-packages/pvlib/pvsystem.py:1943: RuntimeWarning: invalid value encountered in double_scalars
  I = -V/(Rs + Rsh) - (nNsVth/Rs)*lambertwterm + Rsh*(IL + I0)/(Rs + Rsh)
Out[1]:
OrderedDict([('i_sc', nan),
             ('v_oc', 112.87971015555131),
             ('i_mp', nan),
             ('v_mp', 0.02227117920245893),
             ('p_mp', nan),
             ('i_x', nan),
             ('i_xx', nan)])

[markcampanelli]

Update: Sufficiently large values of resistance_shunt cause numerical issues as well. I'm not sure about the computational overhead to detect large Rsh issues and then possibly swap in the infinite shunt resistance approximation as appropriate.

Very small, yet strictly positive, resistance_series values seem to be better behaved in pvlib.pvsystem.singlediode(), which appears to rely heavily on pvlib.pvsystem.i_from_v(). I have not explored the "edge" behavior of pvlib.pvsystem.v_from_i(), but that is apparently called in pvlib.pvsystem.singlediode() to get Voc.

My concern here is that sometimes parameter fitting routines return resistance values that are at/near these edge cases.

[cwhanse]

I support these additions. Perhaps we set a threshold above which Rsh is considered as Inf. Mark can you post a set of parameters which give trouble with high Rsh?

…

Sent from my iPhone On May 10, 2017, at 7:02 PM, Mark Campanelli <[email protected]<mailto:[email protected]>> wrote: Update: Sufficiently large values of resistance_shunt cause numerical issues as well. I'm not sure about the computational overhead to detect large Rsh issues and then possibly swap in the infinite shunt resistance approximation as appropriate. Very small, yet strictly positive, resistance_series values seem to be better behaved in pvlib.pvsystem.singlediode(), which appears to rely heavily on pvlib.pvsystem.i_from_v(). I have not explored the "edge" behavior of pvlib.pvsystem.v_from_i(), but that is apparently called in pvlib.pvsystem.singlediode() to get Voc. My concern here is that sometimes parameter fitting routines return resistance values that are at/near these edge cases. - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#324 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFJNL7gVnfi7t6TUEU-2fNFzLUABd_3rks5r4l4dgaJpZM4NXYRV>.

[adriesse]

Solving the single diode equation is a lot easier when there is an infinite shunt resistance. I would suggest implementing a simpler solver to handle that case, if the general solver has trouble.

[wholmgren]

I agree this would be a useful feature. A threshold seems reasonable.

Also relevant: #298, #268, #266, #260. We're waiting on a test case for #298.

[markcampanelli]

In my own code I compute the explicit ideal model first (depends on I_from_V vs. V_from_I case), then replace values at those indices that produce a lower absolute residual for the implicitly computed model. It is perhaps not the most efficient, but it does not require arbitrary thresholds. I would provide benchmarking if I pursued that path for this PR. Will: Thanks for the other issue references. Hope to review soonish. Cliff: I think Rsh=1.e10 in the previous dataset should generate an exp overflow in the Voc computation. However, the function seems to still return reasonable values.

[markcampanelli]

I haven't forgotten about this. I think I may have a new solution here that covers both the typical and edge cases cleanly, efficiently, flexibly with respect to various input dimensions, and with surprisingly little code (leveraging numpy's ufunc's). My only question is how well the new algorithm converges for devices with very high series resistance (in the current computation given voltage) and/or low shunt resistance (in the voltage computation given current).

At the risk of appearing lazy here, can anyone point me to the specific unit tests around computing I-V curves?

[wholmgren]

These are probably the most relevant:

https://github.com/pvlib/pvlib-python/blob/master/pvlib/test/test_pvsystem.py#L357-L379

There are some other tests in test_pvsystem.py that calculate these parameters, but they don't push the algorithm to its limits.

[markcampanelli]

@wholmgren Thanks for the unit test ref's. I need some guidance on how to set up my local fork to allow me to run unit tests with pytest. Currently, I use pip to do a re-install of my local fork before I can run the unit tests against any code change using pytest pvlib/test/test_pvsystem.py from the root of my fork. This is far from ideal. How do I run unit tests when pvlib-python is not pip installed?

[wholmgren]

Just to confirm: you ran pip install -e . from your cloned pvlib-python directory? As far as I know, that's the right thing to do. If you want to separate a clean pvlib from your development pvlib, then you probably should use conda environments or python's own virtual environments. I could have misunderstood something, though.

[markcampanelli]

Yeah, it looks like I missed the -e part. I will give that a try. Thanks yet again.

[markcampanelli]

@wholmgren pvlib.pvsystem.i_from_v() indicates that it returns "current : np.array". However, test_i_from_v() takes python scalars as input arguments and returns a numpy.float64, not a numpy.ndarray. Is numpy.float64 considered a subtype of np.array? More generally, what is the difference between numpy.array and numpy.ndarray?

[wholmgren]

The numpy array type is ndarray, not array. The array function creates ndarray objects. So, the i_from_v docstring should read "current: np.ndarray or np.float64"

numpy.float64 is not a subtype of np.ndarray:

>>> isinstance(np.float64(5), np.ndarray)
False

[markcampanelli]

Thanks for clarifying. These types behave a bit strange under the simplest of operations:

print(type(np.array(1.)))
print(type(np.array(1.) + np.array(1.)))

returns

<class 'numpy.ndarray'>
<class 'numpy.float64'>

[wholmgren]

Yeah, I've never fully understood the type or broadcasting rules for numpy scalar or scalar-like arrays. The important thing for our function is that if you put scalars in, you get a scalar-like thing out, and if you put arrays in, you get arrays out. Other pvlib functions also guarantee that if you put a Series in, you get a series out, but this one does not.

[markcampanelli]

Draft PR created: #340