# The constraints appear to have not taken effect

I found problems when using IPOPT to solve my optimization problem. The result I obtained isn’t a feasible solution. Even after attempting to alter some parameters, the obtained solution remains infeasible. Hence, I am considering whether the constraints I have written are unable to convey my true intent to AMPL. The formulation of my optimization problem and the model code I have written are as follow:

``````##ExampleTwo
#set Nodes {1..2001};
#set Dimension {1..2};

param N := 2000;
param M := 100;
param delta := 0.2;
param Hight := 50;
param Vmax := 100;
param Vmin := 3;
param amax := 5;
param B := 500000;
param N0 := 1*10^(-17);
param sigma2 := 1*10^(-11);
param P := 10;
param beta0_1 := 3.23461517152694*10^(-5);
param beta0_2 := 1.20564246274771*10^(-5);
param beta0_3 := 3.53583092353553*10^(-5);
param beta0_4 := 1.90906735010188*10^(-5);

var ita; # variable for DF relay system
var q {1..2,1..N+1};
var v {1..2,1..N+1};
var a {1..2,1..N};
var m_1 {1..N+1} >=0, <=M integer; # blocklength for user 1  integer
var m_2 {1..N+1} >=0, <=M integer; # blocklength for user 2  integer
var m_3 {1..N+1} >=0, <=M integer; # blocklength for user 3  integer
var m_4 {1..N+1} >=0, <=M integer; # blocklength for user 4  integer

let {i in 1..N+1} m_1[i] := 0.25*M;
let {i in 1..N+1} m_2[i] := 0.25*M;
let {i in 1..N+1} m_3[i] := 0.25*M;
let {i in 1..N+1} m_4[i] := 0.25*M;
let {i in 1..2, j in 1..N} a[i,j] := 0.00001;
let {j in 2..N} v[1,j] := 0.497878679656440;
let {j in 2..N} v[2,j] := -0.497878679656440;
let {j in 2..N} q[1,j] := 0+21.2132034355964*0.2+0.497878679656440*(j-1);
let {j in 2..N} q[1,j] := 1000-21.2132034355964*0.2-0.497878679656440*(j-1);

maximize OBJ:ita;
subject to DFconstraint_1: sum{i in 1..N+1} (3*B*((1/log(2))*log(1+(P*beta0_1/sigma2)/((q[1,i])^2+(q[2,i])^2+Hight^2))-sqrt(1/m_1[i])*5.6120))>=ita;
subject to DFconstraint_2: sum{i in 1..N+1} (B*((1/log(2))*log(1+(P*beta0_2/sigma2)/((q[1,i]-600)^2+(q[2,i]-460)^2+Hight^2))-sqrt(1/m_2[i])*5.6120)+
B*((1/log(2))*log(1+(P*beta0_3/sigma2)/((q[1,i]-460)^2+(q[2,i]-600)^2+Hight^2))-sqrt(1/m_3[i])*5.6120)+
B*((1/log(2))*log(1+(P*beta0_4/sigma2)/((q[1,i]-160)^2+(q[2,i]-160)^2+Hight^2))-sqrt(1/m_4[i])*5.6120))>=ita;
subject to BOUNDconstraint_1: sum{i in 1..N+1} (B*((1/log(2))*log(1+(P*beta0_2/sigma2)/((q[1,i]-600)^2+(q[2,i]-460)^2+Hight^2))-sqrt(1/m_2[i])*5.6120))>=ita/4;
subject to BOUNDconstraint_2: sum{i in 1..N+1} (B*((1/log(2))*log(1+(P*beta0_3/sigma2)/((q[1,i]-460)^2+(q[2,i]-600)^2+Hight^2))-sqrt(1/m_3[i])*5.6120))>=ita/4;
subject to BOUNDconstraint_3: sum{i in 1..N+1} (B*((1/log(2))*log(1+(P*beta0_4/sigma2)/((q[1,i]-160)^2+(q[2,i]-160)^2+Hight^2))-sqrt(1/m_4[i])*5.6120))>=ita/4;
subject to InitialVelocity_1: v [1,1] = 21.2132034355964;
subject to InitialVelocity_2: v [2,1] = -21.2132034355964;
subject to FinalVelocity_1: v [1,N+1] = 21.2132034355964;
subject to FinalVelocity_2: v [2,N+1] = -21.2132034355964;
subject to InitialLocation_1: q [1,1] = 0;
subject to InitialLocation_2: q [2,1] = 1000;
subject to FinalLocation_1: q [1,N+1] = 1000;
subject to FinalLocation_2: q [2,N+1] = 0;
subject to TaylorRelation_11 {i in 1..N}:q[1,i+1] = q[1,i]+v[1,i]*delta+a[1,i]*0.5*delta^2;
subject to TaylorRelation_12 {i in 1..N}:q[2,i+1] = q[2,i]+v[2,i]*delta+a[2,i]*0.5*delta^2;
subject to TaylorRelation_21 {i in 1..N}:v[1,i+1] = v[1,i]+a[1,i]*delta;
subject to TaylorRelation_22 {i in 1..N}:v[2,i+1] = v[2,i]+a[2,i]*delta;
subject to MaximumVelocity {i in 1..N+1}:sqrt(v[1,i]^2+v[2,i]^2) <= Vmax;
subject to MinimumVelocity {i in 1..N+1}:sqrt(v[1,i]^2+v[2,i]^2) >= Vmin;
subject to MaximumAcceleration {i in 1..N}:sqrt(a[1,i]^2+a[2,i]^2) <= amax;
subject to SUMlimit {i in 1..N+1}: m_1[i]+m_2[i]+m_3[i]+m_4[i] <= M;
``````

Below are the results of the variable ‘q,’ and it is evident that it does not comply with TaylorRelation_11.

I look forward to receiving some suggestions from someone; your assistance is greatly appreciated.

I tried running your model using Ipopt, but the log listing showed that Ipopt never found a feasible solution. (Eventually I aborted the run.) You may have chosen different options, however. Can you post the entire Ipopt listing? Preferably copy the whole listing, then paste it into a file and upload the file to this forum.

Also I noticed that `q[1,j]` is initialized twice:

``````let {j in 2..N} q[1,j] := 0+21.2132034355964*0.2+0.497878679656440*(j-1);
let {j in 2..N} q[1,j] := 1000-21.2132034355964*0.2-0.497878679656440*(j-1);
``````

Is the second statement supposed to be initializing `q[2,j]`?

Thanks for your reply. I have corrected the error related to repeated initialization, but I am still unable to obtain feasible results. Below is my code file (My apologies, I couldn’t directly upload .mlx files, so I placed it in a compressed archive along with the .mod file.). Thank you for your assistance, and I look forward to receiving further recommendations.
AMPL_test.zip (16.0 KB)

Even with your correction, Ipopt fails to make any progress on this problem. You can see this in the iteration log, which reports measures of primal infeasibility (inf_pr) and dual infeasibility (inf_du) at each iterate:

``````iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
0 -0.0000000e+00 2.07e+01 1.46e+00  -1.0 0.00e+00    -  0.00e+00 0.00e+00   0
1 -6.0897207e-02 2.07e+01 3.45e+01  -1.0 4.45e+02  -2.0 1.11e-03 6.08e-04f  4
2 -2.7418726e+07 2.07e+01 3.48e+01  -1.0 2.45e+13    -  7.19e-07 1.12e-06f  1
3 -2.7418726e+07 2.00e+01 3.50e+01  -1.0 8.16e+01  -0.7 2.76e-03 3.16e-02f  1
4 -2.7418726e+07 1.97e+01 3.45e+01  -1.0 6.70e+01  -1.1 3.69e-02 1.63e-02f  1
5 -2.7418726e+07 1.92e+01 3.38e+01  -1.0 3.63e+01  -0.7 4.11e-02 2.74e-02f  1
6 -2.7418728e+07 1.70e+01 3.02e+01  -1.0 2.89e+01  -1.2 3.31e-02 1.13e-01f  1
7 -2.7418732e+07 1.55e+01 2.75e+01  -1.0 4.75e+01  -1.7 7.67e-02 8.96e-02f  1
``````

If the iterates are approaching an optimal solution, both of these measures will converge toward zero. But after 300 iterations, there is no sign of convergence:

``````iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
300r-1.0198004e+10 7.83e+03 4.02e+04   6.8 7.97e+09    -  8.42e-02 8.70e-04f  1
301 -1.1149636e+10 9.71e+03 2.19e+00  -1.0 2.18e+13    -  1.73e-03 4.37e-05f  6
302 -1.1149636e+10 9.70e+03 1.55e+12  -1.0 3.63e+05   9.5 2.35e-01 1.42e-03h  1
303 -1.1149636e+10 9.70e+03 1.55e+12  -1.0 3.62e+05   9.0 2.84e-01 1.42e-05h  1
304r-1.1149636e+10 9.70e+03 1.00e+03   7.1 0.00e+00   8.5 0.00e+00 2.83e-07R  3
305r-1.1149632e+10 9.70e+03 4.25e+04   7.1 9.38e+09    -  6.08e-02 1.12e-03f  1
306 -1.2448545e+10 5.27e+08 2.16e+00  -1.0 1.49e+13    -  1.73e-03 8.74e-05f  5
307 -1.2448545e+10 5.23e+08 1.33e+11  -1.0 5.49e+05   8.0 2.55e-01 2.16e-03h  1
308 -1.2448545e+10 5.23e+08 1.33e+11  -1.0 5.48e+05   7.6 2.96e-01 2.17e-05h  1
309r-1.2448545e+10 5.23e+08 1.00e+03   7.1 0.00e+00   7.1 0.00e+00 2.82e-07R  6
``````

At the 300 second time limit, the solution still has a large primal infeasibility (“Constraint violation”) and dual infeasibility:

``````iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
1250r-1.5777952e+10 3.19e+09 1.54e+03   1.0 2.42e+02   0.7 1.94e-02 1.03e-02f  1
1251r-1.5777952e+10 3.19e+09 1.49e+03   1.0 9.06e+01   1.1 1.26e-03 1.43e-02f  1

Number of Iterations....: 1251
(scaled)                 (unscaled)
Objective...............:  -1.5777952148725967e+10   -1.5777952148725967e+10
Dual infeasibility......:   1.4833298516575230e+03    1.4833298516575230e+03
Constraint violation....:   1.8045571158670068e+07    3.1946253515459814e+09
Complementarity.........:   4.4258234085845373e+01    4.4258234085845373e+01
Overall NLP error.......:   1.8045571158670068e+07    3.1946253515459814e+09
``````

So, although the final iterate is returned to AMPL, it is not a feasible solution that you can use.

Here are some thoughts on what might be the problem here, and what you might do:

1. If you can specify some reasonable lower and upper bounds on variables q, v, and q, that might help to prevent Ipopt from stepping into irrelevant parts of the search space.

2. Since Ipopt cannot handle integrality restrictions on variables, it is ignoring “integer” in its definition of m_1; it is only requiring 0 <= m_1[i] <= M. The same is true for m_2, m_3, and m_4.

3. The expression 1/m_1[i] in the objective goes to infinity as m_1[i] approaches zero. To avoid trouble that this might cause for the solver, m_1[i] should have a positive lower bound. Similar comments can be made about m_2, m_3, and m_4.

4. I tried solving with Knitro, using its interior-point solver which takes an approach like the one in Ipopt. It also could not find a feasible solution. This suggests that there could be an error in your model, that it causing it to actually have no feasible solution. There is no simple and general way to deal with an error like this; you may need to study the application and the model for a while before you can understand the cause of the infeasibility. It is possible to suggest some good ways to get started, however:

• As an initial troubleshooting step, it is often helpful to use AMPL’s expand command to see whether AMPL generated the constraints that you expected. By itself, expand; shows all of the constraints. If there are many of them, you can use, for example, expand C1; to expand all of the constraints that have a particular name. Also you can write, for instance, expand >listing.txt; or expand C1 >listing.txt; to send all of the output to the file listing.txt.

• You should also consider using AMPL’s drop and restore commands to narrow your search for the cause of the infeasibility. If you drop some constraints and the resulting problem is still infeasible, then you don’t need to consider the dropped constraints in looking for the cause of infeasibility. By trying a series of drops, you may be able to determine that infeasibility is being caused by only a small subset of the constraints.

Thank you very much for your reply. After I removed a couple of constraints, I found that IPOPT could eventually converge, but solving the problem once was also very slow. Can I assume that IPOPT is not a good solution for my problem? Do you have any recommendations on solvers to use for my problem? Looking forward to your reply.

Ipopt is a local nonlinear solver, which is the fastest kind of solver for nonlinear problems (but is only guaranteed to find locally optimal solutions). Maybe other solvers of this kind would be faster, though it is also possible that you have a hard problem that is going to be slow for any solver.

Ipopt is the only free local nonlinear solver that we currently recommend. However, there are other ones that you can try out, even though they are not free, by using the free NEOS Server or one of our free trial options. These ones include CONOPT, Knitro, LOQO, MINOS, and SNOPT. They use a variety of different methods, so one of them might happen to work better than Ipopt on your problem; but the only way to tell is to run some tests and see which is best.

Here are two other details to note:

• Unlike the other solvers listed, Knitro tries to find integer values for variables defined as `integer` or `binary`. That will make it run longer; to make it comparable to the other solvers, you can set `option` `relax_integrality` `1;` in AMPL before solving. Also Knitro implements more than one different method — see “alg” in the list of Knitro options.

• A constraint like `sqrt(v[1,i]^2+v[2,i]^2)<=Vmax` can be made into a quadratic constraint by squaring both sides. The quadratic constraint might be much easier for the solvers. And if you can write all your constraints to be linear or quadratic, then you might be able to use some of the linear-quadratic solvers such as CBC, CPLEX, Gurobi, HiGHS, Mosek, SCIP, and Xpress.