You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Variable endpoints undefined when order is not ascending or descending #594
It looks like this issue shows up when longitude is in the 0–360 format, centered around 0.
@malmans2@aulemahal This is an edge case we didn’t cover in PR #579. The coordinates are circular (0–360), and the 1-D core dimension isn’t strictly monotonic because it crosses the seam at 0°. In cf_xarray.helpers._get_core_dim_orders, that situation is inferred as "mixed" order.
cf_xarray.helpers._get_ordered_vertices doesn’t handle "mixed" order (e.g., [359, 0, 1]), so endpoints is never set and we end up with an UnboundLocalError.
I’m planning to open a PR to raise a clear ValueError in bounds_to_vertices whenever a 1-D core dimension isn’t strictly increasing or decreasing. Longer term, the cf-xarray devs might consider opt-in support for circular axes, e.g. bounds_to_vertices(..., circular_period=360.0, start=None). With circular_period set, cf-xarray could detect circular monotonicity, rotate away from the seam, and proceed safely.
Suggestions
Your script: Normalize longitudes to a monotonic convention before regridding with xESMF (short-term fix).
Simplest: convert to [-180, 180) and sortby("longitude").
If you need 0–360, roll so the seam isn’t inside the array, then sort.
xesmf: Pre-normalize/unwrap coords (lon, lat if needed) before calling bounds_to_vertices.
Detect circular longitude grids, then either:
convert to [-180, 180) and sort, or
roll within 0–360 to move the seam away, then sort.
If cf-xarray adds circular_period, pass it through; otherwise handle normalization inside xESMF.
Add validation + helpful errors for non-monotonic or seam-crossing inputs.
Activity
tomvothecoder commentedon Sep 15, 2025
Hi @malmans2, thanks for reporting this issue. I'll try debugging once you provide a minimal reproducible example.
I think the order is "mixed", so there might be some issues with the bounds in your dataset. This code block determines the order of bounds:
cf-xarray/cf_xarray/helpers.py
Lines 247 to 257 in 70be853
However, the code you pointed to should still handle that case (e.g., maybe raise an error).
malmans2 commentedon Sep 15, 2025
It looks like the issue occurs when longitude is in the 0-360 format, centered around 0.
Here’s the MRE:
The MRE is basically a simplified version of this internal function of
xesmf, which is how I discovered the problem: https://github.com/pangeo-data/xESMF/blob/f2eeeb2071f4f1386dd0852ddb2696568134e387/xesmf/frontend.py#L85-L105Traceback
tomvothecoder commentedon Sep 18, 2025
@malmans2 @aulemahal This is an edge case we didn’t cover in PR #579. The coordinates are circular (
0–360), and the 1-D core dimension isn’t strictly monotonic because it crosses the seam at0°. In cf_xarray.helpers._get_core_dim_orders, that situation is inferred as"mixed"order.cf_xarray.helpers._get_ordered_vertices doesn’t handle
"mixed"order (e.g.,[359, 0, 1]), soendpointsis never set and we end up with anUnboundLocalError.I’m planning to open a PR to raise a clear
ValueErrorinbounds_to_verticeswhenever a 1-D core dimension isn’t strictly increasing or decreasing. Longer term, the cf-xarray devs might consider opt-in support for circular axes, e.g.bounds_to_vertices(..., circular_period=360.0, start=None). Withcircular_periodset, cf-xarray could detect circular monotonicity, rotate away from the seam, and proceed safely.Suggestions
Your script: Normalize longitudes to a monotonic convention before regridding with xESMF (short-term fix).
[-180, 180)andsortby("longitude").0–360, roll so the seam isn’t inside the array, then sort.xesmf: Pre-normalize/unwrap coords (lon, lat if needed) before calling
bounds_to_vertices.[-180, 180)and sort, or0–360to move the seam away, then sort.circular_period, pass it through; otherwise handle normalization inside xESMF.