Subject: [Ffc] Broken demos

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 31 Jan 2010 16:57:36 +0000

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

---

From: Anders Logg <[email-masked]>
Date: Sun, 31 Jan 2010 18:44:15 +0100

> 'cell=triangle' is added to the Expressions in the Python demo, it all

Should be fixed now.

Which demos were failing? I checked Poisson 1D which works now.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 31 Jan 2010 17:51:37 +0000

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

How do I control FFC options from PyDOLFIN?

Garth

---

From: Anders Logg <[email-masked]>
Date: Sun, 31 Jan 2010 20:25:44 +0100

> It would be useful if the representation would be printed to the screen

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.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 31 Jan 2010 23:37:41 +0000

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

Garth

---

From: Johan Hake <[email-masked]>
Date: Sun, 31 Jan 2010 16:13:26 -0800

On Sunday 31 January 2010 15:37:41 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.
> >>>

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?

Johan

> Garth
> 
> > --
> > Anders
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>

---

From: Anders Logg <[email-masked]>
Date: Mon, 1 Feb 2010 09:18:17 +0100

> explaining the meaning of the different options, which then could be reached

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?

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Mon, 1 Feb 2010 09:30:41 +0100

> 'parameters' in DOLFIN. Is there some logic behind this or should we

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

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Mon, 1 Feb 2010 10:01:13 -0800

On Monday 01 February 2010 00:30:41 Anders Logg 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.
> > > > >>>
> > > > >> 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.
> > > > >
> > > > > 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.
> > > >
> > > > 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.
> > >
> > > 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?
> >

:)

Johan