[Clp] Value of objective changes after enableSimplexInterface

Tue Mar 16 11:03:57 EDT 2010

I have only checked this model withlp_solve (a different solver).
It warns in dual simplex
Objective value                  0 at iter        140.
dualloop: Assuming convergence with reduced accuracy 1.14688e-007.
dualloop: Assuming convergence with reduced accuracy 1.14688e-007.
Found feasibility by dual simplex after           151 iter.
primloop: Lost primal feasibility at iter         159: will try to recover.
dualloop: Assuming convergence with reduced accuracy 1.14688e-007.
dualloop: Assuming convergence with reduced accuracy 1.14688e-007.
Difficult numerics encountered; validate accuracy
Optimal solution      -426.899993127 after        159 iter.
Marginal numeric accuracy ||*|| = 1.14688e-007 (rel. error 1.81354e-010)

It refuses to solve in primal simplex. With 10 lost feasibilities.

So First clean up your problem scaling.
The solution variables from the dual range from 271 to 5500 except for the
fixed 0 for x50.

I would first replace all the rows of form 
cons111:  - 0.0018587361 x82 + 0.0018587361 x83 >= 1
cons112:  - 0.0023424690 x49 >= -1
cons113:  0.0002038320 x1 - 0.0002038320 x2 >= -1
by division by the constant left multipliers.

cons111:	-	x82	+	x83	>= 1537.9999883
cons112:	-	x49			>= -426.8999931
cons113:		x1	-	x2	>= -4906.00102
Then I would seriously consider rounding the RHS to 1 or 2 decimals.
Next for better scaling, it is perfectly reasonable to change units to
divide all the RHS by a constant say the mean or the min abs value.
For example ther ar a bunch with -89.59999989 so use 100.
Now the abs RHS ranges from .90 to about 50 ant the variable will
correspondingly range from about 2.7 to 55. This is quite a respectable
Small scaling. I am not so sure what your are trying for from these
constraints.  It would seem there are easy variable eliminations bu adding
the row blocks.
But all the happens by the change of units is a rhs divide by 100.
So the 1e-4 becomes 1e-6 , I would personally start with 1e-2 so it becomes
1e-4.
cons0:  x84 >= 1e-4
cons1:  x66 - x84 >= 1e-4
cons2:  - x66 + x67 >= 1e-4
cons3:  - x67 + x85 >= 1e-4
cons4:  - x85 >= -5759.9999000000  

Well for LP_solve just the scaling of the coefficients to near 1 did the
trick for the primal.
SUBMITTED
Model size:      256 constraints,     107 variables,          436 non-zeros.
Sets:                                   0 GUB,                  0 SOS.

CONSTRAINT CLASSES
General REAL     256

Using PRIMAL simplex for phase 1 and PRIMAL simplex for phase 2.
The primal and dual simplex pricing strategy set to 'Devex'.

Objective value      -119588.26671 at iter         25.
Objective value     -58592.2077967 at iter         50.
Objective value     -29918.2267595 at iter         75.
Objective value      -3228.1599588 at iter        100.
Objective value   -0.0200000000445 at iter        125.
Found feasibility by primal simplex after         127 iter.

Revised model attached.

-----Original Message-----
From: clp-bounces at list.coin-or.org [mailto:clp-bounces at list.coin-or.org] On
Behalf Of Valentin Ziegler
Sent: Tuesday, March 16, 2010 6:21 AM
To: clp at list.coin-or.org
Subject: [Clp] Value of objective changes after enableSimplexInterface

Hello,

We solve some LP by initialSolve, check that the solution is proven
optimal, and then call enableSimplexInterface(true).

Immediately after enabling the simplex interface, we often observe
dramatic changes in the objective. The reason seems to be some penalty
cost applied by ClpSimplex::checkBothSolutions().

Sebastian reported this before (see
http://list.coin-or.org/pipermail/clp/2009-March/000902.html ) and
recommended to do a resolve after enabling the simplex interface, but
this does not always help. I attached a problem (Test.lp) for
reproduction, test by

OsiClpSolverInterface solver;
solver.setupForRepeatedUse(0);
solver.readLp("Test.lp", 1e-10);

solver.initialSolve();
assert(solver.isProvenOptimal());
solver.getObjValue();  // == -426.899993

solver.enableSimplexInterface(true);
solver.getObjValue();  // == 573012.4375

solver.resolve();
assert(solver.isProvenOptimal());
solver.getObjValue();  // still 573012.4375

Are there any suggestions how to fix or work around this? Thank you in
advance.

Valentin

--
Valentin Ziegler . vziegler at think-cell.com
Software Engineer

think-cell Software GmbH . Chausseestr. 8/E . 10115 Berlin, Germany 
http://www.think-cell.com . phone +49 30 666473-10 . toll-free (US) +1 800
891 8091
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl . Amtsgericht
Berlin-Charlottenburg, HRB 85229

-------------- next part --------------
A non-text attachment was scrubbed...
Name: valentin1w.lpt
Type: application/octet-stream
Size: 8835 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/clp/attachments/20100316/6355a771/attachment.obj>