[deal.II] Re: hp convergence for non-linear solver.

Thank for the reply! I just fixed my code according to your suggestion. Now, I am evaluating my error with following code lines. template void msurface::evaluate_error() { Vector difference_per_cell (triangulation.n_active_cells()); *const MappingQ mapping (degree);*

[deal.II] Re: hp convergence for non-linear solver.

Thanks for replying! Could you explain more? I considered mapping degree only when I assemble system... for example. template void msurface::assemble_system () { const MappingQ mapping (degree); const QGauss quadrature_formula(degree+2); FEValues fe_values (mapping, fe, quadratu

Re: [deal.II] Re: using .vtk file as initial condition

Dear Jean-Paul and Timo, Thank you very much for your reply. I would like to use 'save ()' and 'load() ' functions as both of you suggested, but it is not fully clear to me how should they be used in the dealii code (I am using a code similar to step-44 large deformation problem). Suppose I need

[deal.II] Re: hp convergence for non-linear solver.

Jaekwang, [...] > > VectorTools::integrate_difference > (dof_handler,solution,Solution(), > >difference_per_cell > *,QGauss(degree+**2**)*,VectorTools::L2_norm); > somegthing that immediately comes to mind is that you don't use a non-default Mapping i

[deal.II] Re: hp convergence for non-linear solver.

Jaekwang, On Tuesday, November 1, 2016 at 5:43:36 PM UTC-4, Jaekwang Kim wrote: > > I think that I didn't make any mistake on my code lines because at least > my numerical solution is converging for the case p=1. > > but I couldn't get such convergence for the case p=2, and 3. I have tried > to

[deal.II] Re: hp convergence for non-linear solver.

Thanks for replying! Here I attached solution for p=2, and it seems that it has right share. When you said 'right quadrature' dose that meanquadrature for

[deal.II] hp convergence for non-linear solver.

Hi, all. I have asked whether numerical errors also behave ~O(h^p) , even though governing equation is non-linear and thus, a solver includes iterative method. I recall that Dr. Bangerth replied me it is "yes" if we imply small enough tolerance on iteration tolerance. I am trying to confirm

Re: [deal.II] Re: Convergence problem arising for large number of DoFs

Dear Bruno, I mean non of the standard preconditioners helped to make it converged. On Monday, October 31, 2016 at 3:13:35 PM UTC-5, Bruno Turcksin wrote: > > Hamed, > > 2016-10-31 15:56 GMT-04:00 Hamed Babaei >: > > > I have already checked SSOR and AMG non of them make a difference . ILU > >

[deal.II] Re: Extra layer around mesh

Joel, I don't get any errors running a recent developer version. Try to replace the deprecated version of DoFTools::make_periodicity_constraints! Exemplarily, this would be std::vector::cell_iterator > > periodic_faces; GridTools::collect_periodic_faces(dof_handler,0,1,0,periodic_faces,off

[deal.II] Re: Extra layer around mesh

Dear Daniel, Here is the small example you asked for. If you run it as it is, it will work. If you can 1 to 2 in line 107, it crashes. Im run dealii-8.2.1, if that is needed. Best, Joel On Tuesday, November 1, 2016 at 11:44:48 AM UTC+1, Daniel Arndt wrote: > > Joel, > > I have code that runs f

Re: [deal.II] Re: Help with time stepping methods

Vaibhav, 2016-11-01 4:24 GMT-04:00 Vaibhav Palkar : > To quickly restate, I'm solving a reaction-diffusion problem using a > framework much like Step-52. My equations are stiff and hence I'm using > implicit methods for solving the resulting ODEs. Unfortunately, it seems > that even implicit metho

Re: [deal.II] computing some other output quantity after solution is calculated.

Thank you very much for your reply It seems that I can solve the problems I have now. Thank you. Kyusik. -- 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 ar

[deal.II] Re: Extra layer around mesh

Joel, I have code that runs fine with periodic boundary condition for > a GridGenerator::parallelepiped. Also when I change the mesh to > a GridGenerator::subdivided_parallelepiped and has only 1 as > n_subdivisions, it also works. But when I change it to 2, I get the > following error: > [...

Re: [deal.II] Re: Trouble with VisIt 2.11

On Thu, Oct 27, 2016 at 12:53 PM, 'Uwe Köcher' via deal.II User Group < dealii@googlegroups.com> wrote: > Dear Praveen, > > I do not use visit, but deal.II + hdf5 + paraview. Your attached file can > be opened with paraview. > But this does not mean, that we have a correct implementation within >

Re: [deal.II] computing some other output quantity after solution is calculated.

Kyusik, [...] > 3. I calculated l2 norm > Difference = solution; > Difference -= exact_solution; > norm = Difference.l2norm(); > > But, according to what you mentioned, I calculated l2norm of U_i-U_i_exact > not l2norm of u_h(x)-u_h_exact(x) > Yes, this gives you the l2-norm of U_i-U_i_exact

Re: [deal.II] Re: Help with time stepping methods

Hello All, Reviving an old thread as I wasn't able able to resolve my problem. To quickly restate, I'm solving a reaction-diffusion problem using a framework much like Step-52. My equations are stiff and hence I'm using implicit methods for solving the resulting ODEs. Unfortunately, it seems

[deal.II] Re: Extra layer around mesh

Dear all, I have code that runs fine with periodic boundary condition for a GridGenerator::parallelepiped. Also when I change the mesh to a GridGenerator::subdivided_parallelepiped and has only 1 as n_subdivisions, it also works. But when I change it to 2, I get the following error: *An error