Harmonizing grids info across resolutions in /g/data/ik11/grids/

[rbeucher]

This is related to the discussion in #150 .

Issue is that the 0.10, 0.25 and 0.1 grids do not have the same information recorded which make it difficult to visualize outputs using the same notebook recipe. Plotting also relies on the grids being present in /g/data/ik11/grids...

We need to harmonize the grids and / or investigate the possibility to drop the dependence on those grids. Could plotting be done using the field's coordinate information? from what I understand the information is not retained in the outputs and we may not want to do so.

I see 2 options:

• Grids could be a released "product". ACCESS-NRI could support this, add a DOI etc...
• We could have a function that generates the structure on the fly...Might be tricky with the tripolar grid.

@navidcy @AndyHoggANU @aidanheerdegen

Also related:

COSIMA/cosima-cookbook#191

[rbeucher]

@rmholmes can you assign me to this? Or give me the rights to do so?

[aekiss]

These are consistent

/g/data/ik11/grids/ocean_grid_025.nc
/g/data/ik11/grids/ocean_grid_10.nc

but /g/data/ik11/grids/ocean_grid_01.nc is different. Among other things, it is missing metric fields (dxt, dyt, dxu, dyu, area_t and area_u) which are necessary for xgcm - see https://github.com/COSIMA/cosima-recipes/issues/190

Also most of the variables in ocean_grid_025.nc and ocean_grid_10.nc are floats and should probably be doubles.

[rbeucher]

OK. So the thing is the derived fields (dxt etc.) are masked so I was wondering if this is what we wanted...

[rbeucher]

For the type (Float vs Double), I suppose that means we need to regenerate them by running the model?

[aekiss]

Ah yes, dxt, dyt, dxu, dyu are masked in those files. I'm not sure if that will cause problems with xgcm, but in any case I think it would be best for all of these to be unmasked to match the other grid info (geo* and area_*).

[rbeucher]

Also, the 0.1 degree grid has zb and zt as extra dimensions. Do we want that across the 3 grids?

[aekiss]

I'm making the 1 deg data here: /home/156/aek156/payu/make_grids/1deg_jra55_iaf_grid

[aekiss]

see how you go with these instructions: https://github.com/COSIMA/access-om2/wiki/Technical-documentation#outputting-grid-files-with-no-processor-land-masking

[rbeucher]

Thanks @aekiss !

[aekiss]

interestingly, dxt, dyt, dxu, dyu are still masked - maybe that's unavoidable?

see /scratch/v45/aek156/access-om2/archive/1deg_jra55_iaf_grid/output000/ocean/ocean_grid_10.nc

[rbeucher]

??!

[aekiss]

see related issues: https://github.com/COSIMA/access-om2/issues/236 https://github.com/COSIMA/access-om2/issues/233

[aekiss]

There are different versions of the topography, and some of the old ones are still in use, so we should either provide different versions of the grid files, or omit these fields to avoid confusion

            ht:
            hu:
            kmt:
            kmu:

[aekiss]

There are also different versions of the land mask currently in use, so we should remove the mask from dxt, dyt, dxu, dyu if possible.

Note that this is a land mask, not a processor mask.

[aekiss]

drag_coeff is also masked - should we just omit this? Does anyone use it?

[aekiss]

These are standard output fields so are available via the cookbook already. As they are model-dependent and cannot be unmasked they should be omitted from these unmasked grid files

            drag_coeff:
            ht:
            hu:
            kmt:
            kmu:

[ofa001]

One comment about kmt, kmu files that are perhaps more relevant when moving to CICE6 or versions of CICE5 that need real topography read in is that we are starting to use real integers again in these fields not a 0 1 land se mask, have to admit that it was myself and @DaveBi who made the switch away from ncar's approach in using kmt topography when we moved away from using the mom2.2 approach to setting up ocean topography in grid files. In CICE6 there is a land fast ice scheme that in the Arctic can is impacted by basal ice stress in shallow water on shelves and in straits. In Antarctica fast ice position is driven more by icebergs, ice shelves, ice tounges and coasts.

[rbeucher]

Thanks for clarifying this. I'll try to keep it simple and won't add them to the file.

[aekiss]

@rbeucher I tracked down the reason dxt, dyt, dxu, dyu are masked: https://github.com/mom-ocean/MOM5/issues/375

Looks easy to fix.

[rbeucher]

Thanks @aekiss !

[aekiss]

/g/data/ik11/grids/ocean_grid_01.nc is different because it seems to have been created by https://github.com/russfiedler/grid_spec_tools and then variables were renamed:

// global attributes:
        :history = "Fri Mar 20 16:34:09 2020: ncrename -v x_T,geolon_t -v x_C,geolon_c -v y_T,geolat_t -v y_C,geolat_c /g/data/v14/pas548/cosima/enkf/grid/old_grid_spec.nc /scratch/v45/raf599/old_grid_spec.nc" ;

[aekiss]

These changes in mom remove the masking from dxt, dyt, dxu, dyu and have been compiled into /g/data/ik11/inputs/access-om2/bin/fms_ACCESS-OM_3256c3e_libaccessom2_d750b4b.x.

This worked fine to create unmasked grid files at 1 deg and 0.25 deg

/home/156/aek156/payu/make_grids/1deg_jra55_ryf_grid
/home/156/aek156/payu/make_grids/025deg_jra55_ryf_grid

but hung every time I tried it at 0.1deg

/home/156/aek156/payu/make_grids/01deg_jra55_ryf_grid

so I'm currently writing Fortran code to do it, based on @russfiedler's https://github.com/russfiedler/grid_spec_tools

[rbeucher]

Thanks for the update and for helping with this @aekiss

[aidanheerdegen]

Related issue: automatically discovering grids in ACCESS-NRI catalogue

https://github.com/ACCESS-NRI/access-nri-intake-catalog/issues/112