Page **1** of **1**

### Grid2DInterpolator updated

Posted: **13 Nov 2013, 01:57**

by **rgladstone**

When attempting to interpolate values exactly at the end of the domain (x = x0 + lx) interpolation will be attempted using values at both the beginning and end of the domain (including x = x0). This gives large errors at the end of the domain. I'll see if I can fix this soon.

Rupert

### Re: Grid2DInterpolator updated

Posted: **13 Nov 2013, 03:01**

by **rgladstone**

I fixed the issue with interpolating data points at the end of the domain.

I also tidied up the noData implementation a little. Would you like to have the noData value and a tolerance available as optional keywords in the sif solver syntax? Let me know if so and I'll add that.

I've tested with my simple interpolation data and it seems to work fine. Let me know if there are any problems.

Cheers,

Rupert

### Re: Grid2DInterpolator updated

Posted: **15 Nov 2013, 12:43**

by **gagliar**

Hi Ruppet,

Would you like to have the noData value and a tolerance available as optional keywords in the sif solver syntax? Let me know if so and I'll add that.

Yes, that would be nice.

regards

Olivier

### Re: Grid2DInterpolator updated

Posted: **21 Nov 2013, 04:40**

by **rgladstone**

I have added the option of specifying "no data" and "no data tol". Modified wiki text here:

http://elmerice.elmerfem.org/wiki/doku. ... terpolator
Rupppert

### Re: Grid2DInterpolator updated

Posted: **28 Nov 2013, 03:54**

by **rgladstone**

Is this a bug? If someone can confirm I can fix this in the repository.

I found these two lines in the InterpolateDEM function:

ix = INT((x-xb0)/dbx)+1

iy = INT((y-yb0)/dbx)+1

Surely the second line should be divide by dby not dbx? This would be a problem for grids with non-square cells with variation in the y-direction.

Rupert

### Re: Grid2DInterpolator updated

Posted: **28 Nov 2013, 05:11**

by **rgladstone**

The default in the 2d grid interpolator in the event of one to three neighbouring points having the noData value is to take the mean of valid points. I have written a few lines to instead carry out linear interpolation. Shall I set this as the default (which makes more sense to me) or as an option (for full backwards compatibility)?

### Re: Grid2DInterpolator updated

Posted: **04 Dec 2013, 10:20**

by **gagliar**

Hi Rupert,

I'm replying to your two last posts.

I found these two lines in the InterpolateDEM function:

ix = INT((x-xb0)/dbx)+1

iy = INT((y-yb0)/dbx)+1

Surely the second line should be divide by dby not dbx? This would be a problem for grids with non-square cells with variation in the y-direction.

Yes, this is indeed a bug. Thanks for seeing it!

The default in the 2d grid interpolator in the event of one to three neighbouring points having the noData value is to take the mean of valid points. I have written a few lines to instead carry out linear interpolation. Shall I set this as the default (which makes more sense to me) or as an option (for full backwards compatibility)?

I'm not sure a linear interpolation is possible in all cases:

- with only one node, it can only be estimated as the value at that node

- with two nodes, it should work, but one as to determine the direction of the interpolation (x or y)

- with three nodes, it would work only if the point at which you want the value is included in the triangle defined by the three nodes.

So, I would be interested to know more about the strategy you have developed to handle this interpolation.

An other solution should be to use extrapolation from the neighbouring cells.

Nevertheless, missing data should only concern a very limited number of points and at the margin of the domain. Else, you are in trouble...

Regards

Olivier

### Re: Grid2DInterpolator updated

Posted: **05 Dec 2013, 02:13**

by **rgladstone**

Thanks Olivier. I'll check in the bug fix.

For interpolation in presence of noData, I calculate weights for normal bilinear interpolation, set the weights to zero for noData points, then scale the remaining weights so that they total one. You are right, this isn't obvious/trivial and can lead to problems (e.g. if you want to get the value of a node at the exact location of a noData point). If I check in this change then I will make sure to leave the old approach as the default, make this new approach an option triggered by a sif keyword, and document it in the wiki.

Regards,

Rupert