libMesh: A C++ Finite Element Library

On Mon, 15 Nov 2010, Derek Gaston wrote:

> Would anyone be opposed to me adding a
> qrule->has_constant_positions() (that would return true for all of
> our current rules and false for the new one I'm making)... or
> something like it (I'm open to suggestions!)

Does the number of quadrature points change, or just their locations?
If it's just their locations then I think you've probably hit on the
best solution for now.

Also (asking out of curiousity, not criticism) could you explain the
method and its motivation?
---
Roy

On Nov 15, 2010, at 1:21 PM, Roy Stogner wrote:

> Does the number of quadrature points change, or just their locations?
> If it's just their locations then I think you've probably hit on the
> best solution for now.

Both the number and positions.

I'll go ahead and add something like this for now (making it default to to true so no one else is inconvenienced).

Derek

On Mon, 15 Nov 2010, Derek Gaston wrote:

> On Nov 15, 2010, at 1:21 PM, Roy Stogner wrote:
>
>> Does the number of quadrature points change, or just their locations?
>> If it's just their locations then I think you've probably hit on the
>> best solution for now.
>
> Both the number and positions.

Okay.  Thinking it through, I'm not as scared by that as I thought - a
good assembly code already re-queries the number of quadrature points
on each element, in case the element's type has changed from one to
the next on a hybrid grid.  So it would take some
very-overly-aggressive optimization to write an app code that would be
broken by an adaptive quadrature rule underneath it.

I noticed you skipped my "what's your method and motivation" question.
In my mind the answer is now "Multiscale nuclear physics, and if I
told you any more we'd have to kill you."

> I'll go ahead and add something like this for now (making it default to to true so no one else is inconvenienced).

Sounds good.
---
Roy

On Mon, Nov 15, 2010 at 2:49 PM, Roy Stogner <roystgnr@...> wrote:
>
>
> On Mon, 15 Nov 2010, Derek Gaston wrote:
>
>> On Nov 15, 2010, at 1:21 PM, Roy Stogner wrote:
>>
>>> Does the number of quadrature points change, or just their locations?
>>> If it's just their locations then I think you've probably hit on the
>>> best solution for now.
>>
>> Both the number and positions.

Are we married to the "has_constant_positions()" name?  Maybe
something like qrule->need_reinit() in the vein of
FE::shapes_need_reinit().  Just thinking there might potentially be
other reasons quadrature rules need to be recomputed for each element
than just having variable positions...

-- 
John

On Nov 15, 2010, at 3:38 PM, John Peterson wrote:

> Are we married to the "has_constant_positions()" name?  Maybe
> something like qrule->need_reinit() in the vein of
> FE::shapes_need_reinit().  Just thinking there might potentially be
> other reasons quadrature rules need to be recomputed for each element
> than just having variable positions...

That sounds good to me.

I'll go with that.

Derek

On Mon, 15 Nov 2010, John Peterson wrote:

> On Mon, Nov 15, 2010 at 2:49 PM, Roy Stogner <roystgnr@...> wrote:
>>
>>
>> On Mon, 15 Nov 2010, Derek Gaston wrote:
>>
>>> On Nov 15, 2010, at 1:21 PM, Roy Stogner wrote:
>>>
>>>> Does the number of quadrature points change, or just their locations?
>>>> If it's just their locations then I think you've probably hit on the
>>>> best solution for now.
>>>
>>> Both the number and positions.
>
> Are we married to the "has_constant_positions()" name?  Maybe
> something like qrule->need_reinit() in the vein of
> FE::shapes_need_reinit().  Just thinking there might potentially be
> other reasons quadrature rules need to be recomputed for each element
> than just having variable positions...

QBase::always_needs_reinit()?  Whatever the final name, John has a
good point.
---
Roy

On 11/15/10 3:40 PM, Derek Gaston wrote:
> On Nov 15, 2010, at 3:38 PM, John Peterson wrote:
>
>> Are we married to the "has_constant_positions()" name?  Maybe
>> something like qrule->need_reinit() in the vein of
>> FE::shapes_need_reinit().  Just thinking there might potentially be
>> other reasons quadrature rules need to be recomputed for each element
>> than just having variable positions...
>
> That sounds good to me.
>
> I'll go with that.
>
> Derek

Is adding qrule->need_reinit() the only change that you are making to 
QBase?  I am probably missing something, but it seems like allowing the 
quadrature rule to vary from element to element would also require 
something like changing the arguments for qrule->init() to include the 
element on which the quadrature rule is being initialized.

(Incidentally, this is functionality that I would definitely use!)

-- Boyce

On Nov 16, 2010, at 10:27 AM, Boyce Griffith wrote:

> Is adding qrule->need_reinit() the only change that you are making to QBase?  I am probably missing something, but it seems like allowing the quadrature rule to vary from element to element would also require something like changing the arguments for qrule->init() to include the element on which the quadrature rule is being initialized.
> 
> (Incidentally, this is functionality that I would definitely use!)


Hmmm... I only added a new virtual called shapes_need_reinit() that returns false by default.  This is all that was necessary for my application because I added other functions to my qrule class to tell it the information it needs before I call fe->reinit().

I do see your point and wouldn't be opposed to someone making that modification.

Derek

On 11/16/10 2:24 PM, Derek Gaston wrote:
> On Nov 16, 2010, at 10:27 AM, Boyce Griffith wrote:
>
>> Is adding qrule->need_reinit() the only change that you are making to QBase?  I am probably missing something, but it seems like allowing the quadrature rule to vary from element to element would also require something like changing the arguments for qrule->init() to include the element on which the quadrature rule is being initialized.
>>
>> (Incidentally, this is functionality that I would definitely use!)
>
>
> Hmmm... I only added a new virtual called shapes_need_reinit() that returns false by default.  This is all that was necessary for my application because I added other functions to my qrule class to tell it the information it needs before I call fe->reinit().
>
> I do see your point and wouldn't be opposed to someone making that modification.

OK; I'm just now getting a chance to look at this.  It seems like 
changing the interface to QBase to depend on the element instead of the 
element type would screw up caching of points/weights, which seems 
undesirable.

Looking at the implementation of QBase::init(), it seems like the 
quadrature rule will not generally be reinitialized, even if 
QBase::shapes_need_reinit() is set to return true, unless the element 
type or p-order have changed.  Should QBase::init() be virtual?

(FWIW, the functionality that I would like to play around with is to 
have the number of quadrature points depend on the element size/shape.)

-- Boyce

On Thu, Dec 2, 2010 at 9:20 AM, Boyce Griffith <griffith@...> wrote:
>
>
> On 11/16/10 2:24 PM, Derek Gaston wrote:
>>
>> On Nov 16, 2010, at 10:27 AM, Boyce Griffith wrote:
>>
>>> Is adding qrule->need_reinit() the only change that you are making to
>>> QBase?  I am probably missing something, but it seems like allowing the
>>> quadrature rule to vary from element to element would also require something
>>> like changing the arguments for qrule->init() to include the element on
>>> which the quadrature rule is being initialized.
>>>
>>> (Incidentally, this is functionality that I would definitely use!)
>>
>>
>> Hmmm... I only added a new virtual called shapes_need_reinit() that
>> returns false by default.  This is all that was necessary for my application
>> because I added other functions to my qrule class to tell it the information
>> it needs before I call fe->reinit().
>>
>> I do see your point and wouldn't be opposed to someone making that
>> modification.
>
> OK; I'm just now getting a chance to look at this.  It seems like changing
> the interface to QBase to depend on the element instead of the element type
> would screw up caching of points/weights, which seems undesirable.
>
> Looking at the implementation of QBase::init(), it seems like the quadrature
> rule will not generally be reinitialized, even if
> QBase::shapes_need_reinit() is set to return true, unless the element type
> or p-order have changed.  Should QBase::init() be virtual?
>

Hmm... this function ended up getting named "shapes_need_reinit"?

Not sure I understand that, there aren't any "shapes" in the QBase.  I
would have voted for QBase::needs_reinit(), but whatever.

-- 
John