for native ocean path, one hardcoded coordinate-name assumption breaks C-grid vector variables

[ceblanton]

Describe the bug
One hardcoded coordinate-name assumption breaks every C-grid vector variable, two different ways.

load_tripolar_grid() unconditionally reads coordinates named yh/xh from the variable's own data file — correct for scalar tracer fields (tos, so, thetao, on the "h" grid points), but MOM6 reports vector/transport fields on the Arakawa C-grid's staggered velocity points, offset by half a cell in one direction. Verified directly: umo's dimensions are xq, yh (staggered in x); vo's are xh, yq (staggered in y) — neither has both xh and yh together, which is the only case this function handles.

yh = from_ds_get_this(ds, 'yh')
xh = from_ds_get_this(ds, 'xh') + 300.   # cmor_tripolar.py:105-106
...
print_data_minmax(yh[:], 'yh')            # cmor_tripolar.py:109

That single hardcoded pair explains both error signatures, purely as a function of which read fails first: umo, tauuo, uo have yh but not xh — the yh read succeeds, the xh read silently returns None (its IndexError is swallowed internally), and None + 300. immediately raises TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'. tauvo, vmo, vo have xh but not yh — the reverse happens: yh silently becomes None, xh reads fine, and the crash surfaces three lines later at yh[:] as TypeError: 'NoneType' object is not subscriptable. It's one bug wearing two costumes.

Fixing the immediate crash (branch on whichever of xh/xq and yh/yq is actually present in ds.dimensions) is small. Correctly handling what to do with u/v-point data once read — sample at its native staggered location vs. interpolate to h-points — is a separate, larger correctness question this code doesn't attempt at all yet.

To Reproduce

Requirements:

• fremor 0.9.7, unmodified CMIP7_ocean.json
• An input file for a native-tripolar-grid ocean vector variable (u-point and v-point)
• The ocean static/grid file fremor's load_tripolar_grid() looks up automatically (ocean_static_no_basin.nc or similar, containing geolon_c/geolat_c/xq/yq) — this is located by fremor itself via find_gold_ocean_statics_file(), not passed explicitly, so it needs to be discoverable in the expected archive location relative to the input

Variant A — u-point field (umo, tauuo, or uo):
Varlist {"umo": "umo"}

Error:
Exception: problem with rewrite_netcdf_file_var. exc=unsupported operand type(s) for +: 'NoneType' and 'float' [WARNING] OMITTED local_var=umo / target_var=umo, reason: ... exc=unsupported operand type(s) for +: 'NoneType' and 'float' file: .../ocean.0001-0004.umo.nc

Variant B — v-point field (vmo, tauvo, or vo):
Varlist {"vo": "vo"}

Error:
Exception: problem with rewrite_netcdf_file_var. exc='NoneType' object is not subscriptable [WARNING] OMITTED local_var=vo / target_var=vo, reason: ... exc='NoneType' object is not subscriptable file: .../ocean.0001-0004.vo.nc

Both come from the same command shape:

fremor -v run \
  --indir <annual native-grid ocean dir> \
  --varlist varlist.json \
  --table_config CMIP7_ocean.json \
  --exp_config exp_config.json \
  --outdir <output dir> \
  --run_one \
  --grid_desc "test" --grid_label g999 --nom_res "100 km" --calendar noleap

Expected behavior

Additional context
Add any other context about the problem here.

[ilaflott]

@ceblanton i need the exp_config.json

[ilaflott]

also what is indir