Review of: “A global monthly 3D-field of seawater pH over 3 decades: a machine
learning approach” by G. Zhong et al.; submitted to Earth System Science Data
First of all, I would like to thank the authors for the careful and thoughtful responses to my comments
and suggestions. I believe their revisions have improved the manuscript, and the new details make it
clearer to read. However, there are still some issues that deserve to be addressed before the manuscript
can be published.
Specific points to raise :
- To avoid confusion regarding temperature, I suggest adding the following clarification: "Here, we
present a monthly four-dimensional 1°×1° gridded product of global seawater pH at total scale and insitu temperature (without standardization to 25°C)."
This will ensure that readers understand the product focuses on pH measurements, while avoiding any
implication that it is also a temperature product. I recommend adding this clarification at line 60 and
elsewhere when necessary.
- The use of sin(Lat) as a predictor is questionable since latitude is not circular.
Response: This normalization method was inspired from previous research, such as Denvil-Sommer,
A., et al. (2019), where they also normalized latitude and longitude to radians using sine and cosine
transformations. Also, we have corrected the description name in Table 1 to "Sine of (latitude ·
π/180°)", "Sine of (longitude · π/180°)", and "Cosine of (longitude · π/180°)". As we used the "sind"
and "cosd" function (sind(latitude) equals sin(latitude · π/180°)) in MATLAB, the original description
was misleading and has been corrected.
The use of sin(Lat) as a predictor remains questionable, as latitude is not a circular (or periodic)
variable. The response mentions that this normalization method was inspired by previous research,
such as Denvil-Sommer et al. (2019), and the correction to the description in Table 1 has been made.
However, I still have concerns for the following reasons:
• Sine and cosine functions are typically applied to periodic variables, such as longitude or day of
the year, where values "wrap around." Latitude, on the other hand, is not periodic—lat = -90° is
not equivalent to lat = 90°.
• Furthermore, the expression sin(lat · π/180°) seems inappropriate, as radians conversion should
account for the full range of latitude values. If anything, it would be sin(lat · π/90°), but even
this is not ideal for latitude.
Given these issues, I maintain that latitude is not a suitable candidate for inclusion via sine and cosine
transformations.
- Clarify how depth is used as a predictor and whether it corresponds to the depth of retrieval of the
output or if the FFNN estimates X values for X depth levels.
Response: Thanks for the suggestion. Depth was used in the same way as latitude or time-related
variables in Table 1. The sample depths of GLODAP measurements were input into FFNNs during the
training process, and the depths of 41 depth layers defined as target output layers were input into
FFNNs during the interpolation process to generate a product covering 0-2000m. The description has
been added in the 2.1 section as the following: "Temporal and spatial sample information, including
latitude, longitude, depth and sample time, was also used as supplementary variables. Latitude and
longitude were normalized to radians using sine and cosine transformations, to present connected
sample position information. The spatial sample position and time information of GLODAP
measurements were input in the training of FFNNs, and the spatial position and time of defined 1° and
monthly product grids were input into FFNNs during the interpolation process to output a gridded
product."
Thank you for the explanation regarding how depth is used as a predictor in the FFNN models.
However, I am still unclear as to why pressure (pres) is not systematically included as a predictor in
every FFNN (as seen in Table 2). Given that depth-related information is a critical factor, especially in
oceanographic models, it seems logical that pres would be consistently used alongside depth.
Additionally, this raises the broader question of why other key spatial-temporal predictors, such as
longitude, latitude, and time, are not always systematically included as inputs in the FFNNs. It's unclear
why time, in particular, is only integrated in some models and not others, given its fundamental
importance in understanding temporal variability in the data.
I suggest providing a clearer rationale for the selective use of these variables and ensuring that key
predictors are consistently applied across all FFNNs, or explaining why their inclusion is sometimes
omitted.
- Adding a column to Table 1 to indicate which process each variable is associated with would be
informative.
Response: Thanks for the suggestion. The related processes have been added in Table 1 as the
following:
Thank you for incorporating the suggestion to add the related processes to Table 1. However, I believe
further clarification is still needed for some variables. Specifically, variables like PAR, KD, RRS, and
Ta/b may also be associated with the biological production of organic matter, as they are crucial in this
context. Ensuring that these variables are linked to biological processes in the table will provide a more
complete understanding of their roles. I don’t think that ‘Supplementary for lacking interannual
variability of other variables, or potential correlation with unclear process affecting pH’ is relevant for
these variables.
-Line 191: The paragraph is unclear. The statement, “Therefore, the uncertainty of our pH product was
directly estimated from the FFNN pH predicting errors, instead of synthesizing the inherent uncertainty
of each used predictor product,” needs further clarification. How was this done?
Response: As described in equation (2), the uncertainty was estimated from local pH value and pH
predicting error in the corresponding province. For the uncertainty in certain grid, we first convert pH
predicting error in the corresponding province into difference of [H+ ], by logarithm transfer of
predicted and GLODAP measured pH and then calculating RMSE. Subsequently, the RMSE of [H+]
was transferred to pH uncertainty based on the local pH value. 𝜎 = −log ଵ(10ି୮ୌ 𝑅𝑀𝑆𝐸 బ − [ୌశ])
−pH where RMSE[H+] was the RMSE of [H+ ] converted from FFNN pH predicting error in each
vertical layer and in each biogeochemical province. pH0 was the local predicted pH value in the grid
that uncertainty was estimated. Due to missing inherent uncertainty of particular predictor product,
estimating uncertainty from inherent uncertainty of used predictor products was unfeasible.
Thank you for the detailed response, but the explanation is still unclear regarding how the method
described provides local uncertainties. Specifically, the statement “the uncertainty of our pH product
was directly estimated from the FFNN pH predicting errors, instead of synthesizing the inherent
uncertainty of each used predictor product” remains ambiguous.
While equation (2) describes converting pH prediction errors into RMSE for [H+] and then back to pH
uncertainty, it’s still not clear how this process provides uncertainty estimates at a local (grid-specific)
level. Could you provide more detailed clarification on how this method operates for each grid and how
the local predicted pH value (pH ) factors into the uncertainty calculation? Additionally, a more ₀
intuitive explanation of why inherent uncertainty from each predictor was not feasible would help
clarify this point for readers.
- Moreover, it would be interesting to add comparison against qualified pH data from BGC-Argo
dataset.
Response: Thanks for the suggestion. Comparison of global scale trend has been added in Table 4. The
BGC ARGO pH data qualified by IMOS has been added in the validation section. Different from the
validation results based on the GLODAP dataset, the RMSE between FFNN pH and BGC ARGO pH
data is higher in the deep ocean. Only the bias between FFNN pH and BGC ARGO pH data tends to
increase with depth in most basins. In contrast, greater biases between FFNN pH and GLODAP pH
occur mainly in the surface layer. Especially in the Southern Ocean, the bias between FFNN pH and
GLODAP pH is nearly zero below 1000 m, notably lower than biases between FFNN pH and BGC
ARGO pH data ranging from 0.053 to 0.076. This may be primarily attributed to the discrepancies
between GLODAP dataset and the BGC ARGO dataset in the deep ocean, as our product was based on
GLODAP dataset and small biases with GLODAP pH were observed in the deep ocean.
Thank you for incorporating the comparison with the BGC-Argo pH data into the validation section.
However, there are several important points that still need to be addressed:
• BGC-Argo should be written with proper formatting (i.e., "BGC-Argo," not all caps for "Argo").
• It would be valuable to include a reference to the BGC-Argo dataset, such as Claustre et al.
(2020) https://www.annualreviews.org/content/journals/10.1146/annurev-marine-010419-
010956.
• As it is mentioned that only data qualified by IMOS were used, does this imply that the
validation was limited to the Southern Ocean and data from CSIRO? If so, the validation is not
truly global. For a more comprehensive validation, I suggest using data from all DACs (Data
Assembly Centers), accessible via the GDACs (Global Data Assembly Centers). There are two
GDACs available: US GDAC and France Coriolis GDAC (https://argo.ucsd.edu/data/data-fromgdacs/).
• A geographical map of BGC-Argo pH profiles should be included to visualize where the
validation was performed.
• Specific details regarding the data used in the validation should be provided. Only delayedmode pH-adjusted data with QC (Quality Control) 1 applied should be used for a robust
comparison.
• Additionally, BGC-Argo should be acknowledged in the acknowledgments, following the
guidelines here: https://argo.ucsd.edu/data/acknowledging-argo/. |