Is your feature request related to a problem? Please describe.
The current 'do_schmidt' option in make_hgrid (taken from FV3) rotates the south pole (center of tile 6 on the cubed sphere) to the target_lat and target_lon. This has the effect that tile 6 is 'upside down' in the new orientation, with south at the top. Since tile 6 is the the highest-resolution grid when doing grid stretching (stretch_fac > 1.0), is where nested grids are usually placed, and is the foundation for the regional domain, the native grids are all upside down. This is not only aesthetically unpleasing, but makes placement of nested grids extremely difficult since [ij]offset are given in terms of local grid coordinates, and so counterintuitively i points westward and j points southward. Plus this has led to significant confusion for users of the nest and the regional domain.
Describe the solution you'd like
A revision to do_schmidt, called do_cube_transform, has been implemented within FV3. This uses the routine fv_grid_utils_mod::cube_transform(). For idealized tests in either SHiELD or solo_core this works very well to create a tile 6 which is oriented as expected, with north at the top. I would like this option to be implemented within make_hgrid as well for generating the supergrid. With the supergrid and grid mosaic, the input datasets can be generated to run full-physics SHiELD or UFS. The new make_hgrid can then easily be inserted within preprocessing workflows.
The name is also much more indicative than do_schmidt---who is Schmidt and what does he have to do with grids? (Someone who appears to have written a single article in 1977 in a German journal.)
Describe alternatives you've considered
I had thought of having FV3 write out supergrid tiles itself, replicating the capabilities of make_hgrid within the dycore itself. I realized this may be quite a bit of work since I would have to define a supergrid within the solver, including defining a domain structure on the supergrid, and then create the I/O routines to write out to disk. This may be a powerful way of rapid testing of new grids though.
Is your feature request related to a problem? Please describe. The current 'do_schmidt' option in make_hgrid (taken from FV3) rotates the south pole (center of tile 6 on the cubed sphere) to the target_lat and target_lon. This has the effect that tile 6 is 'upside down' in the new orientation, with south at the top. Since tile 6 is the the highest-resolution grid when doing grid stretching (stretch_fac > 1.0), is where nested grids are usually placed, and is the foundation for the regional domain, the native grids are all upside down. This is not only aesthetically unpleasing, but makes placement of nested grids extremely difficult since [ij]offset are given in terms of local grid coordinates, and so counterintuitively i points westward and j points southward. Plus this has led to significant confusion for users of the nest and the regional domain.
Describe the solution you'd like A revision to do_schmidt, called do_cube_transform, has been implemented within FV3. This uses the routine fv_grid_utils_mod::cube_transform(). For idealized tests in either SHiELD or solo_core this works very well to create a tile 6 which is oriented as expected, with north at the top. I would like this option to be implemented within make_hgrid as well for generating the supergrid. With the supergrid and grid mosaic, the input datasets can be generated to run full-physics SHiELD or UFS. The new make_hgrid can then easily be inserted within preprocessing workflows.
The name is also much more indicative than do_schmidt---who is Schmidt and what does he have to do with grids? (Someone who appears to have written a single article in 1977 in a German journal.)
Describe alternatives you've considered I had thought of having FV3 write out supergrid tiles itself, replicating the capabilities of make_hgrid within the dycore itself. I realized this may be quite a bit of work since I would have to define a supergrid within the solver, including defining a domain structure on the supergrid, and then create the I/O routines to write out to disk. This may be a powerful way of rapid testing of new grids though.