Single diode model helper function to wrap Lambert w and other methods

[mikofski]

I propose the following:

• Move Lambert w to a separate method
• change existing singlediode method to be a wrapper to methods like Lambert w or bishop88() from ENH: add methods and tests for a explicit IV curve calculation of single-diode model #409, similar to how to get_solarposition() wraps several solar position algorithms

[markcampanelli]

It appears that singlediode() does not expose a way to compute i-from-v at an arbitrary array of v. One would use i_from_v() for that. Also, singlediode() makes a choice for i_from_v(), v_from_i(), and the maximum power computation.

Also, I have vectorized max power and fill factor functions that I think can be very useful for plotting max power and ff as a function of temperature and/or photocurrent, for example.

I think this will first and foremost require some careful thinking about what the current API definition is and what we want it to be going forward with alternative implementations.

[cwhanse]

Guys this is great, by all means press on. When I can get back to my desk I'll contribute, meanwhile I'll just follow the fun from my phone.

…

Sent from my iPhone On Jan 29, 2018, at 4:49 PM, Mark Campanelli <notifications@github.com<mailto:notifications@github.com>> wrote: It appears that singlediode() does not expose a way to compute i-from-v at an arbitrary array of v. One would use i_from_v() for that. Also, singlediode() makes a choice for i_from_v(), v_from_i(), and the maximum power computation. Also, I have vectorized max power and fill factor functions that I think can be very useful for plotting max power and ff as a function of temperature and/or photocurrent, for example. I think this will first and foremost require some careful thinking about what the current API definition is and what we want it to be going forward with alternative implementations. - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#410 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFJNLzHXrvN9cs_hGI88KWWjylUT5Nfbks5tPeh-gaJpZM4RwCs->.

[wholmgren]

Makes sense to me. We can do this without any breaking API changes, right?

[mikofski]

Yes, that's my view - the api will remain the same. Is it okay to make bishop88 and it's related i_from_v, v_from_i, etc. methods the defaults?

[wholmgren]

I need to review the paper and probably see a clean PR before I can recommend a default.

[markcampanelli]

I'd really like to know where pandas support starts and ends in the API. I was told earlier that I didn't need to match output to pandas input in i_from_v() and v_from_i(). I realize folks love pandas, but it's hard enough just wrangling numpy types into some sort of consistency (esp. python scalar vs. numpy scalar vs. dim-0 array vs. dimensioned array)!

[wholmgren]

The rule of thumb is pandas in, pandas out. Beyond that, I'd just say don't remove pandas consistency from functions that do already support it. *_from_* does not, singlediode does.

I'm guessing that most users would consider pandas consistency to be more important than numpy type consistency.

[markcampanelli]

Thanks. I think the i_from_v() and v_from_i() docstrings indicate that pandas.Series are ok inputs, but won't be the output. I propose removing that promise on the inputs and leave it to higher level functions.

[wholmgren]

In general, it's ok with me to remove it as a promise on the inputs of a function if it's not also a promise on the outputs. In most cases I think it's much better to have a feature that only supports numpy than a feature that doesn't exist.

[markcampanelli]

@mikofski Note the above pandas support discussion for #409.

[markcampanelli]

@wholmgren Is numba used in pvlib-python yet? If not, then are there remaining blockers to using it?