Skip to content

Materialize ds before snow-index calcs to fix read-only buffer error#83

Closed
ZachHoppinen wants to merge 2 commits into
mainfrom
fix-deltaCR-readonly
Closed

Materialize ds before snow-index calcs to fix read-only buffer error#83
ZachHoppinen wants to merge 2 commits into
mainfrom
fix-deltaCR-readonly

Conversation

@ZachHoppinen

Copy link
Copy Markdown
Contributor

Summary

calc_delta_cross_ratio (and the rest of the snow-index funcs) do in-place dataset['x'].loc[time=...] writes. After the s1 preprocessing chain leaves vv/vh wrapping a non-writeable numpy buffer, the second orbit's write fails with:

```
ValueError: assignment destination is read-only
```

The author already hit this in retrieval_from_parameters (retrieval.py:238) and fixed it with dataset = dataset.load(). The main retrieve_snow_depth flow was missing the same line. This adds it between s1_clip_outliers and calc_delta_cross_ratio.

Reproduces from a real run failure on Fairbanks 2024_2025 (snow_index.py:102).

Test plan

  • pytest tests/ — 73/73 pass.
  • Re-run fairbanks 2024_2025 and confirm snow-index calcs succeed.

🤖 Generated with Claude Code

ZachHoppinen and others added 2 commits May 9, 2026 13:31
calc_delta_cross_ratio and the other snow-index funcs do in-place
.loc[time=...] writes. After the s1 preprocessing chain
(generate_sentinel1_dataarray -> combine_close_images -> amplitude_to_dB
 -> s1_orbit_averaging -> s1_clip_outliers), the underlying numpy
buffer for vv/vh ends up non-writeable, so the second-orbit write in
calc_delta_cross_ratio fails with "assignment destination is read-only".

Force materialization with ds.load() between s1 preprocessing and the
snow-index step. Mirrors the same .load() already done in
retrieval_from_parameters at the analogous point.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…itable

PR #83's .load() alone fixed the snow-index read-only error for
white_mtns 2025_2026 and fairbanks 2025_2026 but not for fairbanks
2024_2025: .load() materializes lazy/dask arrays but does NOT
deep-copy already-in-memory arrays whose buffers happen to be
read-only. Chain .copy(deep=True) after .load() to guarantee fresh
writable buffers regardless of the upstream chain's state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ZachHoppinen

Copy link
Copy Markdown
Contributor Author

Updated: chained .copy(deep=True) after .load(). .load() alone wasn't enough for fairbanks 2024_2025 — that scene set's vv/vh end up already-in-memory but with read-only numpy buffers, which .load() doesn't deep-copy. The combined ds = ds.load().copy(deep=True) guarantees writable backing.

Memory note: .copy(deep=True) transiently allocates a second copy of the dataset (~+4GB for Fairbanks-sized AOIs), but the original is dropped after assignment so the steady-state stays the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant