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 -
RC2: 'Reply on AC1', Amirhossein Nikfal, 06 Aug 2026
reply
Code tree.py:
The fs dictionary hardcodes a B-tree root offset and key size for each variable per file (e.g. "uas": [28671, 8+8*(3+1)]), but the code used to derive these values isn't included. Could you share the script/method used to locate them? This would let reviewers reproduce fs independently rather than trusting the hardcoded numbers.
Citation: https://doi.org/10.5194/egusphere-2026-3249-RC2 -
AC2: 'Reply on RC2', Ezequiel Cimadevilla, 06 Aug 2026
reply
We obtained the B-tree root node offsets by inspecting and debugging pyfive, while opening each netCDF file. Specifically, we identified the offset used to initialize chunk B-trees, which is available in the pyfive source code here [1]. Note that pyfive does not provide a public API for accessing this information, nor are there any plans to add one in the short term, as this is considered a private implementation detail of the library. The tree.py script included in the GitHub repository verifies that the TREE signature is present at the specified location, in accordance with the HDF5 specification.
[1] - https://github.com/NCAS-CMS/pyfive/blob/667c4681685ac32d5528c93a4058c733914dadb4/pyfive/btree.py#L133
Citation: https://doi.org/10.5194/egusphere-2026-3249-AC2
-
AC2: 'Reply on RC2', Ezequiel Cimadevilla, 06 Aug 2026
reply
-
RC2: 'Reply on AC1', Amirhossein Nikfal, 06 Aug 2026
reply
-
AC1: 'Reply on RC1', Ezequiel Cimadevilla, 17 Jul 2026
reply
-
RC3: 'Comment on egusphere-2026-3249', Anonymous Referee #2, 11 Aug 2026
reply
Review of “New insights on the suitability of NetCDF/HDF5 as storage format for climate cloud repositories” by Ezequiel Cimadevilla , David Hassell, and Bryan N. Lawrence
Summary
In their study the authors investigate the suitability of HDF5-based netCDF-files to efficiently operate in cloud-based environments. They analysed the data structures of selected CMIP netCDF-files and identified metadata scattered throughout the file. They propose that reorganizing the metadata and storing it all together at the beginning of linear storage of the netCDF file together with a client that can exploit these file features can significantly reduce the time reading variables from netCDF-files via WAN networks.
General comments
The general idea that restructuring netCDF files and using advanced clients would make them also effectively useable via cloud services is very appealing. The authors introduced a concept and explained it very well, but used only 3 example files and a 2D variable for demonstration. As this method has the potential to use one file format, namely netCDF, efficiently on local systems, HPC-platforms, as well as cloud environments and thus helps to reduce disk space consumption by reducing metadata and data duplication (same data in various file formats), as well reducing inode consumption (by avoiding extra metadata files for each file), it deserves to be put on a broader data basis. I highly recommend increasing the set of test files and variables. This would also help to derive robust statistics and quantify the potential time reductions.Specific Comments
Introduction: Using kerchunk and zarr extensively on large data archives significantly increases the number of files and hence, used inodes. This can pose challenges with respect to inode availability or inode/capacity trade-offs in HPC environments. Is this also an issue in cloud environments? As the suggested approach of repacking netCDF files would not consume additional inodes, which I consider a strong advantage, I'd suggest to also address inodes.l72: Please name here explicitly cloud-native storage formats you had in mind when writing.
Table1: What about rounding up to 26 MB? Or at least using a decimal point instead of a comma.
l84/85: How did you extract the B-tree fragments from the netCDF file?
Figure 2: The tick labels and axis labels are too small. Please increase to make them readable at 100 % zoom level. I cannot see the colours for lat and lon in the figures.
Comparing the metadata size of Table 1 with the kerchunk file size in table 2, can one generally say that kerchunk increases the metadata size by a factor of approximately 2 plus generating these files the inode usage is doubled?
l133: Please explain what uas is (u-component of the near-surface wind). Why did you select a 2D variable for demonstration and not a 3D variable, e.g. ua, which is the 3D wind component? Usually the 3D variables account for the largest fraction of atmospheric netCDF files.
Table3: What is meant by “Relation of the repacked NetCDF files…”? I rather understand this table as same as Table 1, but for the repacked files. A relation would be, e.g. in the repacked file the number of chunks is only ~2 % and metadata size is only 3.6, 0.8, 0.8 % of the original netCDF files. Please clarify.
l125: Does cmip7repack work only for CMIP data sets, or can it be applied to all kinds of netCDF files? Are there other tools available that can do repacking? Would it be possible to specify another variable than time to rechunk the data? E.g. thinking about reanalysis data, where each file contains one time step, but many height levels.
l138-141: Could one say that a reduction of the kerchunk file size of more than 98 % is possible? A larger data basis would be helpful to prove this advantage.
Figure 3: Same as Figure 2, the labels are too small to read. Also, please add a sentence to the figure caption that the x-axis is only a fraction of 2 to highlight the changes. Moreover, lat, lon, time are hardly visible. I don't know if they are present in the middle and right panel. In the left panel maybe a logarithmic y-scale could make them better visible.
l153-155: Please provide examples for clients that are capable of this.
Figures 4 and 5: From how many samples are the values derived? Are they averages? Why are there some tests with relatively large error bars compared to the others? Please provide an explanation. Please consider rearranging the order, to have the results sorted by tool and file format, e.g. kerchunk first, followed by pyfive, and zarr, to facilitate the comparison. Could the error bars also depend on network speed and cloud setup? Would other cloud setups connections show less variability?
l167-170: Is it just impractical to open the original files or is it even impossible?
Figure 5: I think the clear advantage shown here is that repacking speeds up the reading process significantly. Since the scale is log-scale it would be good to provide some numbers in the text how much faster the variables from the repacked files can be read by pyfive and kerchunk.
Figure 6: Isn't Figure 6 a subset from Figure 5? Here the values for “Amon”' are hardly visible. Maybe a table would be the better choice.
l190: Please consider providing an example list of clients that can and cannot fetch chunks concurrently.
l194-196 & l220-221 & l256-257: The same conclusion is repeated here. Rather have the conclusion just in the conclusions section.
Typos
General: Please consider writing “netCDF”' instead of “NetCDF” in running text. This is what the developers do: https://www.unidata.ucar.edu/software/netcdf. Capital “N” in netCDF is only used at the beginning of a sentence or in headlines.l41: “a NetCDF files” -> “a netCDF file”
Figures 5 & 6 caption: minimun -> minimum
l163 & 252: Please consider replacing LLM-hyphens.
Citation: https://doi.org/10.5194/egusphere-2026-3249-RC3
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 74 | 40 | 7 | 121 | 4 | 2 |
- HTML: 74
- PDF: 40
- XML: 7
- Total: 121
- BibTeX: 4
- EndNote: 2
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.