Subject: Re: [UFC-dev] [FFC-dev] [HG FFC] Added quadrature representation file for ufl forms. Doesn't do anything yet.

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 8 Jan 2009 11:20:17 +0100

Seems we lost the list. Below are some pointers to where
I think you should begin to get into the UFL codebase.

On Thu, Jan 8, 2009 at 9:32 AM, Kristian Oelgaard
<[email-masked]> wrote:
> Quoting Martin Sandve Alnæs <[email-masked]>:
>
>> On Thu, Jan 8, 2009 at 9:19 AM, Kristian Oelgaard
>> <[email-masked]> wrote:
>> > Quoting Martin Sandve Alnæs <[email-masked]>:
>> >
>> >> It might be that we can share quite a lot of quadrature generation
>> >> code. Tell me when you make plans for implementing this (I'm working
>> >> on it).
>> >
>> > Sounds good. I was planning on starting today. The first problem for me
>> will be
>> > to figure out what information I receive from UFL about a form. Maybe you
>> can
>> > point me to places in syfi to look at?

I'm currently reworking some of the algorithms that are "between"
ufl and syfi, so this is not a stable part right now.

When I'm done (hopefully fairly soon, I need to get it done!),
you can get a linearized computational graph from an expression,
sorted in a suitable order for code generation and partitioned
by dependencies on cell data, coefficients and basis functions.

>> > My plans also involve implementing automatic selection of representation
>> and in
>> > this respect it would be nice to get the meta data from integrals such that
>> a
>> > user may be given full control over which representation to use for
>> different
>> > terms in the *.ufl file.
>> >
>> > Kristian

Take a look at Form (form.py) and Integral (integral.py).
Each Integral has an integrand variable, which is an Expr
object (expr.py). The Expr subclasses are divided in two
groups, subclasses of Terminal (terminal.py) which are
leaves of the expression tree and "the rest", or non-terminals,
which have children in the expression tree (see Expr.operands()).

It is important to keep everything (Form, Integral and Expr objects)
immutable, so never  change an existing object, but recreate it from
its data. I'll try to write up other core design principles.

Keep in mind that UFL is not limited to sums of monomials.
It seems to me all FFC developers are thinking like that :)
This is a valid form:
    u = Function(element)
    v = TestFunction(element)
    a = exp(u***2)*v*dx

The implementation is split into two parts:
  ufl/*.py
  ufl/algorithms/*.py
the algorithms part is not to be used by end-users, this is where
we put code that analyses and transforms UFL expressions
which can be used by form compilers. Take a look at
algorithms/traversal.py and algorithms/analysis.py to begin with,
I'm currently working on several other parts there.

Take a look at the tests too. If you wonder about how something
behaves, it would be great if you could test it by writing unit tests :)
If you expect something to work, send the test here and I'll look at it.
I haven't written comprehensive enough tests...

Sadly, this is not really a good time for me to be in a "support role",
since I have some deadlines and a lot to do, but I'll try to answer
specific questions you have, and your review and testing is valuable to me.

Martin