# MOM6 Regional - Increasing vertical resolution

**URL:** <https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559>\
**Category:** Ocean\
**Created:** [15 March 2023 01:12 UTC](https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559 "2023-03-15T01:12:47Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![john\_reilly](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/john_reilly/32/237_2.png) [@john\_reilly](https://forum.access-hive.org.au/u/john_reilly)\
**Post date:** [15 March 2023 01:12 UTC](https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559/1 "2023-03-15T01:12:47Z")

</div>

Hi, I’ve got some general questions as well as technical questions about what happens when we substantially increase the vertical grid resolution in a regional model. For the EAC-003 (30th-degree Tasman/Coral Sea) configuration that @ChrisC28, @angus-g, @ashjbarnes and I have worked on, we’ve previously used the vertical grid from ACCESS-OM2-01 (KDS75 I believe). This had a max depth of ~6km, and aligns well with the boundary forcing segments as these segments are also from ACCESS-OM2-01.

I’ve now increased the vertical resolution using Kial’s script to 150 levels with a max-depth of 4500m. See the comparison of the two grids below…  
 ![image](https://us1.discourse-cdn.com/flex020/uploads/access1/original/1X/cd76468b429faa020ae760453d515097c41b3b5b.png)

Now I’m wondering what other considerations I might need to look into for everything to work nicely, e.g.:

- what happens at the boundaries? is the forcing regridded at runtime? Or do we need to regrid these forcing segments prior?
- Should we think about decreasing either timestep?
- Any other factors I should consider?

Thank you!

---

<div class="post-metadata">

**Author:** ![angus-g](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/angus-g/32/89_2.png) [@angus-g](https://forum.access-hive.org.au/u/angus-g)\
**Post date:** [15 March 2023 01:32 UTC](https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559/2 "2023-03-15T01:32:05Z")

</div>

> [@john\_reilly](#):
>
> - what happens at the boundaries? is the forcing regridded at runtime? Or do we need to regrid these forcing segments prior?

Yes, the forcing is regridded (vertically) at runtime. The horizontal grid has to match for “brushcutter”-style inputs, which we use anyway. Then the `dz` dimension for each variable defines the source column from which to remap onto the model grid. I _think_ it’s fine to also increase the column depth, but I don’t know off the top of my head exactly how that’s dealt with.

> [@john\_reilly](#):
>
> - Should we think about decreasing either timestep?

There’s no vertical CFL limit with ALE, but I guess there could be some impact on the surface forcing given how you’re changing the upper part of the water column. I would just run with whatever timestep you’ve figured out works for the given horizontal resolution, and if you’re seeing instabilities or too-high CFL, you could try decreasing it slightly.

> [@john\_reilly](#):
>
> Any other factors I should consider?

The diagnostic coordinates (i.e. `DIAG_COORD_DEF` stuff) doesn’t need to have the same _number_ of levels as the model. So you can output on a common grid, regardless of the vertical resolution. Of course, you might choose to do this offline out of the native-coordinate output as an alternative.

---

<div class="post-metadata">

**Author:** ![ChrisC28](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/chrisc28/32/299_2.png) [@ChrisC28](https://forum.access-hive.org.au/u/ChrisC28)\
**Post date:** [15 March 2023 01:41 UTC](https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559/3 "2023-03-15T01:41:00Z")

</div>

1. My understanding, which may very well be wrong, is that the model handles interpolation of the boundary forcing onto the vertical grid at run-time. MOM6 has to handle the case of a temporally variable vertical coordinate (as in ALE), which would lead me to believe that this can be done at run-time. However, the documentation is incomplete, so that’s not definitive…
2. If the model blows up due to CFL, it’ll tell you. Halve the time-step and run again!

---

<div class="post-metadata">

**Author:** ![john\_reilly](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/john_reilly/32/237_2.png) [@john\_reilly](https://forum.access-hive.org.au/u/john_reilly)\
**Post date:** [16 March 2023 05:14 UTC](https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559/4 "2023-03-16T05:14:59Z")

</div>

Thanks for clearing that up @angus-g - I’ve come across another problem related to this - getting the following error when running the 30th-degree eac with the KDS150 vcoord plotted above in this post:  
`NetCDF: Start+count exceeds dimension bound: netcdf_read_data_3d: file:INPUT/forcing/init_vel_cgrid.nc- variable:u`

My thinking is that this is due to `init_vel_cgrid.nc` having a different depth coordinate (KDS75 - H\_{max} \approx 6000m, whilst the model depth coordinate is now KDS150 - H\_{max} \approx 4500). So essentially the model depth-bounds is much less than the IC depth-bounds. Have you come across this before?

---

<div class="post-metadata">

**Author:** ![angus-g](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.access-hive.org.au/angus-g/32/89_2.png) [@angus-g](https://forum.access-hive.org.au/u/angus-g)\
**Post date:** [16 March 2023 05:58 UTC](https://forum.access-hive.org.au/t/mom6-regional-increasing-vertical-resolution/559/5 "2023-03-16T05:58:59Z")

</div>

You’re on the right track. It’s failing just because it doesn’t have the right number of points in the vertical. The Z-space initialisation only works for temperature and salinity, not velocity; if you provide initial velocities, they need to already be on the model grid.
