On Wed, Jan 14, 2009 at 08:10:13AM +0000, Garth N. Wells wrote:
>
>
> Shawn Walker wrote:
> >
> > On Tue, 13 Jan 2009, 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.
> >>
> >>> 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?
> >
> > Yes. I don't see why that would be a problem. And if you don't want to
> > use the higher order mesh data (that happens to be in a file), then that
> > should also be fine.
> >
>
> OK, so we won't have the issue that Anders outlined above with respect
> to reading in meshes.
>
> >> 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
> >
> > Did you mean quadratic elements? Quadrilaterals are just deformed squares.
> >
>
> I meant quadrilaterals (with just 4 nodes) as a first step in having FFC
> generate code for non-affine maps. I expect that quads would require
> less initial work on the DOLFIN side, perhaps just an extension of
> ufc::cell.
>
> > Yes, I agree. In reality, I cannot forsee the potential difficulties
> > this will cause. So, trying to have the full implementation ironed out
> > before we even put it in may not be helpful. So, maybe just assuming a
> > 2nd order vector polynomial for the local map may suffice. This is very
> > much in line with the current philosophy of implicitly assuming a linear
> > map.
> >
> > So, where would the data be stored in the code? In FunctionSpace by
> > some extra variable field that contains the vector of coordinate data
> > and the DoFmap?
> >
>
> Using a FunctionSpace sounds complicated to me. What about letting the
> mesh carry this data?
>
> GarthHow would it be represented? We already know how to represent such fields (by Functions). We would need to reinvent and reimplement Lagrange elements as part of the Mesh class. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
