fix: cast lat/lon coordinates to float64 at CMOR writer level

[siligam]

Summary

• Adds _cast_geo_coords_to_float64() helper in std_lib/files.py that promotes lat, lon, latitude, longitude, and their bounds variants to float64 before any write path in save_dataset()
• Covers both coordinate variables (via assign_coords) and bounds data variables (via direct assignment), handling both xr.DataArray and xr.Dataset inputs
• Fix is applied once at the CMOR writer level — all pipelines benefit automatically without any per-pipeline changes

Closes #269

Why float64 is required

CMOR3 (the reference implementation) explicitly casts geographic coordinate variables to float64. CF Conventions §2.2 recommends double precision for coordinate variables. Compliance checkers (PrePARE, cf-checker) and publication tools (cmip7repack) will flag or rewrite float32 coordinates.

Note for Jan (#266)

feat/cmip7-awiesm3-veg-hr has heavily modified files.py (670 additions). Once this merges into main, please rebase that branch so it picks up this fix. The change is a small, self-contained addition with no semantic conflict.

Test plan

• test_save_dataset_casts_geo_coords_to_float64 — parametrized over lat/lon/latitude/longitude × float32/float16 input dtypes, verified output is float64 on disk
• test_save_dataset_casts_geo_bounds_to_float64 — parametrized over lat_bnds/lon_bnds/lat_bounds/lon_bounds, verified bounds written as float64
• All 49 existing test_savedataset.py tests pass
• Full unit suite: 423 passed, 0 new failures (1 pre-existing failure and 3 errors unrelated to this change)

🤖 Generated with Claude Code

[siligam]

Conflict notes for Jan (#266 rebase)

When rebasing feat/cmip7-awiesm3-veg-hr after this merges, three areas need attention:

1. Import — trivial
This PR adds import numpy as np at the top level of files.py. Jan's branch imports numpy locally inside three functions. Resolution: keep the top-level import, drop the redundant local ones.

2. _GEO_COORD_NAMES + _cast_geo_coords_to_float64 — pure addition, no conflict
These land in a region that doesn't exist in Jan's branch. Git inserts them cleanly.

3. Call site in save_dataset — real conflict, easy to resolve
This PR adds:

# CMOR3 / CF requirement: geographic coordinates must be float64
da = _cast_geo_coords_to_float64(da)

right after time_encoding["calendar"] = "standard". Jan's branch continues directly into if not has_time_axis(da): at that point. Resolution: just insert the two lines in the same position in Jan's version.

4. Watch out: bounds created by _ensure_lat_lon_bounds_impl bypass the cast
Jan's branch calls _ensure_lat_lon_bounds_and_external_vars(ds_temp, rule) after save_dataset receives da, meaning any lat/lon bounds it synthesises from the mesh file arrive too late to be caught by our upfront cast. np.asarray(bvar.values) in _recover_bounds_from_inputs preserves the source dtype — so if the mesh has float32 bounds, they'd still be written as float32.

Suggested fix: call _cast_geo_coords_to_float64(ds_temp) immediately after each call to _ensure_lat_lon_bounds_and_external_vars(ds_temp, rule) in Jan's write paths, e.g.:

ds_temp = _ensure_lat_lon_bounds_and_external_vars(ds_temp, rule)
ds_temp = _cast_geo_coords_to_float64(ds_temp)  # ensure bounds are also float64

[pgierz]

Looks good, although I have one suggestion that might be interesting to look at.

[pgierz]

Out of curiosity, can this be done with xarray's "encoding" trick? Basically you can set a dict of specific properties if I remember correctly, and when the data structure gets serialized to disk, it gets transformed then and not before.

Just as an idea.

[siligam]

Out of curiosity, can this be done with xarray's "encoding" trick?

Great suggestion @pgierz — just implemented it in the latest commit. Replaced _cast_geo_coords_to_float64 (which called .astype(np.float64) + assign_coords, mutating in-memory data) with _set_geo_coords_encoding_float64 that sets variable.encoding["dtype"] = np.float64 instead.

The cast is now deferred to write time only, which is cleaner and consistent with how time encoding is already handled in this same file (ds[time_label].encoding.update(time_encoding)). All four write paths — plain to_netcdf, scalar-time path, native-timespan split, and resample — pick it up automatically since they all respect per-variable .encoding, with no call-site changes needed.

Extended the tests to also assert the in-memory dtype is not mutated, which confirms the deferred behaviour.