[Os-project-managers] Updates to OSoL schema

[Kipp Martin]

Hi Gus:

One thing that we have all discussed many times, and agreed upon, is 
that OSSolverService.exe NEVER EVER interprets an OSoL file. The 
OSSolverService.exe simply passes the OSoL file (perhaps as a string, 
perhaps as an in-memory object) to the appropriate solver. (Jun, you and 
I even discussed this before Gus came on board and we agree this was a 
good policy.) The appropriate solver then reads the optimization element 
and grabs its appropriate options. Only the Java server reads the OSoL 
file and tries to do anything with options other than the optimization 
solver. In this proposoal were does <outputOptions> get processed?

Cheers


>
> to follow up on the conversation Jun and I had this afternoon, I attach
> for your enjoyment a proposed new version of the OSoL schema. (I
> checked, and it seems to be valid.) I summarize below the main features.
>
> 1. There is a new element added to the <job> element, <outputOptions>.
> <outputOptions> consists of an optional <stdout> element, followed by
> zero or more <outputStream> elements.
>
> 2. <stdout> has an optional attribute "defaultPrintLevel" as well as an
> optional boolean attribute "returnFromRemoteSolver", which will replace
> the <other> mechanism we implemented recently. I hope this is not too
> much work, and I hope that the current approach is more unified and
> therefore better. <stdout> also has an optional sequence of zero or more
> <special> elements, where special print levels can be set for different
> areas/components of the code. Unlike Ipopt we can add this customization
> feature at little extra cost, and I think it will be worth it.
>
> 3. The intent of the "returnFromRemoteSolver" is to return the stdout
> capture to the local machine. For a local serve I think it should do
> nothing (although I can be convinced otherwise, if that turns out to be
> easier to implement).
>
> 4. If the <stdout> element is missing, there should be a suitable global
> default print level, just so that we have covered all the angles.
>
> 5. The <outputStream> element is similar to the <stdout> element, except
> that it has a mandatory attribute "fileName" instead of
> "returnFromRemoteSolver". This underscores that we do not return files.
> In fact, the desired behavior is to intercept the presence of this
> element in the java servlet and to throw an error if encountered, as
> suggested by Kipp this afternoon. For a local solve, on the other hand,
> the user is king and can do pretty much whatever makes sense at the
> time. There can be as many files as necessary, with as much detail as
> needed, and customized as to the area/component that writes the output.
>
> 6. As for the implementation, I envision proceeding along the lines of
> Andreas Waechter's code in ipopt. There is an array of output streams,
> each with an array of print levels (one print level for each
> area/component of the code). This array is populated by the OSoL parser.
>
> 7. Every piece of output is sent to a global output handler that checks
> each of the output streams to see if the print level and area/component
> allow the item to be printed to that stream.
>
> 8. I still think that we should have a two-tiered print level hierarchy,
> with only the first layer accessible to production code, and both layers
> available to a code compiled in Debug mode. The distinction can be made
> by defining a global variable _DEBUG (in fact, I believe this variable
> is defined already), and hiding each debug print behind an #ifdef _DEBUG
> ... #endif construct.
>
> 9. If we can get agreement on these basic design features, then we
> should move on to defining the areas/components as well as the print
> levels we want to make available --- here we can again look to Ipopt for
> guidance.
>
> 10. And finally we will have to classify each of the 2000 or so print
> statements by area/component (easy) and print level (deadly boring and
> tedious).
>
> So that's it. Please comment on the schema changes if you get a chance.
>
> 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/


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