the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Compression Safeguards: Building Trust into Lossy Data Compression
Abstract. The growth in data volumes produced by scientific models is accelerating. Data production of high-resolution weather and climate models is outpacing the methods and budgets for storing, sharing, and analysing this data, posing a threat to scientific progress. Lossy data compression greatly reduces data sizes but loses some quality, detail, or precision of the original data. Even though some lossy compressors promise size reductions of 100x or more, the lack of trust in lossy compression, rooted in the risk of losing important information, has thus far limited their adoption. We introduce Compression Safeguards, a user-centric and domain-independent framework to overcome this trust gap, with which (i) scientists declare their precise safety requirements for what lossy compression must preserve, e.g. regionally varying error bounds on quantities derived from the decompressed data, then (ii) wrap a compressor of their choice in the corresponding safeguards, which then (iii) guarantee that the safety requirements are always met by the safeguarded compressor, at most at the cost of a reduced compression ratio. The Compression Safeguards represent a paradigm shift: Data producers and users no longer carry the risks of lossy compression, having to manually check for problems after compression, but instead control up-front what needs to be safeguarded. With the appropriate safeguards, trust can grow in all lossy compressors and even untrusted, potentially unsafe compressors can be used safely and with confidence. Users thus no longer need to re-verify each new compressor for each new use case, or to restrict themselves to few safe compressors and supported use cases. We showcase how our reference implementation of the Compression Safeguards can be flexibly applied to safeguard important properties across several real-world examples from weather and climate sciences for different compressors. The impact on compression ratio varies but is small in many cases. The computational load increases during compression but is negligible during decompression. Altogether, Compression Safeguards provide a key modular tool that gives users the confidence to use lossy compression safely across scientific disciplines. Safeguards can unlock the data reduction benefits of lossy compression and therefore solve many data storage problems across the scientific community that otherwise hinder research.
- Preprint
(58007 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 22 Sep 2026)
- RC1: 'Comment on egusphere-2026-4266', Anonymous Referee #1, 26 Aug 2026 reply
-
RC2: 'Comment on egusphere-2026-4266', Anonymous Referee #2, 02 Sep 2026
reply
I enjoyed reading this paper. Checking and correcting a compressor's output without having to modify the compressor itself makes a lot of sense. The missing-value and vorticity examples help show why this is useful, and being able to combine different safeguards is a real strength. I also appreciate that the authors show cases where safeguarding is expensive or substantially reduces the compression ratio, rather than only presenting favorable results.
1. I would tone down some of the language about safety. Section 2 explains that the guarantee depends on the checks matching the user's requirements, but the abstract and introduction sometimes sound broader than that. Passing the chosen checks doesn't mean that every later analysis is protected. The discussion of bias and spectral errors makes this clear. I don't think the method needs to solve these additional problems for the paper to be useful. I would just make the limits more visible early on, and consistently describe the guarantee as applying to the declared requirements.
2. I was interested in the xarray frontend and would have liked to see it used in the evaluation. The authors explain why the example datasets are small, which is reasonable, but testing individual fields doesn't demonstrate the handling of stencil requirements across chunk boundaries. Could one of the existing examples be repeated with the data split into chunks? Checking the boundary values and reporting the runtime and memory use for a few chunk sizes would already be helpful. I'm not asking for a large multi-node study, just an example that connects the design in Section 3.6 to an actual result.
3. The option to distribute corrections separately raises a practical question. How does a reader know that a correction file belongs to the data they are opening? Since the binary differences are computed against a particular decompressed approximation, applying them to a different reconstruction could give incorrect values. Section 3.5 describes a checksum for the combined stream, which is good. Is an equivalent check available for the separate-file workflow? Please explain what is stored to identify the matching data and detect a mismatch. Also, the random-access discussion should distinguish accessing the raw correction array from accessing corrections after lossless compression.
4. I would be a little more careful with the comparisons to earlier work. I understand the difficulty with running QPET-SZ, and the reason given for leaving out MGARD-QoI, but the conclusions should stay within what was actually tested. The examples where masking, a ratio-error wrapper, or compressor tuning works better are useful and deserve attention. To me, the strongest contribution is that users can combine requirements and apply them across compressors, not that safeguards are always the most efficient way to preserve a particular property.
There are also a few small things to fix. Figure 1 has "to corrections are checked," and its caption seems to be missing some words. "We herefore utilise" should be "We therefore utilise," and "Table B1 shoes" should be "Table B1 shows." Around line 655, the explanation needs checking: cos(phi) tends to zero at the poles, whereas the magnitude of its derivative tends to one.
These comments don't change my overall positive view. The paper offers a useful approach, and most of what I'm asking for is clarification and a more concrete demonstration of the chunked workflow. I recommend minor revisions.
Citation: https://doi.org/10.5194/egusphere-2026-4266-RC2
Model code and software
compression-safeguards Juniper Tyree, Robert Underwood, Clément Bouvier, Daniel Köhler, Tim Reichelt, Peter Dueben, Sara Faghih-Naini, Heikki Järvinen, and Milan Klöwer https://doi.org/10.5281/zenodo.21390619
ClimateBenchPress compressor Tim Reichelt and Juniper Tyree https://doi.org/10.5281/zenodo.21393343
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 211 | 68 | 21 | 300 | 19 | 20 |
- HTML: 211
- PDF: 68
- XML: 21
- Total: 300
- BibTeX: 19
- EndNote: 20
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Overall, I think the paper is in a good place. I have a few points of feedback that I think ought to be addressed but otherwise see no big defect that should require major changes.
The problem is well motivated, and legitimate. I know from my own research that this area is of import, and this work is meaningful towards a goal of improving confidence when it comes to lossy compression.
Overall, great ideas and engineering.
Main points of feedback:
Some more minor points:
Once again, overall good work. I am definitely open to be persuaded on pretty much all of the above.