John, If I understand the implementation for edges correctly, for all the higher order edges, you split the element in half and create 2 children of same order with h/2. If this is true, I dont see a problem with my numbering scheme or the implementation of the embedding matrix. Btw, here's the numbering for the edges that I missed out in my previous mail.
* EGDE5: o----o----o----o----o * 0 2 3 4 1 * EGDE6: o----o----o----o----o----o * 0 2 3 4 5 1 Once I finish testing the 1-d elements completely, I will move to the 2-d elements and implement the embedding and mesh generation algorithms which still need some cleaning up. Let me know if you have any comments. Vijay On Sun, Oct 3, 2010 at 9:59 PM, Vijay S. Mahadevan <[email protected]> wrote: > 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
