The other option is that you are not calling the `error_from_exact` function that takes a mapping argument, but the one without it, and your boundary cells are introducing some error due to a worse mapping…. Are you calling `error_from_exact` with mapping as a first argument?
Luca > Il giorno 8 ago 2021, alle ore 6:49 PM, Luca Heltai <luca.hel...@gmail.com> > ha scritto: > > > Ciao Marco, > >> I was expanding step-12 using a manufactured solution to check the order p >> in H^1 (and p+1 in L^2) norm on a uniformly refined mesh for the DG upwind >> method. I've used the ParsedConvergenceTable with a parameter file as >> described in the docs. As Rate_key I'm using the DoFs, while as Rate_mode I >> have reduction_rate_log2. >> >> With p=1 and p=2 everything is fine. But if I set the finite element degree >> to 3, then the H^1 convergence rate decreases, as you can see in the >> attached image. >> <Screenshot 2021-08-07 at 17.56.06.png> > > Is it possible that you are using different quadrature rules in the two > cases? Your image shows a deterioration of the error on the order of 1e-8 for > H1, and 1e-12 for L2, which is very close to machine precision. > > Internally the parsed convergence table does the exact same thing you wrote > explicitly. (If you check the source code, you’ll see that it calls > integrate_difference and compute_global_error for each error type you specify > in the parameter file). > >> This, however, doesn't happen if I use a classical ConvergenceTable. Namely, >> I first compute the local error in each cell, and then the global error in >> the classical way: >> VectorTools::integrate_difference(mapping,dof_handler,solution, >> Solution<dim>(),H1_error_per_cell, >> QGauss<dim>(fe->tensor_degree()+1),VectorTools::H1_norm); >> >> const double H1_error = VectorTools::compute_global_error(triangulation, >> H1_error_per_cell, VectorTools::H1_norm); //assuming I provided also the >> gradient method for the Solution<dim> class >> >> >> >> Does anyone have any idea why this is happening? My guess was that while >> computing the H^1 semi-norm the ParsedConvergenceTable class does some >> approximation to compute the gradient from the exact solution expression and >> hence that could be the source of the issue. Conversely, in the >> "ConvergenceTable" way I do define explicitly the gradient of the exact >> solution in the Solution<dim> class. > > If the Solution<dim> class implements the Gradient, then > ParsedConvergenceTable should use that. > > You are calling “error_from_exact” of that class, right? > > This is where it is called: > > https://www.dealii.org/current/doxygen/deal.II/parsed__convergence__table_8h_source.html > > Line 621. As you see, the quadrature rule used is a Gauss formula of order > (dh.get_fe().degree+1)*2. > > Can you check if you get the same results with this order? > > L. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/1D73F9DA-128C-4CB4-B154-D915344238A0%40gmail.com.
