ffc team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

Martin Sandve Alnæs wrote:
> 2007/4/12, Garth N. Wells <g.n.wells@xxxxxxxxxx>:
> > Anders Logg wrote:
> > > On Wed, Apr 11, 2007 at 06:15:30PM +0200, Garth N. Wells wrote:
> > > > Anders Logg wrote:
> > > > > On Tue, Apr 10, 2007 at 06:14:12PM +0200, Garth N. Wells wrote:
> > > > > > Connected to Kristian's work on quadrature in FFC, we should think about
> > > > > > how to work with functions which do not come from a finite element
> > > > > > space. Such functions (like stress for a plasticity model or viscosity
> > > > > > for a non-Newtonian flow) are evaluated at quadrature points, rather
> > > > > > than at nodes.
> > > > > >
> > > > > > Garth
> > > > > The current design (including UFC) assumes that all functions can be
> > > > > interpolated to a finite element basis, but I think it will work for
> > > > > the quadrature code generation to imagine that you have a finite
> > > > > element basis where the quadrature points are the same as the nodes.
> > > > > (But you never need to know the basis functions.)
> > > > >
> > > > > The array of coefficients (double** w) that comes in to the function
> > > > > tabulate_tensor() should contain the coefficients, but for the
> > > > > quadrature these will be the same as the values at the quadrature
> > > > > points, and this should work out fine since the values that go in to w
> > > > > are decided by the evaluate_dof() function that also gets
> > > > > generated.
> > > > >
> > > > > So the quadrature code generator just needs to make sure that
> > > > > evaluate_dof() picks the values at the quadrature points.
> > > > The problem with this approach is that it's not possible to create a
> > > > consistent linearisation when dofs and integration points do not
> > > > coincide. Kristian and I went through this in detail a while ago.
> > > >
> > > > Garth
> > > Yes, I remember, but my suggestion was that the dofs and the points
> > > should coincide. Then the linearization should be ok?
> > I don't see how this can work. The locations of the dofs and the Gauss
> > quadrature points do not in general coincide.
>
> The idea is to construct an "artificial finite element" where the dofs
> _are_ values in the Gauss quadrature points. By generating a
> corresponding implementation of ufc::finite_element where
> evaluate_dof(i, f, ...) evaluates the function f in dof (quadpoint) i,
> and local_dimension() returns the number of quadrature points, this
> should work.

Isn't this getting overly-complicated? It would also be necessary to 
evaluate the functions and derivatives of functions on the "real" 
element at the dofs of the artificial element (to compute a stress 
update in a plasticity problem, for example).

Garth


> Some functions like evaluate_basis can have empty implementations,
> perhaps raising an exception, if no sensible implementation is
> possible.
>
> martin
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

--

Dr. Garth N. Wells
Faculty of Civil Engineering and Geosciences
Delft University of Technology
Stevinweg 1
2628 CN Delft
Netherlands

tel.   +31 15 278 7922
fax.   +31 15 278 5767
e-mail g.n.wells@xxxxxxxxxx
url    http://www.mechanics.citg.tudelft.nl/~garth