[Os-project-managers] Todays Discusssion

[R. Kipp Martin]

Hi Gus:

Agenda:

1) Gus report on Visual Studio

2) Discussion of OSI II

3) Implementing Clp options. See below



%%%%%%%%%%%%%%%%%%%%%%%%%%

Our OSCoinSolver communicates with the
linear continuous and linear integer COIN-OR solvers. These are Clp,
Cbc, DyLP, Vol, and SYMPHONY. These solvers build by default with
OSCoinSolver. You can also build OS with Glpk and Cplex and communicate
with these through OSCoinSolver.  We communicate with these solvers
through the Osi interface. Unfortunately, there is a serious problem
with the Osi interface. In particular, with regard to setting options.
The Osi interface attempts to enumerate all of the options a linear
integer solver might use. Of course this is a hopeless task and is in
stark contrast to what we do with our OSoL (as an aside I think 1) we
really need to lobby Matt and Lou who are working on Osi II to use our
OSoL/OSOption, and 2) we should think about writing a paper this summer
on solver options and results and discuss what we have learned).
Because the Osi options are relatively limited there is for example no
way to tell an LP solver to use a barrier/interior point algorithm. You
cannot tell an IP solver which classes of Cgl cutting planes to use. You
cannot solve a quadratic program with a linear solver such as Clp that
supports this. The list goes on. I have seen numerous complaints and
requests on various mailing lists about this.

Indeed, we currently treat Cbc differently than the other solvers
because solving an IP takes far more time than necessary if you go
through Osi.  I strongly feel we need to treat Clp differently so we can
tell Clp to do barrier, solve QPs, take advantage of pure networks, etc.

The task is (was) easier with Cbc because Cbc provides a method which is
equivalent to its command line option parser. This allows us to create a
char** and pass options to Cbc that way. Not so with Clp. It will be
more complicated. Clp provides NO option API. I have spent a fair amount
of time studying Clp source code and think we can still do what we need
to do. Please look at

ApplicationTemplates/template.cpp

I want to use this as a basis for our discussion.  You will see for
example code such as

ClpSolve solveOptions;
ClpSolve::SolveType method;
method = ClpSolve::useBarrier;
//or primal simplex
method = ClpSolve::usePrimal;
solveOptions.setSolveType( method);

where you can set the solution method. There is also a class

CbcOrClpParam parameters[CBCMAXPARAMETERS];


with for example

parameters[whichParam(CBC_PARAM_ACTION_DIRMIPLIB, numberParameters,
parameters)].setStringValue(dirMiplib);
parameters[whichParam(CLP_PARAM_DBL_DUALBOUND, numberParameters,
parameters)].setDoubleValue(models->dualBound());
parameters[whichParam(CLP_PARAM_DBL_DUALTOLERANCE, numberParameters,
parameters)].setDoubleValue(models->dualTolerance());parameters[whichParam(CLP_PARAM_ACTION_EXPORT, 

numberParameters, parameters)].setStringValue(exportFile);

You can use parameters to set options like this

	parameters[ whichParam(CLP_PARAM_INT_SOLVERLOGLEVEL, numberParameters,
parameters)].setIntParameter(qpClpModel, 0);
	parameters[ whichParam(CLP_PARAM_INT_MAXITERATION, numberParameters,
parameters)].setIntParameter(qpClpModel, 10);
	

So I suggest we support the current options that Clp supports at the
command line which are

Clp:?
In argument list keywords have leading - , -stdin or just - switches to
stdin
One command per line (and no -)
abcd? gives list of possibilities, if only one + explanation
abcd?? adds explanation, if only one fuller help
abcd without value (where expected) gives current value
abcd value sets value
Commands are:
Double parameters:
   dualB(ound) dualT(olerance) preT(olerance) primalT(olerance)
primalW(eight)
   sec(onds) zeroT(olerance)
Int parameters:
   idiot(Crash) log(Level) maxF(actor) maxIt(erations) output(Format)
   sprint(Crash)
Keyword parameters:
   allC(ommands) chol(esky) crash cross(over) direction error(sAllowed)
   fact(orization) keepN(ames) mess(ages) perturb(ation) presolve
   printi(ngOptions) scal(ing) timeM(ode)
Actions or string parameters:
   allS(lack) barr(ier) basisI(n) basisO(ut) directory dualS(implex)
   either(Simplex) end exit export gsolu(tion) help import max(imize)
min(imize)
   para(metrics) primalS(implex) printM(ask) quit saveS(olution) solu(tion)
   solv(e) stat(istics) stop

we then map these into the parameters class and then set them.

I would like to keep one OSCoinSolver but somehow break up or overload the

setSolverOptions()

method for Clp, Cbc, and other Osi solvers.  Something like

setSolverOptions(){
	
	if(sSolverName == "cbc") setSolverOptions( CbcModel *model);	
		elseif (sSolverName == "cbc") setSolverOptions(ClpSolve* solveOptions);
			else setSolverOptions(OsiSolverInterface *si);
}

I think by function overloading we can keep everything still within
OSCoinSolver as opposed to OSCbcSolver, OSClpSolver, etc. This way we
can avoid changing the OSSolverService and cause as little interruption
as possible to the system. We can discuss in more detail in our meeting.


-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS