[Os-project-managers] May 19 Agenda

[Horand Gassmann]

I can now confirm that I will be able to initiate the call at 1:30.  
Talk to you then.

Cheers

gus

"R. Kipp Martin" <kmartin at chicagobooth.edu> wrote:

> Here are some possible agenda items.
>
> 1) Gus -- report and discuss timing issues.
>
> 2) Server update -- on Wednesday I signed an agreement with Comcast
> Cable for their Business Class Internet service. I am frustrated with
> dealing with the University and I am going to run a dedicated OS server
> out of my Condo. This machine will do nothing but act as a dedicated OS
> server.  As part of this service agreement I purchased a (actually five)
> dedicated IP addresses.  Right now we only need one for the dedicated
> server, but we might want to experiment with calling several servers in
> the future. We will be able to give this IP address to anyone (for
> example the GAMS people, Mike Steglich, the Python modeling language
> developers, etc.) wishing to test our remote service.
>
> 3) The fun one -- OSCoinSolver.  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.
>
> Cheers
> --
> 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
>
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>