Evaluating the gradient of the solution at the centroid of the element

70 views
Skip to first unread message

cmha...@gmail.com

unread,
Dec 21, 2016, 11:47:24 PM12/21/16
to deal.II User Group
I have gone through some of the tutorials previously and thought it was about time I actually tried to implement something on my own in the library.

I am attempting to implement a finite strain code using the F-Bar method. Essentially this is a single field formulation which requires the calculation the of the deformation gradient at the element center. The trick here is though that the element centroid isn't a vertex.

My question is, is there a way to "interpolate" the displacement gradient at the element center without explicitly making it a quadrature point or will I have to implement my own quadrature formula for this method?

Thank you for any assistance that can be provided.

Denis Davydov

unread,
Dec 22, 2016, 9:21:01 AM12/22/16
to deal.II User Group
Hi
Yes, employ a custom quadrature formula with a single point with coordinates {0.5, 0.5, 0.5} to feed it to FEValues. 
There is no reason to figure out how to interpolate things, just use Quadrautre<dim> and FEValues<dim> together to evaluate your solution at quadrature point(s).

Regards,
Denis.

cmha...@gmail.com

unread,
Dec 22, 2016, 11:10:04 AM12/22/16
to deal.II User Group
The thing is though that I don't actually need to integrate at these points. The method still employ a 4node quad element in 2d or an 8 node hex element in 3d but only uses the element centroid to calculate the deformation gradient, no quadrature is actually done at that point so I feel like I need to interpolate otherwise the way deal makes the FESystem objects I'll now have quad points at all centroids that should be integrated, or am I misunderstanding something here?

Denis Davydov

unread,
Dec 22, 2016, 11:14:57 AM12/22/16
to dea...@googlegroups.com

> On 22 Dec 2016, at 17:10, cmha...@gmail.com wrote:
>
> The thing is though that I don't actually need to integrate at these points. The method still employ a 4node quad element in 2d or an 8 node hex element in 3d but only uses the element centroid to calculate the deformation gradient, no quadrature is actually done at that point so I feel like I need to interpolate otherwise the way deal makes the FESystem objects I'll now have quad points at all centroids that should be integrated, or am I misunderstanding something here?

Nothing stops you from using different quadrature rules with different FEValues objects simultaneously.
One pair with centroid will be auxiliary and not participate in integration directly (so you won’t use the weight associated to your single point quadrature rule anywhere).
Whereas for integration on your linear elements you would most likely be using QGauss<dim> quarature(degree+1);


Regards,
Denis.

cmha...@gmail.com

unread,
Dec 22, 2016, 11:21:51 AM12/22/16
to deal.II User Group
Thanks Denis. I guess I still don't quite understand the intimate relationship between all the key data structures in deal.ii quite yet. I thought of this previously but I was hesitant because this seems memory expensive to me but then again I don't know how it is implemented so maybe it is not as expensive as I thought.

Jean-Paul Pelteret

unread,
Dec 22, 2016, 11:22:40 AM12/22/16
to deal.II User Group
Firstly, a tangential observation: For the mean dilatation element (Q1-P0-P0), the dilation and pressure variables can be condensed out on an element level and a modified one-field formulation remains. For this element the "mean dilatation" means that one must compute
  \bar{\theta} = 1/V_{e} * \int_{element} \theta (X) dV
where V_{e} is the volume of the element 
  V_{e} = \int_{element} dV

Could it be that your "centroid" value \bar{F} is to coincide with the mean value of F? If so, then could you not just compute the element average in the same way as for the mean dilation \theta?

J-P

cmha...@gmail.com

unread,
Dec 22, 2016, 11:32:06 AM12/22/16
to deal.II User Group
The computational savings at the element level for this method is much more efficient than the dilatation element because for each element I just need to calculate one quantity instead of solving a linear system to remove the static condensation from the displacement system.

Jean-Paul Pelteret

unread,
Dec 22, 2016, 11:40:48 AM12/22/16
to dea...@googlegroups.com
You've misunderstood. For the mean dilatation element this can all be done locally as well.

Anyway, thats not exactly the point I was trying to make. I was just asking whether the centroid value \bar{F} is the same as the mean value of the field F. If so, you could compute F using the quadrature rule that you already have in place and then do the element-wise averaging as a further post-processing step.

J-P

Wolfgang Bangerth

unread,
Dec 22, 2016, 5:03:25 PM12/22/16
to dea...@googlegroups.com
On 12/22/2016 09:10 AM, cmha...@gmail.com wrote:
> The thing is though that I don't actually need to integrate at these points.
> The method still employ a 4node quad element in 2d or an 8 node hex element in
> 3d but only uses the element centroid to calculate the deformation gradient,
> no quadrature is actually done at that point so I feel like I need to
> interpolate otherwise the way deal makes the FESystem objects I'll now have
> quad points at all centroids that should be integrated, or am I
> misunderstanding something here?

We use FEValues in deal.II to *evaluate shape functions and solutions* at
individual points. These are typically quadrature points, but in reality
that's just a convention: FEValues is quite happy to give you point values
whether you do or do not want to use them for integration/quadrature. So what
you do is describe the point you are interested in through a Quadrature<dim>
object; if you don't want to use it for integration, then you don't care about
the FEValues' JxW value, which also means that it is not important to set any
weights in the Quadrature object you create for the points you care about.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

Reply all
Reply to author
Forward
0 new messages