FIX: Stop inflating pluvio gauge variables by 5x in the column match - #42
Merged
Merged
Conversation
Ground instruments matched with resample="sum" were binned into a hard-coded 5-minute total and then linearly interpolated back onto the column's 1-minute time grid, so every output step received a whole 5-minute bin. Accumulations came out inflated by exactly the ratio of the two steps: a 19.29 mm day was written as 96.45 mm. The sum was also applied indiscriminately to every surviving pluvio variable, including two rain intensities (mm/hr) and the running bucket level, none of which may be summed. sgpradclssC1.c0 was reporting a mean intensity_rt of 139 mm/hr and a bucket_nrt of 3327 mm. - Integrate only true accumulations (accum_nrt, accum_rtnrt). Rates and the bucket level now take the same averaging path as every other instrument. - Regrid accumulations conservatively: integrate to a running total, interpolate that onto the column grid, then difference it back. This preserves the integral on regular and irregular (radar-based) time coordinates alike, and is an exact identity at native resolution. - Keep gaps missing. The old .sum() skipped NaNs with no min_count, so an all-NaN bin reported 0 mm and an outage read as "no rain". - Fix the closed="right" label. Pandas labels bin (t, t+step] as t, a timestamp the bin excludes, shifting data one step early. This also moves met, ldquants, vdisquants, wxt, kazr and sonde timing. - Only close datasets this function opened; _grd_raw was unbound whenever DataSet=True, breaking that match_datasets_act path. Existing c0 files need reprocessing, and the correction is not limited to accum_nrt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rcjackson
pushed a commit
that referenced
this pull request
Sep 14, 2026
_apply_match raised IndexError: dimension coordinate 'time' conflicts between indexed and indexing objects, taking five tests in test_radclss.py down on every platform since #42 merged. The scheduled run hours before that merge was green. A column time coordinate is built from base_time, which carries second resolution. _accumulate_to_grid subtracted a pandas Timedelta from it to form the leading interpolation edge, and to_timedelta64 carries sub-second precision, so the subtraction promoted the whole edges array to nanoseconds. interp handed that unit to the result, and _apply_match then tried to write a nanosecond-stamped result into a second-resolution column. The timestamps were identical; only the unit differed. Whether that is fatal depends on the xarray version, which is why it never reproduced locally. xarray 2025.6.1, which CI pins, compares coordinates by dtype as well as by value and rejects the write. Newer xarray compares by value and accepts it. The existing tests could not catch this: they build column grids with pd.date_range, which is always nanoseconds, so the promotion is invisible. The new test uses a second-resolution grid like the real pipeline and asserts on dtype directly, so it holds on any xarray version rather than relying on one to raise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was an issue with the accumulations being done over 5 minute periods from the Pluvio instead of the 1 minute timestamps. This is a holdback from when we were doing RadClss over 5 minute periods, so it would only affect the data being currently under review.