Re: [Libmesh-users] project solution with FEMFunction

[Paul T. B. <ptb...@gm...>]

Hmm. I can't reproduce this. I have a code that uses FEMFunction for
projections and I bumped up the basis order and cannot trip the error you
are. In fact, I manually verified that n_points() returns the correct value
on that line. Can you make a test case that trips the error? Are you using
a LAGRANGE basis or some other one? What order?


On Fri, Sep 20, 2013 at 3:24 PM, Manav Bhatia <bha...@gm...> wrote:

> Just found the the call to side_fe_reinit() in this for loop. It seems
> like the entire block from lines 2238 to 2247 should be moved to after the
> context.side_fe_reinit() ?
>
> -Manav
> On Fri, Sep 20, 2013 at 4:21 PM, Manav Bhatia <bha...@gm...>wrote:
>
>> I was comparing the code with AssemblyContributions in  fem_system.C, and
>> see that context.side_fe_reinit() has not been called before the call to
>> get qsiderule.n_points(). Should that be added to the for loop on element
>> sides at line 2248 and move the get_side_qrule method call (line
>> 2238) after this call?
>>
>> -Manav
>>
>>  On Fri, Sep 20, 2013 at 4:09 PM, Manav Bhatia <bha...@gm...>wrote:
>>
>>> Yes, it is 2239. I am sorry about the typo and the resulting confusion.
>>> -Manav
>>>
>>>
>>> On Fri, Sep 20, 2013 at 4:07 PM, Roy Stogner <roy...@ic...>wrote:
>>>
>>>>
>>>> On Fri, 20 Sep 2013, Manav Bhatia wrote:
>>>>
>>>> Sorry I was not too specific. I am on the git master, and line 2339 is a
>>>>> call to qsiderule.n_points(). It has an assertion of
>>>>> libmesh_assert(!_points.empyt(**)), where the code throws an
>>>>> exception.
>>>>>
>>>>
>>>> I think Paul's (and my) confusion was a simple typo - you're referring
>>>> to line 2239, not 2339.
>>>> ---
>>>> Roy
>>>>
>>>
>>>
>>
>