Hey Colin, If you want to go wild, you might try merging my WIP bootstrapping branches (mostly firedrake+ little ufl) and the usual bendy branches (ufl+ffc + (optional) firedrake), and play with them. I just tried solving (non-mixed) Helmholtz on an icosahedral/cubed sphere, and I seem to be getting 6-order convergence on a degree 4 mesh with P5/Q5. Cheers, Miklos ________________________________ From: firedrake-bounces@imperial.ac.uk [firedrake-bounces@imperial.ac.uk] on behalf of Andrew McRae [A.T.T.McRae@bath.ac.uk] Sent: 29 October 2015 21:34 To: firedrake Subject: Re: [firedrake] Higher order bendy Yes. The simple idea of 1) building a higher-order (vector-valued) Function 2) setting its values appropriately 3) setting mesh.coordinates = new_coordinates does _not_ "just work", because UFL manages to sniff the function space of the something of the domain [you get the idea] that the coordinate field Function was built on. This, of course, is still P1/Q1. Therefore the generated C code is written as if the coordinate field is still lowest-order. I've recently discovered that simply doing mesh.coordinates = new_coordinates seems to break many things, including Firedrake par_loops and mixed problems. I understand Miklós has made significant progress on a more robust solution. If you're desperately trying to get something working in time for Monday(!), there might be a short-term hack that makes sure the underlying coordinates are (e.g.) quadratic and builds everything on top of that, but I don't remember the details. On 29 October 2015 at 21:14, Colin Cotter <colin.cotter@imperial.ac.uk<mailto:colin.cotter@imperial.ac.uk>> wrote: Hi all, Please can you remind me what the story is with higher order coordinate fields? Do I recall correctly that there is a snag? Cheers Cjc