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

 Re: [Libmesh-devel] Embedding matrices in cells. From: Vijay S. Mahadevan - 2010-10-05 00:09:24 Yes. I agree that the numbering change for EDGE5 would be logical to be nested with EDGE3. All my nodes are equi-spaced as of now and I don't have any requirements to have a non-standard element definition for any of my problems. > Are you planning to use isoparametric elements (element map has same > order as basis functions)? Yes. > For higher-order elements the embedding matrices will be enormous, not > sure we want to mess with these if we don't have to... Are you saying that higher order elements dont need the embedding matrix defined ? Or am I understanding you wrongly. I am going to try to write a matlab script that will evaluate the basis functions at a given point and that should hopefully minimize all the work for creating these matrices. As long as I specify the right coordinates in the reference element, the embedding matrix should be easy to evaluate. Do you think there is an easier way ? I found another quirk in the EDGE* codes. There is an assert in connectivity() routine as follows: libmesh_assert (sc < this->n_sub_elem()); where sc is the number of linear cells. This is fine till quadratic elements (EDGE3) since sc < 2 but for EDGE4, and higher order elements, this is not true anymore. Should this assert still exist or was there an ulterior motive to placing this in the code ? Since VTK does not support visualizing higher order elements, splitting the elements to many linear elements and writing out the solution at the vertices would require that this condition not be met. Comments ? An alternative is that there are more n_sub_elem() (more than 2) for higher order elements. Is this an option ? Vijay On Mon, Oct 4, 2010 at 12:55 PM, John Peterson wrote: > On Mon, Oct 4, 2010 at 11:16 AM, Vijay S. Mahadevan 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: o----o----o----o----o >>  *         0    2    3    4    1 > > Hmm, for EDGE5 I think I'd suggest > > o----o----o----o----o > 0     3     2    4    1 > > So that it nests with the EDGE3, and I suppose what you have for EDGE6 > > o----o----o----o----o----o > 0      2    3    4    5    1 > > is OK, there is no nice way to nest orders 4 and 6.  Unless you allow > non-equispaced 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 non-standard and confusing to > have them non-equispaced. > >> 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. > > 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 higher-order elements the embedding matrices will be enormous, not > sure we want to mess with these if we don't have to... > > -- > John >