On Wed, Nov 2, 2011 at 9:51 AM, Roy Stogner <roystgnr@...> 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,
>> 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.