[Os-project-managers] Updates to OSoL schema

[Horand Gassmann]

Hi guys,

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSoL2.xsd
Type: application/xml
Size: 26144 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/os-project-managers/attachments/20120726/866f2f06/attachment-0001.wsdl>