[Gfs-devel] gfs_interpolate_from_corners

[Daniel Fuster]

Hi Stephane

I was looking at the interpolation function and there is something I
do not quite understand. After getting the corner values, you
interpolate the values within the cell using the corner values AND the
value at the center of the cell. This gives an interpolation function
which looks a little bit weird in some points inside the cell.

I do not know if there is a reason why you included the cell center
value in the interpolation and not just using bilinear interpolation
from the corner values, which gives a more nice (and at least
intuitive from my point of view) interpolation function.

Thanks for the clarification
Daniel


--
www.danielfuster.com

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

[Stephane Popinet]

Hi Daniel,

> value at the center of the cell. This gives an interpolation function
> which looks a little bit weird in some points inside the cell.

In what way does it look "weird"?

> I do not know if there is a reason why you included the cell center
> value in the interpolation and not just using bilinear interpolation
> from the corner values, which gives a more nice (and at least
> intuitive from my point of view) interpolation function.

Yes, bilinear is what I was doing before. A problem with bilinear is
that the bilinearly-interpolated value at the center of the cell is
the average of the 4-corner values i.e. this is a "filtered" version
of the field (it will be much smoother than the original cell-centered
field). The idea with the current implementation is to replace
bilinear interpolation with linear interpolation in the 4 triangles
(in 2D) covering the square and sharing the cell-center. This should
be a linear, continuous (C0) representation of the field which
evaluates to the original values at cell centers.

Note that the same problem (i.e. smoothing due to bilinear
representation) can be seen visually in GfsView i.e. the fields
represented using "Linear" or "Isolines" look much smoother (i.e.
loose details) compared to the "Squares" representation. This is
because both "Linear" and "Isolines" still use bilinear interpolation
on squares rather than linear interpolation on triangles. Fixing this
would lead to a more accurate representation for both "Linear" and
"Isolines".

Note also that the way corner values are interpolated
(gfs_cell_corner_interpolator) is pretty old and somewhat messy. I
think it could be reimplemented much more cleanly and efficiently
using gfs_domain_locate() rather than the do_path() stuff. Also, it
uses "distance-weighted" interpolation which is probably not the best
way to do it.

Generally it would be nice to check that this interpolation business
does what it is meant to do i.e. write a test case which checks the
order of convergence etc... when discretising and interpolating a
known function on both constant-resolution and variable-resolution
meshes.

cheers

Stephane

[Gael Guedon]

Hi Stéphane,

Note also that the way corner values are interpolated
(gfs_cell_corner_interpolator) is pretty old and somewhat messy. I
think it could be reimplemented much more cleanly and efficiently
using gfs_domain_locate() rather than the do_path() stuff.

I agree with this! While developing the vertex divergence filter, it took me 3 days to get out alive of the do_path() labyrinth !!

However it allowed me to better understand better the octree indices ;-)

I think I will keep this piece of code as a souvenir !

Cheers,

Gael

[Daniel Fuster]

Hi Stephane

I was trying to compute the interpolation error in two different cases:

a) A variable initialized with T1 = 1. - x*x - y*y
b) A step function (x*x + y*y - 0.1*0.1 < 0. )

Because the interpolation function is continuous in all the domain, I
can compute the L1 norm very accurately of ||f_exact - f_interp|| in a
very refine grid

I attach the convergence obtained for both cases. It seems to all work fine.

The reason why i said "weird" is seen in the circle example. I attach
the following figures:
circlecell.eps with the cell centered values
circlecellandcorners.eps with the cell and interpolated values at the corners
interpolationfunc.jpg The continuous interpolation function in all the domain

This is not what the interpolation function I was expecting, but if it
is clear that it is the function that better reduces the interpolation
error among the ones I tested.

Thanks for the clarification
Daniel

2012/11/28 Stephane Popinet <s.po...@gmail.com>:

--
www.danielfuster.com