This paper is a re-submission of an earlier paper that describes a potential problem in the SCRIP high-order conservative remapping algorithm that requires a correction. This revision has a slightly better understanding of the  underlying algorithm but still has some significant problems and the testing appears to be incorrect.

As in the first submission, the author attempts to derive a flux distribution from a Taylor series in section 2.1. As I wrote in the first review, this derivation is incorrect and the author should not attempt to derive this from a Taylor series. In particular, the constraints in equations 4,5 do not follow uniquely from 3 without additional assumptions. For example, it cannot always be true that a flux evaluated at c_n will be the mean. DK87 actually makes this point in the sentence referenced by the author in which DK87 says it is a Taylor series "only if the mean is _assumed_ to be located at the centroid". Instead, both DK87 and J99 use the distribution of the flux as

[can't seem to upload an equation image but latex form is: f_n = \overline{f}_n + \nabla_n f\cdot({\vec{r}} - \vec{r}_n) ]

which is a construction that automatically satisfies Eq 1 as long as r_n is the centroid so that the second term integrates to zero.  By making the leap from his eq 3 to the constraints in 4,5, the author is essentially making the same assumption that the original DK87 and J99 approaches have done by construction, so it's better to start with that anyway and state it as a common constructions that satisifies eq 1.  The only reason a Taylor-like expansion is used is so that DK87 can claim the distribution is second-order as long as the gradient is first-order. The author should simply present the distribution as is done in DK87 and J99 to make the assumption explicit and avoid the incorrect derivation in 2.1.

Section 2.2, line 132, the author calls phi_c, theta_c a reference point and mentions that J99 calls it a centroid. In fact, this is still required to be the centroid and it is not an arbitrary reference point.

The actual demonstration of the issue with longitudinal weights appears correct and the pivot fix seems reasonable as shown in Fig 1.

An additional proposed fix around line 250 should be removed and the C Scheme later also removed. There is a reason why metric terms are included in coordinate system transformations and relevant operators. Removing the cos(lat) weighting in this fix is likely to introduce significant error in more general meshes, especially near the polar singularities.

The biggest problem with the current paper is in the testing section. A couple things are simply oversights: The RLL mesh description in line 337 is wrong and needs to be corrected. Also, they refer to a Scheme O, which I assume was the original formulation which they have now named Scheme N in the previous section. The author needs to pick a consistent name across the sections.

More seriously, most of the tests use a high-res mesh as the source and perform remaps to coarser meshes. The high-order terms only impact a coarse-to-fine remap so these tests need to use the coarse meshes as the source mesh and the finer mesh as a destination. The fine-to-coarse operation in the tests presented are an averaging and remove most of the impact of the high-order terms. Indeed, in many cases where the overlap is complete, the high-order terms should integrate exactly to zero.

The global offset case does not fix the multi-value longitude issue. It only shifts the problem to a different longitudinal branch cut. So the high errors in these tests are more likely an incorrect correction of the multi-value longitude. If a 2-d map of the solution was shown, I would guess all of the errors would be along a branch cut in the domain and are separate from the error in the formulation that this paper is trying to address. In general, it would be a good idea to show a 2-d greyscale or colormap of the resulting field after a remap in addition to showing the global error norms to demonstrate there are no such artifacts. It's possible they would still not show up in these cases due to the fine-to-coarse averaging, but they would absolutely show up in a coarse-to-fine remap.

In the end, there are many issues with SCRIP, including probably the modification in this paper, but this paper requires significant revision to make that case.

This manuscript revisits the analytical foundation of the second-order conservative remapping scheme presented in Jones (1999, J99). The authors identify an inconsistency in J99’s longitudinal term and propose a corrected formulation that resolves the issue. This topic is of continued interest, and clarifying the original derivation is potentially helpful for users and developers of legacy tools derived from J99.

At the same time, I believe the manuscript would benefit from substantial revision to improve clarity of motivation, definitions, and scope. Many statements are broadly phrased and may give readers the impression of general geometric validity, even though the proposed corrections remain tied to the coordinate-specific structure of regular latitude–longitude grids. A clearer presentation would greatly strengthen the manuscript’s impact and accessibility.

I offer the following comments in the hope that they will assist the authors in presenting their valuable observations in the clearest possible way.



1. Clarifying the motivation and historical context

The manuscript motivates its analysis by stating (Lines 29–30) that J99 “extends the DK87 theory to spherical coordinates, offering an approach that can be applied to any type of grid on a sphere.” This wording may lead some readers to infer that J99 handles arbitrary spherical geometry correctly, whereas in practice:

• SCRIP, which implements J99, computes weights using line integrals in latitude–longitude space,
• and treats edges as straight lines in the coordinate chart,
• rather than as great-circle arcs or geodesic boundaries on the sphere.

Thus, J99 is applicable to any grid in the sense of an algorithm that can be run on arbitrary inputs, but it does not necessarily handle geometric properties of arbitrary spherical grids appropriately. A more precise description of this distinction may strengthen the manuscript.

Similarly, the discussion of Climate Data Operators (CDO) on Lines 34–40 might be reconsidered. The phrase “have once included” is somewhat ambiguous, and current CDO implementations no longer rely on the SCRIP-based second-order scheme. Today, CDO’s first-order conservative remapping is based entirely on YAC. A second-order scheme was also planned, again using YAC, but has not been deployed so far because the available YAC implementation is parallel (MPI-based), and porting it into CDO’s primarily serial remapping framework has turned out to be technically nontrivial. This decision was driven by software-engineering constraints, not by any concerns about YAC’s geometric formulation. Thus, citing CDO as an example of active reliance on the J99 formulation may be less compelling than intended.

In addition, more recent work such as the GECoRe paper provides a geometrically exact remapping framework between regular latitude–longitude and cubed-sphere grids, together with closed-form expressions for the relevant integrals (e.g. its Appendix A). It would be helpful if the authors could clearly position the present manuscript relative to such geometry-exact approaches — for example, by explaining that their contribution is a correction within the J99/SCRIP analytical framework, rather than an alternative to fully geometric methods like GECoRe, and by briefly discussing what specific gap or practical advantage this correction offers in that broader context.

Nevertheless, because J99/SCRIP remain historically important and are still used in legacy workflows, there is value in clarifying the original analytical inconsistency. Presenting this as a pedagogically motivated correction, and clearly situating it with respect to later developments such as GECoRe and geometry-aware couplers (YAC, TempestRemap, etc.), may resonate better with modern readers.



2. Clarifying terminology and coordinate dependence

(a) Use of “spherical coordinate system”

At Line 31, the manuscript refers to “the spherical coordinate system,” but the meaning of this term is not formally defined. In practice:

• There is no unique “spherical coordinate system”; multiple conventions exist.
• Modern conservative remapping frameworks (e.g., YAC, TempestRemap) deliberately avoid relying on latitude–longitude formulas and instead express all geometry in 3D Cartesian coordinates, ensuring rotational invariance.

The manuscript would be stronger if it were clarified early on that the derivation is performed entirely within the latitude–longitude coordinate chart, and that this choice is intentional.

(b) Inner product discussion (Lines 112–113)

The sentence

“The inner product on spherical coordinates is not simply a component-wise product as in Cartesian coordinates…”

may inadvertently suggest a misuse that most current geometry-aware remapping codes already avoid. Since $\theta$ and $\phi$ are angular parameters rather than Cartesian axes, they are never combined using componentwise Cartesian logic in modern implementations.

If the intention is to emphasize that the gradient operator in spherical coordinates includes metric factors and basis-vector rotation, it may help to express this more precisely. Equation (8) can in fact be written cleanly in terms of 3D vectors, making all inner products well-defined and coordinate-invariant.

(c) Misuse of the term “centroid”

Throughout the manuscript — including in the title — the term centroid is used without a consistent definition. Equation (7) defines the geometric mass centroid of a cell, which lies inside the sphere and might then need to be projected outward onto the spherical surface. However, none of the three schemes introduced later in the paper (Scheme N, Scheme P, or Scheme C) actually computes this geometric centroid (the interior point). Both the “pivot” point $(\theta_p,\phi_p)$ and the “centroid” point $(\theta_c,\phi_c)$ are coordinate-based constructions rather than true geometric centroids on the sphere. Referring to these quantities as centroids is therefore potentially misleading for readers who interpret centroid in the strict geometric sense (i.e. $\mathbf{c}_{\mathrm{geo}} = \tfrac{1}{A}\int_A \mathbf{x}, dA$, which again lies inside the sphere).

The authors might either need to justify why the flux formulation would remain valid if the reference point were taken to be the geometric centroid (which lies inside the sphere), or explicitly explain that this interior centroid must first be projected back to the spherical surface (e.g. by normalization) if a surface reference point is required.

(d) Closed-form expressions and relation to GECoRe

It may help readers if explicit closed-form formulas for the reference points in Schemes N, P, and C are included, especially since the manuscript’s title centers on “centroids.”

In this context, it may also be useful to refer to the GECoRe paper, which provides closed-form expressions (and derivations) in its Appendix A. The GECoRe paper also presents a geometrically exact regridding solution between regular latitude–longitude and cubed-sphere grids. It would be beneficial to include a brief comparison between the present manuscript and the GECoRe approach — for example, by pointing out the potential gap between the two methods and discussing the potential benefits of the present work relative to GECoRe.

3. Scope and generality

Two limitations of the current formulation deserve clearer acknowledgment:

(a) The corrections apply only within the coordinate framework of J99/SCRIP

Because SCRIP uses a latitude–longitude planar approximation, the corrected formulas presented here remain applicable only to the same class of structured grids. The method does not extend to arbitrary, non-uniform unstructured grids. A brief comment on this limitation may prevent misinterpretation.

(b) The proposed centroid/pivot definitions are meaningful only for regular RLL grids

Area-weighted averages of $\theta$ and $\phi$ (even with a $\cos\theta$ weight for longitude) do not correspond to geometric centers for general spherical polygons. Their interpretation becomes ambiguous when cells are skewed, large, or irregular.

These points do not invalidate the proposed correction — which is internally consistent within the J99 framework — but clarifying scope will improve the precision of the manuscript.

Minor Comments

• Line 48: The phrase “serious damage to the remapping result” would benefit from a concrete explanation or example illustrating the numerical consequences.
• Some expressions, such as those involving coordinate shifts ($\phi_{\text{ofs}}$), could be clarified to ensure readers understand exactly how invariance is being tested.
• The manuscript might benefit from reorganizing Sections 2.1–2.2 to distinguish clearly between the flat Cartesian case and the spherical-coordinate case.

Reference: