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.
