On Mon, 6 Apr 2009, Anders Logg wrote: > On Thu, Apr 02, 2009 at 11:12:20AM -0400, Shawn Walker wrote: >> Hello all. >> >> I have finally got some time to put in (at least the first stage) the >> higher order mesh stuff for triangles >> mapped with P2 lagrange elements. Just to remind you, the agreement that >> we came up with was this: >> >> 1. The local mapping for each element is independent of whatever finite >> elements you are using. Thus, there >> should be a completely different description of the mapping. > > Sounds good. > >> 2. This info will be stored in MeshGeometry with extra data structures. > > Sounds good. > >> 3. The info to store is (i) all the higher order vertex position data, and >> (ii) the `DoFmap' for your >> particular map. Storing the extra vertex data is just like storing the >> usual 3 triangle coordinates. > > Are you thinking of using DofMap for this?
I was thinking of this, but not sure how to do it, i.e. read it into the DoFmap structure. For now I just have it as an array. >> 4. Eventually, for computing the local finite element matrices, there just >> needs to be a short subroutine >> that returns the higher order vertex data (for a specific cell) to be used >> by, say, the code generated by >> FFC. > > Yes. > >> My question is about the dofmap. It is certainly reasonable to store it >> similarly to the vertex data. But >> there is a problem if the mesh is locally refined. It seems like it will >> be a pain to modify this data >> structure. Any suggestions for this? > > When a mesh is locally refined, an entirely new mesh is created. The > mesh class stores all data in large arrays so all mesh data needs to > be copied to new data structures anyway. ok. Are there any plans to have binary tree type meshes? This is the main reason some people use Alberta, plus it has multigrid. >> Remember, we do NOT want to use a function space here. This was already >> discussed! > > I know, but I keep forgetting why. :-) One problem was that a Function Space needs a mesh first. But the higher order geometric mapping is defining the mesh, so kind of a chicken-and-egg problem. Another thing to keep in mind is that the mapping is completely independent of the finite element. For instance, you could mix Raviart-Thomas with P2 triangles. > We just removed all the precompiled elements which means one must > always instantiate the correct function spaces maunually (at least in > C++). The question here is how to create/number the extra nodes. The > form compilers already know how to generate code for this, and it > would be extra work to try to duplicate that code for the mapping of > higher order coordinates. Do you have a good plan for how to number > the coordinates? Well, not particularly, other than the `standard' way. Any suggestions would be good. I have tried emailing my patch twice, but I have not seen that it has come through. Has anyone seen it? - Shawn _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
