dolfin team mailing list archive

[Shawn Walker <walker@xxxxxxxxxxxxxxx>]

On Sat, 25 Apr 2009, Anders Logg wrote:

> On Wed, Apr 22, 2009 at 05:28:30PM -0400, Shawn Walker wrote:
> > Here is the changeset that adds a `higher_order_coordinates' variable for
> > storing higher order mesh data.  This is a very minor change so please
> > push this.
> >
> > A changeset for DOLFIN is coming immediately after this.
> >
> > - Shawn
>
> I'm not sure what to do about this. It's problematic to add
> experimental work to UFC since it must be stable. In particular, any
> small change to ufc.h means that all forms must be recompiled
> everywhere for everyone.

I see...

> So before we make a change to UFC, we need to know exactly what we
> need. Which also means I can't import your DOLFIN patch since it
> depends on the UFC patch.
>
> I see you've added
>
>    double** higher_order_coordinates;
>
> to ufc::cell. This is analogous to what is now implemented in
> MeshGeometry and the mesh XML format so I think it's good.
>
> The question is what other information we need. As it works now (for
> the standard ufc::cell), UFC code generated by a form compiler knows
> what to expect from for a ufc::cell argument. If higher order mappings
> should work the same way, then the generated code and thus the form
> compilers need to know which mapping should be used and also the
> length of higher_order_coordinates. Is this what you were thinking?

Yes, that is what I was thinking.  There needs to be some variable that 
stores the number of DoF's used to represent the geometry.  And I also 
think there should be a string with the "name" of the mapping.  That way 
there can be an error check, because presumably FFC will `assume' a type 
of mapping (based on user input).

For the stuff I did in MeshGeometry, I plan on going back and making a 
single struct variable that has all the pertinent higher order mesh 
variables together.  Depending on what is needed in ufc::cell, the same 
thing may be in order.

> Before we do much more about it, more people need to weigh in on it as
> it affects DOLFIN, UFC, SyFi and FFC.

ok.  I say you need:

1.  higher order vertex data that is already in the PROPER
    order/numbering. 
2.  the number of higher order vertices.
3.  a string identifying the type of map i.e. "P2_Lagrange".
4.  AND a boolean variable stating whether the cell is affine or not (i.e. 
straight or curved).  This is useful because then the tabulate_tensor 
routines can have a switch between the standard code, and the probably 
more complicated curved element code.  Remember, in most cases, only the 
boundary triangles need to be curved; the interior elements can be 
straight (IN MOST CASES).

And I would probably put this into a single struct.  I don't think a whole 
separate class is necessary.  But I am open to suggestions.

I hope people comment on this.  This effects many things besides the 
matrix assembly.  It affects interpolation, computing the facet normal, 
etc...

- Shawn