Gurobi - Infeasible Irreducible Solution: Non-Linearity might be the problem?

[Friedrich, Pascal]

Dear AMPL community,

Dear Robert,

I am trying to run my model, which has the objective to find the optimal shipping box dimensions (height, length, width) for a certain amount of items of an order.

Given are the amount of items and its dimensions, which have to fit inside the shipping packaging.

Anyhow, besides this goal I have not found a feasible solution yet, due to following feedback of AMPL:

Gurobi 9.5.1: iisfind=1

Gurobi 9.5.1: infeasible

Returning an IIS of 7 constraints and 5 variables.

241 simplex iterations

1 branch-and-cut nodes

No primal variables returned.

suffix iis symbolic OUT;

When I found Robert's recommendations in AMPL of, how to handle non-feasible models, I utilized them is this is my progress so far:

First used the commands:

ampl: display {i in 1.._ncons: _con[i].iis <> 'non'} (_conname[i],_con[i].iis);

:                 _conname[i]              _con[i].iis    :=

1    include_all_items                       mem

8    'box_orientation_constraint_2[2]'       mem

12   "box_orientation_constraint_3[1,'X']"   mem

17   "box_orientation_constraint_3[2,'Z']"   mem

22   "box_orientation_constraint_3[4,'Y']"   mem

93   "box_format_1['X']"                     mem

98   "box_format_2['Z']"                     mem

;

ampl: display {j in 1.._nvars: _var[j].iis <> 'non'} (_varname[j],_var[j].iis);

:             _varname[j]          _var[j].iis    :=

1    "var_Dim['X']"                  low

79   "var_allocation_point['X',1]"   low

83   "var_allocation_point['X',5]"   low

86   "var_allocation_point['Y',3]"   low

87   "var_allocation_point['Y',4]"   low

;

To specify the possible error's location through gurobi's IIS feature.

I checked what values AMPL would insert in the problematic constraints:

ampl: for {i in 1.._ncons: _con[i].iis <> 'non'} expand _con[i];

subject to include_all_items:

var_item_orientation['X',1,1] + var_item_orientation['X',1,2] +

var_item_orientation['X',1,3] + var_item_orientation['X',1,4] +

var_item_orientation['X',1,5] + var_item_orientation['Y',1,1] +

var_item_orientation['Y',1,2] + var_item_orientation['Y',1,3] +

var_item_orientation['Y',1,4] + var_item_orientation['Y',1,5] +

var_item_orientation['Z',1,1] + var_item_orientation['Z',1,2] +

var_item_orientation['Z',1,3] + var_item_orientation['Z',1,4] +

var_item_orientation['Z',1,5] = 5;

subject to box_orientation_constraint_2[2]:

-var_item_orientation['X',1,2] + var_item_orientation['X',2,2] -

var_item_orientation['Y',1,2] + var_item_orientation['Y',2,2] -

var_item_orientation['Z',1,2] + var_item_orientation['Z',2,2] = 0;

subject to box_orientation_constraint_3[1,'X']:

var_item_orientation['X',2,1] + var_item_orientation['X',3,1] -

var_item_orientation['Y',1,1] - var_item_orientation['Z',1,1] = 0;

subject to box_orientation_constraint_3[2,'Z']:

-var_item_orientation['X',1,2] - var_item_orientation['Y',1,2] +

var_item_orientation['Z',2,2] + var_item_orientation['Z',3,2] = 0;

subject to box_orientation_constraint_3[4,'Y']:

-var_item_orientation['X',1,4] + var_item_orientation['Y',2,4] +

var_item_orientation['Y',3,4] - var_item_orientation['Z',1,4] = 0;

subject to box_format_1['X']:

0.5*var_Dim['X'] - var_Dim['Y'] >= 0;

subject to box_format_2['Z']:

var_Dim['X'] - var_Dim['Y'] <= 0;

But also this seem to look fine according to my understanding.

Then I checked if a constraint that seem to have a huge impact on the complete model was the issue:

ampl: expand box_orientation_constraint_1;

subject to box_orientation_constraint_1[1]:

var_item_orientation['X',1,1] + var_item_orientation['Y',1,1] +

var_item_orientation['Z',1,1] <= 1;

subject to box_orientation_constraint_1[2]:

var_item_orientation['X',1,2] + var_item_orientation['Y',1,2] +

var_item_orientation['Z',1,2] <= 1;

subject to box_orientation_constraint_1[3]:

var_item_orientation['X',1,3] + var_item_orientation['Y',1,3] +

var_item_orientation['Z',1,3] <= 1;

subject to box_orientation_constraint_1[4]:

var_item_orientation['X',1,4] + var_item_orientation['Y',1,4] +

var_item_orientation['Z',1,4] <= 1;

subject to box_orientation_constraint_1[5]:

var_item_orientation['X',1,5] + var_item_orientation['Y',1,5] +

var_item_orientation['Z',1,5] <= 1;

But also here AMPL allocated the correct values to each variable.

I still believed that the variable var_item_orientation was the potential cause, so I used the expand command on it:

mpl: expand var_item_orientation['X',1,1];

Coefficients of var_item_orientation['X',1,1]:

include_all_items                     1

box_orientation_constraint_1[1]       1

box_orientation_constraint_2[1]      -1

box_orientation_constraint_3[1,'Y']  -1

box_orientation_constraint_3[1,'Z']  -1

containtment_condition_1[1,'X']      90

containtment_condition_2[1,'X']       0 + nonlinear

non_overlapping_condition_1[2,'X']   90

non_overlapping_condition_2[2,'X']    0 + nonlinear

non_overlapping_condition_3[2]       -1

non_overlapping_condition_5[2]        1

Now I believe, that I have found the problem of my model, which is non-linearity, since I multiply in line 80 the objective variable (var_Dim) and another contributing variable (var_item_orientation).

Am I right with my guess, is this the cause of my model?

If so, can I use a non-linear solver to find a solution or is there a way to convert an non-linear equation into a linear one? Could you please describe me how to convert it?

Thank you very much ahead and a lot for your time!

This thing is time critical, but I am still not able to find the right solution to my problem, maybe I am impatient or maybe unmindful...whatever it is, please help me.

Beste Grüße,

Best regards,

Pascal Friedrich

Master student in Global Logistics and Supply Chain Management 

Kühne Logistics University - Hamburg

https://www.the-klu.org

[Friedrich, Pascal]

Gurobi - Infeasible Irreducible Solution: Non-Linearity might be the problem?

this is the model to the above related subject.

Beste Grüße,

Best regards,

Pascal Friedrich

Master student in Global Logistics and Supply Chain Management 

Kühne Logistics University - Hamburg

https://www.the-klu.org

---

Von: Friedrich, Pascal
Gesendet: Donnerstag, 30. Juni 2022 17:54
An: am...@googlegroups.com <am...@googlegroups.com>
Betreff: Gurobi - Infeasible Irreducible Solution: Non-Linearity might be the problem?

 

[AMPL Google Group]

Since var_item_orientation is a binary variable, Gurobi can convert var_Dim [A] * var_item_orientation [A,a,i] to an equivalent linear formulation. However, I agree that the IIS does not look quite right; possibly it is not reported correctly when there is a quadratic term.

You could do the conversion from the quadratic expression to the equivalent linear formulation yourself, in the AMPL model. Then you would have a linear model, and the IIS listing should be more reliable. Instructions for doing the conversion are given, for example, at

https://orinanobworld.blogspot.com/2010/10/binary-variables-and-quadratic-terms.html

--
Robert Fourer
am...@googlegroups.com

{#HS:1937074895-110788#}

On Fri, Jul 1, 2022 at 8:58 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Gurobi - Infeasible Irreducible Solution: Non-Linearity might be the problem?

this is the model to the above related subject.

Beste Grüße,
Best regards,

Pascal Friedrich

Master student in Global Logistics and Supply Chain Management
Kühne Logistics University - Hamburg
https://www.the-klu.org

[Pascal Friedrich]

Dear Robert,

thank you very much.

The conversion to a linear formulation has been done.

I still have some troubles, but will try to figure them out by myself for now.

In case of cases, I might reply again. :)

Pascal

[Pascal Friedrich]

Dear Robert,

Thank you for your help, my model is feasible now!

It doesnot output the desired result, but this will come.

I have a more general question:

It seems like AMPL is ignoring one of my constraints or I am missunderstanding AMPL's output.

I have two constraints that should limit each other to only produce certain values.

Constraint 1: 

var_item_orientation[A,a,i] is a binary variable

include_all_items: sum {i in ITEMS} sum {A in AXIS_CONTAINER} sum {a in AXIS_ITEM} var_item_orientation[A,a,i] = 15;

....looks like this...

ampl: expand include_all_items;

subject to include_all_items:
    var_item_orientation['X',1,1] + var_item_orientation['X',1,2] +
    var_item_orientation['X',1,3] + var_item_orientation['X',1,4] +

    var_item_orientation['X',1,5] + var_item_orientation['X',2,1] +
    var_item_orientation['X',2,2] + var_item_orientation['X',2,3] +
    var_item_orientation['X',2,4] + var_item_orientation['X',2,5] +
    var_item_orientation['X',3,1] + var_item_orientation['X',3,2] +
    var_item_orientation['X',3,3] + var_item_orientation['X',3,4] +
    var_item_orientation['X',3,5] + var_item_orientation['Y',1,1] +

    var_item_orientation['Y',1,2] + var_item_orientation['Y',1,3] +
    var_item_orientation['Y',1,4] + var_item_orientation['Y',1,5] +

    var_item_orientation['Y',2,1] + var_item_orientation['Y',2,2] +
    var_item_orientation['Y',2,3] + var_item_orientation['Y',2,4] +
    var_item_orientation['Y',2,5] + var_item_orientation['Y',3,1] +
    var_item_orientation['Y',3,2] + var_item_orientation['Y',3,3] +
    var_item_orientation['Y',3,4] + var_item_orientation['Y',3,5] +

    var_item_orientation['Z',1,1] + var_item_orientation['Z',1,2] +
    var_item_orientation['Z',1,3] + var_item_orientation['Z',1,4] +

    var_item_orientation['Z',1,5] + var_item_orientation['Z',2,1] +
    var_item_orientation['Z',2,2] + var_item_orientation['Z',2,3] +
    var_item_orientation['Z',2,4] + var_item_orientation['Z',2,5] +
    var_item_orientation['Z',3,1] + var_item_orientation['Z',3,2] +
    var_item_orientation['Z',3,3] + var_item_orientation['Z',3,4] +
    var_item_orientation['Z',3,5] = 15;

And

Constraint 2: item_orientation_constraint_1 {i in ITEMS}: sum {A in AXIS_CONTAINER} var_item_orientation [A,1,i] <= 1;

...which looks like this ...
ampl: expand item_orientation_constraint_1;
subject to item_orientation_constraint_1[1]:

    var_item_orientation['X',1,1] + var_item_orientation['Y',1,1] +
    var_item_orientation['Z',1,1] <= 1;

subject to item_orientation_constraint_1[2]:

    var_item_orientation['X',1,2] + var_item_orientation['Y',1,2] +
    var_item_orientation['Z',1,2] <= 1;

subject to item_orientation_constraint_1[3]:

    var_item_orientation['X',1,3] + var_item_orientation['Y',1,3] +
    var_item_orientation['Z',1,3] <= 1;

subject to item_orientation_constraint_1[4]:

    var_item_orientation['X',1,4] + var_item_orientation['Y',1,4] +
    var_item_orientation['Z',1,4] <= 1;

subject to item_orientation_constraint_1[5]:

    var_item_orientation['X',1,5] + var_item_orientation['Y',1,5] +
    var_item_orientation['Z',1,5] <= 1;

Based on this

the variables var_item_orientation['X',1,1] , var_item_orientation['Y',1,1] ,    var_item_orientation['Z',1,1] should have in sum maximum a value of 1.

But when using expand on the first constraint the model tells me it gave variables following values:

ampl: expand var_item_orientation['X',1,1],  var_item_orientation['Y',1,1];

Coefficients of var_item_orientation['X',1,1]:
    include_all_items                                 1

    item_orientation_constraint_1[1]                  1
    item_orientation_constraint_2[1]                 -1
    item_orientation_constraint_3[1,'Y']             -1
    item_orientation_constraint_3[1,'Z']             -1
    containtment_condition_1[1,'X']                  90
    containtment_condition_2[1,'X']                 -90
    non_overlapping_condition_2[2,'X']               90
    non_overlapping_condition_4[2,'X']              -90
    non_overlapping_condition_6[2]                   -1
    non_overlapping_condition_10[2]                   1
    CONSTRAINT1_for_var_Dim_CC_conversion1[1,'X']  -600
    CONSTRAINT3_for_var_Dim_CC_conversion1[1,'X']  -600
    CONSTRAINT1_for_var_Dim_NC_conversion2[2,'X']  -600
    CONSTRAINT3_for_var_Dim_NC_conversion2[2,'X']  -600

Coefficients of var_item_orientation['Y',1,1]:
    include_all_items                                 1
    item_orientation_constraint_1[1]                  1
    item_orientation_constraint_2[1]                 -1
    item_orientation_constraint_3[1,'X']             -1
    item_orientation_constraint_3[1,'Z']             -1
    containtment_condition_1[1,'Y']                  90
    containtment_condition_2[1,'Y']                 -90
    non_overlapping_condition_2[2,'Y']               90
    non_overlapping_condition_4[2,'Y']              -90
    non_overlapping_condition_6[2]                   -1
    non_overlapping_condition_10[2]                   1
    CONSTRAINT1_for_var_Dim_CC_conversion1[1,'Y']  -600
    CONSTRAINT3_for_var_Dim_CC_conversion1[1,'Y']  -600
    CONSTRAINT1_for_var_Dim_NC_conversion2[2,'Y']  -600
    CONSTRAINT3_for_var_Dim_NC_conversion2[2,'Y']  -600

Already here I stopped, since var_item_orientation['X',1,1] and var_item_orientation['Y',1,1] shouldn't have both the value 1, since they are constrained by constraint item_orientation_constraint_1 .

Why does this happen?

Am I misunderstanding the expand function?

Is there another way to find out, which value has been chosen of a variable by AMPL?

The model is the same as posted in this thread beforehand.

Thank you in advance.

Pascal

[AMPL Google Group]

When "expand" is applied to a variable, the output shows the coefficients of the variable. To see the current values of the variable, it is easiest to use the AMPL "display" command. For example, you could write

display var_item_orientation['X',1,1], var_item_orientation['Y',1,1];

--
Robert Fourer
am...@googlegroups.com

{#HS:1937074895-110788#}

Pascal

On Mon, Jul 4, 2022 at 7:36 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert,

thank you very much.
The conversion to a linear formulation has been done.
I still have some troubles, but will try to figure them out by myself for now.
In case of cases, I might reply again. :)

Pascal

AMPL Google Group schrieb am Montag, 4. Juli 2022 um 08:09:07 UTC+2:

Since var_item_orientation is a binary variable, Gurobi can convert var_Dim [A] * var_item_orientation [A,a,i] to an equivalent linear formulation. However, I agree that the IIS does not look quite right; possibly it is not reported correctly when there is a quadratic term.

You could do the conversion from the quadratic expression to the equivalent linear formulation yourself, in the AMPL model. Then you would have a linear model, and the IIS listing should be more reliable. Instructions for doing the conversion are given, for example, at

https://orinanobworld.blogspot.com/2010/10/binary-variables-and-quadratic-terms.html

--
Robert Fourer

[url=]am...@googlegroups.com

On Mon, Jul 4, 2022 at 6:08 AM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

Since var_item_orientation is a binary variable, Gurobi can convert var_Dim [A] * var_item_orientation [A,a,i] to an equivalent linear formulation. However, I agree that the IIS does not look quite right; possibly it is not reported correctly when there is a quadratic term.

You could do the conversion from the quadratic expression to the equivalent linear formulation yourself, in the AMPL model. Then you would have a linear model, and the IIS listing should be more reliable. Instructions for doing the conversion are given, for example, at

https://orinanobworld.blogspot.com/2010/10/binary-variables-and-quadratic-terms.html

--
Robert Fourer
am...@googlegroups.com

[Pascal Friedrich]

Thank you Robert!

[Pascal Friedrich]

Dear Robert,

I have another question with regards to non-linearity:

Is it possible to linearize a multiplication of two continuous variables?

In my case x1 * x2 = z

I found following solution (attached file), but then have the problem, when using the solution provided, that y1^2 - y2^2 are quadratic terms that cause an infeasible solution with the Gurobi solver.

Can you recommend another way of making this term linear or is there even a way to make Gurobi handle this problem?

Thanks in advance!

AMPL Google Group schrieb am Montag, 4. Juli 2022 um 08:09:07 UTC+2:

[AMPL Google Group]

It is not possible to linearize the multiplication of two continuous variables, but for Gurobi, you do not need to linearize it. Instead, give the command

option gurobi_options 'nonconvex=2';

-- or, if you are already specifying a gurobi_options string, add nonconvex=2 to it. Then Gurobi will accept x1 * x2 in your model.

--
Robert Fourer
am...@googlegroups.com

{#HS:1937074895-110788#}

On Sat, Jul 9, 2022 at 7:51 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert,

I have another question with regards to non-linearity:
Is it possible to linearize a multiplication of two continuous variables?

In my case x1 * x2 = z

I found following solution (attached file), but then have the problem, when using the solution provided, that y1^2 - y2^2 are quadratic terms that cause an infeasible solution with the Gurobi solver.

Can you recommend another way of making this term linear or is there even a way to make Gurobi handle this problem?

Thanks in advance!

On Fri, Jul 8, 2022 at 6:43 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Thank you Robert!

On Tue, Jul 5, 2022 at 9:01 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

When "expand" is applied to a variable, the output shows the coefficients of the variable. To see the current values of the variable, it is easiest to use the AMPL "display" command. For example, you could write

display var_item_orientation['X',1,1], var_item_orientation['Y',1,1];

--
Robert Fourer
am...@googlegroups.com

On Tue, Jul 5, 2022 at 7:57 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert,

Thank you for your help, my model is feasible now!
It doesnot output the desired result, but this will come.
I have a more general question:

It seems like AMPL is ignoring one of my constraints or I am missunderstanding AMPL's output.
I have two constraints that should limit each other to only produce certain values.

Constraint 1:
var_item_orientation[A,a,i] is a binary variable
include_all_items: sum {i in ITEMS} sum {A in AXIS_CONTAINER} sum {a in AXIS_ITEM} var_item_orientation[A,a,i] = 15;
....looks like this...
ampl: expand include_all_items;

subject to include_all_items:
var_item_orientation['X',1,1] + var_item_orientation['X',1,2] +
var_item_orientation['X',1,3] + var_item_orientation['X',1,4] +

var_item_orientation['X',1,5] + var_item_orientation['X',2,1] +
var_item_orientation['X',2,2] + var_item_orientation['X',2,3] +
var_item_orientation['X',2,4] + var_item_orientation['X',2,5] +
var_item_orientation['X',3,1] + var_item_orientation['X',3,2] +
var_item_orientation['X',3,3] + var_item_orientation['X',3,4] +

var_item_orientation['X',3,5] + var_item_orientation['Y',1,1] +

var_item_orientation['Y',1,2] + var_item_orientation['Y',1,3] +
var_item_orientation['Y',1,4] + var_item_orientation['Y',1,5] +

var_item_orientation['Y',2,1] + var_item_orientation['Y',2,2] +
var_item_orientation['Y',2,3] + var_item_orientation['Y',2,4] +
var_item_orientation['Y',2,5] + var_item_orientation['Y',3,1] +
var_item_orientation['Y',3,2] + var_item_orientation['Y',3,3] +

var_item_orientation['Y',3,4] + var_item_orientation['Y',3,5] +

var_item_orientation['Z',1,1] + var_item_orientation['Z',1,2] +
var_item_orientation['Z',1,3] + var_item_orientation['Z',1,4] +

var_item_orientation['Z',1,5] + var_item_orientation['Z',2,1] +
var_item_orientation['Z',2,2] + var_item_orientation['Z',2,3] +
var_item_orientation['Z',2,4] + var_item_orientation['Z',2,5] +
var_item_orientation['Z',3,1] + var_item_orientation['Z',3,2] +
var_item_orientation['Z',3,3] + var_item_orientation['Z',3,4] +
var_item_orientation['Z',3,5] = 15;

And
Constraint 2: item_orientation_constraint_1 {i in ITEMS}: sum {A in AXIS_CONTAINER} var_item_orientation [A,1,i] <= 1;
...which looks like this ...
ampl: expand item_orientation_constraint_1;

subject to item_orientation_constraint_1[1]:

var_item_orientation['X',1,1] + var_item_orientation['Y',1,1] +
var_item_orientation['Z',1,1] <= 1;

subject to item_orientation_constraint_1[2]:

var_item_orientation['X',1,2] + var_item_orientation['Y',1,2] +
var_item_orientation['Z',1,2] <= 1;

subject to item_orientation_constraint_1[3]:

var_item_orientation['X',1,3] + var_item_orientation['Y',1,3] +
var_item_orientation['Z',1,3] <= 1;

subject to item_orientation_constraint_1[4]:

var_item_orientation['X',1,4] + var_item_orientation['Y',1,4] +
var_item_orientation['Z',1,4] <= 1;

subject to item_orientation_constraint_1[5]:

var_item_orientation['X',1,5] + var_item_orientation['Y',1,5] +
var_item_orientation['Z',1,5] <= 1;

Based on this
the variables var_item_orientation['X',1,1] , var_item_orientation['Y',1,1] , var_item_orientation['Z',1,1] should have in sum maximum a value of 1.
But when using expand on the first constraint the model tells me it gave variables following values:

ampl: expand var_item_orientation['X',1,1], var_item_orientation['Y',1,1];

Coefficients of var_item_orientation['X',1,1]:
include_all_items 1

item_orientation_constraint_1[1] 1
item_orientation_constraint_2[1] -1
item_orientation_constraint_3[1,'Y'] -1

item_orientation_constraint_3[1,'Z'] -1
containtment_condition_1[1,'X'] 90

AMPL Google Group schrieb am Montag, 4. Juli 2022 um 08:09:07 UTC+2:

Since var_item_orientation is a binary variable, Gurobi can convert var_Dim [A] * var_item_orientation [A,a,i] to an equivalent linear formulation. However, I agree that the IIS does not look quite right; possibly it is not reported correctly when there is a quadratic term.

You could do the conversion from the quadratic expression to the equivalent linear formulation yourself, in the AMPL model. Then you would have a linear model, and the IIS listing should be more reliable. Instructions for doing the conversion are given, for example, at

https://orinanobworld.blogspot.com/2010/10/binary-variables-and-quadratic-terms.html

--
Robert Fourer

[url=]am...@googlegroups.com

On Mon, Jul 4, 2022 at 6:08 AM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

Since var_item_orientation is a binary variable, Gurobi can convert var_Dim [A] * var_item_orientation [A,a,i] to an equivalent linear formulation. However, I agree that the IIS does not look quite right; possibly it is not reported correctly when there is a quadratic term.

You could do the conversion from the quadratic expression to the equivalent linear formulation yourself, in the AMPL model. Then you would have a linear model, and the IIS listing should be more reliable. Instructions for doing the conversion are given, for example, at

https://orinanobworld.blogspot.com/2010/10/binary-variables-and-quadratic-terms.html

--
Robert Fourer
am...@googlegroups.com

[Pascal Friedrich]

Thank you Robert!

Highly appreciated!

[Pascal Friedrich]

Dear Robert,

I have another request related to infeasiblility with the gurobi solver.

If the data file contains, in my case, more than 9 items it runs for a long time (15s) until it tells me that the model is infeasible.

I tried other data and I know for sure, that with less than 9 items the model is feasible.

Now, I believe the issue is Gurobi. I am using Gurobi 9.5.1.

Could you please recommend what I should do to tackle this problem?

Either I choose another solver or are there features, that let Gurobi run longer to prevent an infeasible statement (if this is possible and a solution at all)?

If this information helps: I received the 30 day trial for students yesterday with its solver package.

Attached please find the mod, run and dat fie.

Thanks in advance.

AMPL Google Group schrieb am Sonntag, 10. Juli 2022 um 06:34:53 UTC+2:

[Pascal Friedrich]

Dear Robert,

sorry for my dumb question. ^^

I have permitted only a certain value inside my model, so that's why it was infeasible.

[AMPL Google Group]

It is good to hear that you discovered the cause. This confirms what I have seen in other cases: an "infeasible" message is usually due to some issue with the model or data, rather than being caused by an error in the solver computations.

--
Robert Fourer
am...@googlegroups.com

{#HS:1937074895-110788#}

On Thu, Jul 14, 2022 at 8:30 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert,

sorry for my dumb question. ^^

I have permitted only a certain value inside my model, so that's why it was infeasible.

On Wed, Jul 13, 2022 at 6:44 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert,

I have another request related to infeasiblility with the gurobi solver.
If the data file contains, in my case, more than 9 items it runs for a long time (15s) until it tells me that the model is infeasible.
I tried other data and I know for sure, that with less than 9 items the model is feasible.

Now, I believe the issue is Gurobi. I am using Gurobi 9.5.1.
Could you please recommend what I should do to tackle this problem?
Either I choose another solver or are there features, that let Gurobi run longer to prevent an infeasible statement (if this is possible and a solution at all)?

If this information helps: I received the 30 day trial for students yesterday with its solver package.

Attached please find the mod, run and dat fie.

Thanks in advance.

On Wed, Jul 13, 2022 at 6:44 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Thank you Robert!
Highly appreciated!

On Sun, Jul 10, 2022 at 4:34 AM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

It is not possible to linearize the multiplication of two continuous variables, but for Gurobi, you do not need to linearize it. Instead, give the command

option gurobi_options 'nonconvex=2';

-- or, if you are already specifying a gurobi_options string, add nonconvex=2 to it. Then Gurobi will accept x1 * x2 in your model.

--
Robert Fourer
am...@googlegroups.com