Re: [deal.II] Unsuccessful integration of p4est with dealii

2016-12-12 Thread 'Uwe Köcher' via deal . II User Group
Dear Kartik, well, candi has users around the world - if it reports a successful installation, then everything should be fine. But anyhow, you can go to each installation folder, e.g. deal.II, and try to run their specific test suite, if available. Kind regards Uwe On Monday, December 12, 20

Re: [deal.II] square pyramid boundary

2016-12-12 Thread Jean-Paul Pelteret
Dear Loylick, Great, I'm glad you've managed to create a grid using the merge function. The way that you've specified the boundary id's is typically fine. The other function sets the boundary id's of both the faces and edges, which is unnecessary for most cases. Regards, Jean-Paul On Tuesday,

Re: [deal.II] square pyramid boundary

2016-12-12 Thread Loylick
Hi! Thanks for reply. Following to 1) I have built my square pyramid from 2 simplexes end merged them. Next problem arose immediately. I realized that I did not quite understand which of set_boundary functions to use. Is the following code enough or I should use some more sophisticated approac

[deal.II] Re: Periodic boundary conditions seem to be not applied

2016-12-12 Thread Hamed Babaei
Dear Daniel, I just resolved the problem. Because constraints.close function resolves chains of constraints, It interfered with set_inhomogeinity process. So I had to issue constraints.close before applying inhomogeinities. Thank you very much for your helpful hints. I appreciate it. Hamed

[deal.II] a query from step44

2016-12-12 Thread Anup Basak
Hello all, I am going to solve a generalized plane stain problem based on step 44. I have three displacement components (3 dofs per node) on a 2D geometry (dim =2) and mesh (compressible material hence no pressure). All displacements are function of x and y coordinates only, i, e u = u(x,y),

[deal.II] Re: Periodic boundary conditions seem to be not applied

2016-12-12 Thread Hamed Babaei
Dear Daniel, > It seems that you are now constraining all the components, i.e. > u_x(0,y)=u_x(L,y) and u_y(0,y)=u_y(L,y). > Is this really what you want to do? Otherwise, you should have a > ComponentMask in your call to > DoFTools::make_periodicity_constraints as well, i.e. > > You are righ

Re: [deal.II] manipulate a solution variable that is an easy function of other solution variables

2016-12-12 Thread Lailai Zhu
HI, Wofgang, thanks very much for your reply. It indeed helps. Now I can get the gradient of the velocity of the previous solution, basically \nabla u, which is a nonsymmetric second-order tensor, with 4 entries in a 2D case. std::vector > grads_velocity (n_q_points); for (; cell!=endc; ++cell