Re: [Libmesh-users] Exact Error Estimator with Fine Grid Solution...

[Derek G. <fri...@gm...>]

That pretty much confirms my suspicions... we're having this same
"problem" right now with our own code... where we want to use the
comparison to a fine grid solution for an error indicator.  In our
case we _can_ do the fine grid per element error accumulation/map back
to the coarse grid (very sophisticated search and interpolate
functions for element fields), but it is fairly costly.  We are still
evaluating the right way to do this though.

For now, I think I'll implement it on the coarse grid with extra
quadrature.  Should be fine for my purposes.  I'll try to get this
done and checked in this week.

Derek

On 5/21/07, Roy Stogner <roy...@ic...> wrote:
> On Mon, 21 May 2007, Derek Gaston wrote:
>
> > One question... the ExactSolution object iterates over the fine grid
> > to calculate error right?
>
> Right.
>
> > How would that work for the ExactErrorEsimator?
>
> Hmm... for most people it would work pretty well (since every fine
> grid element is contained in a coarse grid element, and it's easy to
> find out which one), but for your distorted meshes that would be a
> problem.
>
> > You would have to accumulate the fine grid per element error... and
> > find what elements that matches up with on the coarse grid... it
> > would be tough.
>
> Finding what element a point is in is easy (the MeshFunction has to do
> that anyway), but what do you do when the fine grid element matches up
> with multiple elements on the coarse grid?
>
> > A quick fix would be to just iterate over the coarse grid... with a
> > very fine quadrature rule to help capture the fine grid solution
> > accurately.... but there are definite drawbacks to that as well.
>
> That may be the most reasonable way to do things.  Gaussian quadrature
> error from integrating non-smooth functions isn't good, but the error
> you'd get by trying to assign overlapping fine grid elements to one or
> another coarse element would be even worse.
> ---
> Roy
>