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

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
> What you wrote below is logical and makes sense. However, the ticket  
> uses the words "register an output handler".  Is that what you are  
> describing below?

I assume so. This is very much the blind leading the blind. I cannot  
recall the terminology Andreas uses in this regard, but "register an  
output handler" is a description I would accept as fitting for the  
mechanism I described.

> When I asked Stefan to elaborate here is what he wrote in an email:
>
> "I like the message handling of Ipopt, where you can register several
> journals that can handle output for different categories with differing
> print levels.

Yes, this is exactly how I understood and described the mechanism.

> For the GAMSlinks we then have a GamsJournal that is used
> to direct the output into the GAMS output channels.
>
> Cbc and Osi-interfaced solvers use CoinMessageHandler. I do not really
> like them because the message handler sometimes insert spaces or
> newlines which make them very inflexible about what kind of output you
> can print, but we have a GamsMessageHandler that does the job. Not all
> Osi links support this yet. For Clp, Cbc, DyLP it should work. For the
> trunk versions of Cpx, Msk, Xpr it should also work. Symphony I don't
> remember.
>
> For Bonmin and Couenne one has to pass in both an Ipopt::Journal and a
> CoinMessageHandler."
>
> Somehow I feel that something more is involved.

Well, Andreas has a raft of methods that either format or don't format  
the output. I thought this was a bit of overkill, but maybe we need to  
look at that more closely. I have not looked at the CoinMessageHandler  
and hence cannot comment on the differences. But Stefan's comment  
about formatting makes me think that it is at heart very similar to  
the Ipopt approach.

Cheers

gus

>> 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/
>>
>> _______________________________________________
>> Os-project-managers mailing list
>> Os-project-managers at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>
> -- 
> 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/