dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Dec 19, 2006 at 06:43:30PM +0100, Garth N. Wells wrote:
> 
> 
> Johan Jansson wrote:
> > 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.
> >
> 
> Agree. There is something to be gained here, with recycling sparse 
> matrix structures in particular.

So do we call it Assembler?

Any other options?

> >> 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.
> >
> 
> Sounds good.

Something of a problem here will be that a dolfin::Form and a
ufc::form is something fixed. It can be assembled into a tensor of a
fixed rank r. You can't say that you want to think of it as an
operator (matrix) or action (vector) when you have created it.

On the other hand, in PyDOLFIN the just-in-time compilation of UFC
forms makes it possible to be dynamic about these things.

What do we want the interface to be for working with forms? There are
two very different use cases:

  1. FFC/DOLFIN

  Write form in FFC, compile, #include in C++ code.
  Here we have two different worlds: FFC Python and DOLFIN C++.

  2. PyDOLFIN

  Write form in PyDOLFIN and assemble.
  Here it's just one world and Form could mean something different.

Any suggestions for how we want the interface to look? If we decide
how we want the interface, I'm sure we can make it happen.

/Anders