dolfin team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

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

Attachment: pgp0NZormyhPH.pgp
Description: PGP signature