Hi all - I’ve been trying to get up to speed on what’s involved in generating a new hgrid for higher resolution eac configurations following the discussion in Chris’ ‘Changing resolution’ thread [here] (Changing resolution · Issue #6 · COSIMA/mom6-eac · GitHub)
Seems the first step is to generate a new ‘grid_file’ that has the curvilinear coordinates and cell thicknesses at the specified nominal resolution. Just wondering if there are any tools out there to generate this grid_file?
Also - is this something that belongs here or better suited to Github?
Great, thanks Angus! I initially thought that a ‘grid_file’ was required here, but that link has some well-documented examples of grid generation with other flags.
So far, I’ve generated grids using both the tripolar and spherical grid_type.
At first, the width of grid cells reduced (longitude lines converging) but the height (distance between latitudinal interfaces) remained constant resulting in elongated grid cells at higher latitudes. The code that produced this was: (NB: longitude coordinates and no. vertices (nlat, nlon) arbitrary for now).
I noticed that gridcells in the ACCESS-OM2 hgrid remain square at all latitudes (width and height both decrease with cos(lat)). Hence, I then tried setting the cell width (dlon) and cell height (dlat) to be ‘nominal’ at the equator and zero at the pole. The interpolation made the cell height and width decrease with latitude, however in more of a cubic fashion than scaling with cos(lat). The code that produced that was:
Hi, a couple of months ago I tried to regenerate the ACCESS-OM2 grids with make_hgrid and got exactly the same issues. Then I found out that there’s another tool in the FRE-NCTOOLS repository included as a git submodule that might be better suited:
Unfortunately I didn’t have the opportunity to try it out yet.
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
6
In the GitHub thread I suggested a family of “nested” grids:
I was thinking that if there was a plan to have a suite of resolutions, the easiest way to do it might be to generate the very finest resolution you’re likely to want within the next 5 years, then just make the coarser grids the same, but with different strides across the fine grid spacing.
You could go the other way and start with the current 1 degree grid and sub-divide it, maybe into sixty as it has so many factors (1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30 and 60).
It would make regridding pretty painless, e.g. in xarray you can
Thanks for the suggestions. @micael - I looked into the ocean_model_grid_generator and after some playing around, was able to generate global grids at a specified resolution, but not regional - seemed quite clunky. Then the problem was that generating a global grid at e.g., 1/40 nominal resolution overloaded my memory (12 CPUs).
After discussing options with @ChrisC28 (Chris Chapman), we’ve decided for consistency to adopt a similar approach @angus-g used for the Panan 1/20 run. However in our case, we use the already generated hgrid of ACCESS-OM2 and divide horizontal cells by factors of 3 to keep original T-points consistent between model grids of different resolution (reason for this is primarily in interpolating topography). @AndyHoggANU - is the global MOM6-01 hgrid taken from ACCESS-OM2-01? If so, we’ll have a more robust comparison between MOM6 global and MOM6 regional runs to assess the potential loss of skill in downscaling.
So, if we continue with this approach, we’ll have a 1/10, 1/30 (~2-5km) and 1/90 (~1km) regional resolutions for EAC region which should cover most use-cases?
Hi @john_reilly - yes, the MOM6 global-01 case does just use the z* formulation with the ACCESS-OM2-01 vertical grid. If you want to see all the gory details, the run directory is saved in this repo:
Also, the data is here if you want to see it: /g/data/ik11/outputs/mom6-global-01/global-01-v1
It’s run 20 years so far, and we have paused to wait for @schmidt-christina to do a bit of analysis.
This is probably a stupid question, but how were the ACCESS-OM2 grids generated? There’s a lot of discussion in this post about reusing/resampling these grids. Is that because they’re hard to recreate?
I think it’s just a matter of creating a meshgrid and then transforming it to spherical-type coordinates so dx,dy and area scale with cos(lat). But Ashley might be able to shed more light on it.
I think we originally wanted to keep the same hgrid to reduce the amount of interpolation at the boundaries or something like that. @ChrisC28 had a discussion with Russ which motivated that original choice.
The grids that John and I make with the regional modelling module are nice and simple for regional domains. Making a equally spaced cartesian or Mercator is easy with meshgrid tools, but I expect the trioplar global grids are a bit more involved!
Like John says, regional modellers have the choice of inheriting a global grid (as long as its well away from the tripole region) or just making up a new one and interpolating all of your input data onto it