Skip to content

Conversation

@kanekosh
Copy link
Contributor

@kanekosh kanekosh commented Dec 8, 2025

Purpose

This PR fixes a bug in the IPOPT wrapper #459 introduced. Closes #469 .

I messed up with the variable scaling in the previous PR and overlooked it because we didn't have an IPOPT test with scaling. Now I modified one of the HS071 tests to run IPOPT with scaling, which would've caught this bug.

Expected time until merged

Urgent (and should make a patch release)

Type of change

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (non-backwards-compatible fix or feature)
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no API changes)
  • Documentation update
  • Maintenance update
  • Other (please describe)

Testing

Checklist

  • I have run ruff check and ruff format to make sure the Python code adheres to PEP-8 and is consistently formatted
  • I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
  • I have run unit and regression tests which pass locally with my changes
  • I have added new tests that prove my fix is effective or that my feature works
  • I have added necessary documentation

@kanekosh kanekosh requested a review from a team as a code owner December 8, 2025 21:27
@codecov
Copy link

codecov bot commented Dec 8, 2025

Codecov Report

❌ Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.69%. Comparing base (647fc06) to head (8405e38).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
pyoptsparse/pyIPOPT/pyIPOPT.py 66.66% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #470      +/-   ##
==========================================
- Coverage   86.73%   86.69%   -0.05%     
==========================================
  Files          24       24              
  Lines        3460     3464       +4     
==========================================
+ Hits         3001     3003       +2     
- Misses        459      461       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@kanekosh kanekosh requested a review from ewu63 December 8, 2025 23:31
@ewu63 ewu63 requested a review from marcomangano as a code owner December 11, 2025 01:54
ewu63
ewu63 previously approved these changes Dec 11, 2025
Copy link
Collaborator

@ewu63 ewu63 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

# IPOPT calls objective and constraints separately, so we find two call counters and append iter_dict to both counters.
call_counter_1 = self.hist._searchCallCounter(self.cache["x"])
call_counter_2 = self.hist._searchCallCounter(self.cache["x"], last=call_counter_1 - 1)
call_counter_1 = self.hist._searchCallCounter(self.optProb._mapXtoUser(self.cache["x"]))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I wonder if we should have some checks in case even with scaling we fail to find the call counter. In such cases we should be able to continue gracefully without raising errors

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if from a user perspective it would be better to continue with a warning or exit, but I agree we should probably add a check (try/except?) to make the error more understandable?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should exit, I think the correct behaviour is to potentially warn, and then continue without saving these additional variables. I don't think an issue in saving some extra parameters during the optimization should kill the optimization,. it is very important that we continue the optimization loop wherever possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified here to keep going if the matching call counter cannot be found and print a warning.

@ewu63 ewu63 merged commit c9c8c9d into main Dec 12, 2025
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Updated IPOPT wrapper fails when call_counter_1 is None

4 participants