You can subscribe to this list here.
2003 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(12) 
_{Oct}
(8) 
_{Nov}
(3) 
_{Dec}
(4) 

2004 
_{Jan}
(1) 
_{Feb}
(21) 
_{Mar}
(31) 
_{Apr}
(10) 
_{May}
(12) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(6) 
_{Sep}
(5) 
_{Oct}
(11) 
_{Nov}
(43) 
_{Dec}
(13) 
2005 
_{Jan}
(25) 
_{Feb}
(12) 
_{Mar}
(49) 
_{Apr}
(19) 
_{May}
(104) 
_{Jun}
(60) 
_{Jul}
(10) 
_{Aug}
(42) 
_{Sep}
(15) 
_{Oct}
(12) 
_{Nov}
(6) 
_{Dec}
(4) 
2006 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(31) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(95) 
_{Jul}
(38) 
_{Aug}
(44) 
_{Sep}
(6) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}

2007 
_{Jan}
(5) 
_{Feb}
(46) 
_{Mar}
(9) 
_{Apr}
(23) 
_{May}
(17) 
_{Jun}
(51) 
_{Jul}
(41) 
_{Aug}
(4) 
_{Sep}
(28) 
_{Oct}
(71) 
_{Nov}
(193) 
_{Dec}
(20) 
2008 
_{Jan}
(46) 
_{Feb}
(46) 
_{Mar}
(18) 
_{Apr}
(38) 
_{May}
(14) 
_{Jun}
(107) 
_{Jul}
(50) 
_{Aug}
(115) 
_{Sep}
(84) 
_{Oct}
(96) 
_{Nov}
(105) 
_{Dec}
(34) 
2009 
_{Jan}
(89) 
_{Feb}
(93) 
_{Mar}
(119) 
_{Apr}
(73) 
_{May}
(39) 
_{Jun}
(51) 
_{Jul}
(27) 
_{Aug}
(8) 
_{Sep}
(91) 
_{Oct}
(90) 
_{Nov}
(77) 
_{Dec}
(67) 
2010 
_{Jan}
(25) 
_{Feb}
(36) 
_{Mar}
(98) 
_{Apr}
(45) 
_{May}
(25) 
_{Jun}
(60) 
_{Jul}
(17) 
_{Aug}
(36) 
_{Sep}
(48) 
_{Oct}
(45) 
_{Nov}
(65) 
_{Dec}
(39) 
2011 
_{Jan}
(26) 
_{Feb}
(48) 
_{Mar}
(151) 
_{Apr}
(108) 
_{May}
(61) 
_{Jun}
(108) 
_{Jul}
(27) 
_{Aug}
(50) 
_{Sep}
(43) 
_{Oct}
(43) 
_{Nov}
(27) 
_{Dec}
(37) 
2012 
_{Jan}
(56) 
_{Feb}
(120) 
_{Mar}
(72) 
_{Apr}
(57) 
_{May}
(82) 
_{Jun}
(66) 
_{Jul}
(51) 
_{Aug}
(75) 
_{Sep}
(166) 
_{Oct}
(232) 
_{Nov}
(284) 
_{Dec}
(105) 
2013 
_{Jan}
(168) 
_{Feb}
(151) 
_{Mar}
(30) 
_{Apr}
(145) 
_{May}
(26) 
_{Jun}
(53) 
_{Jul}
(76) 
_{Aug}
(33) 
_{Sep}
(23) 
_{Oct}
(72) 
_{Nov}
(125) 
_{Dec}
(38) 
2014 
_{Jan}
(47) 
_{Feb}
(62) 
_{Mar}
(27) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(22) 
_{Aug}
(22) 
_{Sep}

_{Oct}
(17) 
_{Nov}
(20) 
_{Dec}
(12) 
2015 
_{Jan}
(25) 
_{Feb}
(2) 
_{Mar}
(16) 
_{Apr}
(13) 
_{May}
(21) 
_{Jun}
(5) 
_{Jul}
(1) 
_{Aug}
(8) 
_{Sep}
(9) 
_{Oct}
(30) 
_{Nov}
(8) 
_{Dec}

2016 
_{Jan}
(16) 
_{Feb}
(15) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(1) 
2

3
(2) 
4
(3) 
5
(1) 
6

7

8

9
(1) 
10

11
(3) 
12

13
(3) 
14
(9) 
15
(7) 
16

17

18

19

20
(8) 
21

22

23

24

25
(3) 
26

27
(3) 
28

29
(1) 
30

31







From: John Peterson <peterson@cf...>  20101004 17:55:47

On Mon, Oct 4, 2010 at 11:16 AM, Vijay S. Mahadevan <vijay.m@...> wrote: > 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: ooooo > * 0 2 3 4 1 Hmm, for EDGE5 I think I'd suggest ooooo 0 3 2 4 1 So that it nests with the EDGE3, and I suppose what you have for EDGE6 oooooo 0 2 3 4 5 1 is OK, there is no nice way to nest orders 4 and 6. Unless you allow nonequispaced nodes on the master element? I don't think there is any equispacing assumption required for the interpolation estimates to hold, but it would probably be at least nonstandard and confusing to have them nonequispaced. > Once I finish testing the 1d elements completely, I will move to the > 2d elements and implement the embedding and mesh generation > algorithms which still need some cleaning up. Let me know if you have > any comments. Are you planning to use isoparametric elements (element map has same order as basis functions)? If you can stick to quadratic elements for the mappings, I don't *think* you need to add any new embedding matrices, though I could be wrong about that. For higherorder elements the embedding matrices will be enormous, not sure we want to mess with these if we don't have to...  John 
From: Vijay S. Mahadevan <vijay.m@gm...>  20101004 16:16:28

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: ooooo * 0 2 3 4 1 * EGDE6: oooooo * 0 2 3 4 5 1 Once I finish testing the 1d elements completely, I will move to the 2d 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 <vijay.m@...> 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: oooo > *   > *  15 14  > * 10 o o o o 7 > *   > *   > *  12 13  > * 11 o o o o 6 > *   > *   > * oooo > * 0 4 5 1 > > > * 3 12 11 10 2 > * QUAD25: ooooo > *   > *  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 > *   > *   > * ooooo > * 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 anticlockwise > 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 2D > elements tomorrow. > > Thanks for the help. > Vijay > > On Sun, Oct 3, 2010 at 7:55 PM, John Peterson > <peterson@...> wrote: >> On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan <vijay.m@...> wrote: >>> >>> I have implemented higher order lagrange basis for 1d elements (till >>> EDGE6) and am in the process of testing 2d quad elements (QUAD16, >>> QUAD25). But I have another question regarding the 2d 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 >> firstorder 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 >> > 
From: Vijay S. Mahadevan <vijay.m@gm...>  20101004 02:59:47

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: oooo *   *  15 14  * 10 o o o o 7 *   *   *  12 13  * 11 o o o o 6 *   *   * oooo * 0 4 5 1 * 3 12 11 10 2 * QUAD25: ooooo *   *  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 *   *   * ooooo * 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 anticlockwise 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 2D elements tomorrow. Thanks for the help. Vijay On Sun, Oct 3, 2010 at 7:55 PM, John Peterson <peterson@...> wrote: > On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan <vijay.m@...> wrote: >> >> I have implemented higher order lagrange basis for 1d elements (till >> EDGE6) and am in the process of testing 2d quad elements (QUAD16, >> QUAD25). But I have another question regarding the 2d 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 > firstorder 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 > 