# Generating model bathymetry from alternative datasets **URL:** \ **Category:** COSIMA\ **Tags:** technical\ **Created:** [12 January 2026 05:16 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773 "2026-01-12T05:16:03Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![edoddridge](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/edoddridge/32/108_2.png) [@edoddridge](https://forum.access-hive.org.au/u/edoddridge)\ **Post date:** [12 January 2026 05:16 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773/1 "2026-01-12T05:16:03Z")
Hi everyone, **Summary** : I’m trying to apply the bathymetry pipeline to new datasets and not succeeding. If that interests you, or you think you might be able to help, please read on! > **Gory details** > > I’m trying to build on the topography workflow described [here](https://github.com/ACCESS-NRI/make_OM3_025deg_topo) to create an ensemble of PanAntarctic runs using different bathymetries. > > I’ve modified the `gen_topo.sh` script to take a command line argument for the bathymetry dataset, and verified that it works for me when I use GEBCO as the input. Unfortunately, I can’t make it work with other datasets yet. > > From the script `gen_topo.f90` in `bathymetry-tools`, I can see that the data variable needs to be called ‘height’ or ‘elevation’, so I’ve modified the bathymetry files accordingly. > > When I call `gen_topo.sh`, it falls over with an error from `gen_topo.f90`. This is my `gen_topo.sh.e*` file > > ```auto > Loading conda/analysis3-25.11 > Loading requirement: singularity > + set -e > + cp -L --preserve=timestamps /g/data/vk83/prerelease/configurations/inputs/access-om3/mom/grids/mosaic/global.025deg/2025.01.30/ocean_hgrid.nc ./ocean_hgrid.nc > + cp -L --preserve=timestamps /g/data/vk83/prerelease/configurations/inputs/access-om3/mom/grids/vertical/global.025deg/2025.01.30/ocean_vgrid.nc ./ocean_vgrid.nc > + ln -sf /g/data/jk72/ed7737/datasets/bathymetry/ML_topos/DTU_DKL_6_Ker50_pre_processed.nc ./BATHY.nc > + ./bathymetry-tools/bin/float_vgrid --vgrid ocean_vgrid.nc --vgrid_type mom6 > + ./bathymetry-tools/bin/topogtools gen_topo -i BATHY.nc -o topog_new.nc --hgrid ocean_hgrid.nc --tripolar --longitude-offset -100 > FATAL ERROR: NetCDF: Index exceeds dimension bound > > ``` > > The error comes from line 364 of [`gen_topo.f90`](https://github.com/COSIMA/bathymetry-tools/blob/a29d07a28ce1413bcdfcdbb96356fd7a04506995/src/gen_topo.f90#L364), where it is trying to get data from the supplied bathymetry file. > > The output file is > > ```-- > -- FindNetCDF defines targets: > -- - NetCDF_VERSION [4.7.3] > -- - NetCDF_PARALLEL [FALSE] > -- - NetCDF_C_CONFIG_EXECUTABLE [/apps/netcdf/4.7.3/bin/nc-config] > -- - NetCDF::NetCDF_C [SHARED] [Root: /apps/netcdf/4.7.3] Lib: /apps/netcdf/4.7.3/lib/libnetcdf.so > -- - NetCDF_Fortran_CONFIG_EXECUTABLE [/apps/netcdf/4.7.3/bin/nf-config] > -- - NetCDF::NetCDF_Fortran [SHARED] [Root: /apps/netcdf/4.7.3/include] Lib: /apps/netcdf/4.7.3/lib/Intel/libnetcdff.so > -- Configuring done (0.2s) > -- Generating done (0.2s) > -- Build files have been written to: /home/552/ed7737/coding-and-projects/panant_bathy_ensemble/make_OM3_panant_topo/bathymetry-tools/build > [8%] Building Fortran object CMakeFiles/M_CLI2.dir/external/M_CLI2/src/M_CLI2.F90.o > [16%] Linking Fortran static library libM_CLI2.a > [16%] Built target M_CLI2 > [25%] Building Fortran object CMakeFiles/topography.dir/src/kdtree2.f90.o > [33%] Building Fortran object CMakeFiles/topography.dir/src/utils.f90.o > [41%] Building Fortran object CMakeFiles/topography.dir/src/gen_topo.f90.o > [50%] Building Fortran object CMakeFiles/topography.dir/src/vgrid.f90.o > [58%] Building Fortran object CMakeFiles/topography.dir/src/topography.f90.o > [66%] Linking Fortran static library libtopography.a > [66%] Built target topography > [75%] Building Fortran object CMakeFiles/topogtools.dir/src/topogtools.f90.o > [83%] Linking Fortran executable topogtools > [83%] Built target topogtools > [91%] Building Fortran object CMakeFiles/float_vgrid.dir/src/float_vgrid.f90.o > [100%] Linking Fortran executable float_vgrid > [100%] Built target float_vgrid > -- Install configuration: "Release" > -- Installing: /home/552/ed7737/coding-and-projects/panant_bathy_ensemble/make_OM3_panant_topo/bathymetry-tools/./bin/topogtools > -- Installing: /home/552/ed7737/coding-and-projects/panant_bathy_ensemble/make_OM3_panant_topo/bathymetry-tools/./bin/float_vgrid > Reading vgrid from file 'ocean_vgrid.nc' > Writing vgrid to file 'ocean_vgrid.nc' > Reading supergrid info > j_lat located at 903 latitude 65.0000000000000 > Mosaic grid starts at -80.9675013444044 topography jstart = > 1 lat = -79.9916666666667 > Mosaic grid starts at -80.9675013444044 topography jstart = > -58 lat = 0.000000000000000E+000 > Shifted topography longitude grid by -100.0000 (ishift = -6000 ) > jmosaic = 1 -80.9675013444044 -74.4608728325249 > -58 332 > imosaic = 1 -280.000000000000 -255.000000000000 > 1 1500 > ncid = 131072 hid = 3 itopo = > listart = 15601 jstart = -58 > icount = 1500 jcount = 391 > > ``` > > The bathymetry files I have tried span ~80S to ~80N, while GEBCO is pole-to-pole, so I wondered if the `Index exceeds dimension bound` error was due to the negative value for `jstart` (`topography jstart =-58`) being used in the `nf90_get_var` call. > > So, I tried expanding the bathymetry arrays by padding them with zeros. Unfortunately, this made `gen_topo.f90` error out earlier. > > my error file: > > ```auto > Loading conda/analysis3-25.11 > Loading requirement: singularity > + set -e > + cp -L --preserve=timestamps /g/data/vk83/prerelease/configurations/inputs/access-om3/mom/grids/mosaic/global.025deg/2025.01.30/ocean_hgrid.nc ./ocean_hgrid.nc > + cp -L --preserve=timestamps /g/data/vk83/prerelease/configurations/inputs/access-om3/mom/grids/vertical/global.025deg/2025.01.30/ocean_vgrid.nc ./ocean_vgrid.nc > + ln -sf /g/data/jk72/ed7737/datasets/bathymetry/ML_topos/DTU_DKL_6_Ker50_pre_processed.nc ./BATHY.nc > + ./bathymetry-tools/bin/float_vgrid --vgrid ocean_vgrid.nc --vgrid_type mom6 > + ./bathymetry-tools/bin/topogtools gen_topo -i BATHY.nc -o topog_new.nc --hgrid ocean_hgrid.nc --tripolar --longitude-offset -100 > FATAL ERROR: NetCDF: Start+count exceeds dimension bound > > ``` > > This time the error comes from line 221 of [`gen_topo.f90`](https://github.com/COSIMA/bathymetry-tools/blob/a29d07a28ce1413bcdfcdbb96356fd7a04506995/src/gen_topo.f90#L221), where it is trying to put the longitude variable in to the output file. > > And the output file, `gen_topo.sh.o*` > > ```auto > -- Found NetCDF: /apps/netcdf/4.7.3/include;/apps/netcdf/4.7.3/include/Intel (found version "4.7.3") found components: Fortran > -- FindNetCDF defines targets: > -- - NetCDF_VERSION [4.7.3] > -- - NetCDF_PARALLEL [FALSE] > -- - NetCDF_C_CONFIG_EXECUTABLE [/apps/netcdf/4.7.3/bin/nc-config] > -- - NetCDF::NetCDF_C [SHARED] [Root: /apps/netcdf/4.7.3] Lib: /apps/netcdf/4.7.3/lib/libnetcdf.so > -- - NetCDF_Fortran_CONFIG_EXECUTABLE [/apps/netcdf/4.7.3/bin/nf-config] > -- - NetCDF::NetCDF_Fortran [SHARED] [Root: /apps/netcdf/4.7.3/include] Lib: /apps/netcdf/4.7.3/lib/Intel/libnetcdff.so > -- Configuring done (0.2s) > -- Generating done (0.2s) > -- Build files have been written to: /home/552/ed7737/coding-and-projects/panant_bathy_ensemble/make_OM3_panant_topo/bathymetry-tools/build > [8%] Building Fortran object CMakeFiles/M_CLI2.dir/external/M_CLI2/src/M_CLI2.F90.o > [16%] Linking Fortran static library libM_CLI2.a > [16%] Built target M_CLI2 > [25%] Building Fortran object CMakeFiles/topography.dir/src/kdtree2.f90.o > [33%] Building Fortran object CMakeFiles/topography.dir/src/utils.f90.o > [41%] Building Fortran object CMakeFiles/topography.dir/src/gen_topo.f90.o > [50%] Building Fortran object CMakeFiles/topography.dir/src/vgrid.f90.o > [58%] Building Fortran object CMakeFiles/topography.dir/src/topography.f90.o > [66%] Linking Fortran static library libtopography.a > [66%] Built target topography > [75%] Building Fortran object CMakeFiles/topogtools.dir/src/topogtools.f90.o > [83%] Linking Fortran executable topogtools > [83%] Built target topogtools > [91%] Building Fortran object CMakeFiles/float_vgrid.dir/src/float_vgrid.f90.o > [100%] Linking Fortran executable float_vgrid > [100%] Built target float_vgrid > -- Install configuration: "Release" > -- Installing: /home/552/ed7737/coding-and-projects/panant_bathy_ensemble/make_OM3_panant_topo/bathymetry-tools/./bin/topogtools > -- Installing: /home/552/ed7737/coding-and-projects/panant_bathy_ensemble/make_OM3_panant_topo/bathymetry-tools/./bin/float_vgrid > Reading vgrid from file 'ocean_vgrid.nc' > Writing vgrid to file 'ocean_vgrid.nc' > Reading supergrid info > j_lat located at 903 latitude 65.0000000000000 > Mosaic grid starts at -80.9675013444044 topography jstart = > 543 lat = -80.9583333333324 > Mosaic grid starts at -80.9675013444044 topography jstart = > 542 lat = -80.9749999999991 > Shifted topography longitude grid by -100.0000 (ishift = -6000 ) > > ``` > > I’m not sure what to look at next. I have a vague worry that perhaps the ordering of dimensions is getting mucked up, but I don’t have anything to back that up at the moment. > > Help greatly appreciated! ---
**Author:** ![anton](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/anton/32/1836_2.png) [@anton](https://forum.access-hive.org.au/u/anton)\ **Post date:** [12 January 2026 21:45 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773/2 "2026-01-12T21:45:07Z")
> [@edoddridge](#): > > to the negative value for `jstart` (`topography jstart =-58`) being used in the `nf90_get_var` call. Yeah - this seems likely, it looks like there is hidden assumption that the topography source file is larger than the model grid: > > [@edoddridge](#): > > This time the error comes from line 221 of [`gen_topo.f90`](https://github.com/COSIMA/bathymetry-tools/blob/a29d07a28ce1413bcdfcdbb96356fd7a04506995/src/gen_topo.f90#L221), where it is trying to put the longitude variable in to the output file. This doesn’t make sense, this line shouldn’t by impacted by changing the topo file. It’s just writing the model grid coordinates to the new output file. > I think line 218 might have a bug - it should use `dids_topo` not `dids` , although how it ever works is a fluke/mystery! ---
**Author:** ![edoddridge](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/edoddridge/32/108_2.png) [@edoddridge](https://forum.access-hive.org.au/u/edoddridge)\ **Post date:** [12 January 2026 22:53 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773/3 "2026-01-12T22:53:05Z")
Nice catch! If I change `dids` to `dids_topo` in both L218 and L224 > the script makes it through that section. It then manages to execute the `imosaic` loop a couple of times and before throwing an error here > Last part of output file: ```auto ... Reading supergrid info j_lat located at 903 latitude 65.0000000000000 Mosaic grid starts at -80.9675013444044 topography jstart = 543 lat = -80.9583333333324 Mosaic grid starts at -80.9675013444044 topography jstart = 542 lat = -80.9749999999991 Shifted topography longitude grid by -100.0000 (ishift = -6000 ) jmosaic = 1 -80.9675013444044 -74.4608728325249 543 932 imosaic = 1 -280.000000000000 -255.000000000000 1 1500 ncid = 131072 hid = 1 itopo = listart = 15601 jstart = 543 icount = 1500 jcount = 390 100 imosaic = 101 -255.000000000000 -230.000000000000 1501 3000 ncid = 131072 hid = 1 itopo = listart = 17101 jstart = 543 icount = 1500 jcount = 390 100 imosaic = 201 -230.000000000000 -205.000000000000 3001 4500 ncid = 131072 hid = 1 itopo = listart = 18601 jstart = 543 icount = 1500 jcount = 390 100 imosaic = 301 -205.000000000000 -180.000000000000 4501 6000 ``` The error happening with longitude of -180 makes me think it is possibly a dateline issue (but I don’t understand the purpose of the longitude shift, so might well be missing something). ---
**Author:** ![anton](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/anton/32/1836_2.png) [@anton](https://forum.access-hive.org.au/u/anton)\ **Post date:** [12 January 2026 23:27 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773/4 "2026-01-12T23:27:29Z")
There seems to be a column missing in the source data? ![image](https://us1.discourse-cdn.com/flex020/uploads/access1/original/2X/d/da69fcee1fb10cef5bc501425b08caecbb259601.png) Where is 179.991667°E ? ---
**Author:** ![edoddridge](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/edoddridge/32/108_2.png) [@edoddridge](https://forum.access-hive.org.au/u/edoddridge)\ **Post date:** [13 January 2026 00:37 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773/5 "2026-01-13T00:37:48Z")
That was the problem. With an extra column and the `dids_topo` bug fix, the script is running all the way through without errors. I’ll submit a PR for the bathymetry-tools repo. Thanks @anton! ---
**Author:** ![anton](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/anton/32/1836_2.png) [@anton](https://forum.access-hive.org.au/u/anton)\ **Post date:** [13 January 2026 00:44 UTC](https://forum.access-hive.org.au/t/generating-model-bathymetry-from-alternative-datasets/5773/6 "2026-01-13T00:44:22Z")
No worries - a couple of thoughts: It’s worth checking that: - the data at -180 looks ok the final output? I am not sure if that code knows to wrap from 180 to -180. - that netcdf \_FillValue value (xarray tends to show these as NaN) is used for land in the output (as its just 0 in the source data)