Should there be a "merging" of base and source grid data before `calc_diff_grid`?

[alessandrofelder]

This ppt by Pauline Weatherall suggests so but I don't understand how that would work in detail.

• It does promise to smooth the boundary between the grids in some implicit way (first bullet point of slide 4, this might address Remove-restore at high resolutions produces a discontinuity in the data #32 ).
• I don't understand why the difference grid extent goes beyond the update grid extent (slide 9 on the right)?

@Devaraj-G @JamieJQuinn what do you think? I am tempted to email Pauline and ask for help at this point.

[alessandrofelder]

My best interpretation of page 148 of the GEBCO cookbook makes me think that the source grid data should be combined with the base grid data into one set of x,y,z points and then undergo

• blockmedian (at base grid resolution, I guess)
• surface
• (optionally) grdfilter or grdblend (cosine tapering)
• grdsample

In other words, are we missing steps B and C of that workflow in our implementation?

[JamieJQuinn]

The GEBCO data has already been through steps A-C so the base grid we actually put into our remove-restore alg is the output from some previous step C, but then we do resample the grid to even finer resolutions than 500m, so I'm intrigued by that optional grdfilter step and why they choose the specific "cosine arch" with parameter 6000m. Keep in mind, they're just using remove-restore to create the GEBCO data from their data sources, I don't think every part of their implementation necessarily applies to cascadia.

[alessandrofelder]

Agreed... unless the idea of the algorithm is that the update grid data must be included in those steps before doing the update. I'm not entirely certain that this is the idea, I admit, but

• the slide show definitely suggests so to me
• it would help with discontinuities

Does that make sense?

[alessandrofelder]

To decide the best way forward, we'll test various approaches, including at least

• a preprocessing step along the lines of workflow steps B+C in the Gebco cookbook
• running surface on the difference grid
  It might not matter much, as long as the bathymetry is smooth, but let's see.

[alessandrofelder]

When implementing workflow steps B+C we should try keeping the ratios the same as in the GEBCO cookbook... i.e. the grid is B should have resolution 4*spacing and the cosine tapering step width 12*spacing.

[alessandrofelder]

I am testing this with
remove-restore --base gebco_2020_n54.0_s43.0_w-130.0_e-117.0.nc --output=vancouver-island-no-smoothing.nc --plot --spacing 0.00028 NOAA_South_VancouverIsland_30m.tif --region_of_interest -123.4 -123 47.8 48.0