Changing mesh coordinates restrictions
Hi, I am interested in using firedrake to investigate using different "higher order" meshes. By this I mean replacing mesh coordinates with piecewise polynomial function from a particular function space. A typical example would be a higher order Lagrange space but I am also interested in investigating other function spaces too (e.g. Hermite). According to the documentation I can find online this should be possible (https://www.firedrakeproject.org/mesh-coordinates.html). I've written what I think is about the simplest test case - solving a Poisson equation on a unit square (taken from https://www.firedrakeproject.org/demos/helmholtz.py.html) and used L2 projection to define the new coordinates of the identity map (I understand that interpolation isn't always defined for different spaces). Test case simple.py attached. I can run successfully with a Lagrange space of different orders: ``` (firedrake) Singularity> python simple.py Lagrange 3 Lagrange (3) mesh with 200 elements created successfully. problem on mesh defined successfully problem solved successfully error 0.053347460759624356 ``` But the equivalent code for a Hermite basis doesn't work (and gives the long errors attached). ``` (firedrake) Singularity> python simple.py Hermite &> hermite.out ``` Can anyone help with this? Is there any reason why this code shouldn't run? Thanks, Tom
Hi Thomas, Only spaces with a trivial pullback currently work as coordinate spaces. The reason for this is that the coordinate field is required in order to compute nontrivial pullbacks, so if the coordinate field itself needs to be pulled back then you only know the pullback implicitly and will need to solve a local nonlinear problem at each quadrature point for the pullback. This is significantly more complicated than just using a vector CG or DG field for the coordinates. Now, there are reasons why you might want to use a smoother coordinate field (for example to represent a moving thin structure such as a parachute) but that would require a significant extension in the guts of Firedrake. If you'd like to take that on then we can certainly talk about what you would need to do in order to achieve that. Cheers, David On 15/04/2020, 10:53, "firedrake-bounces@imperial.ac.uk on behalf of Thomas Ranner" <firedrake-bounces@imperial.ac.uk on behalf of T.Ranner@leeds.ac.uk> wrote: Hi, I am interested in using firedrake to investigate using different "higher order" meshes. By this I mean replacing mesh coordinates with piecewise polynomial function from a particular function space. A typical example would be a higher order Lagrange space but I am also interested in investigating other function spaces too (e.g. Hermite). According to the documentation I can find online this should be possible (https://www.firedrakeproject.org/mesh-coordinates.html). I've written what I think is about the simplest test case - solving a Poisson equation on a unit square (taken from https://www.firedrakeproject.org/demos/helmholtz.py.html) and used L2 projection to define the new coordinates of the identity map (I understand that interpolation isn't always defined for different spaces). Test case simple.py attached. I can run successfully with a Lagrange space of different orders: ``` (firedrake) Singularity> python simple.py Lagrange 3 Lagrange (3) mesh with 200 elements created successfully. problem on mesh defined successfully problem solved successfully error 0.053347460759624356 ``` But the equivalent code for a Hermite basis doesn't work (and gives the long errors attached). ``` (firedrake) Singularity> python simple.py Hermite &> hermite.out ``` Can anyone help with this? Is there any reason why this code shouldn't run? Thanks, Tom
Hi David, Thanks for the quick response. On 15 Apr 2020 at 11:01, Ham, David A <david.ham@imperial.ac.uk> wrote:
Only spaces with a trivial pullback currently work as coordinate spaces. The reason for this is that the coordinate field is required in order to compute nontrivial pullbacks, so if the coordinate field itself needs to be pulled back then you only know the pullback implicitly and will need to solve a local nonlinear problem at each quadrature point for the pullback. This is significantly more complicated than just using a vector CG or DG field for the coordinates.
I think I've misunderstood what these function space definitions mean. I would like to work with spaces where you push forward a reference element basis rather than pull back a basis constructed on the physical (possibly curved) domain. That is I would like to use e.g. $$ V_h = \{ \phi_h \in C(Omega_h) : \phi_h|_K \circ F_K \in \hat{P} for each element K \}. $$ where $\hat{P}$ is the appropriate reference element function space and $F_K$ is the element parametrisation. I think this is not what is implemented in simple.py. One way to use this space would be to include the transformation terms in the bilinear form (i.e. do things sort of manually). Do you think there is anyway to compute these transformations automatically? Thanks, Tom On 15 Apr 2020 at 11:01, Ham, David A <david.ham@imperial.ac.uk> wrote:
Hi Thomas,
Only spaces with a trivial pullback currently work as coordinate spaces. The reason for this is that the coordinate field is required in order to compute nontrivial pullbacks, so if the coordinate field itself needs to be pulled back then you only know the pullback implicitly and will need to solve a local nonlinear problem at each quadrature point for the pullback. This is significantly more complicated than just using a vector CG or DG field for the coordinates.
Now, there are reasons why you might want to use a smoother coordinate field (for example to represent a moving thin structure such as a parachute) but that would require a significant extension in the guts of Firedrake. If you'd like to take that on then we can certainly talk about what you would need to do in order to achieve that.
Cheers,
David
On 15/04/2020, 10:53, "firedrake-bounces@imperial.ac.uk on behalf of Thomas Ranner" <firedrake-bounces@imperial.ac.uk on behalf of T.Ranner@leeds.ac.uk> wrote:
Hi,
I am interested in using firedrake to investigate using different "higher order" meshes. By this I mean replacing mesh coordinates with piecewise polynomial function from a particular function space. A typical example would be a higher order Lagrange space but I am also interested in investigating other function spaces too (e.g. Hermite). According to the documentation I can find online this should be possible (https://www.firedrakeproject.org/mesh-coordinates.html).
I've written what I think is about the simplest test case - solving a Poisson equation on a unit square (taken from https://www.firedrakeproject.org/demos/helmholtz.py.html) and used L2 projection to define the new coordinates of the identity map (I understand that interpolation isn't always defined for different spaces). Test case simple.py attached.
I can run successfully with a Lagrange space of different orders:
``` (firedrake) Singularity> python simple.py Lagrange 3 Lagrange (3) mesh with 200 elements created successfully. problem on mesh defined successfully problem solved successfully error 0.053347460759624356 ```
But the equivalent code for a Hermite basis doesn't work (and gives the long errors attached). ``` (firedrake) Singularity> python simple.py Hermite &> hermite.out ```
Can anyone help with this? Is there any reason why this code shouldn't run?
Thanks, Tom
Hi Thomas, The Hermite space is a subspace of CG3, so you can create your Hermite coordinate field, then remap it (by interpolation or projection) to CG3, which gives the same function but now represented in a different basis. Then you can use the CG3 field as a coordinate field. all the best --Colin ________________________________ From: firedrake-bounces@imperial.ac.uk <firedrake-bounces@imperial.ac.uk> on behalf of Thomas Ranner <T.Ranner@leeds.ac.uk> Sent: 15 April 2020 13:05 To: Ham, David A <david.ham@imperial.ac.uk> Cc: firedrake <firedrake@imperial.ac.uk> Subject: Re: [firedrake] Changing mesh coordinates restrictions Hi David, Thanks for the quick response. On 15 Apr 2020 at 11:01, Ham, David A <david.ham@imperial.ac.uk> wrote:
Only spaces with a trivial pullback currently work as coordinate spaces. The reason for this is that the coordinate field is required in order to compute nontrivial pullbacks, so if the coordinate field itself needs to be pulled back then you only know the pullback implicitly and will need to solve a local nonlinear problem at each quadrature point for the pullback. This is significantly more complicated than just using a vector CG or DG field for the coordinates.
I think I've misunderstood what these function space definitions mean. I would like to work with spaces where you push forward a reference element basis rather than pull back a basis constructed on the physical (possibly curved) domain. That is I would like to use e.g. $$ V_h = \{ \phi_h \in C(Omega_h) : \phi_h|_K \circ F_K \in \hat{P} for each element K \}. $$ where $\hat{P}$ is the appropriate reference element function space and $F_K$ is the element parametrisation. I think this is not what is implemented in simple.py. One way to use this space would be to include the transformation terms in the bilinear form (i.e. do things sort of manually). Do you think there is anyway to compute these transformations automatically? Thanks, Tom On 15 Apr 2020 at 11:01, Ham, David A <david.ham@imperial.ac.uk> wrote:
Hi Thomas,
Only spaces with a trivial pullback currently work as coordinate spaces. The reason for this is that the coordinate field is required in order to compute nontrivial pullbacks, so if the coordinate field itself needs to be pulled back then you only know the pullback implicitly and will need to solve a local nonlinear problem at each quadrature point for the pullback. This is significantly more complicated than just using a vector CG or DG field for the coordinates.
Now, there are reasons why you might want to use a smoother coordinate field (for example to represent a moving thin structure such as a parachute) but that would require a significant extension in the guts of Firedrake. If you'd like to take that on then we can certainly talk about what you would need to do in order to achieve that.
Cheers,
David
On 15/04/2020, 10:53, "firedrake-bounces@imperial.ac.uk on behalf of Thomas Ranner" <firedrake-bounces@imperial.ac.uk on behalf of T.Ranner@leeds.ac.uk> wrote:
Hi,
I am interested in using firedrake to investigate using different "higher order" meshes. By this I mean replacing mesh coordinates with piecewise polynomial function from a particular function space. A typical example would be a higher order Lagrange space but I am also interested in investigating other function spaces too (e.g. Hermite). According to the documentation I can find online this should be possible (https://www.firedrakeproject.org/mesh-coordinates.html).
I've written what I think is about the simplest test case - solving a Poisson equation on a unit square (taken from https://www.firedrakeproject.org/demos/helmholtz.py.html) and used L2 projection to define the new coordinates of the identity map (I understand that interpolation isn't always defined for different spaces). Test case simple.py attached.
I can run successfully with a Lagrange space of different orders:
``` (firedrake) Singularity> python simple.py Lagrange 3 Lagrange (3) mesh with 200 elements created successfully. problem on mesh defined successfully problem solved successfully error 0.053347460759624356 ```
But the equivalent code for a Hermite basis doesn't work (and gives the long errors attached). ``` (firedrake) Singularity> python simple.py Hermite &> hermite.out ```
Can anyone help with this? Is there any reason why this code shouldn't run?
Thanks, Tom
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
participants (3)
-
Cotter, Colin J
-
Ham, David A
-
Thomas Ranner