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

[Howe]

Dear Jaekwang,

Thanks for your code, I do come with the same problem as yours! 
After adding a "mapping" to the constructor of the FEFaceValues  in my 
code, the problem solved~

Best,
Howe

在 2017年8月10日星期四 UTC+8上午3:26:00，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 )*
>>> *:*
>>> *   parameters (),*
>>> *   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 

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

[Howe]

Dear Matrin

Thank you very much! 
It is exactly the problem of "mapping", in my calculation of the drag/lift 
coefficient, a "mapping" is not added as the first argument to the 
FEFaceValues constructor. After this fixed, the result looks much better.

Once again, thanks for your kind help!

Best,
Howe

在 2017年8月9日星期三 UTC+8下午5:38:57，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 ) *
>> *: *
>> *   parameters (), *
>> *   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.
>>
>>
>> 

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 )*
>> *:*
>> *   parameters (),*
>> *   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 

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 )
//:
//   parameters (),
//   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 

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 )*
> *:*
> *   parameters (),*
> *   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 receiving 

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.

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

[Daniel Arndt]

Jaekwang,

Have a look at step-10. There you see how the order of the mapping 
influences the error.
Basically, you have to set the mapping for your FEValues objects, when you 
compute error via integrate_difference
and when you project or interpolate some Function to an FE Vector.

Best,
Daniel

Am Dienstag, 20. September 2016 18:10:11 UTC+2 schrieb JAEKWANG KIM:
>
>
>
> 2016년 9월 18일 일요일 오전 10시 57분 16초 UTC-5, 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.

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

[JAEKWANG KIM]

2016년 9월 18일 일요일 오전 10시 57분 16초 UTC-5, 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.

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

[JAEKWANG KIM]

Thank you for all repliers!!

I tried fix code as you mentioned please see redline...

 template 

  void StokesProblem::assemble_system ()

  {

system_matrix=0;

system_rhs=0;


*QGaussLobatto<**2>   quadrature_formula(degree+2);*


FEValues fe_values (fe, quadrature_formula,

 update_values|

 update_quadrature_points  |

 update_JxW_values |

 update_gradients);



but I received an error message that







An error occurred in line <1831> of file 
 in 
function

void dealii::BlockMatrixBase::add(const 
size_type, const size_type, const value_type) [MatrixType = 
dealii::SparseMatrix]

The violated condition was: 

dealii::numbers::is_finite(value)

The name and call sequence of the exception was:

ExcNumberNotFinite(std::complex(value))

Additional Information: 

In a significant number of places, deal.II checks that some intermediate 
value is a finite number (as opposed to plus or minus infinity, or NaN/Not 
a Number). In the current function, we encountered a number that is not 
finite (its value is (nan,0) and therefore violates the current assertion.


This may be due to the fact that some operation in this function created 
such a value, or because one of the arguments you passed to the function 
already had this value from some previous operation. In the latter case, 
this function only triggered the error but may not actually be responsible 
for the computation of the number that is not finite.


There are two common cases where this situation happens. First, your code 
(or something in deal.II) divides by zero in a place where this should not 
happen. Or, you are trying to solve a linear system with an unsuitable 
solver (such as an indefinite or non-symmetric linear system using a 
Conjugate Gradient solver); such attempts oftentimes yield an operation 
somewhere that tries to divide by zero or take the square root of a 
negative value.


In any case, when trying to find the source of the error, recall that the 
location where you are getting this error is simply the first place in the 
program where there is a check that a number (e.g., an element of a 
solution vector) is in fact finite, but that the actual error that computed 
the number may have happened far earlier. To find this location, you may 
want to add checks for finiteness in places of your program visited before 
the place where this error is produced.One way to check for finiteness is 
to use the 'AssertIsFinite' macro.

-- 
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 Jaekwang,

if you are using the most recent developer version, you should
automatically get the Gauss-Lobatto version of the node distribution. We
made those point distributions the default for FE_Q(degree) this spring.

Regarding the limits of quadrature formulas: Depending on what exactly
you are doing, I would expect that the accuracy decreases as soon as you
go beyond degree 10 or so. I don't think that your problem is the
accuracy issues in terms of roundoff, because those issues would appear
first as you go beyond 1e-10.

Did you check the suggestions regarding the mapping? (I.e., you put a
"Mapping" argument to all the constructors of FEValues,
FEFaceValues, interpolate_boundary_values, etc.) Are the solver
tolerances tight enough? What happens if the mesh is refined? If this
still does not help, it might be good to share a small example where the
issue is observed.

Best,
Martin


On 09/20/2016 04:35 PM, JAEKWANG KIM wrote:
> thank for the reply!!
>
> my fe degree is declared as "fe (FE_Q(degree+1),
> dim,FE_Q(degree), 1)" and I used "QGauss  
> quadrature_formula(degree+2);" to calculate integral over the cell. 
>
> 2016년 9월 20일 화요일 오전 9시 26분 6초 UTC-5, Praveen C 님의 말:
>
>
> On Tue, Sep 20, 2016 at 7:49 PM, JAEKWANG KIM  > wrote:
>
> Can I ask more about "the limits of our implementation of our
> quadrature formulas?". 
> I wonder when it usually happens. 
>
>
> Once I calculated drag coefficient, with Q1, my error is 10%
> compare to exact solution. 
> However, I can 1.7% error when I use Q2 which is significant
> decrease!
> At Q3, I get 0.4% and At Q4 it starts to increase again 0.5%. 
> If I go higher, then my error is more than 100%. I really
> want to figure out why this happens
>
> To summarize 
> From Q1~Q3... it shows significant decrease in error
> but it is not anymore at Q4 and Q5 
>
>
> Hi
>
> If you are using FE_Q space with uniformly spaced support points,
> then there could be problem at higher degrees. Just to check, you
> should use Gauss nodes, e.g.
>
> FE_Q(QGaussLobatto<1>(degree+1))
>
> Best
> praveen
>
> -- 
> 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.

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

[Praveen C]

On Tue, Sep 20, 2016 at 7:49 PM, JAEKWANG KIM  wrote:

> Can I ask more about "the limits of our implementation of our quadrature
> formulas?".
> I wonder when it usually happens.
>
>
> Once I calculated drag coefficient, with Q1, my error is 10% compare to
> exact solution.
> However, I can 1.7% error when I use Q2 which is significant decrease!
> At Q3, I get 0.4% and At Q4 it starts to increase again 0.5%.
> If I go higher, then my error is more than 100%. I really want to
> figure out why this happens
>
> To summarize
> From Q1~Q3... it shows significant decrease in error
> but it is not anymore at Q4 and Q5
>

Hi

If you are using FE_Q space with uniformly spaced support points, then
there could be problem at higher degrees. Just to check, you should use
Gauss nodes, e.g.

FE_Q(QGaussLobatto<1>(degree+1))

Best
praveen

-- 
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]

Can I ask more about "the limits of our implementation of our quadrature 
formulas?". 
I wonder when it usually happens. 


Once I calculated drag coefficient, with Q1, my error is 10% compare to 
exact solution. 
However, I can 1.7% error when I use Q2 which is significant decrease!
At Q3, I get 0.4% and At Q4 it starts to increase again 0.5%. 
If I go higher, then my error is more than 100%. I really want to 
figure out why this happens

To summarize 
>From Q1~Q3... it shows significant decrease in error
but it is not anymore at Q4 and Q5 

2016년 9월 19일 월요일 오전 8시 8분 21초 UTC-5, Guido Kanschat 님의 말:
>
> You will also encounter the limits of our implementation of our quadrature 
> formulas and our polynomial evaluation. Both are not stable for high order, 
> and thus at some point approximation will stall.
>
> Best,
> Guido
>
>
>
> -- 
> Prof. Dr. Guido Kanschat
> Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
> Universität Heidelberg
> Im Neuenheimer Feld 368, 69120 Heidelberg
>

-- 
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?

[Guido Kanschat]

You will also encounter the limits of our implementation of our quadrature
formulas and our polynomial evaluation. Both are not stable for high order,
and thus at some point approximation will stall.

Best,
Guido



-- 
Prof. Dr. Guido Kanschat
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Universität Heidelberg
Im Neuenheimer Feld 368, 69120 Heidelberg

-- 
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?

[Bruno Turcksin]

On Monday, September 19, 2016 at 2:12:31 AM UTC-4, Martin Kronbichler wrote:
>
>
> In addition to what Daniel and Wolfgang said: One does definitely benefit 
> from going to higher degrees and deal.II is able to handle this (the 
> accurate boundary representation by a mapping is one thing that is easily 
> forgotten). In a recent preprint, we considered the flow around a cylinder, 
> a standard benchmark test for the incompressible Navier-Stokes equations:
> http://arxiv.org/pdf/1607.01323v1.pdf
>
34 billions degrees of freedom on 147,456 cores. Not too bad...

Best,

Bruno

-- 
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?

[Martin Kronbichler]

Dear Jaekwank,

In addition to what Daniel and Wolfgang said: One does definitely benefit 
from going to higher degrees and deal.II is able to handle this (the 
accurate boundary representation by a mapping is one thing that is easily 
forgotten). In a recent preprint, we considered the flow around a cylinder, 
a standard benchmark test for the incompressible Navier-Stokes equations:
http://arxiv.org/pdf/1607.01323v1.pdf
Go to page 23, Table 1, to see how the solution quality increases as the 
polynomial degree is increased from 4 to 7.

Best,
Martin

On Sunday, September 18, 2016 at 5:57:16 PM UTC+2, JAEKWANG KIM wrote:
>
>
> 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.

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

[Wolfgang Bangerth]

On 09/18/2016 05:34 PM, JAEKWANG KIM wrote:

I also wonder whether their is a limitation in higher order method that deal
offer.

If no, then we can use Q10 method, just putting degree value as 10?


Yes. It will work, but you will find practical restrictions such as the fact 
that matrices become very dense and difficult to invert.


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.

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

[Wolfgang Bangerth]

On 09/18/2016 03:43 PM, JAEKWANG KIM wrote:


To, Daniel Arndt.
Also, I didn't understand what you meant by
_"Are you using a Mapping of the same order as your velocity ansatz space is?"_


You will want to look at the step-10 and step-11 tutorial programs to see what 
mappings are.


You can't expect a high accuracy for a boundary integral if the boundary is 
not accurately represented.


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: Can we say that the higher order method, the more accurate?

[JAEKWANG KIM]

I also wonder whether their is a limitation in higher order method that 
deal offer. 

If no, then we can use Q10 method, just putting degree value as 10?  

-- 
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?

[JAEKWANG KIM]

This is how my mesh looks like. 
I am using half domain of 2D sphere assuming that it would symmetrical 
along phi domain. 
Tho my domain is 2d, I am describing 3D phenomena. I am using cylindrical 
coordinate. 
So... in real horizontal line mean r-axis and vertical line is z-axis. 

When r=0 (so the left straight line), I used boundary condition that u_r=0 
(because there will be no flow across this axis if flow is symmetric) 

other boundary, sphere boundary condition is 0 velocity, and top,end,right 
side boundary condition is given by analytical solution (it was expressed 
in spherical coordinate, so I transferred it into cylindrical coordinate) 

To, Daniel Arndt. 
Also, I didn't understand what you meant by 
*"Are you using a Mapping of the same order as your velocity ansatz space 
is?"*


Thanks for reply!!!

-- 
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?

[Daniel Arndt]

Jaekwank,

You would indeed expect significantly better results with higher polynomial 
degree on the same mesh, if the solution is sufficiently regular.
What kind of mesh are you using? Are you resolving all the boundary layers 
suitably? Are you using a Mapping of the same order as your velocity ansatz 
space is?

Best,
Daniel

Am Sonntag, 18. September 2016 17:57:16 UTC+2 schrieb 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.