[Os-project-managers] Fork in the Road

[Kipp Martin]

Hi Gus:

>
> Hmmmh. Interesting. So you think the problem is in the OSoL file. I
> would have thought the much bigger problem is in the OSrL file, where
> different layers of the software can write to (and potentially
> overwrite) the same elements. The OSoL file is easily fixed. We have, in
> fact, set up the elements already in such a way that the server should
> not and cannot act on anything that is in the <optimization> element,
> and the solver cannot act on anything else.

I view the OSoL/OSrL as the same. We are combining OSpL with OSrL/OSoL 
and this is fundamentally wrong.

> distinction between a local solve and a remote solve, in that a local
> solve does not and should not see anything other than the <osol> element
> at all. So we should again send an OSoL file to the local solver and an
> OSpL file with an embedded <osol> element to a remote solver server.
> What I said in my message of this morning still holds, I think.


EXACTLY!!! EXACTLY!!!!

The local solver gets OSoL and returns OSrL. That was the intention from 
day 1. The remote solver gets and sends OSpL with OSoL/OSrL imbedded. 
Inside solve we implement your idea 4 with local_solve() and 
remote_solve(). We the remote_solve() sends OSpL with OSoL inside.

I think the above is really clean and YOU MADE A HUGE BREAKTHROUGH.

But I still need my wine.

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