dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 30 June 2008 16:27:51 Johan Hake wrote:
> 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.

Sorry for the unconsistent english, I need vacation...

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

but the form is placed in the present directory, not in $HOME/.ffc/cache

Anyone know why?

Johan

> > >> 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
>
> > --
> > Martin
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev