[Os-project-managers] straw man

[Horand Gassmann]

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

> Hi Gus:
>
>>> 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?
>
> This is the osOptionsStruc we currently use in OSSolverService.  It  
> has everything we need including stings for OSiL and OSoL. See
>
> src/OSParsers/OSOptionsStruc.h
>
> When we do a remote solve, we need strings.  So in this case there  
> is a string for OSiL and a string for OSoL. The initial values go  
> into the string
>
> osoptions->osol
>
> This how we currently work things in OSSolverService.
>>
>> 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.
>
> The idea is that the calling program fills in the osOptionsStruc.  
> The calling program reads the file, creates the string, and passes a  
> pointer to osOptionsStruc to osRemoteSolve.
>
> I think the thing that is confusing is the naming, which is my  
> fault. osOptionsSruc is not akin to an OSOption object, it is akin  
> to the command line options, hence it includes the osil and osol,  
> serviceLocation, serviceMethod, etc.
>>
>>> 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.)
>
> I think all of the above can be taken care of inside osRemoteSolve.  
> The osOptionsStruc has a serviceMember method. My thinking is along  
> the lines is what Stefan is doing in GAMSLinks.

OK. That makes sense. Actually, I am prepared to sign off on this.

Wow!

Cheers

gus