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