[Os-project-managers] Some more thoughts about ticket 14

[Horand Gassmann]

Some more thoughts about ticket 14.

1. The mechanism in Ipopt (at least in theory) provides for a two-way  
classification into area and severity for every output statement in  
the code. This allows (at least in theory) the user to define  
("register") multiple output streams into which specific output  
statements can be directed. For instance, one output stream could be  
dedicated to a very detailed log of the parser algorithm --- and  
nothing else, a second stream could contain detailed information about  
iterations of the algorithm, etc.

2. In practice, Ipopt makes available TWO output streams, stdout plus  
ONE file, and it only allows a global severity level that applies to  
all areas.

3. Aside from efficiency considerations there is no reason to limit  
the output to two streams.

4. We should probably code the necessary information into the <job>  
element. Unfortunately it does not seem enough to use the <other>  
element for that purpose, though, because it only uses a name, value  
and description. The name needs to be reserved for something like  
"outputStream", the name of the option, and the value could be a  
global print level, but where do we put the file name? In the  
description field? I don't think so.

5. I think we should design a special element for this, perhaps  
<journalist> with the following attributes:

streamName (string, required)
defaultPrintLevel (integer, optional; defaults to 0 or 1)
numberOfSpecials (or whatever we want to call them; integer, defaults to zero)

Then there would be a matching list of <special> elements, each of  
which has an area  (enumeration; required) and a printLevel (integer,  
required)

6. Here is an example:

<journalist streamName="parserOutput.txt" defaultPrintLevel="2"  
numberOfSpecials="2">
     <special area="osolParser" printLevel="99"/>
     <special area="solverInterface" printLevel="0"/>
</journalist>

This would send detailed output from the osol parser to  
parserOutput.txt, suppress any output from the solverInterface, and  
use the default print level of 2 for all other output.

7. There should be one preset journalist, stdout.

8. I have some qualms about letting any output be redirected on a  
remote system, as this can open a backdoor for mischief. I think only  
stdout should be configurable for a remote solver.

9. As mentioned before, I think that the allowable print levels should  
depend on whether the OSSolverService was compiled in Debug or Release  
mode, for reasons of efficiency.

I will think about areas next.

Let me know what you think about this. If there is anything unclear,  
let me know, and I will try to elaborate.

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/