Kristian Oelgaard wrote:
On 29 January 2010 18:46, Marie Rognes <[email protected]> wrote:
Kristian Oelgaard wrote:
On 29 January 2010 16:55, Marie Rognes <[email protected]> wrote:
Marie Rognes wrote:
Kristian Oelgaard wrote:
On 29 January 2010 01:23, Anders Logg <[email protected]> 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
_______________________________________________
Mailing list: https://launchpad.net/~ffc
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
