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