From: Derek G. <der...@in...> - 2010-11-15 20:16:40
|
I'm trying to make a new quadrature rule... that is different in that the points it integrates at are different on every element in the mesh. This would seem to be an easy task but I am wondering about FE::reinit(). Reading through it, it seems as if it is missing the case where the quadrature points might change... ie it assumes that the quadrature points will stay constant as long as the element type (and order) doesn't change and if the shape doesn't change it is even more aggressive about not recomputing things. It does have a call to shapes_need_reinit()... but that is so that shape functions can override this caching behavior. It seems like we need a similar call to the quadrature rule object to know if the quadrature point locations have changed. 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!) Thanks! Derek |
From: Roy S. <roy...@ic...> - 2010-11-15 20:21:32
|
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 |
From: Derek G. <der...@in...> - 2010-11-15 20:44:29
|
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 |
From: Roy S. <roy...@ic...> - 2010-11-15 20:49:47
|
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 |
From: John P. <pet...@cf...> - 2010-11-15 22:38:35
|
On Mon, Nov 15, 2010 at 2:49 PM, Roy Stogner <roy...@ic...> 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 |
From: Derek G. <der...@in...> - 2010-11-15 22:41:10
|
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 |
From: Roy S. <roy...@ic...> - 2010-11-15 22:42:12
|
On Mon, 15 Nov 2010, John Peterson wrote: > On Mon, Nov 15, 2010 at 2:49 PM, Roy Stogner <roy...@ic...> 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 |
From: Boyce G. <gri...@ci...> - 2010-11-16 17:51:11
|
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 |
From: Derek G. <der...@in...> - 2010-11-16 19:24:36
|
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 |
From: Boyce G. <gri...@ci...> - 2010-12-02 15:19:45
|
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 |
From: John P. <pet...@cf...> - 2010-12-02 23:59:23
|
On Thu, Dec 2, 2010 at 9:20 AM, Boyce Griffith <gri...@ci...> 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 |