dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 30, 2008 at 01:28:11PM +0200, Martin Sandve Alnæs wrote:
> 2008/6/30 Anders Logg <logg@xxxxxxxxx>:
> > On Mon, Jun 30, 2008 at 12:50:39PM +0200, Martin Sandve Alnæs wrote:
> >> 2008/6/28 Anders Logg <logg@xxxxxxxxx>:
> >> > On Sat, Jun 28, 2008 at 08:55:44PM +0200, Johan Hake wrote:
> >> >> Hello!
> >> >>
> >> >> I tried to compile an advection diffusion form using Streamline Upwind Petrow
> >> >> Galerkin stabilazing method, similar to the one introduced in DOLFIN 0.6.4.
> >> >> Using 3 dimensional and first degree Lagrange elements, FFC/g++ chokes when
> >> >> the produced code is compiling. It wont finish compile... Is this a known
> >> >> problem and a limitation of FFC/g++?
> >> >
> >> > Try compiling with the -r quadrature option. I guess this is not
> >> > supported in the JIT compiler yet, but could easily be added. There
> >> > should be an option
> >> >
> >> >  dolfin_set("form representation", "quadrature");
> >> >
> >> > in the same way as there is an option "optimize". See if you can
> >> > figure it out and send a patch, or else file a bug report.
> >> >
> >> > Options are added in DefaultParameters.h in DOLFIN and the JIT
> >> > compiler is in jit.py in FFC.
> >> >
> >> > Possible options for "form representation" are "tensor", "quadrature"
> >> > and (unsupported at the moment) "symbolic" (for SyFi).
> >> >
> >> > The quadrature representation generates much less code than the tensor
> >> > representation.
> >>
> >> SFC also does quadrature (in fact most users (me) mainly use that),
> >> and there are many possible compilation options. I don't think it's a good
> >> idea to mix form compiler details into dolfin. We should talk about this
> >> to find a solution that doesn't discriminate form compilers :-)
> >
> > I think we need have to. It is DOLFIN that sends the form to the form
> > compiler so DOLFIN needs to make a choice which form compiler to use.
> >
> > But I agree we should not discriminate form compilers. Any form
> > compiler that handles UFL/UFC should be possible to use.
> 
> Then we should at least have an options system that doesn't
> need every possible form compiler option pre-registered.
> 
> And setting form compiler options globally for all jit calls may not
> be enough, different forms may call for different compilation options.
> 
> As I see it, dolfin doesn't need to know more than the option "form compiler".
> Compiler-specific options should be applied to the particular compiler.
> 
> Like:
> dolfin_set("form compiler", "ffc")
> ffc_set("form representation", "quadrature")
> A = assemble(ufl_form, ...)
> 
> or:
> dolfin_set("form compiler", "sfc")
> A = assemble(ufl_form, ..., options=sfc_options_dict)

Looks good. FFC also takes a dictionary of options so we might want to
do this for all form compilers:

  dolfin_set("form compiler", "foo")
  A = assemble(ufl_form, ..., options=foo_options_dict)

-- 
Anders

Attachment: signature.asc
Description: Digital signature