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?
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.
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…
If the model blows up due to CFL, it’ll tell you. Halve the time-step and run again!
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?
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.
