[Os-project-managers] Updates to OSoL schema

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

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

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?

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/