← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #04523

Re: pointmap

  Thread Previous • Date Previous • • Thread Next 


Anders Logg wrote:

On Sun, Mar 25, 2007 at 10:44:58AM +0200, Garth N. Wells wrote:


Anders Logg wrote:

On Sat, Mar 24, 2007 at 06:52:04PM +0100, Garth N. Wells wrote:

In the old FFC output format, the function

   void pointmap(Point points[], unsigned int components[],
                 const AffineMap& map) const
returns in components[] a degree of freedom identifier (e.g. 0 for u, 1 for v, 2 for p, etc) for each entry in the element tensor. How can we get this information with the new UFC format? (or how can we avoid requiring it?) 

Garth

Do you mean for evaluating dofs on user-defined functions (to get the
expansion coefficients in the nodal basis to put in the array w) or
for setting boundary conditions?

I think that in both cases it should be enough to evaluate the dofs on
the ufc::function, but we might have missed something. The function
evaluate_dof() takes a function f that may or may not be vector-valued
and computes the scalar value of dof i. So for a 2D vector-valued
Lagrange element of degree 1, dof 0 will be f_0(v0), dof 1 will be
f_0(v1), dof 2 will be f_0(v2), dof 3 will be f_1(v0) etc. The
function evaluate() in ufc::function needs to compute all values of
the possibly tensor-valued function.
What I don't see is how to make the link between a user-defined function in terms of x and j (j being u0, u1 and p for Stokes), and ufc::function which is in terms of x and i (i = 0 --> space_dimension). 

Garth


The ufc::function needs to evaluate all values at once, not one at a
time. So for 2D Stokes, the array values would be of length 3.

We could keep the current interface eval(p, i) for Function and then
call this for each i to fill in the array values, but perhaps we
should change the interface of the class Function in DOLFIN so that
for a vector-valued function one needs to set all the values at once.
An advantage of this would be that one would not need the

   if ( i == 0 )
     return 3.0;
   else if ( i == 1 )
     return 5.0;
   else
     return 6.0;

Instead, one would write

   values[0] = 3.0;
   values[1] = 5.0;
   values[2] = 6.0;

The array values is a contiguous array that may represent something
tensor-valued as well. If the function takes values in R^{3x3} then
the array has length 9.
For a vector and scalar function this would be be nicer, but we have to make sure that it works nicely with mixed elements. When applying boundary conditions, not all vector components will always be supplied and something like an boolean array will be required to denote Dirichlet bc's. 

Garth


There's one thing I don't know how to handle yet though. So far (in
the implementation of assembly) we have only needed to send data into
the UFC interface, so we can take a DOLFIN::Cell, create a ufc::cell
from that and send it through the interface. But now, we need to send
in a ufc::function to evaluate_dof(), which will call the
ufc::function which will in turn call the users eval method. The
evaluate() method in ufc::function gets a ufc::cell, but there is no
way to convert this to a DOLFIN::Cell (since we don't know the global
cell number).

I guess the solution could be to do as we do know, when the Cell is
not an argument to eval() but it can be accessed by a call to
Function::cell() if needed?

/Anders
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

Follow ups

References

  Thread Previous • Date Previous • • Thread Next