dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Aug 24, 2008 at 03:55:49PM -0400, Shawn Walker wrote:
>
> On Sun, 24 Aug 2008, Anders Logg wrote:
>
>> The main problem here seems to be how to even represent a higher-order
>> mesh. Are there any existing conventions for this?
>
> Not that I know of, other than the 'obvious' way.
>
>> Doing it locally is fine. For each cell, we have a convention for how
>> we number vertices, edges and faces (it's in the UFC manual) but we
>> don't have a convention for how to number mesh entities globally.
>>
>> We could use the dof map (for Lagrange elements) that FFC computes
>> based on the numbering of mesh entities, but that computation is based
>> on a global numbering of edges and faces, and that numbering depends
>> on the algorithm for computing these entities (in TopologyComputation).
>>
>> So, the only solution I see is to store the coordinates cell-wise,
>> which would mean duplicating the data, both in the XML file and for
>> storing the coordinates in MeshGeometry.
>
> I think this would be ok.  But it must still be possible to update the  
> mesh geometry (i.e. update the coordinates of all the control points for  
> the curved triangle geometries) in, say, a time-stepping loop.  For  
> example, you would need this for ALE moving mesh applications.  This 
> means you must update the individual cell geometries in a 'compatible' 
> way.  I haven't actually thought about this.  Would this be do-able?  If 
> so, I have no problem with keeping the higher order mesh geometry 
> completely local.  So the question is: "Is it possible to access and 
> change the local higher order mesh geometry such that the higher order 
> mesh coordinates stay consistent?"
>
> - Shawn

Yes, we just need to have a global list of coordinates, and then
mappings from all cells to the coordinate indices of those cells.

Then one can move a coordinate once and it will affect all cells
sharing that coordinate.

My suggestion would be to have one single list of coordinates like we
do now in MeshGeometry. The first N coordinates would be the vertex
coordinates (like now) and then the remaining coordinates (if any)
would be stored per cell, so that coordinate N is the coordinate for
the first edge midpoint of the first cell, coordinate N + 1 is the
coordinate for the second edge midpoint of the first cell etc.

The other option would be to store all coordinates for the first cell,
then the second etc, but I think it's advantageous to store all vertex
coordinates first since that is what we mostly use.

-- 
Anders

Attachment: signature.asc
Description: Digital signature