Re: [deal.II] Extracting Shape Laplacian

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

Re: [deal.II] Extracting Shape Laplacian

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 quadratu

[deal.II] Re: Extracting Shape Laplacian

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

[deal.II] Extracting Shape Laplacian

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

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

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 ma

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

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

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

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 const

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

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(

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

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 pl

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

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.