ffc team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

Kristian Oelgaard wrote:
> On 29 January 2010 18:46, Marie Rognes <meg@xxxxxxxxx> wrote:
> > Kristian Oelgaard wrote:
> > > On 29 January 2010 16:55, Marie Rognes <meg@xxxxxxxxx> wrote:
> > > > Marie Rognes wrote:
> > > > > Kristian Oelgaard wrote:
> > > > > > On 29 January 2010 01:23, Anders Logg <logg@xxxxxxxxx> wrote:
> > > > > > > There seem to be just a couple of issues remaining in order of
> > > > > > > importance:
> > > > > > >
> > > > > > > 1. QuadratureElement
> > > > > > >
> > > > > > > 2. DOLFIN fem unit test
> > > > > > >
> > > > > > > 3. evaluate_basis_derivatives
> > > > > > >
> > > > > > > 4. RestrictedElement
> > > > > > >
> > > > > > > Among these, I would say 1-2 are crucial to fix before 0.9.0,
> > > > > > > but 3-4 are less crucial.
> > > > > > >
> > > > > > > It would be good to have evaluate_basis_derivatives working, but I
> > > > > > > don't know how much work is involved.
> > > > > >
> > > > > > First my apologies for the late reply, Internet was down again all
> > > > > > morning and it pisses me off.
> > > > > >
> > > > > > Now that BDM elements also compiles for gcc it looks like 
> > > > > > everything is
> > > > > > in place for evaluate_basis.
> > > > > > CG and CR elements work, and so does all linear elements and DG
> > > > > > constants. 2nd and 3rd order elements of BDM, RT, and DG type 
> > > > > > does not
> > > > > > give
> > > > > > the same result but there are explanations for this and at least it
> > > > > > looks
> > > > > > like they agree with the values you would get from FIAT if you 
> > > > > > tabulate
> > > > > > on
> > > > > > the reference element.
> > > > > >
> > > > > > evaluate_basis_derivatives works for CG elements and for most 
> > > > > > elements
> > > > > > of
> > > > > > degree 1.
> > > > > >
> > > > > > I'm working on some kind of unit testing framework for 
> > > > > > evaluate_basis
> > > > > > and
> > > > > > evaluate_basis_derivatives, such that we can make sure that at least
> > > > > > cpp
> > > > > > code and FIAT agrees on the reference element. If this test 
> > > > > > works, then
> > > > > > the
> > > > > > only bug can be in the transformation back to the physical 
> > > > > > element, but
> > > > > > since this works for CG elements I don't see why it shouldn't for 
> > > > > > other
> > > > > > elements too.
> > > > > > However, I'll put this development on hold until Quadrature and
> > > > > > Restricted elements work.
> > > > > >
> > > > > > > RestrictedElement is also good to have, but I would say it is less
> > > > > > > important, especially since it's unclear what exactly it should 
> > > > > > > do and
> > > > > > > how it should be implemented.
> > > > > >
> > > > > > It should be implemented like I did it in the old FFC :)
> > > > > > w.r.t. the demo, it should test if restrictions on a MixedElement 
> > > > > > are
> > > > > > propagated to the sub elements and that a restricted element can 
> > > > > > appear
> > > > > > in a
> > > > > > MixedElement.
> > > > >
> > > > > I'm taking care of RestrictedElement (onto facets/cells etc) at ze
> > > > > moment.
> > > >
> > > >
> > > > This was actually slightly more mind-boggling than planned.
> > > > I ended up letting FFC convert restricted mixed elements to mixed
> > > > restricted
> > > > elements.
> > > > That kept the codegeneration complexity low and my head from 
> > > > exploding.
> > > >
> > > > I'll clean up and push tomorrow, unless that is too late ;)
> > > >
> > > > Also, question for Kristian: About the IR for evaluate_basis for mixed
> > > > elements: You want a (non-nested) list of sub-elements, right?
> > >
> > > Yes, I think that should work. But why do you need to bother if you 
> > > create
> > > a 'normal' MixedElement? Then nothing should change with respect to the
> > > functions in representation.py
> >
> > The IR for evaluate_basis for mixed element iterate[s|d] over the
> > ufl_element. I don't want to do that (since that would be an
> > ufl.ElementRestriction.)
>
> I don't follow. If you have a mixed element
>
> mixed_element = elem0 + elem1
>
> and then restrict it to facets:
>
> element = mixed_element["facet"]
>
> which is now a RestrictedElement. 

on the UFL side, yes.

> Then, as I understand it, you create a new MixedElement equivalent to:
>
> element = elem0["facet"] + eleme1["facet"]

on the FFC side, yes

> in this case the evaluate_basis IR (and all other IRs) will only see a 
> 'normal' MixedElement and we can proceed without problems.

Exactly. That is the bonus of this approach :)

But I did not want to tamper with the UFL representation of the element. 
Hence, it is way easier to iterate
over the FFC element rather than the UFL element in the IR of 
evaluate_basis. Just wanted
to check with you that the way I planned doing that was correct. For the 
other IRs I know what
the correct way of doing this is ;)


--
Marie

> Kristian
>
> > --
> > Marie
> >
> >
> >
> > > Kristian
> > >
> > > > --
> > > > Marie