On sø., 2008-08-17 at 00:08 -0400, Shawn Walker wrote:
I think you are right. I would propose the following:
1. Add a meshfunction to the mesh.xml file. The name of it will
correspond to a new enum variable in ufc::cell. For example, say we have
piecewise quadratics for the local map, so we call it "P2_map". Maybe
later this could be made a more permanent xml data type, but for now this
should be ok. The mesh function would just be a vector lagrange 2nd
order function. And there would also be a boolean function on each cell
to say whether the element is straight or not. This of course rules out
mixing curved types, i.e. having P3 and P2 in the same mesh. But I am ok
with that for now.
2. In ufc::cell, we have another enum variable called "map_type":
enum map_type {P1_map, P2_map, P3_map, etc...}
Of course, this will only be for lagrange type polynomial maps. But this
enum variable can have other types (i.e. iso-geometric). We then create
a
variable "map_type cell_map_type;"
Yes, we probably would need one extra variable for the map.
The way I see it, if one assume that all elements in the mesh has the
same order, the main work would be to create a dolfin mesh containing
a higher order geometry. Once this is done, you would need to ensure
that the coordinates in ufc::cell follows the UFC convention locally.
Finally, the computation of the Jacobian, the inverse of the Jacobian
and the determinant of the Jacobian has to be moved inside the
quadrature loop. This is the only modification to the form compiler, I
believe. The finite elements, its derivatives, dofs etc
stay the same.
Hence, once a higher order mesh is up an running, there should only
be minimal modifications to the form compilers and UFC.
3. When the mesh is read in, and the element is created, I think the
"coordinates" variable can store the vertex positions of the element,
including the extra ones for the curved sides. If not, then some other
variable would need to be created to store it; actually, that may be
better. Also, the "cell_map_type" will be set to either P1_map, or
P2_map, or etc...
4. The tabulate_tensor routine will have a switch to pick the correct
routine for computing the tensor coefs. This will require modifying FFC
which I don't know yet.
5. Another thing that should change will be the basis function
evaluations. This may be a pain. Computing the inverse map to get the
location of the coordinates in the reference element may be inconvenient.
This can be ignored for now; this isn't really critical for what I would
like to do.
I am a little confused on where the ufc::cell data gets set by the data
in
the mesh.xml file. I'm still very new to this code. Any help would be
appreciated. If I am totally off on this, please say so!
Have a look in UFCCell.
Kent
