syfi team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/5/2 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.

It shouldn't be very different, but I think those problems will be the
same any way.

Frankly, I don't think SFC will cope well with p=10 anyway.
I plan to fix some bottlenecks to make it more robust.
However, there are some things I need UFL to be able to do,
so it may take a little time.


>> 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)?

Note that SFC doesn't yet have form files in the same sense as FFC does.
I'm working on the unified form language (UFL), but it's not finished.
There are some SFC demos in the newest syfi under examples/solvers/.


>> 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 :-)

That is a good idea, and it can be merged back in UFC for UFC 2.0.

--
Martin