dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 30, 2008 at 09:47:31PM +0200, Martin Sandve Alnæs wrote:
> 2008/6/30 Johan Hake <hake@xxxxxxxxx>:
> > On Monday 30 June 2008 13:28:11 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.
> >
> > The jit compiler allready a kwarg for the representation. The only thin I had
> > to add was a dolfin_set("form representation",value). The value of this
> > parameter is checked if an uncompiled form is sent to the assemble function.
> > The value is then just passed to jit, without checkes. I also added a
> > dolfin_set("quadrature points",value) which is also just passed to the jit
> > compiler.
> >
> > The changes is only done in the python interface, i.e., in assemble.py. Maybee
> > you freek on this Anders? I thought the changes would not have any meaning
> > for the c++ interface and therefore I did not add the parameters in
> > DefaultParameters.h.
> >
> >> >> > Possible options for "form representation" are "tensor", "quadrature"
> >> >> > and (unsupported at the moment) "symbolic" (for SyFi).
> >
> > As it is now ffc check if the string is "tensor" if not it assume it is
> > quadrature. A more thorough check would be nice.
> >
> >> >> > The quadrature representation generates much less code than the tensor
> >> >> > representation.
> >
> > It did, and it compiled nicely!
> >
> >> >> 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)
> >
> > I like this.
> >
> > For now one could just get around all this parameter settings by just send a
> > precompiled form to assemble. I assume that this is what you do Martin?
> >
> > Johan
> 
> Yes, and dolfin should support raw UFC no matter what we implement with
> automatic jit calls etc. I don't see why we would need or want to
> restrict dolfin
> to using UFC implementations that are the direct output of a form compiler.
> 
> The best way to achieve good UFC compatibility is to limit
> assumptions about the form compilers to a minimum, and
> (a) ufl form
> (b) which compiler?
> (c) a generic set of compiler options (any kind of object)
> sounds to me like a good generalization.

Sounds good. We can just have a parameter

  form_compiler_options

which is passed on to the form compiler in assemble().

Should the choice of form compiler be an argument to assemble() or
should it be a global option set by dolfin_set()?

-- 
Anders


> This amounts to a simple call to
>     ufc_form = chosen_compiler.jit(ufl_form, compiler_options)
> in assemble.py, and mostly all other code should only relate to UFC.
> 
> There are many cases in which no UFL will be available and/or no form
> compiler should be involved. Using modified form compiler output for debugging
> or as workarounds for compiler limitations is one case, using precompiled forms
> for heavy equtions is another case, UFC adaptions of external codes
> should be possible to plug in, SyFi may still support working directly
> with swiginac to define the form even after UFL support is added, etc.
>

Attachment: signature.asc
Description: Digital signature