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> 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