[Os-project-managers] Fork in the Road

[Kipp Martin]

Hi Gus:

>
> But I remember that 1.0 had its problems too. In particular, it seems
> that it violates encapsulation also in that it sends and receives two
> different pieces, OSpL/OSoL and OSpL/OSrL, respectively. With true
> encapsulation, shouldn't that just be a single item? It's also asking

Yes.

> quite a bit of the user to remember which option bits to put into the
> OSpL file and what to put into the OSoL file, and on the return it is
> mighty inconvenient to have to look in two places for the information.
>
> In fact, I have always had a bit of a problem with the two-way nature of
> OSpL. I have always felt that there should be two flavors of it, if you
> will, one for sending, and one for receiving. And the OSoL and OSrL
> should be *packaged* within them as separate elements. But maybe that
> could be achieved with a choice element. If the OSpL file contains an
> <osol> element, it is meant to be sent to the server, if it contains an
> <osrl> element it is a return file, and if it contains neither, then we
> can't tell, and we probably don't need to worry about it.
>
> Much of that we have already. When we send an OSoL to the server, only
> the <optimization> element needs to be passed on to the remote solver,
> so we could just convert the <optimization> element into an <osol>
> element, with proper OSoL (3.0) syntax. (I am ambivalent as to whether
> we need to go back and call the combined file an OSpL file.) The server
> can then strip out the <osol> element and pass it to the remote solver.
> No mess, no fuss. But I think there should be a mandate that the server
> not modify the <osol> element. It is of course free to read it, but
> modifications should be verboten.
>
> This has one particular disadvantage: a local solve() is _different_
> from a remote solve(). A local solve needs to be given an OSoL file (or
> the <osol> element only), while the remote solve() needs the larger
> version. This could be confusing.

You have hit on the problem exactly!  We need to encapsulate. The OSoL 
should be nothing more than solver options. The OSrL should be nothing 
more than solver results. I think our big mistake was taking elements 
from OSpL and putting them in OSrL/OSoL. I see no problem with putting 
OSoL/OSrL inside OSpL. It actually makes a lot of sense.

However, I do not think we should do any kind of element conversion, 
i.e. changing the optimization tag to an osol tag. I really don't like 
the idea of changing tag names if that is what you are proposing. I 
think OSrL/OSoL should be what we had in 1.0 (of course with the changes 
we have made to the optimization element) and we put this inside OSpL.
>
> On the way back we can do the same thing. The remote server writes an
> OSrL file, which the server reads and packages into an <osrl> element in
> the OSpL(out) file. (No modifying of the <osrl> element!) The only

Yes, this is exactly the way I see it. No modifying the OSrL element.

Cheers


> problem I see off the top of my head is that timing information and
> possibly other system-related items can show up in two places. That is
> not nice, but given that there are two different places that can
> contribute this information, I don't really see a way around it.
>
> These are of course major changes to how we do things. I have copied to
> the managers list, so we have a record for later. I also invite your
> comments, of course.
>
> Cheers
>
> gus
>
>


-- 
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.
--