ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Aug 17, 2009 at 02:27:35PM +0200, Johan Hake wrote:
> On Monday 17 August 2009 14:09:50 Anders Logg wrote:
> > On Mon, Aug 17, 2009 at 01:46:21PM +0200, Johan Hake wrote:
> > > On Monday 17 August 2009 13:23:16 Anders Logg wrote:
> > > > Fixed. I've set the log level to INFO in the JIT compiler, and then do
> > > > push_level(WARNING) before calling the code generation, then
> > > > pop_level.
> > >
> > > Nice, but I wonder if this is a hack more than a fix ;)
> > >
> > > It circumvent the whole log system, by forcing the log level to be at a
> > > certain level, without possibility for the user to control it. Now I
> > > cannot get rid of the message by altering the log level. We should at
> > > least use option["log_level"] when the setting the log level for
> > > jit_form.
> > >
> > > My fix lets the begin message be level conscious, and then we have to
> > > change all info("") call in the sub routines of analyze_form to
> > > debug("").
> > >
> > > I have done some work in this direction already. I can hand a patch if
> > > this is what we want.
> > >
> > > Johan
> >
> > I guess the problem is that what is considered as normal output when
> > running from the command-line is verbose when running in JIT mode.
>
> Ok, I didn't anticipate this
>
> > So what is normally printed on the INFO level should be moved to the
> > DEBUG level, but only when running in JIT mode. I don't know how to do
> > this, but changing the log level has much the same effect.
>
> We could add a log function to ufl.log, which do the same as logging.log. It
> takes a level argument as first argument. We could also skip the argument to
> the function and let that be a constant that is set differently using jit and
> from the command line.

How would this help? The problem as I see it is that the user (of the
JIT function through DOLFIN) wants to print INFO messages, but
disagrees with FFC about what constitutes INFO messages and thinks
that FFC INFO messages should really be DEBUG messages.

So the user would need something like

  set_offset(10)

which would move all messages up one level (in particular from INFO to
DEBUG) so that INFO messages are not printed when the INFO level is set...

> > How about this:
> >
> >   set_level(options["log_level"])
> >
> >   info("Calling FFC JIT compiler...")
> >
> >   push_level(min(WARNING, options["log_level"] + 10))
> >
> >   compile()
> >
> >   pop_level()
> >
> >   info("Done")
>
> Even if I see the features of {push,pop}_level, I think it is somewhat abusive
> to use them in a library as they prevent the user to control the level. (I
> want be a zealous about it ;) )

It doesn't prevent the user from setting the level. It just makes the
best of the situation. The user just gives one input for log level,
which is used (or should be used) when printing

  "Calling FFC JIT compiler..."

Then another level is needed for the other stuff that goes on inside
this call and the JIT compiler then makes a guess that the user is not
really interested and so treats these as DEBUG messages (or sets the
level to WARNING so that INFO is ignored).

--
Anders


> Johan
>
> >
> >
> > > > On Mon, Aug 17, 2009 at 12:57:47PM +0200, Johan Hake wrote:
> > > > > Hello!
> > > > >
> > > > > I want to get back the nice
> > > > >
> > > > >   "Calling FFC just-in-time (JIT) compiler, this may take some
> > > > > time..."
> > > > >
> > > > > message when jit compiling a form. I see that when I add a
> > > > >
> > > > >   set_log_level(INFO)
> > > > >
> > > > > in jit_form I get a bunch of uninteresting information:
> > > > >
> > > > > Compiler stage 1: Analyzing form
> > > > > --------------------------------
> > > > >
> > > > > Compiler stage 2: Computing form representation(s)
> > > > > --------------------------------------------------
> > > > >   Computing quadrature representation.
> > > > >
> > > > > ...
> > > > >
> > > > > After some research I found out that this comes from the begin(),
> > > > > end() statements in ffc.analyze_form. As it is now begin just uses
> > > > > info when it present the information.
> > > > >
> > > > > Could we let begin take a level, like:
> > > > >
> > > > >   begin(DEBUG,"Compiler stage 1: Analyzing form")
> > > > >
> > > > > or if this is too verbose, provide a set_begin_level, which the begin
> > > > > function could use. With alternative 1 we have:
> > > > >
> > > > >   begin(DEBUG,"Compiler stage 1: Analyzing form")
> > > > >   debug("Jada")
> > > > >   debug("Bada")
> > > > >   end()
> > > > >
> > > > >   begin(DEBUG,"Compiler stage 2: Computing form representation(s)")
> > > > >   debug("Jada")
> > > > >   debug("Bada")
> > > > >   end()
> > > > >
> > > > >   ...
> > > > >
> > > > > and with alternative 2 we have:
> > > > >
> > > > >   set_begin_level(DEBUG)
> > > > >   begin("Compiler stage 1: Analyzing form")
> > > > >   debug("Jada")
> > > > >   debug("Bada")
> > > > >   end()
> > > > >
> > > > >   begin("Compiler stage 2: Computing form representation(s)")
> > > > >   debug("Jada")
> > > > >   debug("Bada")
> > > > >   end()
> > > > >
> > > > >
> > > > > I go for alternative 1.
> > > > >
> > > > > Johan
> > > > > _______________________________________________
> > > > > FFC-dev mailing list
> > > > > FFC-dev@xxxxxxxxxx
> > > > > http://www.fenics.org/mailman/listinfo/ffc-dev

Attachment: signature.asc
Description: Digital signature