[Os-project-managers] Updates to OSoL schema

[Kipp Martin]

Hi Gus:
>
> That is actually a good question, and it calls into question a whole lot
> of stuff, perhaps the entire ticket 14. Let`s say, I want to print out a
> detailed log of what goes on inside of the OSoL parser. I now don`t
> think I can do it, because I need to have parsed the osol file before I
> can set any echo levels. So what comes first, the chicken or the egg?
>
> This means in particular that there is no way we can (let the user)
> control any print statement that gets executed before the OSoL file is
> parsed. I am starting to suspect that this might mean that aside from
> the banner about the version information we cannot have *any* print
> statement in the production code. Is this your read also?

Ugh, that does not sound good. I guess this should be at the top of our 
list when we meet next.

Cheers


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