← Back to team overview

ffc team mailing list archive

Re: [Branch ~ffc-core/ffc/main] Rev 1498: Added support for CellVolume from UFL.

 

On Thu, Jul 08, 2010 at 02:36:09PM +0100, Garth N. Wells wrote:
>
>
> On 08/07/10 13:13, Anders Logg wrote:
> >On Thu, Jul 08, 2010 at 01:02:43PM +0100, Garth N. Wells wrote:
> >>
> >>
> >>On 08/07/10 12:59, Anders Logg wrote:
> >>>On Thu, Jul 08, 2010 at 12:00:38PM +0100, Garth N. Wells wrote:
> >>>>
> >>>>
> >>>>On 08/07/10 11:49, Kristian Oelgaard wrote:
> >>>>>On 8 July 2010 08:22, Garth N. Wells<gnw20@xxxxxxxxx>    wrote:
> >>>>>>On Jul 8 2010, Anders Logg wrote:
> >>>>>>
> >>>>>>>On Wed, Jul 07, 2010 at 10:34:39PM +0100, Kristian Oelgaard wrote:
> >>>>>>>>
> >>>>>>>>On 7 July 2010 20:22, Garth N. Wells<gnw20@xxxxxxxxx>    wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>On 07/07/10 20:14, Anders Logg wrote:
> >>>>>>>>>>
> >>>>>>>>>>On Wed, Jul 07, 2010 at 06:26:20PM +0100, Kristian Oelgaard wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>Supporting CellVolume makes it possible to do:
> >>>>>>>>>>>
> >>>>>>>>>>>CG = FiniteElement("Lagrange", triangle, 2)
> >>>>>>>>>>>DG = FiniteElement("DG", triangle, 0)
> >>>>>>>>>>>v = TestFunction(DG)
> >>>>>>>>>>>f = Coefficient(CG)
> >>>>>>>>>>>vol = triangle.v
> >>>>>>>>>>
> >>>>>>>>>>Would it be better to call it vol or volume instead of v? Or does it
> >>>>>>>>>>have to be a one-letter word?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>. . . or call it 'volume'.
> >>>>>>>>
> >>>>>>>>It can be whatever we want, I just followed what was already there.
> >>>>>>>>Should we then rename 'd', 'n' and 'x' to 'geometric_dimension',
> >>>>>>>>'facet_normal', and 'spatial_coordinate' while we're at it?
> >>>>>>>
> >>>>>>>I think d, n, x are fine, but v does not necessarily look like a
> >>>>>>>volume to me (it looks like a test function).
> >>>>>>>
> >>>>>>
> >>>>>>I agree - d, n and x are all commonly used, but v for volume isn't.
> >>>>>
> >>>>>I changed 'v' to 'volume' and fixed a few bugs along the way.
> >>>>>
> >>>>>On a related note, should we implement CellDiagonal too?
> >>>>>We use cell.diagonal() for MeshSize in SpecialFunctions.h of DOLFIN
> >>>>>and since we often use MeshSize for the 'h' coefficient in DG forms
> >>>>>e.g., PoissonDG we could remove the need for this function evaluation.
> >>>>>The code to compute the CellDiagonal could just be copied from
> >>>>>IntervalCell, TriangleCell and TetrahedronCell of DOLFIN and dumped in
> >>>>>codesnippets.py.
> >>>>>
> >>>>
> >>>>What if we call it 'Circumradius'?
> >>>>
> >>>>I recall that the agreed not have have CellSize because of the
> >>>>ambiguity in its definition, but circumradius is unambiguous, so I
> >>>>vote to add it.
> >>>
> >>>Isn't 'diameter' better? It is shorter and well-defined
> >>>(2*circumradius).
> >>>
> >>
> >>'diameter' isn't well defined. We can use it, but we would need to
> >>define it as being 2*circumradius.
> >>
> >>Garth
> >
> >Why isn't it well-defined? The diameter of a set T is
> >
> >   d = sup_{x,y \in T} ||x - y||
> >
> >and that should be the same as 2*circumradius unless I'm mistaken.
> >
>
> What's the set T? At a glance, the above is true if T is not the
> polygon, but the set of all points inside the circle inside which
> the polygonal can be inscribed.

Yes, don't know what I was thinking. Let's try again... For a
polygon, the diameter should be the same as the longest edge which
should be very easy to compute so why not use that?

--
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References