[Os-project-managers] Some proposals about OSSolverService and OSAmplClient

[Horand Gassmann]

Hi guys,

at Kipp's request I collect here number of changes to OSSolverService  
that I would like to propose. Some are innocent enough, while others  
are quite far-reaching. It would be useful to get a discussion going  
about this.

1. I have implemented a generic command line parser, which is just a  
special constructor for an osOptionsStruc struct. This one should be  
non-contentious. I can live with the names, although I would  
personally prefer to change the struct to a class and to call it  
OSCommandLine. If we get agreement on some of the later items, I will  
make this change at the same time.

2. I would like to use this command line parser in both  
OSSolverService and OSAmplClient. There are two reasons for this: (i)  
it is easier to maintain one parser than many, (ii) I can see someone  
wanting to use AMPL (or perhaps some nicer interface such as AMPL+ ---  
if that still exists) or other such environment as a front end to our  
service methods.

3. We stated at one point that we want to promote the use of OSiL and  
to discourage the use of mps, nl, etc. I think it would be very useful  
to this end to allow the user to save the resulting OSInstance. I  
propose a new command line option saveOsil <filename>, which would  
write the OSInstance into <filename> after it has been converted from  
mps, nl, etc. This is a minor thing, but I can see great advantages.

4. I would like to unify the order in which our executables search for  
an instance. In OSSolverService there are two ways, and in  
OSAmplClient there could be three: (i) a file mentioned on the command  
line, (ii) an osil instance mentioned in an <instanceLocation>   
element in an osol file, (iii) an in-memory string representation  
built by the algebraic modelling system. Within (i), I am not overly  
picky about the order, but it seems we are already searching for osil,  
nl, mps, GAMS dat, lindo files, in that order. This is something we  
should sign off on and make consistent throughout.

5. I would like to make the service methods and some embedded  
utilities (such as the instance selector under point 4. into a  
separate file and/or module. In this way every interface that calls  
the solve or send method can make use of the same code. This improves  
encapsulation and maintainability. However, I am still looking for a  
good mechanism to implement point 4.(iii) selectively (and, perhaps  
dependent on where it is called from). In OSSolverService we skip  
4.(iii) altogether, in OSAmplClient we look for a .nl file at that  
point, in GAMSlinks we would look for a dat string, etc. (Any  
suggestions?)

6. I do not like the global variable osoptions in  
OSSolverService.cpp:183. However, eliminating this might mean that I  
would have to change the signature of the service methods from, e.g.,  
solve() to solve(osOptionsStruc *osoptions).

7. Perhaps I should state again my reasons for wanting to do all of  
this: As a part of our paper and also because of the way we positioned  
OS, we should demonstrate the full communication path from the AML to  
the solver (and back). In order to do that, we need to address the  
fact that, e.g., AMPL codes some of its options into the nl string  
(regardless of whether that is passed in form of an nl file  
asynchronously or pulled out of the model and data inside AMPL). Since  
we need to make these changes for two systems I view it as imperative  
that this be implemented once only. To that end I propose to write a  
new module OSnl2os, to replace OSnl2osil, that writes information into  
both an instance and an option object.

With the exception of point 6. above (and the second half of 1.) this  
does not change the API, and I am not 100% sure whether 6. and 1.b  
would necessitate going to version 3.0. I know this is pretty  
far-reaching, but I would welcome discussion on any and all of my  
points.

Cheers

gus




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

Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

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