[deal.II] fixing one component of solution to the same value

Hello all, I am using deal.ii to solve a 3D solid mechanics problem which uses p::d::triangulation. I am solving equilibrium equations to solve for the displacement in the domain. The domain of the problem is a cylinder with the z-axis aligned along the axis of the cylinder. To avoid the war

Re: [deal.II] Re: Internal instability of the GMRES Solver / Trilinos

Pascal, I have no idea why this is happening. I think you have to try to make a minimal example that hangs so we can find out what the problem is. I assume we incorrectly allocate/deallocate temporary vectors somewhere. Are all processors stuck inside > 9 dealii::TrilinosWrappers::MPI::Vector::re

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

Dear Seyed, But according to the documentation this is only true for sequential > triangulations and not for distributed triangulations. Ah yes, of course, my mistake . Sure. How and where can I

[deal.II] Re: Internal instability of the GMRES Solver / Trilinos

By the way: After some time I see the additional function opal_progress() on top of the stack. Also here is what I use: gcc (GCC) 6.3.1 20170306 openmpi 1.10.6-1 trilinos-12.6.1 dealii-8.4.1 and my testcases consit of 4 MPI processes. Am Dienstag, 14. März 2017 19:29:09 UTC+1 schrieb Pascal Kraft

[deal.II] Internal instability of the GMRES Solver / Trilinos

Dear list members, I am facing a really weird problem, that I have been struggling with for a while now. I have written a problem class which, based on other objects, generates a system matrix, rhs and solution vector object. The datastructures are Trilinos Block distributed types. When I do th

[deal.II] Evaluate solution of face elements

Dear all, I'm trying to evaluate the solution of face elements (FE_FaceQ) at specific points on a face. For uniformly refined meshes the following works perfectly (as far as I can tell) std::vector> result_values (1, Vector(1)); const Point punit_face = StaticMappingQ1::mapping

Re: [deal.II] Re: Issue of extrude_triangulation for distributed mesh

Wenbo, 2017-03-14 11:21 GMT-04:00 : > "Virtual material? This seems strange. " > We can fill with "strong absorption" material which is similar with zero > boundary condition. So you would use strong absorption in a diffusion equation? But the diffusion equation is derived assuming that there is

Re: [deal.II] Re: Issue of extrude_triangulation for distributed mesh

Bruno, Thanks for your reply! "Virtual material? This seems strange. " We can fill with "strong absorption" material which is similar with zero boundary condition. The method you give is great! You mean vertex move on the same level of refinement is OK. But after refinement, vertex which belon

Re: [deal.II] Re: Issue of extrude_triangulation for distributed mesh

Wenbo, 2017-03-14 9:49 GMT-04:00 : > For example, the case is with 289 * 289 cells. Firstly we define coase mesh > with 19*19. And then coarse mesh is refined 4 times. The fine mesh would be > with 19*16 * 19*16 = 304 * 304 which coverd 289*289 cells and is with more > layers near boundary. Then

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

I solved the problem. The following line had to be fixed in order to prevent the error due to the changing size of the vectors which were passed to MPI_Allreduce: int disp_size = dof_handler.n_dofs()/dim; Nevertheless, I wonder, if there are any commands like dof_handler.n_dofs() which also u

[deal.II] Re: Issue of extrude_triangulation for distributed mesh

Bruno, I have one more question about your methods. For example, the case is with 289 * 289 cells. Firstly we define coase mesh with 19*19. And then coarse mesh is refined 4 times. The fine mesh would be with 19*16 * 19*16 = 304 * 304 which coverd 289*289 cells and is with more layers near bou

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

I think I found the problem regarding the mesh refinement issue in parallel mode. Probably, it is not even related to the boundary indicators. From what I understood, there is a problem with the MPI_Allreduce function I mentioned in the previous post: https://groups.google.com/forum/#!topic/dea

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

Dear Jean-Paul, > Yes, this looks like a copy-paste error in the documentation. Would you > like to submit a patch to correct it? > Sure. How and where can I submit a patch? When you refine cells at a boundary, the child cell's faces will inherit > the boundary and manifold ID's of the pa

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

Dear Seyed, I assume there is a mistake within the documentation of > parallel::distributed::Triangulation class. Below the > "detailed description" part within the second box there is written > &MyGeometry. Doesn't it have to be &MyClass? > Yes, this looks like a copy-paste error in the docum