the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 11 Sep 2025
Towards Bedmap Himalayas: a new airborne glacier thickness survey in Khumbu Himal, Nepal
Abstract. Mountain glaciers provide an important service in sustaining river flows for large populations downstream of High Mountain Asia (HMA) but these glaciers are retreating and the future of this water resource is highly uncertain. Glacier thickness measurements are vital for accurate mapping of the remaining ice reserve and for predicting where and how fast it will decline under climate change, but such measurements are severely lacking in this region due to the difficulties of surveying in remote, high-altitude settings. We report on a uniquely extensive new thickness dataset for eleven glaciers in the Khumbu Himal around Mount Everest that we collected in late 2019 using a novel, low-frequency helicopter-borne radar. To aid in interpreting the survey radargrams we developed a terrain clutter model, and we succeeded in mapping ice thickness with a precision of around ±7 % and horizontal spacing of around 40 m, for thicknesses of up to 445 m and spanning a total of 119 line-km, approximately doubling the length of previous thickness surveys in HMA. To demonstrate the utility of our new measurements, we compare them to existing modelled thickness products and find that the models struggle to reproduce the distribution of ice in these complex, steep, rapidly slowing, thinning and stagnating glaciers, with widespread systematic thin and thick biases equivalent to around half of the measured ice thickness or more. This new dataset (https://doi.org/10.5285/e39647f5-fb72-4d16-acbd-9784ed2167b8) permits for the first time a detailed analysis of model performance on Himalayan glaciers, a key step in improving model skill and hence the accuracy of modelled thickness distributions and future ice loss on the mountain-range scale.
- Preprint
(2704 KB) - Metadata XML
- BibTeX
- EndNote
Status: closed
-
RC1: 'Comment on essd-2025-519', Howard Conway, 13 Oct 2025
-
AC2: 'Reply on RC1', Hamish Pritchard, 16 Dec 2025
Many thanks Howard for your supportive review and helpful comments. Please see below our responses to the specific suggestions:
1) Fig. 2: Glacier names are small – perhaps put them with a white background??
Thanks, we have now increased the font size and added a grey background to help legibility.
2) Fig. 3: Clutter modelling appears to be working well. However, it is not clear that the clutter test (panel c) (vertical scale differs from other panels) – should it refer to the vertical scale differs for (panel d), rather than (panel c)? Or am I missing something?
We have now clarified this to read:
“…(panel d vertical scale differs from other panels)…”
3) Fig. 4: Use black font for (panel b) to make it visible
Agreed, we’ve now made this change.
4) Fig. 7: Make the lines around the “grey box” thicker to illustrate the central Khumbu Glacier
Also now done.
5) Fig. 14: Inset (bottom left) is cropped (on RHS)
Thanks, now corrected.
Citation: https://doi.org/10.5194/essd-2025-519-AC2
-
AC2: 'Reply on RC1', Hamish Pritchard, 16 Dec 2025
-
RC2: 'Comment on essd-2025-519', Thomas Teisberg, 11 Dec 2025
The authors present a dataset of radar data collected by helicopter surveys in the Khumbu Himal region. The work details the parameters of the radar system, the collection and processing of the radar data, and the process of picking the basal interface in the presence of significant sources of clutter. It also analyzes the resulting thickness data relative to prior surveys and modelling work.
This represents a valuable dataset for understanding water resources in the region and the careful analysis and processing of the data will make it easy for others to build upon this work.
A few minor suggestions:
Section 2.1.1: It would be useful to include the transmit power of the radar system
Figure 3 (d) is confusing to me. The Y axis should be shown separately for this subplot if it needs to be different from the others. It's also confusing that the areas marked as rejected have a red line through them apparently indicating a bed pick.
Section 3.2: I appreciate the careful analysis of resolution and uncertainty for the radar system and particular survey setting. I would suggest adding a note to the second paragraph to point out that the "vertical precision" refers to the ability to detect the location of a particular target and that ambiguities in picking which target is the basal interface could significantly exceed 2.8 m.
Data files:
It would be helpful to include timestamps in the CSV bed picks and GPS files. This is a region that will change rapidly. Hopefully more work continues to be done here. As efforts are made to unify data collected in the region, timestamps in every file make data collation and post-processing much easier
A readme file packaged with the raw data would be very helpful to help understand how to decode it.
GitHub repository:
I appreciate the effort you've put into creating nice documentation!
Please consider adding a license to your GitHub repository.
Citation: https://doi.org/10.5194/essd-2025-519-RC2 -
AC1: 'Reply on RC2', Hamish Pritchard, 16 Dec 2025
Many thanks Thomas for your thoughtful review and comments. Please find below our responses to specific suggestions.
1) Section 2.1.1: It would be useful to include the transmit power of the radar system
Good point. The actual transmitted power of full systems like this is difficult to determine and instead is typically specified as the transmitter voltage, which is known. We have therefore changed this sentence to:
“We used a wide band mono-pulse dipole radar with a transmitter that produces ±2000 V pulses at a centre frequency of 7 MHz (Pritchard, King et al. 2020) for this survey”
2) Figure 3 (d) is confusing to me. The Y axis should be shown separately for this subplot if it needs to be different from the others. It's also confusing that the areas marked as rejected have a red line through them apparently indicating a bed pick.
Thanks, yes, we now show the Y-axis for panel (d) separately and for clarity have changed the caption to read:
“…d) the terrain-corrected radargram with the initial bed pick bed (red lines), highlighting the sections that were subsequently rejected following the clutter test (panel c) (panel d vertical scale differs from other panels)... “
3) Section 3.2: I appreciate the careful analysis of resolution and uncertainty for the radar system and particular survey setting. I would suggest adding a note to the second paragraph to point out that the "vertical precision" refers to the ability to detect the location of a particular target and that ambiguities in picking which target is the basal interface could significantly exceed 2.8 m.
We have changed Section 3.2, paragraph 2 to read:
“…This implies that the practical vertical precision in thickness (assuming that the bed reflector has been correctly identified (see below)) is the combination in quadrature of these two precisions, i.e., ~2.8 m”.
The ‘see below’ refers to the next paragraph on accuracy (as opposed to precision), which notes that “Potentially more significant bias (e.g., tens of metres) could result from mistaking a non-bed reflection horizon for the bed, which we sought to avoid with our clutter modelling…”
4) Data files: It would be helpful to include timestamps in the CSV bed picks and GPS files. This is a region that will change rapidly. Hopefully more work continues to be done here. As efforts are made to unify data collected in the region, timestamps in every file make data collation and post-processing much easier
This is a good point, and in fact the bed-pick csv files have the date stamps encoded in the first column (“heli_line”) for each point, at daily resolution, e.g. the first 10 characters of entry 2019_11_06_F2_P93 are in format yyyy_mm_dd. The next column (“survey”) notes the approximate period of the survey in free text format, e.g., “Helicopter October/November 2019”, though the period is more precisely defined in the header metadata which include standardised date flags as, e.g., “# time_coverage_start: 2019-10-27” and “# time_coverage_end: 2019-11-06” (Please see the metadata held in the header of each csv file). Similarly for the GPS data, the date is encoded in the filename, e.g., the first 10 characters of the filename 2019_10_28_F1_coords.csv are also in format yyyy_mm_dd. In using this approach, we were governed by the metadata formatting policies of the Polar Data Centre.
5) A readme file packaged with the raw data would be very helpful to help understand how to decode it.
This is an understandable suggestion as the absence of a downloadable readme file in this folder is a little confusing, though we’re again constrained by the formatting policies of the Polar Data Centre. Instead, the metadata for the raw datasets are actually held with the main combined metadata record associated with our submission, available here: https://data.bas.ac.uk/full-record.php?id=GB/NERC/BAS/PDC/02073. Fortunately, there is a link to this on the page that serves the raw datasets themselves. When scrolling down on this page, the metadata for the raw data reads:
*Raw radar data *
We collected a raw radar data file for each survey flight. The filename format gives the date and time of file creation as yyyymmddhhmmss.hdf5, e.g., 20191103021438.hdf5.
File contents:
Each file contains two channels of radar data as recorded by the digitiser in the radar receiver system. Channel A is amplified, Channel B unamplified.
For each channel, there are multiple Traces, numbered sequentially (e.g., Trace00001). Each trace records a series of radar receiver signed voltages as a measure of returning signal strength.Channel metadata:
The total duration of each trace (and therefore its range, in number of samples) is given by the NoOfSamples parameter in the channel metadata. Each sample has a duration of 2 nanoseconds, hence a trace with 10152 samples is 20304 ns long (a range of around 1700 m in ice, or 3000 m in air).The 'SampleRate' parameter gives the timeout time (in seconds) for the receiver to wait to detect a returning pulse before assuming that triggering has failed and moving on to the next set.
Each trace represents the averaged voltages of the number of independent radar pulses given by the 'Stacks' parameter.
'Repeats' is an internal system parameter that sets the number of samples to store before writing to disk.
The GPS time is recorded along with the corresponding file start and end 'system' times for the onboard computer, to allow the system timestamps to be synchronised to the GPS data in post processing.
Trace metadata:
In each file, Trace00001 metadata shows the number format (Type) and the precise system date and time (yyyy,mm,dd,hh,mm,ss.ssssss). The 'GGA' string reports the GPS time at completion of this trace as hhmmss.s (e.g., 082520.8) and the GPS position at that time (ddmm.mmmmm, N/S, dddmm.mmmmm, E/W) (e.g., 2748.34269,N,08641.95129,E means 27deg 48.34269' N, 086deg 41.95129' E).
A new system time and GPS time and position is then stored for every 1000th subsequent trace, hence for trace 1001, 2001 etc. This is because GPS data could not be written to disk at the same rate as the trace creation. High frequency, high precision GPS times and positions were stored internally on the GPS, however, and matched to trace times in post-processing.6) GitHub repository: Please consider adding a license to your GitHub repository.
Good idea, we have applied the BSD-3 Clause license to the repository (https://github.com/bearecinos/radar-declutter/blob/master/LICENSE).
Citation: https://doi.org/10.5194/essd-2025-519-AC1
-
AC1: 'Reply on RC2', Hamish Pritchard, 16 Dec 2025
Status: closed
-
RC1: 'Comment on essd-2025-519', Howard Conway, 13 Oct 2025
The manuscript presents novel airborne radar surveys in the Khumbu Himal that are a huge step forward to map ice thickness and bed topography. These measurements improve the accuracy of ice thickness distributions, which are essential to improve modeling of present and future ice loss in High Mountain Asia.
I recommend publication.
I just have just a few suggestions/comments:
Fig. 2: Glacier names are small – perhaps put them with a white background??
Fig. 3: Clutter modelling appears to be working well. However, it is not clear that the clutter test (panel c) (vertical scale differs from other panels) – should it refer to the vertical scale differs for (panel d), rather than (panel c)? Or am I missing something?
Fig. 4: Use black font for (panel b) to make it visible
Fig. 7: Make the lines around the “grey box” thicker to illustrate the central Khumbu Glacier
Fig. 14: Inset (bottom left) is cropped (on RHS)
Citation: https://doi.org/10.5194/essd-2025-519-RC1 -
AC2: 'Reply on RC1', Hamish Pritchard, 16 Dec 2025
Many thanks Howard for your supportive review and helpful comments. Please see below our responses to the specific suggestions:
1) Fig. 2: Glacier names are small – perhaps put them with a white background??
Thanks, we have now increased the font size and added a grey background to help legibility.
2) Fig. 3: Clutter modelling appears to be working well. However, it is not clear that the clutter test (panel c) (vertical scale differs from other panels) – should it refer to the vertical scale differs for (panel d), rather than (panel c)? Or am I missing something?
We have now clarified this to read:
“…(panel d vertical scale differs from other panels)…”
3) Fig. 4: Use black font for (panel b) to make it visible
Agreed, we’ve now made this change.
4) Fig. 7: Make the lines around the “grey box” thicker to illustrate the central Khumbu Glacier
Also now done.
5) Fig. 14: Inset (bottom left) is cropped (on RHS)
Thanks, now corrected.
Citation: https://doi.org/10.5194/essd-2025-519-AC2
-
AC2: 'Reply on RC1', Hamish Pritchard, 16 Dec 2025
-
RC2: 'Comment on essd-2025-519', Thomas Teisberg, 11 Dec 2025
The authors present a dataset of radar data collected by helicopter surveys in the Khumbu Himal region. The work details the parameters of the radar system, the collection and processing of the radar data, and the process of picking the basal interface in the presence of significant sources of clutter. It also analyzes the resulting thickness data relative to prior surveys and modelling work.
This represents a valuable dataset for understanding water resources in the region and the careful analysis and processing of the data will make it easy for others to build upon this work.
A few minor suggestions:
Section 2.1.1: It would be useful to include the transmit power of the radar system
Figure 3 (d) is confusing to me. The Y axis should be shown separately for this subplot if it needs to be different from the others. It's also confusing that the areas marked as rejected have a red line through them apparently indicating a bed pick.
Section 3.2: I appreciate the careful analysis of resolution and uncertainty for the radar system and particular survey setting. I would suggest adding a note to the second paragraph to point out that the "vertical precision" refers to the ability to detect the location of a particular target and that ambiguities in picking which target is the basal interface could significantly exceed 2.8 m.
Data files:
It would be helpful to include timestamps in the CSV bed picks and GPS files. This is a region that will change rapidly. Hopefully more work continues to be done here. As efforts are made to unify data collected in the region, timestamps in every file make data collation and post-processing much easier
A readme file packaged with the raw data would be very helpful to help understand how to decode it.
GitHub repository:
I appreciate the effort you've put into creating nice documentation!
Please consider adding a license to your GitHub repository.
Citation: https://doi.org/10.5194/essd-2025-519-RC2 -
AC1: 'Reply on RC2', Hamish Pritchard, 16 Dec 2025
Many thanks Thomas for your thoughtful review and comments. Please find below our responses to specific suggestions.
1) Section 2.1.1: It would be useful to include the transmit power of the radar system
Good point. The actual transmitted power of full systems like this is difficult to determine and instead is typically specified as the transmitter voltage, which is known. We have therefore changed this sentence to:
“We used a wide band mono-pulse dipole radar with a transmitter that produces ±2000 V pulses at a centre frequency of 7 MHz (Pritchard, King et al. 2020) for this survey”
2) Figure 3 (d) is confusing to me. The Y axis should be shown separately for this subplot if it needs to be different from the others. It's also confusing that the areas marked as rejected have a red line through them apparently indicating a bed pick.
Thanks, yes, we now show the Y-axis for panel (d) separately and for clarity have changed the caption to read:
“…d) the terrain-corrected radargram with the initial bed pick bed (red lines), highlighting the sections that were subsequently rejected following the clutter test (panel c) (panel d vertical scale differs from other panels)... “
3) Section 3.2: I appreciate the careful analysis of resolution and uncertainty for the radar system and particular survey setting. I would suggest adding a note to the second paragraph to point out that the "vertical precision" refers to the ability to detect the location of a particular target and that ambiguities in picking which target is the basal interface could significantly exceed 2.8 m.
We have changed Section 3.2, paragraph 2 to read:
“…This implies that the practical vertical precision in thickness (assuming that the bed reflector has been correctly identified (see below)) is the combination in quadrature of these two precisions, i.e., ~2.8 m”.
The ‘see below’ refers to the next paragraph on accuracy (as opposed to precision), which notes that “Potentially more significant bias (e.g., tens of metres) could result from mistaking a non-bed reflection horizon for the bed, which we sought to avoid with our clutter modelling…”
4) Data files: It would be helpful to include timestamps in the CSV bed picks and GPS files. This is a region that will change rapidly. Hopefully more work continues to be done here. As efforts are made to unify data collected in the region, timestamps in every file make data collation and post-processing much easier
This is a good point, and in fact the bed-pick csv files have the date stamps encoded in the first column (“heli_line”) for each point, at daily resolution, e.g. the first 10 characters of entry 2019_11_06_F2_P93 are in format yyyy_mm_dd. The next column (“survey”) notes the approximate period of the survey in free text format, e.g., “Helicopter October/November 2019”, though the period is more precisely defined in the header metadata which include standardised date flags as, e.g., “# time_coverage_start: 2019-10-27” and “# time_coverage_end: 2019-11-06” (Please see the metadata held in the header of each csv file). Similarly for the GPS data, the date is encoded in the filename, e.g., the first 10 characters of the filename 2019_10_28_F1_coords.csv are also in format yyyy_mm_dd. In using this approach, we were governed by the metadata formatting policies of the Polar Data Centre.
5) A readme file packaged with the raw data would be very helpful to help understand how to decode it.
This is an understandable suggestion as the absence of a downloadable readme file in this folder is a little confusing, though we’re again constrained by the formatting policies of the Polar Data Centre. Instead, the metadata for the raw datasets are actually held with the main combined metadata record associated with our submission, available here: https://data.bas.ac.uk/full-record.php?id=GB/NERC/BAS/PDC/02073. Fortunately, there is a link to this on the page that serves the raw datasets themselves. When scrolling down on this page, the metadata for the raw data reads:
*Raw radar data *
We collected a raw radar data file for each survey flight. The filename format gives the date and time of file creation as yyyymmddhhmmss.hdf5, e.g., 20191103021438.hdf5.
File contents:
Each file contains two channels of radar data as recorded by the digitiser in the radar receiver system. Channel A is amplified, Channel B unamplified.
For each channel, there are multiple Traces, numbered sequentially (e.g., Trace00001). Each trace records a series of radar receiver signed voltages as a measure of returning signal strength.Channel metadata:
The total duration of each trace (and therefore its range, in number of samples) is given by the NoOfSamples parameter in the channel metadata. Each sample has a duration of 2 nanoseconds, hence a trace with 10152 samples is 20304 ns long (a range of around 1700 m in ice, or 3000 m in air).The 'SampleRate' parameter gives the timeout time (in seconds) for the receiver to wait to detect a returning pulse before assuming that triggering has failed and moving on to the next set.
Each trace represents the averaged voltages of the number of independent radar pulses given by the 'Stacks' parameter.
'Repeats' is an internal system parameter that sets the number of samples to store before writing to disk.
The GPS time is recorded along with the corresponding file start and end 'system' times for the onboard computer, to allow the system timestamps to be synchronised to the GPS data in post processing.
Trace metadata:
In each file, Trace00001 metadata shows the number format (Type) and the precise system date and time (yyyy,mm,dd,hh,mm,ss.ssssss). The 'GGA' string reports the GPS time at completion of this trace as hhmmss.s (e.g., 082520.8) and the GPS position at that time (ddmm.mmmmm, N/S, dddmm.mmmmm, E/W) (e.g., 2748.34269,N,08641.95129,E means 27deg 48.34269' N, 086deg 41.95129' E).
A new system time and GPS time and position is then stored for every 1000th subsequent trace, hence for trace 1001, 2001 etc. This is because GPS data could not be written to disk at the same rate as the trace creation. High frequency, high precision GPS times and positions were stored internally on the GPS, however, and matched to trace times in post-processing.6) GitHub repository: Please consider adding a license to your GitHub repository.
Good idea, we have applied the BSD-3 Clause license to the repository (https://github.com/bearecinos/radar-declutter/blob/master/LICENSE).
Citation: https://doi.org/10.5194/essd-2025-519-AC1
-
AC1: 'Reply on RC2', Hamish Pritchard, 16 Dec 2025
Data sets
Raw and processed helicopter-borne radio-echo sounding ice thickness data from the glaciers of the Khumbu Himal, Nepal (2019) (Version 1.0) [Data set] H. Pritchard et al. https://doi.org/10.5285/e39647f5-fb72-4d16-acbd-9784ed2167b8
Model code and software
Clutter model B. Recinos et al. https://zenodo.org/records/15488954
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 1,113 | 72 | 36 | 1,221 | 34 | 44 |
- HTML: 1,113
- PDF: 72
- XML: 36
- Total: 1,221
- BibTeX: 34
- EndNote: 44
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
The manuscript presents novel airborne radar surveys in the Khumbu Himal that are a huge step forward to map ice thickness and bed topography. These measurements improve the accuracy of ice thickness distributions, which are essential to improve modeling of present and future ice loss in High Mountain Asia.
I recommend publication.
I just have just a few suggestions/comments:
Fig. 2: Glacier names are small – perhaps put them with a white background??
Fig. 3: Clutter modelling appears to be working well. However, it is not clear that the clutter test (panel c) (vertical scale differs from other panels) – should it refer to the vertical scale differs for (panel d), rather than (panel c)? Or am I missing something?
Fig. 4: Use black font for (panel b) to make it visible
Fig. 7: Make the lines around the “grey box” thicker to illustrate the central Khumbu Glacier
Fig. 14: Inset (bottom left) is cropped (on RHS)