Subject: [UFC-dev] tabulate_coordinates()?

From: Kristian Oelgaard <[email-masked]>
Date: Mon, 07 May 2007 08:18:20 +0200

Hi,

I'm implementing code for the tabulate_coordinates() function from the
ufc::dof_map class. The interface is like this:

  /// Tabulate the coordinates of all dofs on a cell
  virtual void tabulate_coordinates(double **coordinates,
                                    const ufc::mesh& m,
                                    const ufc::cell& c) const

My current implementation uses linear elements to interpolate the coordinates
from the cell vertices.

Now the question is what I need the mesh for as an argument? Maybe the
implementation is supposed to be completely different?

Kristian

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 7 May 2007 10:54:42 +0200

> implementation is supposed to be completely different?

I don't think it's needed. It should be removed.

The SyFi implementation for all elements with point-valued dofs simply
apply the affine map (+translation) to the local coordinate for each
dof.

martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 7 May 2007 10:57:30 +0200

> apply the affine map (+translation) to the local coordinate for each

Great. I'll remove it from the interface.

/Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Mon, 07 May 2007 10:03:43 +0200

> apply the affine map (+translation) to the local coordinate for each

OK, I was just wondering about non-affine mappings where one could have the
location of the mid-edge nodes in the case of 2nd order Lagrange elements as
part of the information from the mesh. But maybe a completely different approach
/implementation will be needed in the case of a non-affine mapping?

Kristian

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 7 May 2007 11:14:34 +0200

> /implementation will be needed in the case of a non-affine mapping?

ufc::mesh doesn't contain any coordinates, only global mesh sizes.

Isn't the coordinates of vertices found in ufc::cell enough for all
non-affine mappings? Anything that can be mapped to the reference cell
should be possible to compute from vertex coordinates. If not, we
might have a problem here.

martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 7 May 2007 11:20:07 +0200

> might have a problem here.

To map something to a curved boundary, we will need more than just the
vertex coordinates. For a quadratic mapping, we would need to know
where to map the edge midpoints.

I think we are limited to affine mappings for now. (UFC 2.0 could do more.)

/Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Mon, 07 May 2007 10:27:03 +0200

> > ufc::mesh doesn't contain any coordinates, only global mesh sizes.

OK, then we don't need mesh.
 
> I think we are limited to affine mappings for now. (UFC 2.0 could do more.)

OK, I'll stick with the current implementation then.

Kristian

> /Anders
> _______________________________________________
> UFC-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufc-dev
>

---

From: [email-masked]
Date: Mon, 7 May 2007 12:08:17 +0200 (CEST)

>> > > > > I'm implementing code for the tabulate_coordinates() function
>> from
>> the
>> > > > > My current implementation uses linear elements to interpolate
>> the
>> > > > coordinates
>> > > > > from the cell vertices.
>> > > > >
>> > > > > Now the question is what I need the mesh for as an argument?
>> Maybe
>> the
>> > > OK, I was just wondering about non-affine mappings where one could
>> have
>> the
>> > > location of the mid-edge nodes in the case of 2nd order Lagrange
>> elements
>> as
>> > > part of the information from the mesh. But maybe a completely
>> different
>> approach

In the case with higher order geometries, I think the cell could/should be a
higher order cell, ie. containing the extra coordinates.

Kent

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 7 May 2007 12:39:50 +0200

> higher order cell, ie. containing the extra coordinates.

Would it be enough with coordinates for facet midpoints?
Or are more coordinates needed for higher order stuff?
If it's enough with facet midpoints, we could simply add
a function "bool ???::need_facet coordinates() const"
similar to need_mesh_entities(i). If something more general
is needed, this function would need some arguments.

martin

---

From: [email-masked]
Date: Mon, 7 May 2007 12:46:18 +0200 (CEST)

> is needed, this function would need some arguments.

You need as many points as is needed to represent the higher order polygon.
Eg. in 2D on a triangle I think you need
 (order+1)*(order+2)/2 points, (the same as the number of basis
functions of a Lagrangian element).

Kent

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 7 May 2007 12:50:10 +0200

> functions of a Lagrangian element).

If the number and position of coordinates are well defined for a given
order, we could define this in the mesh chapter of the UFC manual and
add "unsigned int need_geometry_order()" (close to
"need_mesh_entities"), or "unsigned int cell_order()" (close to
"cell_shape").

martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 7 May 2007 12:55:23 +0200

> "need_mesh_entities"), or "unsigned int cell_order()" (close to

My suggestion is we let this wait until UFC 2.0 and not add anything
more to 1.0.

/Anders