| Thread Previous • Date Previous • Date Next • Thread Next |
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
| Thread Previous • Date Previous • Date Next • Thread Next |
