[Os-project-managers] Updates to OSoL schema

[Horand Gassmann]

Horand Gassmann <Horand.Gassmann at dal.ca> wrote:

> Kipp Martin <kmartin at chicagobooth.edu> wrote:
>
>> Hi Gus:
>>>
>>> That is actually a good question, and it calls into question a whole lot
>>> of stuff, perhaps the entire ticket 14. Let`s say, I want to print out a
>>> detailed log of what goes on inside of the OSoL parser. I now don`t
>>> think I can do it, because I need to have parsed the osol file before I
>>> can set any echo levels. So what comes first, the chicken or the egg?
>>>
>>> This means in particular that there is no way we can (let the user)
>>> control any print statement that gets executed before the OSoL file is
>>> parsed. I am starting to suspect that this might mean that aside from
>>> the banner about the version information we cannot have *any* print
>>> statement in the production code. Is this your read also?
>>
>> Ugh, that does not sound good. I guess this should be at the top of  
>> our list when we meet next.
>
> I agree, and I have thought some more about it. I think Andreas ran  
> into a similar problem with Ipopt, and we can learn from his  
> solution. There are two ways we communicate with our program:  
> Through schema files, and on the command line. Since we cannot put  
> the output options into the OSoL schema, the only other choice is  
> the command line. I think we have no choice, we have to go there.
>
> With command line options we have to be frugal, however. I think it  
> is mandatory that the user be able to
> 1. Set a global print level for messages to stdout
> 2. Set a file name to which to send (possibly different) output
> 3. Set a global print level for messages to that file
>
> In addition it would be nice (for debugging purposes) to be able to  
> control *one* area in which the global print level is overridden. At  
> this point, though, I no longer consider this essential.

I think we can achieve all of these things with just three command  
line options:

printLevel <int>   to control the print level of stdout
outputFile <name>  to set the name of a file for (possibly different) output
filePrintLevel <int> to set the global print level for the secondary  
(file) channel

The point is that a lot of sins can be hidden in a print level. We  
will have, I'd say, about 10 print levels max, with perhaps more than  
one level for debug output. Let's be generous and double this to 20.  
And we will have, I don't know, 10 areas. So the print level scheme  
could be this:

default print level 1
if printLevel < 100, global print level (for all areas)
otherwise printLevel  div 100 gives the number of an area (we need to  
use enumerations for these things, anyway), and printLevel mod 100  
gives the print level in that area. (Same for filePrintLevel.)

So

filePrintLevel 3

says: use global print level 3 in all areas;

filePrintLevel 512

says: use the default print level in all areas, but use print level 12  
in area 5, etc.

Comments? Do you think this can work? Is it too baroque? Overkill?  
What do you say?

Cheers

gus

> We should still allow the more detailed output redirect in the API,  
> however; much the way Ipopt does it.
>
> 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/
>
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>



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

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/