ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 01, 2010 at 09:18:17AM +0100, Anders Logg wrote:
> On Sun, Jan 31, 2010 at 04:13:26PM -0800, Johan Hake wrote:
> > On Sunday 31 January 2010 15:37:41 Garth N. Wells wrote:
> > > Anders Logg wrote:
> > > > On Sun, Jan 31, 2010 at 05:51:37PM +0000, Garth N. Wells wrote:
> > > >> Anders Logg wrote:
> > > >>> On Sun, Jan 31, 2010 at 04:57:36PM +0000, Garth N. Wells wrote:
> > > >>>> Nearly all the DOLFIN demos are working again. The only remaining
> > > >>>> issue appears to be the automatic selection of the cell type for
> > > >>>> Expressions from the Python interface, see for example the Python
> > > >>>> demo. If 'cell=triangle' is added to the Expressions in the Python
> > > >>>> demo, it all looks good.
> > > >>>>
> > > >>>> Garth
> > > >>>
> > > >>> Should be fixed now.
> > > >>>
> > > >>> Which demos were failing? I checked Poisson 1D which works now.
> > > >>
> > > >> Poisson (2D) and a few others (while Poisson is broken, I don't take
> > > >> much notice of the others which are broken), and some of my solvers.
> > > >> Seems ok now.
> > > >>
> > > >> It would be useful if the representation would be printed to the screen
> > > >> when using JIT.
> > > >
> > > > You can print it by decreasing the debug level. Just set the
> > > > "log_level" option to INFO.
> > > >
> > > >> How do I control FFC options from PyDOLFIN?
> > > >
> > > > By passing an optional 'options' argument to assemble() or
> > > > VariationalProblem:
> > > >
> > > >   A = assemble(a, options={"representation": "quadrature",
> > > >                            "log_level": INFO})
> > > >
> > > > This was broken but it works again now. VariationalProblem didn't have
> > > > an options argument before but I have added it. I have also renamed
> > > > form_compiler_options --> options since it's shorter and there is no
> > > > other options dictionary.
> > >
> > > Setting FFC parameters seems a but clunky. How can one set global
> > > parameters (along the lines of 'parameters.optimize = True', which does
> > > work at the moment), and how does one know what keys can go into the
> > > options dictionary?
> >
> > I think this is done by design as PyDOLFIN should be able to use different
> > form_compilers. The option dict should just be passed to the form_compiler
> > using the options argument.
> >
> > It seems that parameter.optimize only deals with caching of tensors and that,
> >
> >    parameters.optimize_form
> >    parameters.optimize_use_dof_map_cache
> >
> > do not do anything more?
> >
> > We could force the form_compiler to define a more verbal option interface,
> > explaining the meaning of the different options, which then could be reached
> > from PyDOLFIN?
>
> I'll see what I can do. It should be fairly easy to integrate the form
> compiler options with the DOLFIN parameter system (without DOLFIN
> needing to know about specific form compiler options).
>
> But one thing that bugs me is that it's called 'options' in FFC and
> 'parameters' in DOLFIN. Is there some logic behind this or should we
> try to make it uniform?

I'm renaming options --> parameters in FFC. Seems like the simplest
solution (easier than renaming in DOLFIN).

--
Anders

Attachment: signature.asc
Description: Digital signature