Subject: [FIAT-dev] Simplicial elements

From: Harish Narayanan <[email-masked]>
Date: Wed, 23 Jan 2008 22:07:26 -0500

Greetings,

I understand from the documentation in FIAT that all its reference 
elements treat spaces as simplicial complexes. Is there an obvious 
difficulty in extending this to non-simplicial elements (assuming the 
mesh is suitably generated elsewhere)?

I would be curious to read some literature on this topic if someone were 
willing to point me to it.

Thanks,
Harish

---

From: "Robert Kirby" <[email-masked]>
Date: Thu, 24 Jan 2008 07:57:43 -0600

Well, FIAT really does simplices because they're hard.  Hexes and rectangles
have tensor-product bases for H(div), H(curl), and H1, so you should really
be doing spectral-type techniques.  See the thesis of Heintsch (sp?) at NYU
for some interesting work on high order H(div) and H(curl) a few years ago.
 Not sure if it got published, but it was very good
I now have a user at Sandia who wants the other shapes, so I will be looking
at doing this, either in Python or else with straight tensor-products in
C++.  Of course, pyramids and prisms present wrinkles of being somewhere
in-between.

On Jan 23, 2008 9:07 PM, Harish Narayanan <[email-masked]> wrote:

> _______________________________________________
> FIAT-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/fiat-dev
>

---

From: Anders Logg <[email-masked]>
Date: Thu, 24 Jan 2008 15:18:51 +0100

On Thu, Jan 24, 2008 at 07:57:43AM -0600, Robert Kirby wrote:
> have tensor-product bases for H(div), H(curl), and H1, so you should really be
> doing spectral-type techniques.  See the thesis of Heintsch (sp?) at NYU for
> some interesting work on high order H(div) and H(curl) a few years ago.  Not
> sure if it got published, but it was very good
> 
> I now have a user at Sandia who wants the other shapes, so I will be looking at
> doing this, either in Python or else with straight tensor-products in C++.  Of
> course, pyramids and prisms present wrinkles of being somewhere in-between.

There has also been some interest in adding quads and hexes to the DOLFIN
mesh library (which should not be very hard) so this might also happen
(if someone has time to implement it).

-- 
Anders

> 
> 
> On Jan 23, 2008 9:07 PM, Harish Narayanan <[email-masked] > wrote:
> 
>     Greetings,
>

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 24 Jan 2008 16:15:28 +0100

> (if someone has time to implement it).

As a sidenote, SyFi supports code generation for quads and hexes (at
least Lagrange elements).

-- 
Martin

---

From: "Robert Kirby" <[email-masked]>
Date: Thu, 24 Jan 2008 10:06:19 -0600

I will also point out that, even if FIAT had these element shapes, it would
be some work for FFC to adapt to use them.  We would be in the world of
non-affine transformations, which means that the tensor representation in
FFC would not work.  It can be generalized, but with some cost in run-time
operation count.
Rob

---

From: Anders Logg <[email-masked]>
Date: Thu, 24 Jan 2008 17:58:44 +0100

On Thu, Jan 24, 2008 at 10:06:19AM -0600, Robert Kirby wrote:
> I will also point out that, even if FIAT had these element shapes, it would be
> some work for FFC to adapt to use them.  We would be in the world of non-affine
> transformations, which means that the tensor representation in FFC would not
> work.  It can be generalized, but with some cost in run-time operation count.
> 
> Rob 

Yes, or we could just go for quadrature in that case (ffc -r quadrature).

-- 
Anders

> On Jan 24, 2008 9:15 AM, Martin Sandve Aln s <[email-masked]> wrote:
>

---

From: "Robert Kirby" <[email-masked]>
Date: Thu, 24 Jan 2008 11:05:11 -0600

Still, in this case you have to handle a non-affine mapping so the jacobian
varies spatially.  The quadrature module will have to be generalized.  I
imagine that isn't too hard once the geometry is in place.

Rob

On Jan 24, 2008 10:58 AM, Anders Logg <[email-masked]> wrote:

> >     > > Well, FIAT really does simplices because they're hard.  Hexes
> and
> >     rectangles
> >     > > have tensor-product bases for H(div), H(curl), and H1, so you
> should
> >     really be
> >     > > doing spectral-type techniques.  See the thesis of Heintsch
> (sp?) at
> >     NYU for
> >     > > some interesting work on high order H(div) and H(curl) a few
> years ago.
> >      Not
> >     > > I now have a user at Sandia who wants the other shapes, so I
> will be
> >     looking at
> >     > > doing this, either in Python or else with straight
> tensor-products in
> >     C++.  Of
> >     > >     difficulty in extending this to non-simplicial elements
> (assuming
> >     the
> >     > >     I would be curious to read some literature on this topic if
> someone
> >     were

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 24 Jan 2008 21:39:42 +0100

> imagine that isn't too hard once the geometry is in place.

quadrature representation mirrors more or less the tensor contraction, the
difference is that it loops the quadrature points (to compute the 'reference
tensor') runtime. But still it might be easier to adapt things in the quadrature
module to other elements.

Kristian