the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 28 Jul 2026
GLOBESINK: A global climatology of sinking organic carbon flux and particle size from optical backscattering measurements
Abstract. Sinking particles play a major role in the global carbon cycle, driving long-term carbon storage in the ocean and providing the primary food source for many deep ocean ecosystems. However, the global flux of sinking organic matter to the deep ocean is poorly constrained, due to the difficulty of measuring sinking particles at global scale. Here we present a global, gridded monthly climatology of size-fractionated optical backscattering by particles ranging from 1–800 µm, derived from the Biogeochemical Argo network of profiling floats. We leverage these data to estimate particulate organic carbon (POC) concentrations and sinking fluxes, as well as area-weighted mean particle diameter and the number concentrations of particles in three size classes: 200–400 µm, 400–800 µm, and >800µm. Each estimate of carbon concentration and flux is accompanied by an estimate of uncertainty due to the empirical relationships used to convert from backscatter, and each quantity derived from backscattering from one or more large (>200 µm) size class is accompanied by an estimate of precision due to random encounter with rare, large particles. For reference, climatologies of the following other parameters measured by the same floats are included: temperature, salinity, nitrate, pH, oxygen, and Chlorophyll a concentration. All climatologies share the same regular grid, with 4° latitude by 8° longitude resolution and spanning 0–2000 m depth, with vertical resolution varying from 10 m to 300 m. The raw climatology, containing gaps in the months, coordinates, and depths without data, is accompanied by a spatially smoothed and interpolated climatology that fills in these gaps, except for the Arctic and areas of near-permanent sea ice around Antarctica. The estimates of POC concentration and particle size are presented as is, without validation, but the estimates of sinking POC flux were validated against a global dataset of independent measurements, finding a mean relative bias of 1.2 and an r2 of 0.57 on a logarithmic scale.
- Preprint
(5364 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 21 Oct 2026)
- CC1: 'Comment on essd-2026-566', Nathan Briggs, 04 Sep 2026 reply
-
RC1: 'Comment on essd-2026-566', Luke Marsden, 15 Sep 2026
reply
Overview
The paper describes GLOBESINK as a global monthly climatology derived from BGC-Argo backscattering measurements, with gridded POC, particle-size and related variables. The manuscript itself is generally thorough and well written, though the readability could be improved and some clarity could be added in some places. The impact of the dataset itself is potentially significant, and I would expect it to be widely used. Aggregated monthly climatology datasets such as this one play a significant role in increasing the reusability of data, since finding and aggregating data requires significant time and expertise. However, the impact of the dataset could be increased by improving how the netCDF files are structured, improving the metadata, and republishing to a different data centre that makes the data more easily findable and reusable. The code should also be openly available, not simply “available upon request”.
About the review
I have focused this review on areas within my expertise, particularly data publication practices, metadata, and clarity of processing and QC. I am not an expert in POC flux estimation or flux-validation methodology.
I have categorised my comments as “recommendations” or “suggestions”. My preference is that all the “recommendations” are addressed before the manuscript is published. The “suggestions” may be my personal preferences or minor comments that the authors or editors are welcome to disagree with.
Manuscript
The numbers used at the beginning of each bullet point refer to line numbers throughout this review.
Recommendations
- Throughout section 2, I do not have an intuitive feel for how aggressive the QC process is. Figures 1-3 are useful in presenting examples of this, but it is difficult to gauge how representative these figures are. I assume these instances were selected to portray particular examples. This could be addressed by including statistics of what percentage of profiles or floats have been affected by each stage of the processing, or by providing further context on why certain thresholds were selected. For example, in 2.2.2., it would be interesting to quantify how much data includes values above the prescribed thresholds.
- 67 - 99: I assume that these steps were applied sequentially and in the stated order, but this is not stated anywhere. This is a thorough enough explanation of all the steps, but I think a flow chart depicting the data processing would be a useful addition to improve readability. This should begin from the data source, include all steps, right through to the final datasets.
- Table 2: It would be good to know the total number of profiles processed for context here. I am more interested in the percentage of profiles removed than the absolute numbers.
- Figures 1-3. These are useful additions to show the effect of the automatic and QC routines. However, they should be referred to at relevant places in the text to instruct the reader when to refer to them. Furthermore, they could be annotated to highlight the changes between the different stages - perhaps using the QC flags introduced in Table 2? Whilst some changes are obvious, in other cases it takes some time to see the changes between successive processing stages. E.g. Figure 3 between raw and auto QC. Annotations would be beneficial here.
Suggestions- A general comment. The readability would be improved by referring to the figures and tables throughout the text.
- 16: Why is “chlorophyll a” capitalised? It is not capitalised elsewhere in the manuscript.
- 21: What do you mean by the mean relative bias? Globesink - obs / obs? Or globesink / obs? Maybe my misunderstanding is due to my ignorance but this is not clear to me.
- 51: Given that the “optical backscattering spikes” particle size fractionation method is fundamental to the dataset presented, I would expect the method to be described briefly within this manuscript, rather than only referring to earlier publications.
- 63: FTP should be all capital letters.
- 79: Consider using bullet points for this?
- 92-93: Bullet points missing here? Or perhaps should be formatted as equations as done from lines 215 onwards?
- 185: “Note that the matchups do not need to be from the same year”. Okay, but are there are temporal limits implemented here? This is not clear.
- 195-196 & Figure 4: The differences in the dataset pre and post alignment are quite striking in some cases. How confident are the authors in the reliability of the aligned data? Could this confidence be quantified and stated somehow? The authors mention that only the post-alignment data are published. It will be important to include quality flags and uncertainty in the data, following best practices. I will describe how to do this in the ‘Data’ section.
- Section 2.7. I see that both interpolated and “uninterpolated” data have been published, but I don’t think this has been mentioned. It would be good to signal at what stage in the processing the “uninterpolated” data have been published. Perhaps the flow chart suggested earlier could help with this. For interpolated datasets, it is also important to include flags in the published data to describe which samples are interpolated.
- 278: Tracked changes on?
- 279, 282: Should be a space between the value and the units. This has not been done consistently throughout the manuscript, and I have not checked every instance.
- 309: A small question to the authors. Does treating 8 degree longitude and 4 degrees latitude as equidistant yield suitable results near the poles? I assume this was investigated during development, I am just curious.
- 314: Chlorophyll a is capitalised again. It is not capitalised on lines 58 or 65. I am no expert in when this should be capitalised and not, but make sure you are consistent with whatever the rules are here.
- 324: Of every year or of one particular year?
- Figures 7, 8, 9, 10, 11, 12: Which year is depicted here?
- 392: Only the year should be in brackets for this citation. /cite instead of /citep
- 482: I understand that it is difficult to commit to time intervals for these periodic updates, but some ballpark estimates could be useful. I suspect you do not plan to publish updates monthly. Annually? Every few years?
Data
Recommendations
- I would advise against publishing data to Zenodo. Whilst Zenodo is commonly used, it limits how discoverable data are. Zenodo follows no standards for discovery metadata (e.g. ISO 19115, GCMD DIF, DCAT, EML, schema.org), and has limited metadata requirements. Data are also not reviewed before publishing. Nor will they be curated over time in the future. It is difficult for someone to search for data that they are not already aware of. I invite you to try speculatively searching for data on Zenodo yourself. A good data centre would include the possibility to filter based on the geospatial and temporal limits of the data, some standardised keywords, etc. This is not possible with Zenodo. Metadata should also be exposed through platforms that support standard metadata harvesting mechanisms (e.g., OAI-PMH, OGC-CSW). Zenodo does not provide this either. These standards allow aggregators to provide unified access to data published in multiple data repositories, regardless of where the data are stored physically. Since it is not practical for individuals to search through all data repositories for interesting data, aggregators have a key role to play in simplifying data discovery. The truth is that the data ecosystem around this does not exist at scale yet, but is being built, and when publishing data we should consider what is best for usage in the future, not just today. Since you are based on the UK, BODC would be a good choice https://www.bodc.ac.uk/ . BODC also supports OPeNDAP, which can be used to stream data over the internet instead of requiring direct downloads. This could be useful as the input for your data visualisation software that you linked to in a comment. If the data are updated later, the data URL could be the same (depending on how you publish future versions) meaning that users will not have to redownload, nor update their code, to access the latest versions.
- The data themselves need to be cleaned up. The metadata are not sufficient for machine readability. I will outline the changes that should be made before providing the CDL of what the data could look like
- All variables should include a standard_name where one exists. https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html
Where a suitable CF standard name does not exist, new ones can be proposed - the expansion of vocabularies is a community effort! But if this is out of the scope of this work, make sure every variable has a long, descriptive long_name as a minimum. The variable lookup table and the “source_variable_name” attribute should not be necessary if standard names are used. Generally speaking it is good practice to encode everything needed to understand and use the data within the file itself, rather than relying on external files. CF-NetCDF supports this.
- Similarly, the discovery metadata is far too limited. You should adhere to the Attribute Convention for Data Discovery (ACDD) documented here: https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3 . These recommendations are a bit outdated and leave a lot of degrees of freedom. I like the requirements and recommendations listed here: https://adc.met.no/submit-data-as-netcdf-cf There are examples of how to encode each attribute at the bottom of the page.
- Time should be encoded as shown here: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#time-coordinate-variables But using the units ‘months since YYYY-MM-DD.
- The coordinate bounds for each bin can be encoded using cell bounds, see here https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#cell-boundaries
This might also be applicable for the POC_bbp_ratio variables and other such variables where bounds are encoded.
- The processing flow is well described in the manuscript, but this provenance information should also be encoded within the datasets themselves. In the CF-NetCDF files, this can be encoded in the ‘history’ global attribute.
- Flags should be used to encode things like data quality. This is particularly useful for encoding which values are interpolated.
- https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#flags
- Include a variable attribute coverage_content_type for every variable with values taken from this list: https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3#Highly_Recommended_Variable_Attributes
- Use the variable attributes valid_min and valid_max to encode defined limits of the variables. For example, you mention in the manuscript that values above certain limits have been discarded: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#attribute-appendix
- You should use the variable attribute ‘ancillary_variables’ to encode how variables are related to each other. Examples here: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.13/cf-conventions.html#ancillary-data For example, n_bpp is an auxiliary variable of the bbr, bbs, bbm… variables I assume.
- Is ‘double’ format really necessary? Usually float32 is sufficient, but depends on the precision required.
- Encoding uncertainty in CF in a standardised way is under development, likely to be included in the next version. I advise that you encode your uncertainties following the proposal linked here: https://github.com/cf-convention/cf-conventions/issues/660#issue-5029532378 Please download and view the cf-conventions.html file provided by davidhassel and jump to section 10. You will find examples of how to encode uncertainty here, which will be useful for your ‘precision’ variables.
Code
Recommendations
- The data should be openly available for the sake of both reproducibility and transparency. I recommend the data are uploaded to a public GitHub repository. Ideally, you should also publish a snapshot of the repository containing the version of the code used in this manuscript. You can publish this code to Zenodo. There are tutorials online on how to do this quite quickly, e.g. https://www.youtube.com/watch?v=HZ6m8oxwvig
-
RC2: 'Comment on essd-2026-566', Anonymous Referee #2, 03 Oct 2026
reply
Briggs et al. (2026) present an interesting and potentially valuable effort to derive a global climatology of sinking particulate organic carbon (POC) flux from BGC-Argo optical backscattering observations. The authors compile BGC-Argo measurements collected globally between 2010 and 2025 and apply an extensive quality-control procedure before partitioning the bbp signal, following and further developing the approaches of Briggs et al. 2011 and 2020, into several operational particle fractions, including a refractory background component, small, medium, large, and extra-large (>800 µm) particle fractions. The processing further includes an alignment of deep bbp among floats and the definition of a refractory small-particle pool, after which size-dependent POC concentrations and prescribed sinking velocities are combined to estimate sinking POC flux. These estimates are then aggregated into a global monthly climatology. The resulting flux product is evaluated against a global compilation of independent POC flux measurements, supplemented by observations from the HOT and BATS time-series sites. Overall, the study is ambitious and addresses an important observational gap in the global carbon cycle by exploiting the rapidly expanding BGC-Argo archive.
I personally found the results quite interesting and took some time to explore the dataset in Zenodo and the visualization website. However, before applying this dataset in the next-step research, I have several questions and comments that I would appreciate the authors addressing.
First, the statement in the Abstract that the sinking POC flux estimates were validated against “independent measurements” needs clarification. Section 4.1.4 notes that the methodology was finalized after examining the validation results, while pre-2010 K2 observations were excluded because they showed a strong low bias. Were these data removed based on independent quality considerations, or because they disagreed with the GLOBESINK estimates?
If methodological choices and data screening were informed by the same validation dataset, Figure 14 should not be considered fully out-of-sample validation. I therefore suggest showing how the validation statistics change when the excluded K2 data are retained, ideally reporting results both with and without these observations. This would help readers better assess the robustness of the validation and the appropriate use of the dataset.
Second, I have some concerns about the deep bbp alignment. Figure 4 shows that the fields change quite a lot before and after alignment, and using a 2000 km seems quite aggressive. This approach effectively assumes that differences among deep bbp measurements mainly reflect sensor offsets rather than real water-mass or regional biogeochemical variability. Is there independent evidence supporting this assumption? It is particularly concerned in like western boundary, fronts, the Mediterranean–Atlantic transition, and other water-mass boundaries, where 2000 km can span strong gradients. Would an alignment based on water-mass properties, rather than geographic distance alone, be more appropriate? If the authors retain the 2000 km approach, it could be better: first, please consider also releasing the pre-alignment data, which would be very useful for users interested in regional or smaller-scale applications; second, a simple sensitivity test using different alignment (like 500, 1000, and 2000 km) would help show how strongly this choice affects the resulting climatology and flux estimates.And, particles > than 800 µm are not included in the flux calculation. I therefore wonder whether this should already be stated clearly in the Abstract when referring to the “total POC flux.” If the authors wish to retain this wording, it would be helpful to provide at least a quantitative estimate of the potentially missing >800 µm contribution, rather than mentioning only in the limitations that this fraction may sometimes be important.
Line-by-line points:
L61: If space and the number of figures allow, adding a simple methodological workflow or pipeline figure in the Methods section would help readers quickly understand the overall processing steps.
L120–125: The stated thresholds for 200, 400, and 800 µm are 1, 4 and 16 *10-4, respectively. However, the upper threshold used for bbm is subsequently given as 8*10-4. Is this a typo, or was 8*10-4 actually used in the processing? Please clarify.
L141: the number of bbp data points saw (was) also counted
Figures 1–3: The captions refer to “raw bbs” and bbl, whereas Section 2.4 describes the visual QC as being applied to bbrs and bbml_raw. Please check whether the variables shown and described in the captions are correct.
Figure 6: The caption states that 16 years of August observations are possible between 2010 and 2025. However, the dataset only extends through May 2025, so August 2025 is not included. Should this be 15 possible years (2010–2024)?
Figures 11–12: The lower-mesopelagic flux is defined as 800–975 m in Figure 11 but 700–975 m in Figure 12. Is there any difference?
L396: DYFAMED site in the Mediterranean (43.4277°W (N), 7.2522°E)
L476: they are best used as a self-consistent, indicative climatologies
Citation: https://doi.org/10.5194/essd-2026-566-RC2
Data sets
GLOBESINK monthly POC flux and particle size climatology Nathan Briggs et al. https://doi.org/10.5281/zenodo.19558504
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 330 | 167 | 137 | 634 | 176 | 131 |
- HTML: 330
- PDF: 167
- XML: 137
- Total: 634
- BibTeX: 176
- EndNote: 131
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
In order to make this dataset more accessible and potentially aid review, we have developed a web-based data viewer. The viewer can be accessed here: https://natembriggs.github.io/globesink-viewer/ . The viewer code is publicly available here: https://github.com/natembriggs/globesink-viewer . We hope that potential users find this tool useful.