I know that bathymetry has been a pain in the neck and that people have evolved artistic talent in modifying bathymetry and opening/closing channels etc.
Can we collect here the accumulated knowledge so that, e.g., CliMA’s efforts (cc @glwagner) don’t need to reinvent the wheel? Is these papers documented anywhere?
What we would like to be able to do is to take the ETOPO super-high resolution bathymetry and be able to coarsen it to the resolution we want to run (e.g., 2, 1, 1/2, 1/4, 1/10, 1/12, 1/25, … whatever).
I am more interested on the procedure rather than scripts since I don’t know FORTRAN myself. @micael is there documentation that goes along with these code? E.g. not so much how to run them (as I see in the readme) but more on what the scripts do.
I’d like to demystify what the scripts are doing? What are the necessary and crucial steps in creating bathymetry file for a particular resolution? I know (from just overhearing lots of discussions) that just getting the ETOPO high-res bathymetry and coarsening it to the resolution we want simply won’t do the job. What else needs to be done?
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
@navidcy I’ve got on my TODO list to add some more detailed instructions and explanations about the part of the process I’m familiar with. Ideally other people in the community can cover the rest at some point.
The processes we use are fully reproducible but not completely automated, because we still need hand-edits (especially at low resolution) for points where the mean of the underlying high-resolution dataset (eg. GEBCO) would misrepresent an important feature, e.g. the depths of sills and channels that control important water mass exchanges. This is basically a sub-gridscale parameterisation and can take multiple test runs to get right. On a B grid there are also non-advective points that can’t be fixed with our automatic tools and require somebody to eyeball it and make a judgement call.
When you get to very high resolution you start to be limited by the resolution of the underlying obs data, which is quite low-resolution away from multibeam tracks. There are methods around to fill in the fine details with something statistically reasonable, e.g. https://doi.org/10.1029%2F2021ea002069