the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
New insights on the suitability of NetCDF/HDF5 as storage format for climate cloud repositories
Abstract. Climate data analysis increasingly relies on cloud infrastructures to offer new and efficient methods of accessing the necessary climate data. Cloud repositories allow access to such data in a remote data access basis, which allows users to retrieve and manipulate their data without requiring file downloads, reducing storage costs resulting in more efficient systems. Together, climate cloud repositories and remote data access are evolving fast, due to the necessity of collaboration that brings together diverse communities to address challenges in climate science. In recent years, a prevailing discourse has emerged suggesting that traditional climate data storage formats are inherently unsuitable for remote data access. In this work, we present new insights that challenge this discourse and demonstrate that established storage formats such as NetCDF/HDF5 can continue to operate efficiently in cloud environments when accessed remotely. These findings contrast with the widespread perception that such formats are inherently unsuitable for cloud based workflows. In the context of the onset of CMIP7, these insights have the potential to substantially enhance climate data access and analysis for the broader research community without incurring major maintenance burdens.
- Preprint
(452 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 22 Aug 2026)
-
RC1: 'Comment on egusphere-2026-3249', Amirhossein Nikfal, 16 Jul 2026
reply
-
AC1: 'Reply on RC1', Ezequiel Cimadevilla, 17 Jul 2026
reply
We have made available the script to generate the CSV files in the repository (tree.py, https://github.com/zequihg50/new-insights-netcdf/). Release v1.1.2 of Pyfive is required to test parallel access to data (https://github.com/NCAS-CMS/pyfive/releases/tag/v1.1.2). Per the HDF5 specification [1], the fields are defined as follows:
level - The node level indicates the level at which this node appears in the tree (leaf nodes are at level zero). Not only does the level indicate whether child pointers point to sub-trees or to data, but it can also be used to help file consistency checking utilities reconstruct damaged trees.
entry - Each entry (key and address of a child) among the entries used in the B-tree.
offset - Byte offset of each entry in the B-tree.Fig-1: The purpose of B-trees is to grow over time as chunks are written. Because clients typically write one chunk at a time, space for future chunks is reserved in the index after the first chunks have been written. During repacking we increase the metadata block size and HDF5 attempts to place B-trees at the beginning of the file. We will clarify this in the reviewed version. For more information, please see https://github.com/Unidata/netcdf-c/issues/3386.
Table 1: We provide links to both the original and repacked files. Please note that repacking is not a deterministic operation, as its output may vary depending on the version and behavior of h5repack.
- https://thredds.climate.ifca.es/thredds/fileServer/tests/uas_Amon_IPSL-CM6A-LR_piControl_r1i1p1f1_gr_185001-234912.nc
- https://thredds.climate.ifca.es/thredds/fileServer/tests/uas_Amon_IPSL-CM6A-LR_piControl_r1i1p1f1_gr_185001-234912.nc_cmip7repack4mb
- https://thredds.climate.ifca.es/thredds/fileServer/tests/uas_day_IPSL-CM6A-LR_piControl_r1i1p1f1_gr_18500101-23491231.nc
- https://thredds.climate.ifca.es/thredds/fileServer/tests/uas_day_IPSL-CM6A-LR_piControl_r1i1p1f1_gr_18500101-23491231.nc_cmip7repack4mb
- https://thredds.climate.ifca.es/thredds/fileServer/tests/uas_3hr_IPSL-CM6A-LR_piControl_r1i1p1f1_gr_187001010300-197001010000.nc
- https://thredds.climate.ifca.es/thredds/fileServer/tests/uas_3hr_IPSL-CM6A-LR_piControl_r1i1p1f1_gr_187001010300-197001010000.nc_cmip7repack4mb[1] - https://support.hdfgroup.org/documentation/hdf5/latest/_f_m_t4.html#subsubsec_fmt4_infra_btrees_v1
Citation: https://doi.org/10.5194/egusphere-2026-3249-AC1
-
AC1: 'Reply on RC1', Ezequiel Cimadevilla, 17 Jul 2026
reply
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 46 | 21 | 3 | 70 | 1 | 1 |
- HTML: 46
- PDF: 21
- XML: 3
- Total: 70
- BibTeX: 1
- EndNote: 1
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
The code repository contains the precomputed CSV files used to construct the B-tree-offset distributions in Figures 2 and 3, but I could not identify the code or commands used to generate these CSV files from the original and repacked NetCDF files. Please provide the complete extraction script and document the meaning of the level, entry, and offset columns, including whether offset represents a B-tree node address or an individual entry address. The required Pyfive version or commit should also be specified.
Fig-1: Why are the B-tree nodes scattered throughout the linear address space of the NetCDF/HDF5 file? Could the authors explain why their locations cannot be organized sequentially or made more predictable during file creation?
Table 1: Please provide direct download links or persistent ESGF catalogue links for the three NetCDF files used in Section 3.