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

[Kipp Martin]

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

Cheers



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