ffc team mailing list archive

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

2008/9/5 Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>:
> Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:
>
>> 2008/9/4 Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>:
>> >
>> >
>> > Hi,
>> >
>> > I think we've addressed this before, but I'm not sure when and what the
>> outcome
>> > was. The following 3 forms all result in the same code apart from some
>> variable
>> > names:
>> >
>> > element = FiniteElement("Lagrange", "triangle", 1)
>> >
>> > v = TestFunction(element)
>> > u = TrialFunction(element)
>> > f = Function(element)
>> >
>> > c = Constant("triangle")
>> >
>> > a = c*dot(grad(v), grad(u))*dx          # 0
>> > a = dot(grad(v), mult(c, grad(u)))*dx   # 1
>> > a = dot(grad(v), grad(c*u))*dx          # 2
>> >
>> > The first two forms are basically identical. However, the latter results in
>> 2
>> > monomial terms that FFC must consider. This is obviously a waste of time
>> since
>> > one evaluates to zero anyway. Should analyze.py or something else pick this
>> up?
>> > How will this be dealt with in UFL? Or should it be handled in the
>> compilers?
>> >
>> > Kristian
>>
>> I believe I will implement automatic differentiation as algorithms
>> working directly on UFL.
>
> So, working directly on UFL inside UFL, or is it in FFC working on output from
> UFL. What I mean is, will FFC (or any other form compiler) only 'see' the
> non-zero terms?

The UFL implementation consists of two parts: the language implementation
(a = ...*dx) and utility algorithms that the form compilers can use if
they wish.
Automatic differentiation is in the algorithm part, and yes, it will remove
nonzero terms. There will be differentiation w.r.t. x,y,z,
user-defined variables,
and Functions (Jacobi computation).

>> I'll have to get back to the details later (hopefully I'll have
>> something working before the
>> end of the month).
>
> Great.
>
> Kristian
>
>> --
>> Martin
>>
>
>
>



-- 
Martin