dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Jan 13, 2009 at 11:50:42PM +0000, Garth N. Wells wrote:
> 
> 
> Shawn Walker wrote:
> > I cleared out the old email some because the discussion had changed a 
> > little.  See below for a recap of higher order mesh data stuff:
> > 
> > -------------
> > 
> >>>> It will if we want to be able to store a higher-order function space
> >>>> as a function space with a regular mesh and an additional function
> >>>> that stores the layout of the coordinates.
> >>>>
> >>> Perhaps that is not the best way to do the higher order mesh 
> > coordinates.
> >>> If we want the higher order mesh data to be a general Function 
> > (requiring
> >>> a FunctionSpace), then I do not see how you can get away from needing 
> > the
> >>> FiniteElement signature associated with it, and possibly other things.
> >>>
> >>> Even if you have the vector of data and the DoFmap, that info must 
> > still
> >>> be used to create a Function/FunctionSpace in the code.  And in order 
> > for
> >>> that to work the DoFmap must be `compatible' with the particular
> >>> FiniteElement you will be using.  I probably have this wrong, sorry for
> >>> my confusion.
> >>>
> >>> Another way to do the higher order mesh data would be to keep a little
> >>> simpler.  Have a vector of data, a DoFmap, and an indicator about the
> >>> degree of polynomial used.  This would be less general but not bad.  In
> >>> case of higher-order mesh data, you will ALWAYS use a continuous 
> > lagrange
> >>> finite element.  At least I cannot think of a situation where you would
> >>> use something else.  Would this not be desirable?
> >>
> >> If we decide to remove input/output for Functions and FunctionSpaces
> >> (as I've understood is desirable since we then we don't need to rely
> >> on precompiled elements and dofmaps) then how should we read in a
> >> higher-order mesh from file?
> >>
> >>
> >> Anders wrote:
> >> Here's one option:
> >>
> >>   Mesh mesh("mesh");
> >>   LagrangeFunctionSpace V(mesh);
> >>   File file("mesh_coordinate_vector.xml");
> >>   Vector x;
> >>   file >> x;
> >>   V.set_coordinates(x);
> >>
> >> That might work, but it's a bit long. There should be room for
> >> improvement.
> > 
> > The discussion on higher-order meshes got a bit confusing for me a
> > little while back. In summary, exactly what information intended to be
> > in the mesh file for a high-order mesh?
> > 
> > Garth
> > 
> > -------------------------------------------
> > 
> > Ok, I will try to recap the higher order mesh stuff.
> > 
> > Currently, in a triangulation, there is an implicit assumption on the 
> > form of the map that takes you from the `unit' reference triangle (or 
> > tetrahedron).  The assumption is that the local map is linear.  As you 
> > well know, this makes for various simplifications which can be used 
> > during matrix assembly.
> > 
> > But, for various reasons, it can be more useful (or possibly required 
> > depending on the nature of the FEM method) to have a curved triangle to 
> > better approximate domain boundaries or to better compute higher order 
> > geometric motion!
> > 
> > In this case, one could use a vector quadratic polynomial map and have a 
> > triangle with edges given by a quadratic parametrization.  The 
> > implementation of this only requires a local Lagrange finite element 
> > basis, whose DoFs are just the coordinates of the nodes (for a quadratic 
> > polynomial on a 2-D triangle, this would be 6 nodes per triangle).  Of 
> > course, you will have this for every triangle, and it makes sense to 
> > take the finite element basis to be continuous lagrange over the whole 
> > domain. This continuity is especially important when deforming the mesh!
> > 
> > So, way back we thought it would be a good idea to have a separate 
> > functionspace to store this `higher order' mesh data.  But that seemed 
> > problematic.
> > 
> 
> Sounds complicated.

The point is that we want to store a field over the mesh which is the
coordinates for certain entities. For a linear map, we need
coordinates at all vertices, for a quadratic map, we need coordinates
at all vertices and all edges etc. We already have a everything we
need to represent such data, namely the Function class. The
coordinates for a linear map is just a vector-valued piecewise linear
Lagrange finite element function, the coordinates for a quadratic map
is just a vector-valued piecewise quadratic Lagrange finite element
function etc.

It seems it would be practical to reuse the Function class to
represent the coordinate fields, rather than inventing a new
representation from scratch.

The coordinate field (Function) will need to have a Function space. In
some cases, this space may be the same space as we use for the
discretization itself (isoparametric!) and this should work out nicely
now that we use shared_ptr to store everything. In other cases, a new
space needs to be created.

It's easy to represent and store the extra coordinate data. We just
need to add an extra member to class FunctionSpace, a Function named
for example "coordinates". The difficulty is how to read this data in
from file since it requires reading in a FunctionSpace.

-- 
Anders


> > However, in principle, all you need is a DoFmap and a vector of data 
> > containing the node coordinate positions.  
> 
> This is what I thought. Will we add a field the Mesh xml file to store 
> this extra data?
> 
> And you need a method for
> > updating the positions (for a deforming mesh) but that isn't a big deal. 
> > Once this information is properly stored, and accessible to the matrix 
> > assembler, THEN...
> > 
> > Then the next step would be to modify FFC to use this higher order 
> > (locally defined) map to compute the local matrices, INSTEAD of the 
> > linear map that is implicitly assumed now.
> > 
> > I realize this will take some time, but we at least need to get a 
> > storage scheme for the higher order mesh data to even proceed!
> >
> 
> Kristian is looking at the UFL transition for the FFC quadrature 
> representation at the moment which will be needed for non-affine maps.
> 
> Perhaps a smaller first step in the non-affine direction would be to 
> support quadrilateral elements.
> 
> Garth
> 
> 
> > - Shawn
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature