dolfin team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

On Mon 2008-08-25 09:12, Shawn Walker wrote:
>
> On Mon, 25 Aug 2008, Jed Brown wrote:
>> I'm not aware of any standard for cubic and higher order meshes (or any
>> visualization software that could use it).  In that case, I think the
>> most reasonable thing is to store full element connectivity without
>> reference to vertices, that is (Region->Face), (Face->Edge),
>> (Edge->Vertex) and then store coordinates as a function over this space
>> (however you store such things, such as by indexing interior degrees of
>> freedom for every element/facet).  Note that there are many more
>> coordinates than vertices.
>
> I agree that for visualization, you probably don't need 3rd order or  
> higher.  But I can definitely envision PDE problems (discretized) that 
> may require it for other reasons.  I am a little confused by what you 
> said for storing the coordinates.  So the full element connectivity would 
> still require changing MeshTopology?

I diverged.  The point is that in order to have higher order mappings,
we would like to store coordinates in the finite element basis, i.e. the
union of the reference elements.  The adjacency thing is more about
managing continuity for higher/mixed order and nonconforming meshes.

>> Providing a canonical numbering for nodes on say, a cubic hex, requires
>> 98 vertices.  Also, the mesh function approach plays nicely with mixed
>> order discretization, modal bases, and nonconforming meshes.
>
> how exactly would the mesh function approach work?  Do you mean use  
> MeshFunction?

Well, Function.  This requires being able to define a Function before
the mesh geometry has been defined.  I haven't looked at the
implementation, but perhaps this could be done by explicitly setting the
element Jacobian to the identity.

Jed

Attachment: pgpdamwFIRfTQ.pgp
Description: PGP signature