OK, that all sounds good. Based on Truman's reply, in L2_HIERARCHIC I'll remove compute_proj_constraints and change to DISCONTINOUS. Also, I'll make the change to MONOMIAL that I mentioned.
I'll leave the copy/pasted version of L2_LAGRANGE. Dave On 02/27/2012 10:30 PM, Roy Stogner wrote: > > On Mon, 27 Feb 2012, David Knezevic wrote: > >> I've just checked in the discontinuous Lagrange basis (L2_LAGRANGE) we >> discussed recently. Changing MONOMIAL to L2_LAGRANGE in >> miscellaneous_ex5 works fine in both 2D and 3D. > > Thanks! > >> 1. Just like in fe_monomial.C, I set compute_constraints to be a NOOP. I >> was surprised to see that this method is not a NOOP in L2_HIERARCHIC? > > compute_proj_constraints would work correctly (it just does an > immediate return for DISCONTINUOUS), it's just slightly less efficient > to call it needlessly. This looks like a minor oversight. > >> 2. Similarly, I was surprised to see that L2_HIERARCHIC returns C_ZERO >> rather than DISCONTINUOUS in get_continuity()? > > This looks just wrong. Could cause lots of subtle breakage. Unless > there's something I'm missing - Truman? > >> 3. In fe_monomial.C, it looks like monomial_n_dofs() and >> monomial_n_dofs_per_elem() are identical? If so, I'd like to delete the >> latter (we only have one of these two functions in L2_HIERARCHIC and >> L2_LAGRANGE) > > Agreed; go right ahead. > >> 4. For now I've just used the same "max_order" for L2_LAGRANGE and >> LAGRANGE, since I wanted to do an initial check-in based directly on >> LAGRANGE. But L2_LAGRANGE's Order is no longer related to "element >> order" (e.g. a SECOND on a TRI3 is perfectly fine for L2_LAGRANGE), so >> those extra valid combinations could be added to L2_LAGRANGE... this >> would also have implications for the serendipity shapes functions: we >> currently assume that QUAD8 or HEX20 implies serendipity, but this need >> not be true with L2_LAGRANGE. > > Right - max_order==unlimited would be fine once the default n > > hand-coded case is handled in the shape function calculations. > >> 5. I followed the L2_HIERARCHIC approach of adding new files >> fe_l2_lagrange_shape_*D.C which are copies of fe_lagrange_shape_*D.C >> with LAGRANGE replaced by L2_LAGRANGE. But it would be possible to just >> call LAGRANGE's shape functions directly, rather than copying and >> pasting --- though this would need some modifications if point 4 above >> is implemented. Any thoughts on the best thing to do here? > > I'm fine with the copy/paste if others are - especially given that the > codes may diverge soon to add those higher-order features. > --- > Roy ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
