Roy I am almost done testing both 1 and 2 dimensional elements (only edges and quads for now). I have the placeholders for Hexes but need to decide a suitable numbering before I can do anything there.
I am not entirely sure about the way to go for the higher-order output. Writing out multiple linear elements is sensible but the call to elem->connectivity in vtkIO is confusing. There is only one call to obtain the connectivity for an element and this is with a '0' index for the first argument. This means for higher order elements (even for second order QUAD), only the first sub-element will be written. Is this correct ? I don't see any check for sub_elem and a loop over these sub elements anywhere. Should I add this to enable higher order output as linear elements or did I misunderstand the code ? I do need to check my embedding matrix for the quads again but once that is done, the code should be in a good shape for a patch. Hopefully I'll find enough time to get back to this by the weekend so that anyone interested can actually test it out on different problems. I'll keep you guys updated if I have any other issues. VIjay On Wed, Oct 13, 2010 at 11:47 AM, Roy Stogner <[email protected]> wrote: > > I'm jumping into this very late; a couple comments: > > On Mon, 4 Oct 2010, Vijay S. Mahadevan wrote: > >>> 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 think John was saying that higher order elements wouldn't need the > embedding matrix defined if they were limited to lower order geometry. > >> 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 think this is probably the way to go. > >> 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 ? > > Based on some conversations at a TACC viz workshop I gather that there > aren't *any* generic visualization codes out there that properly > handle higher order elements. Sad if true. Until that changes > though, splitting into linear subelements is the way to go. > >> An alternative is that there are more n_sub_elem() (more than 2) for >> higher order elements. Is this an option? > > Definitely; this is the right way to do it. But it's not a trivial > option, unfortunately. IIRC we currently do subdivision on an adhoc, > format-by-format basis in the output codes. What we really ought to > have is an Elem method that creates a vector<Elem> with its own > subdivision done, then write those subelements to file in the *IO > classes. > --- > Roy > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
