Apparently I bcc'd the list my previous mail. John, sorry if you get this twice (or thrice ?!).. Guess only some sleep and coffee can cure my stupidities ..
Derek, Absolutely. I have been asked to use higher order lagrange basis before but have always tried to convince people to instead live with Hierarchical bases. But in my current work, it has become unavoidable and so finally I gave in to the idea of adding these to the library. I was hoping that more people will be able to use it and glad to know that atleast you and others will find it useful ! John, I've included the devel list to your reply because you sent the mail only to me. As you rightly point out, my higher order lagrange are only tensor products and as I mentioned before in my email, I'm implementing them only for (EDGE, QUAD and HEX) which precisely use this formulation. The explanation for the embedding matrix makes sense and I will look at the Quad implementations to see if I can derive them accordingly. My node orderings for EDGE's are pretty straightforward and they follow the convention. But my QUAD's, I'm not sure if this would be your expected ordering. Here they are. * 3 9 8 2 * QUAD16: o-----o-----o-----o * | | * | 15 14 | * 10 o o o o 7 * | | * | | * | 12 13 | * 11 o o o o 6 * | | * | | * o-----o-----o-----o * 0 4 5 1 * 3 12 11 10 2 * QUAD25: o-----o-----o-----o-----o * | | * | 22 21 20 | * 13 o o o o o 9 * | | * | | * | 23 24 19 | * 14 o o o o o 8 * | | * | | * | 16 17 18 | * 15 o o o o o 7 * | | * | | * o-----o-----o-----o-----o * 0 4 5 6 1 Let me know if this is logical enough to create child elements from this parent. The numbering essentially goes for vertices first, side nodes next and finally the internal nodes (all in anti-clockwise direction). If you think there is a better numbering that would enable a smoother AMR algorithm, feel free to suggest an alternative. I also need to know about the i0 and i1 arrays in lagrange_2d_shape.C. Without the correct order, the tensor products will not be computed correctly and my tired brain seems to go blank looking at it. A simple explanation for this and I should almost be set to test the 2-D elements tomorrow. Thanks for the help. Vijay On Sun, Oct 3, 2010 at 7:55 PM, John Peterson <[email protected]> wrote: > On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan <[email protected]> wrote: >> >> I have implemented higher order lagrange basis for 1-d elements (till >> EDGE6) and am in the process of testing 2-d quad elements (QUAD16, >> QUAD25). But I have another question regarding the 2-d elements. What >> are the i0 and i1 arrays in fe_lagrange_shape_2d.C ? I am sure they >> represent some array indices to access data for the nodes in the >> element but the numbering is not completely obvious to me. If someone >> can shed some light on this part of the code, that will be helpful >> too. > > These are for doing tensor products of 1D basis function to get 2D > basis functions. For example, the zero'th QUAD bilinear basis > function is given by the product the zero'th 1D basis function (in xi) > and the zero'th 1D basis function (in eta). > > As far as the embedding matrices go, they are basically just tabulated > Lagrange shape function values, used to determine where new nodes will > be inserted for AMR. The simplest one is probably in face_tri3.C, so > I'd start there. The first index is for the child. The second and > third dimensions are indexes into the tabulated shape function values. > So, for example the location of node 0 in the zero'th child of the > Tri3 is 1*phi0 + 0*phi1 + 0*phi2. Likewise the location of node1 in > the zero'th child is 0.5*phi0 + 0.5*phi1 + 0*phi2, and so on. > > By the way, I wonder what node ordering you have chosen for the higher > order Edges, and consequently for the Quads? The second and > first-order nodes are kind of nice in the sense that they are > "nested", i.e. the quadratics reuse all the linear nodes, so no > renumbering is required. This isn't true when you go from Edge3 -> > Edge4 though... > > -- > John > ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
