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<[email protected]> 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<[email protected]> 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
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : [email protected] Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
