navidcy
23 February 2023 19:50
1
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).
1 Like
adele157
23 February 2023 22:36
2
1 Like
I have been using these tools successfully to create th 1/20th panan bathymetry and have a script that calls all functions in the correct order if that would be of any help?
navidcy
25 February 2023 20:36
4
Thanks both!
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
26 February 2023 23:03
5
navidcy:
We are aspiring to
Leaving us hanging @navidcy …
I agree a more general overview about the process, and why each step is necessary, would be helpful.
navidcy
26 February 2023 23:19
6
Deleted it… it was a typo.
I guess I/we are aspiring for a documented reproducible process. Something that does not require bathymetry-magicians (which is how I currently view the process…)
micael
26 February 2023 23:57
7
@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.
1 Like
aekiss
27 February 2023 00:01
8
The ACCESS-OM2 1deg and 0.25deg topography were created with these scripts
but some of this processing is only needed for a B grid and unnecessary for a C grid- see 1/20° topography · Issue #12 · COSIMA/mom6-panan · GitHub
There is a lot of ACCESS-OM2 (B-grid) topography-related discussion here
opened 01:23AM - 24 Aug 22 UTC
This issue was first discussed [here](https://github.com/COSIMA/access-om2/issue… s/158). More details in this [comment](https://github.com/COSIMA/access-om2/issues/158#issuecomment-971064268) and comments following.
The proposed solution is:
> We decided that the way forward is to change the land mask for the Antarctic coast (and nowhere else) to match GEBCO 2014, which will convert some ocean regions to land, but also convert some land to ocean, which will change the number of active tiles and may require tweaks to remove non-advective cells.
opened 07:51AM - 16 Jun 20 UTC
closed 04:19AM - 22 Oct 20 UTC
We went to a lot of effort to eliminate problematic non-advective points in the … 0.1deg `topog.nc` (https://github.com/COSIMA/access-om2/issues/99) but we still need to do the same for the other resolutions.
From https://arccss.slack.com/archives/C6PP0GU9Y/p1592289744341700?thread_ts=1592285883.339600&cid=C6PP0GU9Y
@russfiedler finds 21 non-advective columns in the grid at `/g/data/ik11/inputs/access-om2/input_20200530/mom_025deg/topog.nc`:
```
[raf599@gadi-login-02 topog]$ ./check_nonadvective_mosaic topog.nc
depth dimensions 1440 1080
Zeta dimensions 101 50
816 651 0.0000000E+00 ! nonadvective
819 1080 Surface North south nonadvective
889 49 nonadvective, Deep 25 24
1018 192 nonadvective, Deep 49 48
1328 455 nonadvective, Deep 46 45
1328 456 nonadvective, Deep 46 45
1329 467 nonadvective, Deep 46 45
196 494 nonadvective, Deep 26 25
197 494 nonadvective, Deep 26 25
176 554 nonadvective, Deep 9 0
816 651 nonadvective, Deep 9 0
246 742 nonadvective, Deep 11 0
932 801 nonadvective, Deep 30 29
1003 854 nonadvective, Deep 22 21
1094 864 nonadvective, Deep 38 37
1090 886 nonadvective, Deep 35 34
1099 906 nonadvective, Deep 35 34
169 1080 East west nonadvective, Deep 11 12
11
387 1080 East west nonadvective, Deep 40 41
40
862 1080 East west nonadvective, Deep 21 22
21
1153 1080 East west nonadvective, Deep 43 44
43
```
Results and check program at `/scratch/v45/raf599/bathymetry`
It could also be worthwhile looking for choked estuaries with this tool https://github.com/aekiss/notebooks/blob/master/non-advective.ipynb
Other issues with this topography: https://github.com/mom-ocean/MOM5/issues/172, https://github.com/COSIMA/access-om2/issues/141, https://github.com/COSIMA/access-om2/issues/158
opened 04:00AM - 15 Aug 19 UTC
At some point should we consider creating new topography for 1 and 0.25deg which… is more consistent with the 0.1 deg topo?
The minimum depth is probably too large at 1deg and 025deg, now that we have finer surface resolution with KDS50:
45.11m (10 levels) in ACCESS-OM2,
40.36m (9 levels) in ACCESS-OM2-025, and
10.43m (7 levels) in ACCESS-OM2-01
The land masks are inconsistent, particularly near the tripoles:
There are also gaps in the depth distribution at 1 and 0.25 deg: https://github.com/COSIMA/access-om2/issues/141
and other problems at 1deg: https://github.com/mom-ocean/MOM5/issues/172
and non-advective points at 0.25 deg: https://github.com/COSIMA/access-om2/issues/210
opened 05:24AM - 08 Apr 19 UTC
closed 04:19AM - 22 Oct 20 UTC
See below for a scatter plot of partial cell thickness versus full cell thicknes… s in the three configurations used in the paper. The upper and lower lines have slopes of 1 and 0.2, respectively.
The scatter shows how model bottom cell thickness ranges between the full cell thickness and 20% of that (with a 10m minimum at 0.1deg discussed [here](https://github.com/OceansAus/access-om2/issues/99#issuecomment-414922491)).
I'm posting this issue to note the gaps in the 1deg and 0.25deg distributions.
The 1deg and 0.25deg topog.nc files use the KDS50 vertical grid but were based on files generated for the GFDL50 grid, which already had a (presumably 20%) minimum partial cell thickness. When adapted to KDS50 the GFDL50 minimum cell thickness produces gaps in the thickness distribution, i.e. the small terraces produced by the GFDL minimum partial cell thickness are inherited by the topography on the KDS50 vertical grid. At least, that's what I think is going on.
If we wanted to fix this we'd need to go back to a more raw topography file, before the minimum-thickness threshold was applied.
(plot script is [here](https://github.com/OceansAus/ACCESS-OM2-1-025-010deg-report/blob/master/figures/bathymetry/bathymetry.ipynb))
opened 12:42AM - 10 Dec 18 UTC
closed 02:42AM - 19 Jun 19 UTC
We currently have a relatively small number of very small cells (<1km), which li… mits the timestep, primarily in CICE, necessitating shortening the ice dynamic timestep by the factor ndtd=3 relative to MOM, which in turn messes up the CICE-MOM load balance. It could therefore give a significant speed boost and cost reduction if we convert these into land points.
The small dimension is dy, close to the tripoles at 65N,100W and 65N,80E. It looks like the ocean cells were filled in at 0.25 deg so that the global minimum dy equals the minimum dx (6km). This hasn't been done at 0.1 deg, giving very small (down to 880m) y-sizes near the tripole. The minimum x-size is 2500m so we get large aspect ratios (dx/dy up to 5.1).
A cumulative histogram shows a steep dropoff at very small sizes, with <1% of cells smaller than 2000m and <0.2% smaller than about 1200m
The small cells are in the Canadian Archipelago (along the southern coasts of the passages south of Victoria Island and King William Island and the passage and estuary east of Southampton Island in northern Hudson Bay), and in the Ob River in Siberia:
In grid coords (heavily distorted as we are close to tripoles) these regions look like this (click to enlarge):
If we were to take the same approach as at 0.25deg and set a minimum y-size of 2500m this would join Victoria, Prince of Wales and Baffin islands onto North America and eliminate the Ob estuary, which seems quite drastic but is what is done at 0.25deg:
"bad departure points" errors in CICE with ndtd=2 and RYF occurred mostly with dyt<1100m. So a less-drastic alternative would be to limit the y-size to (say) >1150m to keep Victoria, Prince of Wales and Baffin as islands, retaining passages for ice flow (but probably still joining Southampton Island onto North America). However using ndtd=2 with this topography could still risk "bad departure points" errors due to increased variability with IAF, and maybe retaining constricting versions of these passages could lead to ice congestion there.
Any thoughts/suggestions?
opened 11:10PM - 11 Jun 18 UTC
closed 03:26AM - 19 Jun 19 UTC
I'm getting crashes like this from time to time:
```
FATAL from PE 3457: Err… or: temperature out of range with value 3.081776472849E+02 at (i,j,k) = (2153,2093, 2), (lon,lat,dpt) = ( -64.7500, 64.3310, 1.7294 m)
```
always at the same i,j=2153,2093 but with k=2 or 3. This is at the coast on the southern side of the mouth of Cumberland Sound on the east coast of Baffin Island, Canada. This is marked by the red circle in the figures below. It looks like `/g/data3/hh5/tmp/cosima/bathymetry/topog_latest.nc` has a large shallow estuary with a 1-cell mouth on Hall Peninsula, whereas in `/g/data3/hh5/tmp/cosima/bathymetry/gebco.nc` this is a series of islands and fjords.
I think we could just close off the "estuary". @russfiedler what do you think? Would you have a chance to look at this sometime soon?
1 Like
navidcy
27 February 2023 01:52
9
How come nobody has written a paper on this yet? Wouldn’t that be a great opportunity to gather the knowledge so that it can be reproduced in the future?
navidcy
27 February 2023 01:53
10
Thanks @aekiss !! I’ll look into those issues!
aekiss
27 February 2023 04:58
11
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.
aekiss
21 March 2023 05:15
12
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
aekiss
8 June 2023 00:47
13
1 Like