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

Horand Gassmann Horand.Gassmann at Dal.Ca
Tue Apr 24 23:13:53 EDT 2012


Hi guys,

at the request of Kipp I write up my ideas on how to handle ticket 14.  
I can't find my original post any more, and my comments really concern  
how Andreas handles this in Ipopt.

There are several aspects.

1. Every output statement is classified by two pieces of information:  
the originating component of the output (e.g., parser, solver, etc.),  
and the severity or verbosity level, from "cannot be suppressed" to  
"crucial information" to "extremely verbose debug info".

2. All the actual output is handled by special methods that send the  
output to any file or stream that will accept them.

3. The user can define the files and streams (any number of them) and  
the verbosity level in each component.

Let's say, the user wants to collect detailed tracing on the parser  
into one file, mid-level information concerning the solver into  
another file, and all warnings regardless of the component into a  
third file. So the user would set up

file 1: parser only, all messages
file 2: solver only, everything except debug statements
file 3: all areas, warning messages only

As the program reaches output statements, each statement would be sent  
to the output routine, along with its component and verbosity. The  
output routine would examine all user-defined output files to see  
which of them match on both area and severity, and if there is a  
match, would write the output.

For example:
The statement "number of variables does not match NumberOfVariables"  
would be written to both file 1 (as a parser message) and file 3  
(because it is at least as important as a warning), but not to file 2.
The statement "Now calling the solver" would be written to file 2, etc.

This can get quite involved. We have approximately 2000 separate write  
statements in our code, andd we would have to classify each one of  
them. Also, each output statement would generate a call to the output  
routine, and this could get very inefficient. I would therefore  
suggest if we go this route to put all debug level statements behind  
#ifdef _DEBUG statements.

I do not know how we can get solver-generated output back from a  
remote site, but this is a start, and I think it would address the  
issues Stefan raised in Ticket 14.





-------------------------------------------------------

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/



More information about the Os-project-managers mailing list