[Os-project-managers] straw man

[Horand Gassmann]

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

> Hi Guys:
>
>
> Proposal:
>
> We have new class called OSSolver. The OSSolver.cpp and OSSolver.h files
> will sit in src/OSSolverInterfaces. The OSSolver class is part of  
> the OS library and
> executables such as OSSolverService and OSAmplClient can link to it. It will
> have two methods, a local solve method (which we overload with strings and
> objects) and a remote solve method.
>
> Here are the signatures for a local solve:
>
>
> std::string osLocalSolve(std::string osil, std::string osol);
> std::string osLocalSolve(OSInstance* osinstance, OSOption* osopt)
>
> the osLocalSolve(std::string osil, std::string osol) will convert
> the strings to the corresponding objects and then call
> osLocalSolve(OSInstance* osinstance, OSOption* osopt)
>
> This osinstance and osoption have the only information that a local solve
> needs. By a local solve we mean that the OSSolver will call Clp, Cbc, Ipopt,
> etc. in memory.

This is good.

> The remote solve has only one signature
>
> std::string osRemoteSolve(osOptionsStruc *osoptions)

This could be improved, I think. If you call this method from  
OSAmplClient, where is the instance (and initial values etc.)? Do you  
package that into the osoptions object?

Note that if you have an osil and an osol file for the remote solve,  
then you need to send strings, which you can get by simply reading the  
files. There is no need to create an osoption object, which you would  
then write out again to a string. If there are initial values for a  
million variable problem, you are potentially wasting a lot of time.

> this method will throw an exception if the serviceLocation string is empty.
> The osRemoteSolve manages the kill, send, solve, retrieve, getJobID, and
> knock functions.
>
> All three methods return an OSrL string.
>
> The osRemoteSolve name is misleading in that it does a remote  
> solve(), send(),
> kill(), retrieve(), getJobID.

I think for the remote methods, we should distinguish between  
solve/send (which do the same thing on the local server: send an  
instance and options and wait for an osrl file) and the other methods:  
retrieve, knock, kill, getJobID. I therefore think of OSSolver as  
having six methods: knock, kill, getJobID, retrieve, as well as  
localSolve and remoteSolveSend. (Don't get too hung up on the names  
--- I am not.)

Cheers

gus

> Some of the coding in the current OSSolverService would need to  
> change. For example,
> consider line 481, currently it is
>
> knock()
>
> this would change to
>
> osoptions->serviceMethod="knock"
> std::cout << osRemoteSolve( osoptions) << std::endl;
>
>
> The above philosophy is also the philosphy of GAMS/GMASLinks. In the  
> case of GAMS,
> the GAMS option file .opt takes the palce of osoptions.
>
> 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
>
> Sent without Blackberry, Droid, iPhone, or any other
> wireless device.
> -- 
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>



-------------------------------------------------------

Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue
Halifax, Nova Scotia, Canada , B3H 3J5
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/