Re: [Libmesh-devel] Embedding matrices in cells.

[Vijay S. M. <vi...@gm...>]

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 <vi...@gm...> 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
> <pet...@cf...> wrote:
>> On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan <vi...@gm...> 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
>>
>