From: Boyce G. <gri...@ci...> - 2011-06-29 19:26:50
Attachments:
quadrature_diff
|
I am trying to setup an adaptive quadrature rule that will use different quadrature points/weights on different elements in the mesh. (In this particular application, the number of quadrature points depends on the size of the element.) I am not sure how to get this to work, because QBase::init() seems to default to using precomputed points/weights whenever you pass in the same element type and p level, even for cases in which QBase::shapes_need_reinit() returns true. Modifying QBase::init() so that it does NOT skip initializing the quadrature rule if shapes_need_reinit() seems to have the desired effect: the quadrature rule appears to be reinitialized for each element. I wonder if this (or something similar) should be the default behavior? Is there already another / better way to accomplish this? Thanks! -- Boyce |
From: Derek G. <fri...@gm...> - 2011-06-29 19:40:04
|
What we've done here is inherit from QBase and override shapes_need_reinit() to return true. Then, when we hit each element we call a function on our qrule ourselves (like qrule->recalculate_points(Elem * elem) ) that passes in information and allows the qrule to recalculate it's points. After that we call fe reinit()... and the shape functions will get recomputed at the correct positions because shapes_need_reinit() will return true. You will need to implement dummy init_1D, init_2D and init3D functions that basically do nothing (ours just set this->type and this->plevel).... but you won't actually do anything useful in those functions. Basically, the QBase interface doesn't have any functions that take an Elem* for reinitialization... so you would have to do something like this no matter what. Let me know if that doesn't make sense. If you have a better way let me know. Derek On Jun 29, 2011, at 1:25 PM, Boyce Griffith wrote: > I am trying to setup an adaptive quadrature rule that will use different quadrature points/weights on different elements in the mesh. (In this particular application, the number of quadrature points depends on the size of the element.) > > I am not sure how to get this to work, because QBase::init() seems to default to using precomputed points/weights whenever you pass in the same element type and p level, even for cases in which QBase::shapes_need_reinit() returns true. > > Modifying QBase::init() so that it does NOT skip initializing the quadrature rule if shapes_need_reinit() seems to have the desired effect: the quadrature rule appears to be reinitialized for each element. > > I wonder if this (or something similar) should be the default behavior? Is there already another / better way to accomplish this? > > Thanks! > > -- Boyce > <quadrature_diff.txt>------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2011-06-29 19:47:12
|
On Wed, 29 Jun 2011, Derek Gaston wrote: > Basically, the QBase interface doesn't have any functions that take > an Elem* for reinitialization... so you would have to do something > like this no matter what. Should we be open to changing the QBase interface so that, say, init takes a const Elem* rather than an ElemType? Keep the old version around for max backwards compatibility, but have the library itself switch to the new version? I like the fact that our quadrature rules which derive from QBase can all be successfully used from a QBase; one of the nice things about libMesh is being able to do things like swap quadrature types without having to change the physics code to accomodate. --- Roy |
From: Boyce G. <gri...@ci...> - 2011-06-29 19:50:22
|
This makes sense, thanks. What I had done was to add a method to provide the element specific information, but I was performing the actual initialization in init_1D(), init_2D(), or init_3D(), which was of course not getting called. However, I wonder whether there is any case in which a quadrature rule has an implementation of shapes_need_reinit() that returns true in which QBase::init() should not actually reinit the quadrature points/weights. It seems like the intent of shapes_need_reinit() is to indicate whether or not the quadrature rule should be considered to be "static" or "dynamic". -- Boyce On 6/29/11 3:39 PM, Derek Gaston wrote: > What we've done here is inherit from QBase and override shapes_need_reinit() to return true. Then, when we hit each element we call a function on our qrule ourselves (like qrule->recalculate_points(Elem * elem) ) that passes in information and allows the qrule to recalculate it's points. > > After that we call fe reinit()... and the shape functions will get recomputed at the correct positions because shapes_need_reinit() will return true. > > You will need to implement dummy init_1D, init_2D and init3D functions that basically do nothing (ours just set this->type and this->plevel).... but you won't actually do anything useful in those functions. > > Basically, the QBase interface doesn't have any functions that take an Elem* for reinitialization... so you would have to do something like this no matter what. > > Let me know if that doesn't make sense. > > If you have a better way let me know. > > Derek > > On Jun 29, 2011, at 1:25 PM, Boyce Griffith wrote: > >> I am trying to setup an adaptive quadrature rule that will use different quadrature points/weights on different elements in the mesh. (In this particular application, the number of quadrature points depends on the size of the element.) >> >> I am not sure how to get this to work, because QBase::init() seems to default to using precomputed points/weights whenever you pass in the same element type and p level, even for cases in which QBase::shapes_need_reinit() returns true. >> >> Modifying QBase::init() so that it does NOT skip initializing the quadrature rule if shapes_need_reinit() seems to have the desired effect: the quadrature rule appears to be reinitialized for each element. >> >> I wonder if this (or something similar) should be the default behavior? Is there already another / better way to accomplish this? >> >> Thanks! >> >> -- Boyce >> <quadrature_diff.txt>------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |