Skip to content

Conversation

cwhanse
Copy link
Member

@cwhanse cwhanse commented Oct 3, 2025

  • Closes Use scipy's new optimize.elementwise functions #2497
  • I am familiar with the contributing guidelines
  • 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.

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.

@cwhanse
Copy link
Member Author

cwhanse commented Oct 3, 2025

What do you think of this approach?

Copy link
Member

@kandersolar kandersolar left a 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!

Comment on lines 927 to 931
if res.success.all():
v_mp = res.x
p_mp = -1.*res.f_x
else:
use_gs = True
Copy link
Member

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?

Copy link
Member Author

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)
Copy link
Member

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.

Copy link
Member Author

@cwhanse cwhanse Oct 3, 2025

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.

@cwhanse cwhanse marked this pull request as ready for review October 3, 2025 21:15
@cwhanse cwhanse added this to the v0.13.2 milestone Oct 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use scipy's new optimize.elementwise functions
2 participants