Cliff Hansen

The v_from_i calculation is where the overflow issues occur in the lambertw scheme. There could certainly be a precision loss there. I also suspect that we can't expect the circle...

@thunderfish24 that's really odd behavior, at one voltage value the residual is 13 orders of magnitude greater than at any other value. Any chance you can fix the text wrapping...

@thunderfish24 I think there's something amiss in your calculation of v_test. In the 8th position you get a value of -0.0888234583382328. Using the existing `pvlib.pvystem.v_from_i` I get a value of...

@pvlib/pvlib-maintainer expect a pull request in the near future from @reepoi that should close this issue. @markcampanelli

If I understand right, the new `schlick` equation quantifies the fraction of beam irradiance that enters the front material at the air/front interface. It would not account for extinction within...

> (Also, github comments [now support mathjax](https://github.blog/2022-05-19-math-support-in-markdown/)!) Nice!

pvsystem.py for this simple model, I think. Code for detailed mismatch calculations would go into singlediode or ivtools.

I have no other comment on this PR. The interface (multiple functions `pvwattsv5_xxx`) feels clumsy but so did the original. I support merging this. For discussion: adding `pvwattsv8_xxx`, `pvwattsv10_xx`, etc....

I'm not saying that there isn't value is adding `pvwattsv8_` etc., only that linearly increasing the number of `pvwatts` functions isn't appealing. And: if `pvwattsv8_dc` is the same as `pvwattsv5_dc`,...

Said differently: we're proposing to promote the `ModelChain` method [_complete_irradiance](https://github.com/pvlib/pvlib-python/blob/bdbaf4c238ce2b373d04af48193b14659662cef1/pvlib/modelchain.py#L1301) to a public function in `pvlib.irradiance`.