Giving AMPL-CPLEX an initial solution

[pmk...@ing.puc.cl]

Hi, I'm working with a pretty big MILP in AMPL-CPLEX. 

If I don't provide an initial solution it takes hours and never finds one. My problem is that for small instances the solver has no problem reading and starting from the solution provided (it says at the beginning "initial solution provided with an objective function value of something") but for bigger instances I can't make it read it even though I give a feasible solution specifying values for every single variable. 

To provide the solutions I'm using a file with sentences like "let x[1,2] := 0". 
Is that OK or should I provide it in some other way? 

Thanks for any help!

[Robert Fourer]

If you use "let" to set an initial feasible solution, then CPLEX will recognize it.  So if CPLEX fails to find any feasible solution then maybe, due to some mistake, your solution wasn't really feasible.  After setting the initial feasible solution but before solving, try using the following commands to check for any constraints or variable bounds that are violated by your solution:

 

   display {i in 1.._ncons: _con[i].slack < 0} (_conname[i],_con[i].slack);

   display {j in 1.._nvars: _var[j].slack < 0} (_varname[j],_var[j].slack);

 

Slacks that are negative by only some tiny amount (such as -10^-9) can be ignored, but otherwise negative slacks indicate infeasibilities in your solution.  If there are infeasibilities then CPLEX will try to adjust your solution to make it feasible, but if it is not successful then your initial solution will be ignored.

 

If this test does not show any infeasibilities, then try asking CPLEX for some more information, by adding this setting before solving:

 

   option cplex_options 'mipdisplay 2';

 

(Or, add 'mipdisplay 2' to your existing cplex_options string, if it isn't there already.)  Then post the first 50 lines or so of the resulting output.

 

Bob Fourer

am...@googlegroups.com

 

 

From: am...@googlegroups.com [mailto:am...@googlegroups.com]

On Behalf Of pmk...@ing.puc.cl
Sent: Monday, August 26, 2013 11:54 AM
To: am...@googlegroups.com
Subject: [AMPL 7405] Giving AMPL-CPLEX an initial solution

[pmk...@ing.puc.cl]

Bob, your answer was just perfect to allow me to see the problem.

The initial feasible solution I´m providing is being generated by an algorithm programmed in Visual Studio. That algorithm doesn't have any problem, the difficulty is with the decimals.

At the beginning I got aware that Visual Studio was writing numbers like 3,2 as 3,19999999999 or something like that what, of course, ended for CPLEX as an infeasible solution. To avoid that I started working all the numbers with 2 decimals and I asked Visual Studio to round the numbers after every operation to that same amount. The problem now is that, of course, after multipliying numbers with 2 decimals I won't get another one with 2 decimals and when rounding them I'm making some constraints false.

Do you have any idea about how to solve this problem. I need Visual Studio to manage the operations and the numbers as any of as would when doing the operations ourselves. 

Thanks!

[Robert Fourer]

I would advise not to round any numbers in your Visual Studio program, but rather to send numbers like 3.19999999999 to AMPL.  Then I would advise not rounding in AMPL either, and seeing whether the solution that you provide is deemed feasible by CPLEX.  The CPLEX routines use a feasibility tolerance of something like 10^-6, so the difference between 3.19999999999 and 3.2 is not likely to make any difference to feasibility.  (Indeed neither of these numbers can be converted exactly to binary in the computer anyway.)

 

If you do need rounding to achieve feasibility, then I would advise using AMPL's "precision" function to round at, say, the 6th or 8th significant digit.  In general you will have a lot more control of how you round in AMPL than in Visual Studio.

 

Bob Fourer

am...@googlegroups.com

 

 

From: am...@googlegroups.com [mailto:am...@googlegroups.com]

On Behalf Of pmk...@ing.puc.cl
Sent: Thursday, August 29, 2013 11:34 AM
To: am...@googlegroups.com
Cc: 4...@ampl.com
Subject: Re: [AMPL 7411] Giving AMPL-CPLEX an initial solution

[pmk...@ing.puc.cl]

Bob, thank you very much for your answer.

Indeed I needed to round the numbers because Visual Studio was reading the values provided from an input file normally with only five 9's or 0's after the last digit and then with any numbers. For example, 3.2 could be read by Visual Studio as 3.19999924327 or as 3.20000097662.

As well, even if the input values where read and saved correctly, after operating with them in order to calculate the values of all the variables in the initial solution provided to CPLEX, Visual Studio was also miswriting the values. For example, 3.2 + 1.1 could be written as 4.29999964751 or as 4.30000046328.

Now imagine what happens when instead of adding I'm multiplying and when not only the product but also the factors are miswritten. Something like 3.2 * 1.1 could be written as different as 3.51999803 or 3.52000274.

Now, if you make several operations, after a while you have nothing but numbers that don't represent the numbers they should be. The result, more than half of the big amount of constraints I was dealing with were unfeasible making CPLEX incapable of using the feasible solution I was suposly providing. 

To solve this I had to program my own rounding algorithm in Visual Studio and use it pretty much before and after every math operation. This in order to keep rounding the numbers and keep them right before they change that much that I can't detect what they should be.

Definitely something that shouldn't happen but... what can we say. I hope this is useful for someone else who might be having the same problem.

Thanks!

[Robert Fourer]

Numbers like 3.19999924327 or 3.20000097662 result from single-precision representations of 3.2.  For example, according to www.h-schmidt.net/FloatConverter, the IEEE single-precision floating-point representations that come closest to 3.2 are

 

   binary                               decimal

   0 10000000 10011001100110011001100   3.1999998092651367

   0 10000000 10011001100110011001101   3.200000047683716

 

With CPLEX's default feasibility tolerance of 10^-6, these discrepancies might be big enough to cause some trouble.  The cure for this is to use double precision.  If there's nothing you can do about the form of the input values, then in your Visual Studio program you can read them as they are, round them, and assign them to double precision variables, after which no further rounding should be necessary if you use double precision throughout your program.

 

Bob Fourer

am...@googlegroups.com

 

 

From: am...@googlegroups.com [mailto:am...@googlegroups.com]

On Behalf Of pmk...@ing.puc.cl
Sent: Saturday, August 31, 2013 4:10 PM
To: am...@googlegroups.com
Cc: 4...@ampl.com
Subject: Re: [AMPL 7418] Giving AMPL-CPLEX an initial solution

 

Bob, thank you very much for your answer.

 

Indeed I needed to round the numbers because Visual Studio was reading the values provided from an input file normally with only five 9's or 0's after the last digit and then with any numbers. For example, 3.2 could be read by Visual Studio as 3.19999924327 or as 3.20000097662.

 

As well, even if the input values where read and saved correctly, after operating with them in order to calculate the values of all the variables in the initial solution provided to CPLEX, Visual Studio was also miswriting the values. For example, 3.2 + 1.1 could be written as 4.29999964751 or as 4.30000046328.

 

Now imagine what happens when instead of adding I'm multiplying and when not only the product but also the factors are miswritten. Something like 3.2 * 1.1 could be written as different as 3.51999803 or 3.52000274.

 

Now, if you make several operations, after a while you have nothing but numbers that don't represent the numbers they should be. The result, more than half of the big amount of constraints I was dealing with were unfeasible making CPLEX incapable of using the feasible solution I was suposly providing. 

 

To solve this I had to program my own rounding algorithm in Visual Studio and use it pretty much before and after every math operation. This in order to keep rounding the numbers and keep them right before they change that much that I can't detect what they should be.

 

Definitely something that shouldn't happen but... what can we say. I hope this is useful for someone else who might be having the same problem.

 

Thanks!

.

[polis]

Sorry for re-opening this 2-years old conversation, but the "let" commands seems to not fix an initial solution. The structure of my .run file is:

model model.mod; # here var x is declared;

data data.dat;

include initial_solution.let;

option solver cplex_ampl;

solve;

Every line of file initial_solution.let is of the form

...

let x['a','b','c','d'] := 1;

...

Yet, CPLEX doesn't start with that solution.

P.S. That solution is feasible, in fact if I substitute "let" with "fix" CPLEX says "CPLEX 12.1.0: optimal integer solution; objective 2800"

[Robert Fourer]

CPLEX 12.1.0 is a version from 6 years ago, so maybe you are seeing a bug that has been fixed in later versions. If your files are small enough you could post them here (by attaching them to an email to am...@googlegroups.com) and we could try running them on the current version of CPLEX for AMPL to see how your initial solution is handled. Or you may be able to get some more help by posting the log output from CPLEX when you add

option cplex_options 'mipdisplay 2';

before "solve;" -- this provides a lot of detail as to what happened in the CPLEX solution process.

Bob Fourer
am...@googlegroups.com

=======

From: am...@googlegroups.com [mailto:am...@googlegroups.com] On Behalf Of polis
Sent: Friday, May 8, 2015 8:59 AM
To: am...@googlegroups.com