On Mon, Apr 06, 2009 at 09:16:42AM -0400, Shawn Walker wrote: > > 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.
An array is good. >>> 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. No immediate plans that I know of (but it might be nice to have). We could also consider other stuff like extension to hex meshes and using http://p4est.org/. It's just a matter of resources/priorities. >>> 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. Yes, one would need a different FunctionSpace for the geometry. But I see the problem. >> 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. Maybe we can manage for now with having the mapping stored in an array. It's then the responsibility of the input file to create the dofmap. > I have tried emailing my patch twice, but I have not seen that it has > come through. Has anyone seen it? I haven't. Is it big? Try posting a URL instead. I won't apply any more patches until we've made the new release. We're waiting for the buildbot to become green so we can release and then start breaking stuff again. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
