Thread Previous • Date Previous • Date Next • Thread Next |
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 isin place for evaluate_basis. CG and CR elements work, and so does all linear elements and DGconstants. 2nd and 3rd order elements of BDM, RT, and DG type does notgive the same result but there are explanations for this and at least it lookslike they agree with the values you would get from FIAT if you tabulateon the reference element.evaluate_basis_derivatives works for CG elements and for most elementsof degree 1.I'm working on some kind of unit testing framework for evaluate_basisand evaluate_basis_derivatives, such that we can make sure that at least cppcode and FIAT agrees on the reference element. If this test works, thentheonly 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 otherelements 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 lessimportant, especially since it's unclear what exactly it should do andhow 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 appearin 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 createa 'normal' MixedElement? Then nothing should change with respect to the functions in representation.pyThe 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-- MarieKristian-- Marie
Thread Previous • Date Previous • Date Next • Thread Next |