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 <[email protected]> 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 : [email protected] > > > Unsubscribe : https://launchpad.net/~dolfin > > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dolfin > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
