MOM6 Regional - Increasing vertical resolution

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…

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!

1 Like

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.

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.

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.

1 Like
  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!
1 Like

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/ variable:u

My thinking is that this is due to 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?

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.