Re: [deal.II] Extracting Shape Laplacian

[kylew]

Thanks,

I did try looking at the documentation for FEValuesViews::Vector 
<
 
dim, spacedim >::hessian(const unsigned int shape_function, const unsigned 
int q_point)  before coming here, and all it provides is

"Return the Hessian (the tensor of rank 2 of all second derivatives) of the 
vector components selected by this view, for the shape function and 
quadrature point selected by the arguments."

I looked in fe_values.h to see if it was commented in the implementation 
and all that I see there is

  hessian_type return_value; 
  for (unsigned int d=0; d 

http://www.dealii.org/8.5.0/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html#a15728437b942dab0b0042eb06a407d2c>
) 
if (shape_function_data[shape_function].
is_nonzero_shape_function_component[d]) 
   return_value[d] 
 = fe_values->finite_element_output.shape_hessians[
shape_function_data[shape_function].row_index[d]][q_point];

which I'm not quite sure how to parse. The comments in the header file only 
say "same as for the scalar case except that we have one more index." (the 
added index is d).

This is why I brought my question here. 

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Extracting Shape Laplacian

[Wolfgang Bangerth]

On 08/09/2017 03:46 PM, ky...@math.uh.edu wrote:


Hello all,

I am working on implementing some stabilization methods for the Navier-Stokes 
equations, these techniques often require the use of the laplacian of the 
shape functions. I know I get the hessian of the k'th shape function at 
quadratue point q via the following


|
Tensor<3,dim>hessian_phi =fe_values[velocity_extractor].hessian(k,q);
|

My question is understanding what does this return, and how to extract the 
laplacian from it. Does hessian_phi[ i ][ j ][ k ] = \frac{  \partial 
\varphi_{ i }   } {  \partial x_{ j } \partial x_{ k }   }?


I don't recall, but it should be documented somewhere with 
FEValuesViews::Vector IIRC.



If this is the case, is there a way to contract over the last two components 
to result in a rank 1 tensor that is the laplacian?


Not as you are trying, but you can easily write the summation over the last 
two indices by hand, of course.



I've also seen that I can use shape_hessian_component since I am using 
standard Q2-Q1 elements,


|
intcomponent_i =fe.system_to_component(k ).first;
Tensor<2,dim>hessian_phi =fe_values.shape_hessian_component(k,q,component_i );
|

In this case I can get the laplacian of the i'th component of the k'th shape 
function at quadrature point q by trace( hessian_phi ). But this will result 
in a rank 0 tensor.


Yes, it is the trace of the i'th component. You can then construct a
  Tensor<1,dim> traces;
  for (i=0...dim)
{
   traces_phi = fe_values.shape_hessian_component (...);
   traces[i] = trace(hessian_phi)
}

Best
 W.

--

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

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Extracting Shape Laplacian

[kylew]

I found that my idea above was not what I had typed in my code, I am no 
longer receiving the run time error. However I would still like some 
verification that the indices are as I think they are.

>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Extracting Shape Laplacian

[kylew]

Hello all,

I am working on implementing some stabilization methods for the 
Navier-Stokes equations, these techniques often require the use of the 
laplacian of the shape functions. I know I get the hessian of the k'th 
shape function at quadratue point q via the following

Tensor<3, dim> hessian_phi = fe_values[velocity_extractor].hessian(k, q);

My question is understanding what does this return, and how to extract the 
laplacian from it. Does hessian_phi[ i ][ j ][ k ] = \frac{  \partial 
\varphi_{ i }   } {  \partial x_{ j } \partial x_{ k }   }?

If this is the case, is there a way to contract over the last two 
components to result in a rank 1 tensor that is the laplacian? My idea was 
the following

std::vector< Tensor<1, dim> > laplace_phi_u (dofs_per_cell);
Tensor<3, dim> hessian_phi = fe_values[velocity_extractor].hessian(k, q);
for( int i=0; i hessian_phi = fe_values.shape_hessian_component( k, q, 
component_i );

In this case I can get the laplacian of the i'th component of the k'th 
shape function at quadrature point q by trace( hessian_phi ). But this will 
result in a rank 0 tensor. It would be much more convenient if I could 
convert this back into a rank 1 tensor as the laplacian of the k'th shape 
function. Again though I run into the same problem as above with only 0 
assignment is allowed.

Thanks

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Can we say that the higher order method, the more accurate?

[Jaekwang Kim]

Dear Howe

I have solved this problem before, but I am not sure weather you are 
meeting same problem that I have encountered. 

If your mesh has unstructured structure, (not a rectangular one) you should 
higher order mapping when you asses finite element 
I remember that deal.ii default was Q1 mapping, so you might have been 
caught error form this... 

For example... I fixed my code as... 

Please look for 2 red lines I am impose same degree of mapping 

Thanks 

template 

void StokesProblem::initial_assemble_system ()

{

system_matrix=0;

system_rhs=0;

*const MappingQ mapping (degree);*

QGauss   quadrature_formula(degree+2);



FEValues fe_values (*mapping,* fe, quadrature_formula,

 update_values|

 update_quadrature_points  |

 update_JxW_values |

 update_gradients);



On Wednesday, August 9, 2017 at 3:06:39 AM UTC-5, Howe wrote:
>
> Dear Martin,
>
> Thanks for your rapid response.
> 1.
> The MappingQ is set to be the same as the order of velocity, as is shown 
> in the following code snippet:
>
>
>> *template *
>> *NS::NS (ParameterHandler &prm)*
>> *:*
>> *   parameters (&prm),*
>> *   degree (prm.get_integer("pressure degree")),*
>> *   fe( FE_Q(QGaussLobatto<1>(degree+2)), dim,*
>> *   FE_Q(QGaussLobatto<1>(degree+1)),   1),*
>> *   fe_scalar (FE_Q(QGaussLobatto<1>(degree+2))),*
>> *   dof_handler (triangulation),*
>> *   dof_handler_scalar (triangulation),*
>> *   mapping (degree+2),*
>> *   computing_timer (std::cout,*
>> *   TimerOutput::summary,**   TimerOutput::wall_times)*
>
>
> I am not quite sure whether the computation of the lift/drag in my code is 
> right, and my implementation  is almost the same as the one in this post: 
> https://groups.google.com/d/msg/dealii/rS6soTb69ig/C4QchAyEGwAJ 
> The only change is the first line :
>
> *QGauss face_quadrature_formula(degree+2);*
>
>
> 2. I am using deal.II 8.4.0 now, and I think i am not using manifold 
> description in my code
>
> 3. The mesh is shown as follows:
>
>
> 
>
>
> Best,
>
> Howe
>
>
> 在 2017年8月9日星期三 UTC+8下午3:25:20，Martin Kronbichler写道：
>>
>> Dear Howe,
>>
>> How did you run your simulation? From your picture, it appears that a 
>> higher order method is worse at higher degrees than a lower order method, 
>> which does not match with my experience. If that were the case, nobody 
>> would use high orders. However, you need to bring many pieces in place to 
>> really get to the benefit of the high order method for somewhat more 
>> complicated examples such as the flow around a cylinder. Here is a list of 
>> things to look at:
>>
>> - Do you use a high-order polynomial mapping MappingQ of the same or 
>> higher degree as the interpolation space? Do you use this mapping in all 
>> routines that evaluate quantities, such as the usual assembly, the 
>> computation of the lift/drag, and so on?
>> - Do you use a manifold description that extends into the domain? (Look 
>> into TransfiniteInterpolationManifold.) Without, you will not get more than 
>> third order convergence.
>> - Do you have a good mesh around the area of interest? Flows around 
>> cylinders tend to be really really sensitive to the mesh quality around the 
>> cylinder.
>>
>> For the Navier-Stokes equations around the cylinder, if everything is 
>> done right one gets significantly improved results in terms of accuracy 
>> over the number of degrees of freedom up to degree (6,5) 
>> (velocity,pressure). Beyond that picture is less clear. At least with the 
>> meshes that we tried in our group it was not worth to go beyond. You can 
>> have a look a our results in section 5.4 and Figs. 9 and 10 of this 
>> preprint:
>> https://arxiv.org/pdf/1706.09252.pdf
>>
>> Best,
>> Martin
>>
>> On 09.08.2017 09:01, Howe wrote:
>>
>> Dear Jaekwang  
>>
>> Have you solved this problem? If yes, Could pls share your solution with 
>> us?
>> I am simulating a steady state flow over a cylinder, and the drag/lift 
>> coefficient shows an unexpected trend of change as i increase the 
>> discretization order and refine the mesh.
>>
>>
>> 
>>
>> As is shown in the figure, the Cd increased as the cells increased for 
>> all the discretization orders, however, for a fixed cells, the Cd decreased 
>> as the discretization order increased.
>>
>> In my opinion, to increase the order and refine the mesh should both make 
>> the approximation more close to the exact solution, thus should have the 
>> same trend of change.
>>
>> 在 2016年9月18日星期日 UTC+8下午11:57:16，Jaekwang Kim写道： 
>>>
>>>
>>> Hello, I am a starter of dealii and

[deal.II] Re: Now more than 1000 publications using deal.II :-)

[Tuanny Cajuhi]

Dear Wolfgang,

our paper based on deal.II is online:

Phase-field modeling of fracture in variably saturated porous media. 
T. Cajuhi, L. Sanavia, L. De Lorenzis.
Comput Mech (2017)
https://doi.org/10.1007/s00466-017-1459-3

Thanks for adding to the list. 

Best regards,
Tuanny


On Monday, July 17, 2017 at 11:44:18 PM UTC+2, Wolfgang Bangerth wrote:
>
>
> All, 
> we periodically collect publications that show results obtained using 
> deal.II at 
>http://dealii.org/publications.html 
> As of today, there are now more than 1,000 such publications that we 
> know of -- I think that's a nice reflection of the community that now 
> supports this project! 
>
> Most of these we just happen to come across using search engines [1], 
> but it would be much easier if we would hear about them as they get 
> published. If you have written a paper, preprint, PhD thesis, MSc 
> thesis, or anything else in which you use deal.II, please do let us know! 
>
> Cheers 
>   W. 
>
>
> [1] We search for these publications because we need to demonstrate to 
> our funding agencies and departments that what we do is useful to a lot 
> of people. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Can we say that the higher order method, the more accurate?

[Martin Kronbichler]

Dear Howe,

Regarding 1., the main question is whether you added the 'mapping' 
variable as the first arguments to all FEValues and FEFaceValues 
constructors, to calls to VectorTools::interpolate* and 
VectorTools::integrate_difference calls and the like, i.e., all routines 
that internally construct an FEValues or FEFaceValues object. There is 
defaults for many of those data structures using linear mappings, 
MappingQ1, but you don't want to use them but rather the high order 
description.


Regarding 2, I guess you are using a curved boundary description as 
explained in step-1? You need to tell the triangulation to use a curved 
description.


Regarding 3, your mesh looks quite good. You would probably want to use 
a volume manifold on the whole circular part of the domain, though. And 
ideally a TransfiniteInterpolationManifold on the regions where you go 
from the circle to the straight ends, but the latter is not yet 
available in any of the releases yet, only the github code, and it is 
not critical and you should get better results up to degree 3 at least.


Best,
Martin


On 09.08.2017 10:06, Howe wrote:

Dear Martin,

Thanks for your rapid response.
1.
The MappingQ is set to be the same as the order of velocity, as is 
shown in the following code snippet:


/template 
//NS::NS (ParameterHandler &prm)
//:
//   parameters (&prm),
//   degree (prm.get_integer("pressure degree")),
//   fe( FE_Q(QGaussLobatto<1>(degree+2)), dim,
// FE_Q(QGaussLobatto<1>(degree+1)), 1),
//   fe_scalar (FE_Q(QGaussLobatto<1>(degree+2))),
//   dof_handler (triangulation),
//   dof_handler_scalar (triangulation),
//mapping (degree+2),
//   computing_timer (std::cout,
//   TimerOutput::summary,
//   TimerOutput::wall_times)/


I am not quite sure whether the computation of the lift/drag in my 
code is right, and my implementation  is almost the same as the one in 
this post: 
https://groups.google.com/d/msg/dealii/rS6soTb69ig/C4QchAyEGwAJ

The only change is the first line :

/QGauss face_quadrature_formula(degree+2);/


2. I am using deal.II 8.4.0 now, and I think i am not using manifold 
description in my code


3. The mesh is shown as follows:




Best,

Howe



在 2017年8月9日星期三 UTC+8下午3:25:20，Martin Kronbichler写道：

Dear Howe,

How did you run your simulation? From your picture, it appears
that a higher order method is worse at higher degrees than a lower
order method, which does not match with my experience. If that
were the case, nobody would use high orders. However, you need to
bring many pieces in place to really get to the benefit of the
high order method for somewhat more complicated examples such as
the flow around a cylinder. Here is a list of things to look at:

- Do you use a high-order polynomial mapping MappingQ of the same
or higher degree as the interpolation space? Do you use this
mapping in all routines that evaluate quantities, such as the
usual assembly, the computation of the lift/drag, and so on?
- Do you use a manifold description that extends into the domain?
(Look into TransfiniteInterpolationManifold.) Without, you will
not get more than third order convergence.
- Do you have a good mesh around the area of interest? Flows
around cylinders tend to be really really sensitive to the mesh
quality around the cylinder.

For the Navier-Stokes equations around the cylinder, if everything
is done right one gets significantly improved results in terms of
accuracy over the number of degrees of freedom up to degree (6,5)
(velocity,pressure). Beyond that picture is less clear. At least
with the meshes that we tried in our group it was not worth to go
beyond. You can have a look a our results in section 5.4 and Figs.
9 and 10 of this preprint:
https://arxiv.org/pdf/1706.09252.pdf


Best,
Martin


On 09.08.2017 09:01, Howe wrote:

Dear Jaekwang

Have you solved this problem? If yes, Could pls share your
solution with us?
I am simulating a steady state flow over a cylinder, and the
drag/lift coefficient shows an unexpected trend of change as i
increase the discretization order and refine the mesh.




As is shown in the figure, the Cd increased as the cells
increased for all the discretization orders, however, for a fixed
cells, the Cd decreased as the discretization order increased.

In my opinion, to increase the order and refine the mesh should
both make the approximation more close to the exact solution,
thus shou

Re: [deal.II] Re: Can we say that the higher order method, the more accurate?

[Howe]

Dear Martin,

Thanks for your rapid response.
1.
The MappingQ is set to be the same as the order of velocity, as is shown in 
the following code snippet:


> *template *
> *NS::NS (ParameterHandler &prm)*
> *:*
> *   parameters (&prm),*
> *   degree (prm.get_integer("pressure degree")),*
> *   fe( FE_Q(QGaussLobatto<1>(degree+2)), dim,*
> *   FE_Q(QGaussLobatto<1>(degree+1)),   1),*
> *   fe_scalar (FE_Q(QGaussLobatto<1>(degree+2))),*
> *   dof_handler (triangulation),*
> *   dof_handler_scalar (triangulation),*
> *   mapping (degree+2),*
> *   computing_timer (std::cout,*
> *   TimerOutput::summary,**   TimerOutput::wall_times)*


I am not quite sure whether the computation of the lift/drag in my code is 
right, and my implementation  is almost the same as the one in this post: 
https://groups.google.com/d/msg/dealii/rS6soTb69ig/C4QchAyEGwAJ 
The only change is the first line :

*QGauss face_quadrature_formula(degree+2);*


2. I am using deal.II 8.4.0 now, and I think i am not using manifold 
description in my code

3. The mesh is shown as follows:




Best,

Howe


在 2017年8月9日星期三 UTC+8下午3:25:20，Martin Kronbichler写道：
>
> Dear Howe,
>
> How did you run your simulation? From your picture, it appears that a 
> higher order method is worse at higher degrees than a lower order method, 
> which does not match with my experience. If that were the case, nobody 
> would use high orders. However, you need to bring many pieces in place to 
> really get to the benefit of the high order method for somewhat more 
> complicated examples such as the flow around a cylinder. Here is a list of 
> things to look at:
>
> - Do you use a high-order polynomial mapping MappingQ of the same or 
> higher degree as the interpolation space? Do you use this mapping in all 
> routines that evaluate quantities, such as the usual assembly, the 
> computation of the lift/drag, and so on?
> - Do you use a manifold description that extends into the domain? (Look 
> into TransfiniteInterpolationManifold.) Without, you will not get more than 
> third order convergence.
> - Do you have a good mesh around the area of interest? Flows around 
> cylinders tend to be really really sensitive to the mesh quality around the 
> cylinder.
>
> For the Navier-Stokes equations around the cylinder, if everything is done 
> right one gets significantly improved results in terms of accuracy over the 
> number of degrees of freedom up to degree (6,5) (velocity,pressure). Beyond 
> that picture is less clear. At least with the meshes that we tried in our 
> group it was not worth to go beyond. You can have a look a our results in 
> section 5.4 and Figs. 9 and 10 of this preprint:
> https://arxiv.org/pdf/1706.09252.pdf
>
> Best,
> Martin
>
> On 09.08.2017 09:01, Howe wrote:
>
> Dear Jaekwang  
>
> Have you solved this problem? If yes, Could pls share your solution with 
> us?
> I am simulating a steady state flow over a cylinder, and the drag/lift 
> coefficient shows an unexpected trend of change as i increase the 
> discretization order and refine the mesh.
>
>
> 
>
> As is shown in the figure, the Cd increased as the cells increased for all 
> the discretization orders, however, for a fixed cells, the Cd decreased as 
> the discretization order increased.
>
> In my opinion, to increase the order and refine the mesh should both make 
> the approximation more close to the exact solution, thus should have the 
> same trend of change.
>
> 在 2016年9月18日星期日 UTC+8下午11:57:16，Jaekwang Kim写道： 
>>
>>
>> Hello, I am a starter of dealii and am learning a lot these days with the 
>> help of video lectures and tutorial examples. 
>>
>> I modified step-22 code (stokes flow code) into my own problem, the flow 
>> around sphere.
>>
>> and I intend to evaluate the drag force (which is analytically given by 
>> stokes equation) 
>>
>> My code reached quite close to the value since the absolute error  : 
>> abs(drag_calculated-drag_exact)/drag_exact is around 10^(-3)
>>
>> However, I expected that if I input higher 'degree' I will receive more 
>> accurate result, but it didn't
>>
>> Obviously Q2 is better than Q1. and Q3 is better than Q2. But Q4 or Q4 is 
>> not better than Q2 or Q3? 
>>
>> Is there any reason on this? 
>>
>> (To be specific, if i say degree 2 , that mean I use (2+1) for velocity, 
>> (2) for pressure, and (2+2) for Gauss integral
>>
>>
>> Thank you 
>>
>> Jaekwang Kim  
>>
> -- 
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "deal.II User Group" group.
> To unsubscribe from this group and stop receivi

Re: [deal.II] Re: Can we say that the higher order method, the more accurate?

[Martin Kronbichler]

Dear Howe,

How did you run your simulation? From your picture, it appears that a 
higher order method is worse at higher degrees than a lower order 
method, which does not match with my experience. If that were the case, 
nobody would use high orders. However, you need to bring many pieces in 
place to really get to the benefit of the high order method for somewhat 
more complicated examples such as the flow around a cylinder. Here is a 
list of things to look at:


- Do you use a high-order polynomial mapping MappingQ of the same or 
higher degree as the interpolation space? Do you use this mapping in all 
routines that evaluate quantities, such as the usual assembly, the 
computation of the lift/drag, and so on?
- Do you use a manifold description that extends into the domain? (Look 
into TransfiniteInterpolationManifold.) Without, you will not get more 
than third order convergence.
- Do you have a good mesh around the area of interest? Flows around 
cylinders tend to be really really sensitive to the mesh quality around 
the cylinder.


For the Navier-Stokes equations around the cylinder, if everything is 
done right one gets significantly improved results in terms of accuracy 
over the number of degrees of freedom up to degree (6,5) 
(velocity,pressure). Beyond that picture is less clear. At least with 
the meshes that we tried in our group it was not worth to go beyond. You 
can have a look a our results in section 5.4 and Figs. 9 and 10 of this 
preprint:

https://arxiv.org/pdf/1706.09252.pdf

Best,
Martin


On 09.08.2017 09:01, Howe wrote:

Dear Jaekwang

Have you solved this problem? If yes, Could pls share your solution 
with us?
I am simulating a steady state flow over a cylinder, and the drag/lift 
coefficient shows an unexpected trend of change as i increase the 
discretization order and refine the mesh.




As is shown in the figure, the Cd increased as the cells increased for 
all the discretization orders, however, for a fixed cells, the Cd 
decreased as the discretization order increased.


In my opinion, to increase the order and refine the mesh should both 
make the approximation more close to the exact solution, thus should 
have the same trend of change.



在 2016年9月18日星期日 UTC+8下午11:57:16，Jaekwang Kim写道：


Hello, I am a starter of dealii and am learning a lot these days
with the help of video lectures and tutorial examples.

I modified step-22 code (stokes flow code) into my own problem,
the flow around sphere.

and I intend to evaluate the drag force (which is analytically
given by stokes equation)

My code reached quite close to the value since the absolute error
 : abs(drag_calculated-drag_exact)/drag_exact is around 10^(-3)

However, I expected that if I input higher 'degree' I will receive
more accurate result, but it didn't

Obviously Q2 is better than Q1. and Q3 is better than Q2. But Q4
or Q4 is not better than Q2 or Q3?

Is there any reason on this?

(To be specific, if i say degree 2 , that mean I use (2+1) for
velocity, (2) for pressure, and (2+2) for Gauss integral


Thank you

Jaekwang Kim

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en

---
You received this message because you are subscribed to the Google 
Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to dealii+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Can we say that the higher order method, the more accurate?

[Howe]

Dear Jaekwang 

Have you solved this problem? If yes, Could pls share your solution with us?
I am simulating a steady state flow over a cylinder, and the drag/lift 
coefficient shows an unexpected trend of change as i increase the 
discretization order and refine the mesh.



As is shown in the figure, the Cd increased as the cells increased for all 
the discretization orders, however, for a fixed cells, the Cd decreased as 
the discretization order increased.

In my opinion, to increase the order and refine the mesh should both make 
the approximation more close to the exact solution, thus should have the 
same trend of change.

在 2016年9月18日星期日 UTC+8下午11:57:16，Jaekwang Kim写道：
>
>
> Hello, I am a starter of dealii and am learning a lot these days with the 
> help of video lectures and tutorial examples. 
>
> I modified step-22 code (stokes flow code) into my own problem, the flow 
> around sphere.
>
> and I intend to evaluate the drag force (which is analytically given by 
> stokes equation) 
>
> My code reached quite close to the value since the absolute error  : 
> abs(drag_calculated-drag_exact)/drag_exact is around 10^(-3)
>
> However, I expected that if I input higher 'degree' I will receive more 
> accurate result, but it didn't
>
> Obviously Q2 is better than Q1. and Q3 is better than Q2. But Q4 or Q4 is 
> not better than Q2 or Q3? 
>
> Is there any reason on this? 
>
> (To be specific, if i say degree 2 , that mean I use (2+1) for velocity, 
> (2) for pressure, and (2+2) for Gauss integral
>
>
> Thank you 
>
> Jaekwang Kim  
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.