syfi team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

On Fri 2008-05-02 12:34, Martin Sandve Alnæs wrote:
> Let me try to summarize what's already there.
> 
> In FFC, I think the action of a form can be accomplished by simply changing
>   u = TrialFunction(element)
> to
>   u = Function(element)
> such that u becomes a coefficient, the vector to multiply with.

Oh, right.  We can use a linear form to compute the action of the bilinear form
without getting matrix entries.  So this part is already implemented and well
tested.  Great.

> In SFC, you can write
>   b = Action(a)
> if a is a Form. This will simply do the element matrix-vector
> product symbolically prior to compilation.
> (This hasn't been used or tested very well, but it is short and simple)

How do you think this would compare to using a linear form?  For high order
elements, the symbolic expression could be so huge the compiler has trouble
doing the necessary CSE.

> SFC supports hexahedral elements, FFC does not.

It sounds like I can get what I want if I write a form file, specify high order
hex elements, just have a linear form, and specify quadrature.  Can I expect
that applying this form will be O(p^4)?

> Adding mappings to the form compilers shouldn't be too hard with quadrature.
>
> UFC doesn't cover high order geometries, varying cell types in a mesh
> or varying element orders. This is probably the largest obstacle.

Indeed.  We can do some proof of concept work without these things, but they are
clearly desirable in the long term.  It would greatly complicate the spec,
though.  Would it be better to create a new HpUFC with these features?  Of
course, if hp-adaptivity is made easy, everyone will be doing it :-)

Jed