dolfin team mailing list archive

[Johan Jansson <jjan@xxxxxxxxxxx>]

On Tue, Dec 19, 2006 at 04:08:56PM +0100, Anders Logg wrote:
> Even if FFC does not yet generate code in UFC, it might be time to
> start thinking about how to organize the assembly when we
> (re-)implement it for the new interface. Here are some issues:
> 
> 1. Do we want to keep the interface
> 
>    FEM::assemble(a, A, mesh);
> 
> or do we want to change this? Another option would be
> 
>    Assembler assembler;
>    assembler.assemble(a, A, mesh);
> 
> which could allow for reuse of data. We could also add assemble()
> functions in namespace dolfin that create an Assembler object and
> calls it which would allow
> 
>    assemble(a, A, mesh);

I think it would be good if the assembler has some state, then we
could cache data and reuse if we're assembling again on the same mesh
for instance.

> 2. The UFC specification is the same independent of the rank of the
> global tensor, which might help us remove some of the duplicated code.
> 
> 3. Do we want to keep the abstraction BilinearForm, LinearForm,
> Functional? Or could we throw them away and just use Form? I imagine
> something like
> 
>     class Form
>     {
>     public:
>   
>        ...
>        
>        friend FEM;
> 
>     private:
> 
>        ufc::form form;
> 
>     }
> 
> Opinions?

I think Form is a good idea. The same thinking could be extended to
FFC, like we talked about. Where the specification of a form is just a
(Python) function, which returns a certain type depending on if and
where the test and trial functions are placed.

  Johan