FunctionParser uses a finite difference approximation for the gradient. I
think this is explained in the class documentation.
This explains the results you see...
On Sun, Aug 8, 2021, 15:15 Marco Feder wrote:
> Ciao Luca!
>
> > Can you check if you get the same results with this order?
> Yes,
Ciao Luca!
> Can you check if you get the same results with this order?
Yes, the rates are the same.
> Are you calling `error_from_exact` with mapping as a first argument?
Yes
Actually, I've fixed the issue after reading this:
> If the Solution class implements the Gradient, then
Hi Michael,
I’m glad that you’re on the right track now.
> If you could give some advice or refer to some references on this topic, I
> would appreciate that very mush.
Unfortunately, this is where pretty much I hit the limit of what I can say on
this topic as it would conflict with the
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
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,
