Bug: ringsector breaks interpolation call

[Da-Be-Ru]

While trying to test the cellparents speedup for lazy_interpolate #54 on a ringsector mesh, I ran into the following odd behaviour I haven't examined in detail yet: when interpolating a function into an H1Pk element on a zero times uniformly refined ringsector, we get some out of bounds error in the evaluate! call.

This goes away when the ringsector is actually refined once (though it does kill any lazy_interpolate! call, cellparents use or no...).

HINT: ExtendableGrids needs to be checked out to #100 for this to run

[chmerdon]

At first glance this looks like that maybe the mesh is corrupted and has nodes that are not used in any cell. I'll try to figure it out.

[chmerdon]

Yes, the last six nodes are duplicates of the first six nodes. If you do
xgrid1[Coordinates] = xgrid1[Coordinates][:,1:54]
everything works

So this is a bug in the ringsector function of ExtendableGrids

[chmerdon]

Well at least the normal interpolations work then, but the lazy_interpolations hang up at some point.

This is weird, because I checked that the initcell chosen by the cellparents is a cell that contains the vertex coordinates, so the cell finder should stop after one iteration.

When I reduce the eps to 1e-6, it seems to work again. So, I think we need to investigate thoroughly what happens in the cellfinder.

[Da-Be-Ru]

Yes, the last six nodes are duplicates of the first six nodes. If you do xgrid1[Coordinates] = xgrid1[Coordinates][:,1:54] everything works

So this is a bug in the ringsector function of ExtendableGrids
[...]
When I reduce the eps to 1e-6, it seems to work again. So, I think we need to investigate thoroughly what happens in the cellfinder.

Both of these are now solved by the related PR in ExtendableGrids.jl as suggested by you.

Properly escalated, so closing this PR.