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
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
