dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

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.

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.

--
Martin