Subject: [FFC-dev] facet normal implementation

From: Peter Brune <[email-masked]>
Date: Sun, 23 Aug 2009 14:15:45 -0500

Hey -

Is there any interest (besides me) for the implementation of the facet
normal in FFC?  I've found reason to not want these as propagated from
DOLFIN.  I would vote that they should be calculated in the
facet_determinant code-snippet, as they consist of a subset of the values
computed therein, and are typically required by related pieces of code.
There also seems to be reasonable machinery for this from FIAT.

Thanks,

- Peter

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 23 Aug 2009 20:45:17 +0100

Peter Brune wrote:
> DOLFIN.  

It would be nice to compute the normal inside the generated code. 
Kristian is best placed to comment.

Garth

I would vote that they should be calculated in the
> facet_determinant code-snippet, as they consist of a subset of the 
> values computed therein, and are typically required by related pieces of 
> code.  There also seems to be reasonable machinery for this from FIAT.
> 
> Thanks,
> 
> - Peter
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev

---

From: Kristian Oelgaard <[email-masked]>
Date: Sun, 23 Aug 2009 21:55:10 +0200

> > code.  There also seems to be reasonable machinery for this from FIAT.

It shouldn't be too difficult. For affine mappings we could easily put this in
with the facet_determinant code-snippet and just remove it if it is not use. We
do this often anyway. However, how should the normal be computer for higher
order geometries and where would we put that?

Kristian

---

From: Peter Brune <[email-masked]>
Date: Sun, 23 Aug 2009 15:08:28 -0500

The higher-order normal is the reference normal transformed by the Piola
transform.  Interestingly, it's actually easier to get the local facet
length out of this than it is to compute it "manually".  This is of course:

n_iso = (1 / |J_surface|) * J * n_ref (I might be missing an inverse... it's
getting late)

Anyways, you can normalize the normal computed here to get the local
jacobian determinant for the surface, because you can just use your
higher-order cell jacobian to get your normal going in the right "direction,
and of course it's... normalized, making life easier.  Two birds with one
stone.  This would mean that  facet integrals would need the corresponding
cell Jacobian, but that's the case with both affine and higher-order
normals.  Right now I'm doing this by appending a higher-order normal
function as well as higher-order coordinates to the form with a transformer.

Thoughts?

- Peter

---

From: Anders Logg <[email-masked]>
Date: Sat, 29 Aug 2009 00:20:42 +0200

On Sun, Aug 23, 2009 at 03:08:28PM -0500, Peter Brune wrote:
> transform.  Interestingly, it's actually easier to get the local facet length
> out of this than it is to compute it "manually".  This is of course:
>
> Anyways, you can normalize the normal computed here to get the local jacobian
> determinant for the surface, because you can just use your higher-order cell
> jacobian to get your normal going in the right "direction, and of course
> it's... normalized, making life easier.  Two birds with one stone.  This would
> mean that  facet integrals would need the corresponding cell Jacobian, but
> that's the case with both affine and higher-order normals.  Right now I'm doing
> this by appending a higher-order normal function as well as higher-order
> coordinates to the form with a transformer.
>
> Thoughts?

Sounds good to me but I don't have time to fix it.

--
Anders