dolfin team mailing list archive

[Peter Brune <prbrune@xxxxxxxxx>]

I saw this thread and had already started running the tests I had for this
with the latest FFC to see if anything had changed recently.  I never made
isoparametry through UFL public because I could never get the efficiency to
be reasonable.  The situation appears to have improved a little bit from a
year ago, but not much.  With the latest FFC, it's about 10x slower (in 2D)
to assemble Poisson with P1 for the test/trial space and P2 for the
coordinates than the same problem with affine coordinates.  It's even worse
if you include things like Piola-transformed surface normals into the mix.
When I was working on this I only assembled a very small fraction of the
elements (around a cylinder in a flow) with the parametric Jacobian, so it
worked OK for small problems.

I believe that it would do much, much better if the optimizing quadrature
compiler in FFC supported fractions.  This is necessary because you need to
apply the inverse isoparametric Jacobian, which includes 1 / |J|, to any
basis function derivatives in the form.

For reference, here are the assembly times for the iso(super, I suppose is
more accurate)-parametric, optimized, and non-optimized Poisson problems in
2D on a 256x256 square (with the parametric coordinates just being the
regular coordinates passed through).

isoparametric assembly      |        3.2017      3.2017     1
optimized assembly          |       0.34515     0.34515     1
regular assembly            |       0.36524     0.36524     1

I got really deep in FFC trying to make this work with no success, but this
was before the rewrite.  I'd be willing to declare victory on this one and
submit my code if someone else were willing to make it fast enough to use.
There's also the issue of how exactly to extend the interface to support
this in an elegant fashion.  Right now I just call a function that takes a
form and a parametric Jacobian, runs a Transformer on the form, and spits
out a new form.

- Peter


On Wed, Mar 23, 2011 at 3:30 PM, Anders Logg <logg@xxxxxxxxx> wrote:

> Peter Brune claims to have solved this by a small addition to the form
> language that automatically expresses the curved elements as a mapping
> and expands appropriately (and invisible to the user) those mappings
> to yield a form that may then be assembled. The higher order geometry
> is then expressed as a vector-field on the mesh.
>
> Perhaps Peter can be pushed to polish up on his code and submit it.
>
> --
> Anders
>
>
> On Wed, Mar 23, 2011 at 07:46:57PM +0000, Garth N. Wells wrote:
> > We haven't really looked at this. It was discussed a while back, but no
> > one has committed much time to it. We struggled to settle on an
> > appropriate abstraction to push on with.
> >
> > Garth
> >
> > On 23/03/11 18:40, Douglas Arnold wrote:
> > > What is the status of curved (e.g., isoparametric) elements in dolfin?
> > > I gather they are not implemented in the main branch.   Has anyone
> > > done anything with this can be used?  Is there any example code?
> > > (For example, if you want to
> > > solve the Poisson problem in a disc and get better than 2nd order
> > > convergence, you need to do better than polygonal approximation of
> > > the disc.)
> > >
> > >  -- Doug
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~dolfin
> > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~dolfin
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>
>