MadNLP stucks at an iteration

[vinhpb]

Hi,
When I try the following problem, MadNLP stucks at an iteration without giving an exit, while Ipopt works fine (within 1 second giving an exit of "Converged to a point of local infeasibility", which is correct). Could you guys help me take a look at it? Thanks.

using JuMP, Ipopt

model = Model(MadNLP.Optimizer)
@variable(model, Tc_out[1:2])
@variable(model, T)
@variable(model, Th_out[1:2])
@variable(model, 0<= u[1:2] <= 1, start = 0.5)
    
@NLparameter(model, Tc_in == 41.0)
@NLparameter(model, wc == 97.0)
@NLparameter(model, Th_in[1:2] == 105.0)
set_value(Th_in[2], 206.0)
@NLparameter(model, wh[1:2] == 118.0)
set_value(wh[2], 94.0)
@NLparameter(model, UA[1:2] == 240.0)
set_value(UA[2], 502.0)

@NLobjective(model, Max, 1)
@NLconstraint(model, Tc_outL[i = 1:2], Tc_out[i] >= Tc_in)
@NLconstraint(model, Tc_outH[i = 1:2], Tc_out[i] <= Th_in[i])
@NLconstraint(model, Th_outL[i = 1:2], Th_out[i] >= Tc_in)
@NLconstraint(model, Th_outH[i = 1:2], Th_out[i] <= Th_in[i])
@NLconstraint(model, HTrans[i = 1:2], -1*Tc_out[i] + Tc_in + UA[i]*((Th_in[i]-Tc_out[i])*(Th_out[i]-Tc_in)*0.5*(Th_in[i]-Tc_out[i]+Th_out[i]-Tc_in))^(1/3)/(u[i]*wc*4.2) == 0)
@NLconstraint(model, ECon_cold, -1*T + Tc_out[1]*u[1] + Tc_out[2]*u[2] == 0)
@NLconstraint(model, ECon_HX[i = 1:2], (-1*Th_out[i] + Th_in[i])*wh[i] - (Tc_out[i] - Tc_in)*wc*u[i] == 0)
@NLconstraint(model, MCon, u[1]+u[2] -1 == 0)
@NLconstraint(model, Th_in[2] + Th_in[2] == 0)

set_start_value(model[:Tc_out][1], (41 + 105)*0.5)
set_start_value(model[:Tc_out][2], (41 + 206)*0.5)
set_start_value(model[:T], (2*41 + 105 + 206)*0.25)
set_start_value(model[:Th_out][1], (41 + 105)*0.5)
set_start_value(model[:Th_out][2], (41 + 206)*0.5)

optimize!(model)

[frapac]

Thank you for reporting this. This is a bug inside MadNLP, we are entering into an infinite loop in the final restoration phase:
https://github.com/MadNLP/MadNLP.jl/blob/master/src/IPM/solver.jl#L534-L545
We cannot satisfy the stopping criterion RR.mu_R != solver.opt.mu_min*100 (mu_min=1e-11) because in get_mu we ensure that RR.mu_R >= 10 * opt.tol, with opt.tol = 1e-8. So in the end we get stuck with RR.mu_R = 1e-9 different than the stopping criterion RR.mu_R != 1e-9 because of numerical precision issue (tol/10 is different than 0.01 * tol)...

[frapac]

Solved by #244