[Cbc-tickets] Re: [COIN-OR Branch-and-Cut MIP Solver] #32: Problem
on windows
platform with full paths in interfaces of Cbc, CbcSolve, Clp
COIN-OR Branch-and-Cut MIP Solver
coin-trac at coin-or.org
Sun Oct 14 10:18:12 EDT 2007
#32: Problem on windows platform with full paths in interfaces of Cbc, CbcSolve,
Clp
-------------------------+--------------------------------------------------
Reporter: mserg | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Resolution: | Keywords:
-------------------------+--------------------------------------------------
Comment (by mserg):
Dear colleague,
This problem is model-independent. You can use any model, for example
"hello.mps" from cbc-collection problems. See the follow log:
******** problem ":" **************************************
Coin Cbc and Clp Solver version 1.02.00, build Oct 12 2007
CoinSolver takes input from arguments ( - switches to stdin)
Enter ? for list of commands or help
Coin:import hello.mps
At line 1 NAME Hello
At line 2 ROWS
At line 25 COLUMNS
At line 185 RHS
At line 197 RANGES
At line 209 BOUNDS
At line 263 ENDATA
Problem Hello has 21 rows, 53 columns and 224 elements
Model was imported from .\hello.mps in 0.01 seconds
Coin:solve
Presolve 14 (-7) rows, 23 (-30) columns and 113 (-111) elements
Optimal - objective value 0
After Postsolve, objective 0, infeasibilities - dual 0 (0), primal 0 (0)
Optimal objective 0 - 0 iterations time 0.032, Presolve 0.03
Coin:solu c:\Result.txt
Unable to open file .\c:\Result.txt
Coin:
********* problem ":" ***************************************
The problem is absolute path with symbol ":".
I have found other problems in user's interface. The fatal error happens
when the "pret" parameter is setting:
********* problem "PreT" *************************************
Coin:pret 1
preTolerance was changed from 1e-008 to 1
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
********* problem "PreT" *************************************
The suspected initial value is displayed when change "sec" parameter:
********* problem "sec" **************************************
Coin:sec??
sec(onds) : maximum seconds
After this many seconds coin solver will act as if maximum nodes had
been reached.
<Range of values is -1 to 1e+012;
current 1e+008>
Coin:sec 9999
seconds was changed from 1e+100 to 9999
Coin:Coin:
********* problem "sec" **************************************
Has the time limit the problems without integer variables? I am not yet
sure...
-1 can be assigned to parameters "log" and "slog". What is this mean?
There is no help... To parameter "passC" can be negative. What is this
mean?
********* strange negative **************************************
Coin:log??
log(Level) : Level of detail in Coin branch and Cut output
If 0 then there should be no output in normal circumstances. 1 is
probably the best value for most uses, while 2 and 3 give more
information.
<Range of values is -1 to 63;
current 1>
Coin:slog??
slog(Level) : Level of detail in Solver output
If 0 then there should be no output in normal circumstances. 1 is
probably the best value for most uses, while 2 and 3 give more
information.
<Range of values is -1 to 63;
current 0>
Coin:passC??
passC(uts) : Number of cut passes at root node
The default is 100 passes if less than 500 columns, 100 passes (but
stop if drop small if less than 5000 columns, 20 otherwise
<Range of values is -999999 to 999999;
current -1>
********* strange negative **************************************
The strange value is displayed when the "cutoff" parameter change. The
branch and cut algorithm is ignores "cutoff" changes... I set 1e55, but
B&C use 1e50. See the follow log (the example "p0033.mps" was taken from
cbc-collection):
********* cutoff problems ***************************************
Coin Cbc and Clp Solver version 1.02.00, build Oct 12 2007
CoinSolver takes input from arguments ( - switches to stdin)
Enter ? for list of commands or help
Coin:cutoff??
cuto(ff) : All solutions must be better than this
All solutions must be better than this value (in a minimization sense).
This is also set by code whenever it obtains a solution and is set
to value of objective for solution minus cutoff increment.
<Range of values is -1e+060 to 1e+060;
current 1e+050>
Coin:cutoff 1e55
cutoff was changed from 1e+100 to 1e+055
Coin:heur off
Option for heuristicsOnOff changed from on to off
Coin:cuts off
Option for cutsOnOff changed from on to off
Coin:import p0033.mps
At line 15 NAME P0033
At line 16 ROWS
At line 34 COLUMNS
At line 109 RHS
At line 118 BOUNDS
At line 152 ENDATA
Problem P0033 has 16 rows, 33 columns and 98 elements
Model was imported from .\p0033.mps in 0 seconds
Coin:solve
Optimal - objective value 2520.57
Cgl0006I 1 SOS (5 members out of 33) with 0 overlaps - too much overlap or
too many others
Cgl0004I processed model has 15 rows, 32 columns (32 integer) and 97
elements
processed model has 15 rows, 32 columns and 97 elements
Optimal - objective value 2819.36
32 integer variables
Cbc0009I Objective coefficients multiple of 1
cutoff increment increased from 1e-005 to 0.999
Cbc0010I After 0 nodes, 1 on tree, 1e+050 best solution, best possible
2819.36 (0.01 seconds)
Cbc0016I Integer solution of 3302 found by strong branching after 21
iterations and 9 nodes (0.06 seconds)
Cbc0016I Integer solution of 3089 found by strong branching after 205
iterations and 89 nodes (0.29 seconds)
Cbc0001I Search completed - best objective 3089, took 278 iterations and
121 nodes (0.36 seconds)
Cbc0032I Strong branching done 528 times (921 iterations), fathomed 53
nodes and fixed 29 variables
Cuts at root node changed objective from 2819.36 to 2819.36
Result - Finished objective 3089 after 121 nodes and 278 iterations - took
0.38 seconds
********* cutoff problems ***************************************
Maybe my English is too bad, but the "inc??" says "plus increment" against
"cutoff??" "minus increment"... Seems too strange...
********* cutoff increment direction ****************************
Coin:inc??
inc(rement) : A valid solution must be at least this much better than last
integer solution
Whenever a solution is found the bound on solutions is set to solution
(in a minimizationsense) plus this. If it is not set then the code
will try and work one out e.g. if all objective coefficients are multiples
of 0.01 and only integer variables have entries in objective then
this can be set to 0.01. Be careful if you set this negative!
<Range of values is -1e+020 to 1e+020;
current 1e-005>
Coin:cutoff??
cuto(ff) : All solutions must be better than this
All solutions must be better than this value (in a minimization sense).
This is also set by code whenever it obtains a solution and is set
to value of objective for solution minus cutoff increment.
<Range of values is -1e+060 to 1e+060;
current 1e+050>
********* cutoff increment direction ****************************
I can't understand the help of "PrimalP" without drinking bottle of
vodka... Which options is workable? Why the "primal exact" help is
equivalent "dual steepest" help?
******** primalP & dualP help ***********************************
Coin:primalP??
primalP(ivot) : Primal pivot choice algorithm
Clp can use any pivot selection algorithm which the user codes as
long as it implements the features in the abstract pivot base class.
The Dantzig method is implemented to show a simple method but its
use is deprecated. Exact devex is the method of choice and there
are two variants which keep all weights updated but only scan a subset
each iteration. Partial switches this on while change initially does
dantzig until the factorization becomes denser. This is still a work
in progress.
<Possible options for primalPivot are: auto(matic) exa(ct) dant(zig)
part(ial) steep(est) change sprint;
current auto(matic)>
Coin:dualP??
dualP(ivot) : Dual pivot choice algorithm
Clp can use any pivot selection algorithm which the user codes as
long as it implements the features in the abstract pivot base class.
The Dantzig method is implemented to show a simple method but its
use is deprecated. Steepest is the method of choice and there are
two variants which keep all weights updated but only scan a subset
each iteration. Partial switches this on while automatic decides at
each iteration based on information about the factorization.
<Possible options for dualPivot are: auto(matic) dant(zig) partial
steep(est);
current auto(matic)>
******** primalP & dualP help ***********************************
-----Original Message-----
From: coin-trac at coin-or.org [mailto:coin-trac at coin-or.org]
Sent: Monday, September 24, 2007 1:32 AM
Cc: cbc-tickets at list.coin-or.org
Subject: Re: [COIN-OR Branch-and-Cut MIP Solver] #32: Problem on windows
platform with full paths in interfaces of Cbc, CbcSolve, Clp
#32: Problem on windows platform with full paths in interfaces of Cbc,
CbcSolve,
Clp
-------------------------+--------------------------------------------------
Reporter: mserg | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Resolution: | Keywords:
-------------------------+--------------------------------------------------
Comment (by jpfasano):
What Version of Cbc are you using?
What do you do to create the problem?
How can the problem be recreated?
--
Ticket URL: <https://projects.coin-or.org/Cbc/ticket/32#comment:1>
COIN-OR Branch-and-Cut MIP Solver <http://projects.coin-or.org/Cbc>
An LP-based branch-and-cut MIP solver.
--
Ticket URL: <https://projects.coin-or.org/Cbc/ticket/32#comment:1>
COIN-OR Branch-and-Cut MIP Solver <http://projects.coin-or.org/Cbc>
An LP-based branch-and-cut MIP solver.
More information about the Cbc-tickets
mailing list