Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Dual infeasibility calculated by the CUTEst functions does not coincide with that reported by Ipopt #308

Closed
svigerske opened this issue Jan 29, 2019 · 3 comments
Closed

Dual infeasibility calculated by the CUTEst functions does not coincide with that reported by Ipopt #308

svigerske opened this issue Jan 29, 2019 · 3 comments
Labels
clarification

Comments

@svigerske
Copy link
Member

Issue created by migration from Trac.

Original creator: secchinleo

Original creation time: 2018-08-25 21:29:06

Assignee: ipopt-team

Version: 3.12

I am using Ipopt with default options, except for MA57. Also, I am using the CUTEst interface, which is implemented in Fortran.

In some NETLIB problems, the norm of the gradient of the Lagrangian function obtained through the function "CUTEST_clfg" differs from the dual infeasibility measure reported by Ipopt, specially when the method performs many iterations. For example, in the problem 80BAU3B, both values coincide up to iteration 30, but differ more and more when more iterations are executed. I checked if the internal unscaled multipliers estimates () coincide with those reported by Ipopt, and they are OK. In problem 80BAU3B, the derivative checker failed many times.

In most other NETLIB problems, like 25FV47, everything seems OK.
@svigerske
Copy link
Member Author

Comment by secchinleo created at 2018-09-07 14:15:38

I have identified that the multipliers returned by the main function of Ipopt associated with the bound constraints of fixed variables treated as parameters are wrong. They are set to zero, but should be defined using -grad L.

@svigerske svigerske removed the Ipopt label Jan 29, 2019
@svigerske
Copy link
Member Author

Fixing this would require modifying TNLPAdapter so that it remembers the Jacobian entries corresponding to fixed variables. It may also require reevaluating the Jacobian at the final point to compute the duals for fixed variables.

A workaround should be to set option fixed_variables_treatment to make_constraint.

svigerske added a commit that referenced this issue Apr 20, 2021
@svigerske
add comment on duals of fixed vars to TNLP::finalize_solution
483e4cd 
- ref #308
svigerske added a commit that referenced this issue Apr 21, 2021
@svigerske
compute bound multipliers for fixed variables treated as parameter
d852154 
- extended ResortBoundMultipliers to compute z_L and z_U for fixed
  variables if treatment is make_parameter by evaluating gradient of
  Lagrangian from evaluation of grad_f and jac_g
- added option fixed_variable_treatment=make_parameter_nodual to restore
  original behavior (return 0 for duals of fixed vars)
- extended TNLP::get_curr_iterate to get correct duals also if requesting
  a scaled solution
- extended getcurr test
- fixes #308
@svigerske
Copy link
Member Author

This has been fixed in Ipopt 3.14.
Likely, this causes a call to eval objective gradient and Jacobian, since the entries that correspond to fixed variables are not cached.

If the duals for fixed variables are not required, one can set option fixed_variables_treatment to the new value make_parameter_nodual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clarification
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@svigerske