-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Use scipy's find_minimum in lambertw for MPP #2567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
What do you think of this approach? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see quite a nice speedup locally (maybe 80% reduction in computation time for pvsystem.singlediode
), nice!
pvlib/singlediode.py
Outdated
if res.success.all(): | ||
v_mp = res.x | ||
p_mp = -1.*res.f_x | ||
else: | ||
use_gs = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am inclined to not include this safety net; if we plan to get rid of the GS function eventually, might as well let any unforeseen issues with the scipy approach bubble to the surface now so that we can address them sooner rather than later.
Or is there reason to expect the scipy function to fail sometimes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't think of a reason for failure other than bad inputs. Because res.success
is a vector, we could pass over to the GS only those index values which failed, for whatever reason. Or skip the success
check altogether and just push v_mp
forward. I worry a little that will forward unconverged, but still numeric, values.
|
||
# Find the voltage, v_mp, where the power is maximized. | ||
# Start the golden section search at v_oc * 1.14 | ||
p_mp, v_mp = _golden_sect_DataFrame(params, 0., v_oc * 1.14, _pwr_optfcn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious... I wonder if anyone knows why 1.14
is the magic number. I see it goes back to the early early days of pvlib-python.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was 1.14 * Voc_ref
, the STC value of Voc. The factor of 1.14 was meant to push the right endpoint out when temperature is lower than STC.
In pvlib, v_oc reflects temperature and irradiance. I included 1.01 * v_oc
in case the algorithm needs to start with a negative value of power at the right endpoint, since it is minimizing negative power. Now that I write this, I don't think that's necessary - it is provable that power has a unique maximum between v=0
and v=v_oc
.
optimize.elementwise
functions #2497docs/sphinx/source/reference
for API changes.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`
).remote-data
) and Milestone are assigned to the Pull Request and linked Issue.Switches to the old golden section if
find_minimum
is not available.Since
find_minimum
replaces the golden mean search, if scipy>=1.15, the current tests seem sufficient.