On Wed, Nov 2, 2011 at 9:51 AM, Roy Stogner <[email protected]> wrote: > > On Wed, 2 Nov 2011, John Peterson wrote: > >> I noticed the following line of code in several of the >> FE::nodal_soln() functions: >> >> // u_i = Sum (alpha_i phi_i) >> for (unsigned int i=0; i<n_sf; i++) >> nodal_soln[n] += elem_soln[i]*FE<Dim,T>::shape(elem, order, i, >> mapped_point); >> >> >> But it seems like "order" should be "totalorder" in this case, which >> is != order when using higher-p elements? >> >> fe_monomial.C, fe_xyz.C, fe_hermite.C, fe_hierarchic.C, etc. all have >> essentially the same code. >> >> Any ideas? This came up while I was doing the FE instantiation -> >> specialization refactoring. > > Hmm... yeah, this looks like a bug. I guess I never noticed because > it only affects higher order visualization, which I already expected > to be lousy because we interpolate onto quadratic geometric elements. > > Either that or I just thought "higher order bubble functions are 0 at > the nodes anyway", but that isn't true for non-vertex nodes and isn't > even true for vertex nodes on discontinuous variables.
Cool, I will fix this up in the refactoring. BTW, I looked at both second and third-order hierarchic solutions to ex4 after I implemented the change and they were identical, though I suppose that's because all the higher-order shapes are really bubbles. -- John ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
