On Mon 2008-08-25 11:25, Shawn Walker wrote: > Actually, I am not sure if having the extra mesh data as a separate > function would work. That would mean you need to pass this function to > subroutines that compute the basis functions and their derivatives, and > routines that compute facet normals, etc... It seems that this higher > order mesh information should be more internal. Unless you were thinking > of making another Function variable internal to MeshGeometry?
It would be nice to store and manipulate the coordinates just like any other Function. Suppose the basis operations accept (in some way) a NULL coordinate vector which means that the element Jacobian is the identity everywhere. That way you could manipulate mesh geometry by evaluating forms to construct a new geometry Function. Then register this new Function (i.e. compute associated element Jacobians, required facet normals). Not all operations make sense without coordinates, but basis evaluation, derivatives, and integration in the element interior still do. I think treating the coordinates as a special case would duplicate a lot of code. Of course in the pre- and post-processing you still need to be able to handle `normal' mesh descriptions. For preprocessing, this means projecting nodal coordinates into the finite element basis. They will normally be exactly representable in the FE basis so an elementwise (DG) projection would be sufficient (in the nodal case, it can just be evaluation). Going the other way is just point evaluation (or a continuous Galerkin projection). Thoughts? Jed
pgpuoJAPEWOMI.pgp
Description: PGP signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
