ffc team mailing list archive

[kent-and@xxxxxxxxx]

> ok, but I have a couple other questions/comments?
>

I would also very much like higher order meshes. I'll try to help out, but
I also have alot on my stack.

> 1. Has there been a decision on what kinds of curved meshes will be
> allowed?  And what would the mesh format be?  This seems to be the first
> decision.  It would seem natural to only allow polynomial based maps
> (for now), i.e. a quadratic triangle would require a 2nd order polynomial
> mapping (instead of a 1st order map).  You could also have higher degrees
> if you wanted.  I think the 'curved' mesh feature could be implemented
> first.  And the assembly could just IGNORE the extra curvy info for each
> triangle (for now).
>
> 2. For the assembly, I think it is still possible to compute the matrices
> exactly in SOME cases.  For example, a mass matrix could be computed
> exactly, as well as \int_{\Omega} q div(u), because the det(J) would
> cancel the 1/det(J) part of the inverse of the gradient map.  Of course,
> the stiffness matrix cannot be computed exactly.  For this, I think
> quadrature is the only way.  Or one could maybe take advantage of doing an
> asymptotic expansion (taylor series) of the algebraic expression and
> compute that using enough terms based on the desired number of digits of
> accuracy.  I don't know.

I don't think it is hard to get this into the form compiler (which support
quadrature).
I think the main job will be to get higher order mesh in dolfin and make sure
that the numbering makes sense in UFC.



>
> 3. One could add another boolean property to each triangle called:
>
> Is_Straight
>
> This could give a switch between computing exactly, and using quadrature.
> Most meshes will have straight interior elements; you don't really need
> them inside so much.  only the triangles with a face on the boundary
> would be curved.  So this would help prevent possible performance hit of
> doing high order quadrature.
>
> 4. How hard would it be to understand UFC~FFC for someone who knows just a
> little Python and a decent amount of C++?

You don't need to know much Python.

>
> If there is anything written up on how FENICS wants to do this (i.e.
> desired mesh format, etc...) please tell me.

A list of coordinates and then an element list with its node numbers. The
nodes may
be numbered according to the UFC numbering in the same way that FFC
already does
for higher order elements.

Kent