incorrect topoedits files in /scratch1/NCEPDEV/global/glopara/fix/mom6/20240416/100 (and 20231219/100/)

[DeniseWorthen]

What is wrong?

In the MOM6/100 fix directories, there should be two distinct "topoedits" files: topo_edits_011818.nc and ufs.topo_edits_011818.nc.

The first of these files contains 103 values (nEdits = 103). It is the file which comes directly from GFDL, but which leaves an open boundary along the southern most row.

In cpld_gridgen, we read the original topo_edits_011818.nc file and add 40 "edit" points to close (add land) to the southernmost row. This creates the ufs.topo_edits_011818.nc. This file holds nEdits=143.

UWM 1-deg MOM6 should only use the ufs.topo_edits_011818.nc file.

In the 20240416/100 directory, there is an incorrect link:

lrwxrwxrwx 1 role.glopara global       24 Aug  9 15:38 topo_edits_011818.nc -> ufs.topo_edits_011818.nc

This means that when cpld_gridgen reads the topo_edits_011818.nc, it creates a file with duplicated edits (nEdits = 183) which closes the already closed boundary. This breaks the cpld_gridgen RT.

This apparently was done in NOAA-EMC/global-workflow #2812

What should have happened?

The files should be unlinked; the original 103 file (topo_edits_011818.nc ) needs to be placed in the fix directory instead of linking it to the ufs file. The original file can be recovered from 20220805/100/topo_edits_011818.nc.

Note that the 20231219/100/topo_edits_011818.nc is NOT correct. It is in fact the ufs.topo_edits_011818.nc file.

What machines are impacted?

All or N/A

What global-workflow hash are you using?

4ab8cf8

Steps to reproduce

1. Check the nEdits size in topo_edits_011818.nc and ufs.topo_edits_011818.nc. The first should contain a dimension of nEdits = 103 and the second should contain nEdits = 143

Additional information

No response

Do you have a proposed solution?

No response