the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 12 Jan 2026
Evaluation of preCICE (version 3.3.0) in an Earth System Model Regridding Benchmark
Abstract. In Earth System Modeling (ESM), meshes of different models usually do not match, requiring data mapping algorithms implemented in coupling software. Valcke et al. (2022) recently introduced a benchmark to evaluate such algorithms and compared implementations in four specialized ESM couplers. In this paper, we assess preCICE, a general-purpose coupling library not limited to ESM, using this benchmark and compare our results to the original study. The generality of preCICE with its larger community offers potential benefits to ESM applications, but the software naturally lacks ESM-specific solutions. We describe necessary pre- and postprocessing steps to make the benchmark tangible for preCICE. Overall, preCICE achieves comparable results; using its radial basis function mapping yields significantly lower errors.
- Preprint
(5362 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on egusphere-2025-5618', Moritz Hanke, 14 Jan 2026
-
AC1: 'Reply on RC1', Alex Hocks, 30 Mar 2026
We want to thank the reviewer for the extensive comments. Many interesting discussions are raised, most of which go significantly beyond the scope of the manuscript, however. The idea of the paper is not to do a full comparison of the general-purpose coupling library preCICE to domain-specific ESM couplers. We even believe that a fair comparison is close to impossible to achieve. Instead, the paper focuses on a single aspect: accuracy of data mapping.
To this end, we took the benchmark introduced by Valcke et al. (2022) and its results and supplemented them with results for preCICE. Our goal was to stick as closely as possible to the description, the notation, and the presentation of results of the original benchmark to make our manuscript easy to digest for readers familiar with the original work. Besides the actual results, the interesting aspect (for us) is the fact how meshes and data mappings are handled differently in ESM couplers and preCICE, which we tried to explain thoroughly. We believe that both sides can learn something from these differences.
Out of the scope are:
- Evaluation of the runtime of data mapping, similarly to the original benchmark. Performance of preCICE is analyzed in other publications [a1, a2, a3]. A fair overall comparison would also be very intricate as the initialization in preCICE differs significantly from the initialization in ESM couplers. The performance of data mapping specifically is analyzed in Schneider et al. [a3].
- Detailed introduction or parameter studies of the RBF data mapping. These are done in Schneider et al. [a3]. In our manuscript, we use preCICE "as is" as much as possible.
- Interpretations of the results of the original benchmark. These are done in detail there.
In our opinion, the strength of the manuscript is its limited scope, only studying a single aspect and the "add-on nature" with respect to the original benchmark. If the reviewers agree with this limited scope, we are happy to incorporate the criticism where possible and to make the scope of our conclusions as explicit as possible. But maybe the scope of the manuscript is too limited for GMD, which we would understand as well.
[a1] Bungartz et al. Partitioned fluid–structure–acoustics interaction on distributed data: Coupling via preCICE (2016), [https://doi.org/10.1007/978-3-319-40528-5_11](https://doi.org/10.1007/978-3-319-40528-5_11)
[a2] Totounferoush et al. Efficient and scalable initialization of partitioned coupled simulations with preCICE (2021), [https://doi.org/10.3390/a14060166](https://doi.org/10.3390/a14060166)
[a3] Schneider et al. Efficient partition-of-unity radial-basis-function interpolation for coupled problems (2025), [https://doi.org/10.1137/24M1663843](https://doi.org/10.1137/24M1663843)In the following individual aspects of the review will be addressed section by section. Aspects we deemed out of scope (OOS) will be marked as such.
Section 1 (Introduction)
The introduction suggests that preCICE represents a general-purpose coupling solution that could serve as a coupling library for the ESM community if extended by ESM-specific optimizations. This appears to be an oversimplification and does not sufficiently acknowledge the broader range of functionality provided by domain-specific ESM coupling software beyond accuracy and efficiency considerations.>> This was not our intention. The intention was to supplement the benchmark with results for preCICE and discuss the pros and cons of the general approach. We will add the aspect of "required additional functionality to the discussion of "cons".
In addition to the benchmark by Valcke et al. (2022), the MIRA protocol [5] constitutes another relevant benchmark for regridding quality and could be mentioned for completeness.
>> We will add the reference.
Section 2.2.1 (Library)
Within the ESM community, a clear distinction is made between online and offline generation of remapping weights. It would therefore be useful to clarify which of these approaches preCICE supports in practice and how they would be used in realistic ESM configurations. In the case of online generation, performance and scaling characteristics are of particular interest.>> preCICE only supports online generation, but OOS.
In typical ESM setups, remapping weights are either read from file or computed online during model initialization and remain fixed throughout the simulation, enabling the exchange to be implemented as a distributed sparse matrix–vector multiplication. Based on Chourdakis et al. (2022), this does not appear to be the case for the RBF implementation in preCICE. This is important information and should be stated explicitly. Furthermore, the performance results presented there suggest that the RBF approach may be prohibitively expensive for high-resolution ESM simulations and should be discussed accordingly.
>> We will state the fact that preCICE uses online mapping computation explicitly. Please note that we do not use the RBF implementation as presented in Chourdakis et al. (2022), but the partition-of-unity approach of [a1], which is orders of magnitude more efficient and complexity-wise comparable to a sparse matrix-vector product. We will mention [a1] at this point already, but otherwise OOS.
Section 4 (Results)
The comparison of global conservation properties for interpolation methods that are not designed to be conservative is of limited value. For this reason, the original benchmark did not include such measures for these methods. Metrics such as mean and maximum misfit would be more appropriate in this context.>> We included those to have a value to compare against the reference, as all mapping methods of preCICE are not designed "to be (locally) conservative".
Specific comments
Line 3–4: "a general-purpose coupling library not limited to ESM"
The term “general-purpose” already implies not being limited to ESM. Additionally, describing other couplers as “limited” appears unnecessarily negative and suggests functional equivalence that does not currently exist.>> We did not have this intention in mind. "Limited" is redudant, we will remove it.
Line 7: “yields significantly lower error”
lower than which reference or method?>> Than the results presented by Valcke et al. (2022). We will add more clarification to avoid misinterpretation of the sentence.
Line 10: "SEA"
The abbreviation “SEA” seems at least for me uncommon; “OCE” or “OCN” are more typical for ocean components.>> We will change all to OCN.
Line 12: Consider replacing “dedicated” with “domain-specific”.
>> Dedicated here means that the coupler is an independent software component, not integrated in one of the solvers. We will use "standalone" instead.
Line 13–15: ordering of software
Is there any reason for this ordering? Lexicographic ordering would appear more neutral.>> We used the same ordering as the reference paper. We will chang to lexicographic order, however.
Line 16–17: “already used in ESM”, "limited"
Claims regarding existing use in ESM and limitations of other couplers overstate the general applicability of preCICE beyond the specific setups considered (Abele et al. 2025).>> We will revise and make more accurate. The "limited" was not meant to comment on other couplers.
Line 20: “flexibility of the coupling approach”
This is vague and should be specified more precisely.>> We will drop this point.
Line 23–25:
Listing these as potential benefits implies that existing ESM coupling software lacks these properties, which is debatable.>> While we disagree, we understand the misunderstanding and will revise this section.
Line 25 “advanced numerical [..] methods”
Implicit coupling support is largely irrelevant for current ESM runs, as most component models do not support implicit coupling by design.>> We will revise this section.
Line 25 “advanced [..] HPC methods”
Large-scale coupled ESM simulations using domain-specific couplers have already demonstrated extreme scalability (e.g. [6], [7]) some some of the largest HPC systems of the world. Comparable demonstrations for preCICE are currently lacking.>> This was not our point. We will revise this section.
Line 26: "the absence of ESM-specific optimizations in terms of accuracy and efficiency"
The distinction between generic and domain-specific couplers is not limited to accuracy and efficiency; additional functionality is often crucial.>> As mentioned above, we will include this point.
Line 34: "VTK"
Add a reference or footnote for VTK. Since the VTK format is listed as an important dependency, it could be of interest to the reader to justify the choice of this file format section 2.4.>> We will add a footnote
Line 46–47: "constant data should remain constant"
In addition to conservation, monotonicity (no new extrema) and smoothness (continuously differentiable) are important remapping properties.
Depending on the physical property to be exchanged and the grid configuration, you may want your remapping to have one or the other property. The first property is often achieved using a "first order" method and the second one with the "second order" method. Since, in ESM remapping weights are usually not recomputed during a run, most of the time these two properties exclude themselves. The RBF implementation in preCICE seem to fulfil both properties, however as mentioned above it may have its own significant disadvantage.>> In this section, we describe the classification in preCICE. We will add a further discussion point in the results.
Line 49: "In ESM,..."
Consider starting a new paragraph?>> Yes.
Line 51: "To this end, meshes need to be enriched by connectivity."
This statement would benefit from additional clarification. In the benchmark, a mesh is defined by vertices, edges connecting these vertices, and cells formed by the edges. While most coupling software implicitly assumes that all edges follow great circles, this assumption does not hold for certain grid types commonly used in ESM, such as regular Gaussian grids, where edges follow circles of constant latitude or longitude. Among the coupling solutions considered in the benchmark, only YAC explicitly distinguishes between these edge types, which can affect cell area computations and, consequently, remapping accuracy [2]. Furthermore, although intensive quantities are provided at cell centers in the benchmark, connectivity information is still required by some remapping algorithms used for intensive fields, and is essential for all conservative remapping of extensive quantities. Clarifying these aspects would help readers better understand why and how connectivity information is required in this context.
>> We will add clarification: to compute cell integrals and overlaps.
Line 51: reference for conservative remapping ESM
Add a standard reference for conservative remapping in ESM is. Jones, 1999 [8]>> Thank you for the hint. We will add the reference.
Line 51: "mapping is considered conservative"
There is also the terms of local and global conservation. For numerical weather predication local conservation ensures high accuracy locally. However, for long running climate simulations global conservation is very important. If grid combinations are chosen carefully, local conservation can automatically also lead to global conservation.>> We will clarify the terms.
Formula 4:
For conservative interpolation, the ideal reference solution would be obtained by analytically integrating the test function over each cell, accounting for the exact cell geometry, and then normalizing by the cell area. In the benchmark, however, the source and reference target fields appear to be constructed by evaluating the analytical test function at the cell center and implicitly assuming this value to represent the cell-average. This approximation is likely a major contributor to the observed differences in global conservation between source and target fields, rather than the remapping procedure itself.>> Yes, we agree.
Line 110: "we use the WGS84 model"
Most ESM components assume a spherical Earth; using WGS84 may not be appropriate here.>> Thank you for the hint. We will adapt in follow-up work. As here, we use the same model for all meshes, the results should still be consistent.
Line 115–116: "Cell areas are computed from the nodal-based form."
Clarify whether planar or spherical cell areas were computed.>> We use a planar approximation of the spherical cell. We will add clarification.
Line 122:
The sse7 grid is a reduced Gaussian grid composed exclusively of quadrilateral cells. Owing to the grid’s structure, cell connectivity cannot be straightforwardly inferred. Moreover, as most coupling frameworks do not explicitly support edges following circles of constant latitude, a purely quadrilateral representation would lead to unintended gaps in the mesh. To avoid this issue, three additional vertices were introduced into the grid definition.>> Thank you for the clarification.
Line 127-128: “To use preCICE for coupling, we need to convert these into 3D Cartesian representations using x/y/z coordinates.”
Remark: This is also commonly done internally by domain-specific implementations (using a unit sphere).>> Thank you for the clarification.
Line 138: "The couplers used in the reference are SCRIP ..."
SCRIP is a library for computing remapping weights and not a coupler (XIOS is until now an IO-server library).
How about: "The coupling software used in the reference are....">> Thank you, will apply the recommendation.
Table 1:
The naming of the columns is misleading, because it is not obvious that columns three and four refer to the method names in the benchmark.Table 1 column 4:
In the benchmark, these method names were used only in the appendix and primarily reflect the terminology employed by SCRIP for the respective categories. As such, they are potentially misleading, since different coupling software used different algorithms within the same category depending on availability. This is particularly relevant for the “higher-order” category, where the implemented methods differed substantially between tools.Specifically, “distwgt-1” corresponds to a one-nearest-neighbour approach and was identical across all implementations. The label “distwgt” merely describes the weighting scheme that would be applied if more than one neighbour were used; for the one-nearest-neighbour case, no weighting is actually performed. The “bilinear” category effectively represents first-order interpolation in all cases; for YAC this was combined with inverse-distance weighting, although a different configuration was employed in a later benchmark, leading to significantly improved results (see Fig. 16 in [1]). Finally, the “bicubic” category encompassed fundamentally different methods: bicubic interpolation in SCRIP, patch recovery in ESMF, and HCSBB in YAC.
>> We will modify the table for better clarity. However, to keep our results an easily digestable delta to the original benchmark, we want to stick to the naming scheme used in the original data set.
Line 161-162: “Moreover, similarly to Valcke et al. (2022), we need to transfer land-ocean masks from the SEA to the ATM meshes in a pre-processing step”
Maybe: “Moreover, similar to Valcke et al. (2022), we have to generate a land-sea mask for the ATM mesh by computing the overlap between both meshes.”>> This would not reflect the underlying process then, which is described in the subsequent sections.
Line 162-163: "To increase the usability of the benchmark..."
Due to differences in cell shape representations and the numerical accuracy of the implemented methods, the various software packages in the benchmark may compute different grid overlaps. Consequently, the corresponding masks are generated separately for each software. The procedure for generating these masks was therefore explicitly described in benchmark. In the specific case of the torc grid, a fixed mask is usually provided alongside the grid data.>> We understand the point, but believe that our statement still holds. There is certainly a trade-off between usability and fidelity of the benchmark. We will further clarify.
Line 168: "write the results to VTK"
Maybe: "write the results to a VTK-formated file"?>> Yes.
Line 213: "parameter"
What parameter? The support radius?>> Yes. We will replace with "radius value" for clarity.
Line 214: "of the Earth radius"
Remark: most coupling software actually work on the unit sphere (radius 1.0), which makes a couple of computations much easier.>> Thank you for the clarification.
Line 215-216: "Alternatively, in future studies, we could make use of an automatic parameter optimization, which is currently developed for preCICE."
Remark: It may be worth considering whether the support radius could be determined adaptively based on a measure of the average distance between source points in the neighbourhood of a target point. Such an approach could yield more robust results for source grids with spatially varying resolution. A similar strategy is employed in the RBF implementation of YAC.>> With the partition-of-unity approach as used in prpeCICE, this level of adaptivity is largely handled by the clustering, where we currently investigate a more flexible approach: https://github.com/precice/precice/pull/2450.
Section 3.7:
In contrast to what is suggested in the manuscript, domain-specific software (SCRIP and YAC) is not able to handle the torc grid due to different error handling. The grid itself is valid and does not suffer from missing or invalid cells, its constructors were just “very creative” and did not just cause headaches for you. ;-)
The torc grid is used by an ocean model, hence you can and have to ignore all land cells. Therefore, this grid comes with its specific land-sea mask. Structurally, the grid is curvilinear, with vertices stored in a two-dimensional array and connectivity defined implicitly. To locally increase resolution in regions of interest (e.g. the Mediterranean Sea), unused land cells were relocated, which results in degenerated neighbouring cells. Consequently, this grid can only be processed reliably if all land cells defined by the provided mask are removed prior to further analysis or remapping.>> Thank you for the clarification. In this case we will not change the description.
Line 241: "who tested the three couplers"
Maybe: "who tested the three couplers for the non-conservative case:" (because actually there were four tools being tested)>> Yes true, we will apply the suggestion.
Line 248-249: "We presume that this is due to the scaling of the surface areas with the water fraction in post-processing as explained in Section 3.6"
Or due to the test fields being too smooth and uniform.>> The referenced reduction in variance seems to occur for all cases including gulfstream. As this is the non smooth/uniform case, either it is not sufficiently non smooth/uniform or smoothness is not the underlying cause.
Figure 6:
The benchmark demonstrated that, for the one-nearest-neighbour method, all regridding software produced nearly identical results in terms of mean, maximum, and RMS misfit. For this specific case, any substantial deviation would likely indicate an implementation issue. It is therefore unclear how the differences observed in global target conservation arise. (I still do not think that global target conservation is a valid measure for these methods).>> Same as before: We included these to have a value to compare against the reference, as all mapping methods of preCICE are not designed "to be (locally) conservative". Additionally, as there are also deviation in the reference results, attributing these effects to post-processing does seem valid to us.
Line 257-258: "For gulfstream, we obtain comparable results to the reference."
This could also be an indication for "over-smoothing", which could be a problem for fields used in actual simulations. The benchmark contained an additional measurement, which evaluated this and might be interesting to see here.>> We re-checked the l-min and l-max results. l-min are almost all 0. l-max on the other hand are mainly positive (2 to 3 times larger than reference). Thus, no smoothing but instead reinforced maximum values are present. We will add this observation.
Line 265: "very similarly than the misfit metric"
Do you mean: "very similarly than the mean-misfit metric"?>> Yes, will be amended.
In the benchmark the comparison between mean and max misfit provided quite some interesting insights. For some grid configurations these also differed significantly between the implementations.>> We did not observe any noticable differences between the preCICE runs and the average of the reference runs. In particular in the linear YAC mappings with the sinusoid function, the mean misfits deviated further than the max misfits compared to the others, but this was not the case for preCICE.
Line 277: "demonstrating that it can successfully handle ESM mapping problem"
Claims regarding successful handling of ESM mapping problems are overstated given the absence of conservative remapping and performance evaluation.>> Yes. We will weaken the claim.
Line 279: "An example of such transfer is the RBF mapping method"
Actually, YAC already contains an RBF based method (see [3]). However, to my knowledge it did not yet found a user. The benchmark only evaluated methods that were available in most tested software. This is why other methods and configuration options were ignored.>> Thank you for the clarification.
Line 280-281: "it outperformed ESM-specific second-order methods by in average two orders of magnitude for smooth test function"
Since the benchmark compared similar methods that were already successfully used in the ESM context, using simplified test functions did not seem to cause issues. However, with the introduction the RBF-method, this may have to be reevaluated, because good performance for the test functions may not automatically yield the same for actual data.>> We agree. We will weaken the statement.
Line 285-286: "as it would require a carefully refined benchmark definition."
Especially for Numerical Weather Prediction performance measurements are important. Depending on the overall performance, it may also be of interest for climate simulations. It would be very interesting to see some basic runtime and scaling measurements, similar to the ones described in the original benchmark (see section 8.)>> We agree, but OOS. Runtime and scaling measurement of data mapping in preCICE is done in [a3].
[1]: https://cerfacs.fr/wp-content/uploads/2024/12/TR-CMGC-24-182_yac_in_oasis.pdf
[2]: https://doi.org/10.5194/gmd-17-415-2024
[3]: https://dkrz-sw.gitlab-pages.dkrz.de/yac/d1/d79/interp_method_rbf.html
[4]: https://raw.githubusercontent.com/IS-ENES3/IS-ENES-Website/main/pdf_documents/IS-ENES2_D10.3_FV.pdf
[5]: https://doi.org/10.5194/gmd-15-6601-2022
[6]: https://doi.org/10.1145/3712285.3771789
[7]: https://awards.acm.org/bell-climate
[8]: https://doi.org/10.1175/1520-0493(1999)127<2204:FASOCR>2.0.CO;2Citation: https://doi.org/10.5194/egusphere-2025-5618-AC1
-
AC1: 'Reply on RC1', Alex Hocks, 30 Mar 2026
-
RC2: 'Comment on egusphere-2025-5618', Vijay Mahadevan, 05 Mar 2026
I apologize for the delay. Review comments attached.
-
AC2: 'Reply on RC2', Alex Hocks, 30 Mar 2026
We want to thank the reviewer for the extensive comments. Many interesting discussions are raised, most of which go significantly beyond the scope of the manuscript, however. The idea of the paper is not to do a full comparison of the general-purpose coupling library preCICE to domain-specific ESM couplers. We even believe that a fair comparison is close to impossible to achieve. Instead, the paper focuses on a single aspect: accuracy of data mapping.
To this end, we took the benchmark introduced by Valcke et al. (2022) and its results and supplemented them with results for preCICE. Our goal was to stick as closely as possible to the description, the notation, and the presentation of results of the original benchmark to make our manuscript easy to digest for readers familiar with the original work. Besides the actual results, the interesting aspect (for us) is the fact how meshes and data mappings are handled differently in ESM couplers and preCICE, which we tried to explain thoroughly. We believe that both sides can learn something from these differences.
Out of the scope are:
- Evaluation of the runtime of data mapping, similarly to the original benchmark. Performance of preCICE is analyzed in other publications [a1, a2, a3]. A fair overall comparison would also be very intricate as the initialization in preCICE differs significantly from the initialization in ESM couplers. The performance of data mapping specifically is analyzed in Schneider et al. [a3].
- Detailed introduction or parameter studies of the RBF data mapping. These are done in Schneider et al. [a3]. In our manuscript, we use preCICE "as is" as much as possible.
- Interpretations of the results of the original benchmark. These are done in detail there.
In our opinion, the strength of the manuscript is its limited scope, only studying a single aspect and the "add-on nature" with respect to the original benchmark. If the reviewers agree with this limited scope, we are happy to incorporate the criticism where possible and to make the scope of our conclusions as explicit as possible. But maybe the scope of the manuscript is too limited for GMD, which we would understand as well.
[a1] Bungartz et al. Partitioned fluid–structure–acoustics interaction on distributed data: Coupling via preCICE (2016), [https://doi.org/10.1007/978-3-319-40528-5_11](https://doi.org/10.1007/978-3-319-40528-5_11)
[a2] Totounferoush et al. Efficient and scalable initialization of partitioned coupled simulations with preCICE (2021), [https://doi.org/10.3390/a14060166](https://doi.org/10.3390/a14060166)
[a3] Schneider et al. Efficient partition-of-unity radial-basis-function interpolation for coupled problems (2025), [https://doi.org/10.1137/24M1663843](https://doi.org/10.1137/24M1663843)In the following individual aspects of the review will be addressed section by section. Aspects we deemed out of scope (OOS) will be marked as such.
The manuscript is well written, but the presentation of the results is insufficient to adequately
convince the readers that RBF schemes in preCICE can outperform (in both time and accuracy) the
high-order, non-conservative implementations in SCRIP, ESMF and YAC libraries.>> Please note, that this was not the claim or purpose of the manuscript. The main intent was to supplement the benchmark results of Valcke et al. with those of preCICE. The performance of the RBF scheme was only a noteworthy observation. We will try to further clarify.
1. P2. L26-28: ”For example, preCICE operates solely on Cartesian coordinates, which may require additional pre- and postprocessing for geodesic ESM meshes.”While the intent is correct here, it should be noted that many implementations of both conservative and quasi-interpolant schemes do not need to make explicit assumptions about whether the meshes are on a spherical manifold. It is also important to ensure that the pre and post-processing steps that are used in this manuscript do not introduce additional bias or improvements, as it can affect the conclusions in this study.
>> Yes, but this is not what we are stating here. Regarding the pre- and post-processing: True. We are aware of this issue and provide comparisons to Valcke et al. where possible.
2. P2. L45: ”Mappings in preCICE can be classified as consistent or conservative”
P2. L48: ”Thus, consistent and conservative mappings can be constructed from each other by transposing the mapping matrix.”These are not mutually exclusive attributes of a linear map. For global ESM meshes, conservative meshes are also consistent. However, for culled meshes, conservation along a boundary interface (e.g., the land sea coastal boundary) depends on the local definition of the metric. Rephrase your statements to clarify.
3. P2. L47: ”Here, the sum of the data values should remain constant, which means that all columns of M sum up to 1.”
This is wrong. Given the definition for M , the column sum equates the source area contribution in the corresponding overlap region between source and target, since conservative schemes are area weighted. This will not sum up to 1.
>> Please note that the term "conservative" is used differently in preCICE (and other publications, e.g. https://doi.org/10.1016/j.cma.2008.05.001) and in ESM couplers, as we state in the manuscript. This section explains "conservative" as used in preCICE.
4. P3: Equations (3)
(3) checks the global bounds of the projected field values against the source values, which implies checking for monotonicity in the remapping algorithm. However, I do not see any further discussion of this metric anywhere in the results. If this is not a metric used in the experiment, remove it from the description.
>> We do mention it (briefly) in the results section. But merely mentioned here for completeness compared to the reference paper.
6. P4. L87:
The nearest projection (NP) description sounds like it is actually a natural-neighbor interpolant based on Delaunay triangulation? The terminology is confusing here. If this is not the case, please provide references to where NP was introduced in preCICE, or briefly explain further how NP is achieved.
- Sibson, R. (1981), A Brief Description of Natural Neighbor Interpolation. In Interpolating multivariate data, John Wiley & Sons, New York, 1981, pp. 21-36.
- Watson, David F. (1981). Computing the n-dimensional Delaunay tessellation with application to Voronoi polytropes. The Computer Journal 24(2), p. 167-173.
>> It is not triangulation-based. Instead preCICE requires mesh connectivity information for NP based mappings (restricted to certain cell & face types). Implementation details are given in https://doi.org/10.3390/a14060166.
7. P4. L96-L98: ”Here, the results of a consistent mapping are globally scaled in a post-processing step to conserve integral values. To compute the scaling factor, connectivity information of both meshes is required.”
Scaled normalization to achieve global conservation can yield unphysical non-monotone values, for example if fields are strictly bounded or constrained to be non-negative. How do you deal with that? Given that you do mention a bound checking metric in Equation (3) and since you use normalized post-processing to achieve global conservation, this will directly impact the quality of the remapped result. Elaborate.
>> We do not use the scaled-consistent variant for the actual mapping, but only in the pre-processing.
8. Please refer to the MIRA intercomparison paper that introduces several metrics for the inter-comparison of remapping algorithms in ESM. This will help readers better understand the RBF reconstructions used in preCICE and how they compare against other implementations and algorithms as well. Disclaimer: I am one of the authors of the MIRA protocol. Mahadevan, V. S., et al., Metrics for Intercomparison of Remapping Algorithms (MIRA) protocol applied to Earth system models, Geosci. Model Dev., 15, 6601–6635, https://doi.org/10.5194/gmd-15-6601-2022, 2022.
>> We will add a reference.
9. P5. L114: ”Meshes are provided in two forms: a) node-based including connectivity and b) cell-based, only containing cell centers”
I do not understand the reasoning. If you have a node-based mesh with connectivity information, obtaining the cell-centers is trivial. Do you mean to say that the input grids are either cell-based or node-based?
>> Yes, it is correct that obtaining the cell-centers is trivial. However, at this point we are only describing the meshes contained within the input datasets.
10. P6: Table 1
Table 1 is very confusing. I assume the authors are describing 3 rows: nearest-neighbor, linear and high-order methods. Do the conservative and non-conservative columns specify variants of the scheme used in Valcke et al., (2022)? It was introduced before that preCICE does have a normalized version of the remapper that can retain conservation. In that sense, you can make any non-conservative scheme conservative by choosing an appropriate normalization.
>> The table will be altered for more clarity. Regarding the first question: yes. Lastly, any mapping can be made globally conservative using the previously mentioned scaled-consistent mapping. However, this is an experimental feature within preCICE. In our preliminary tests, it traded off global source conservation with misfit. As this did not yield promising results, we did not investigate it further.
11. P10: Section 3.5
In Section 3.5, RBF mapping algorithm is being discussed. The details are terse and do not give the reader the full picture of how the algorithm is used. Please elaborate a bit more about the algorithm, its properties, compactness, applicability to unstructured topology, and computational complexity. The note about the parameter indicates that for both the fine to fine and fine to coarse remaps use the same value of 2E6 fir support radius. Does this adversely affect the results? How about performance? Please provide a better discussion. Please also highlight that the scripts that perform the different stages of the workflow shown in Figure. 2 have been provided in Hocks, 2025a, to improve reproducibility of the results presented here.
>> Further elaboration within the paper would go beyond our scope. Instead we will add a reference to a paper introducing the used RBF schemes. See: https://doi.org/10.1137/24M1663843. The parameter was chosen by manually performing the mappings with different parameter values. The uniform choice across all runs, does not affect it adversely. Changing overlap and cluster size, mainly affects mapping success. Only the support radius has a significant effect on the misfits. Changing it scales misfits with approx. the same factor across all mappings. Will will include this in the manuscript.
12. P11-12: Section 3.7
Section 3.7 deals with meshing issues, but specifically in the Delaunay triangulation algorithm. This seems like a problem that needs to be fixed in the algorithm implementation. How did you verify the Delaunay triangulation algorithm implemented here in the manuscript?
>> No, the issues addressed there were not related to triangulation. These were due to the form of the input meshes and the subsequent mask mappings. The triangulation was tested over various small test inputs.
13. In Figure 6 and Figure 8
How can the nearest-neighbor be different in any implementation? There is a unique point on the source mesh that is always closest to any given target point. The mean misfit shows this, but why are global conservation values different?
>> First: Even within the reference mappings there are noticable differences, likely due to slight differences in weight computation and numerical accuracy. Second: As described in our pipeline, preCICE cannot use the same meshes as the reference solvers. Instead it needs to operate on a transformed mesh based on the cell centers. As the meshes are not 100% the same, this may lead to different conservation.
14. In the Section (2.2.1) L95-98
It is stated ”Also regarding the ℓ-min and ℓ-max metric, preCICE yields similar results as the reference without much deviation.”. It will be interesting and important to analyze the impact of the normalization by measuring bound-checking metrics. This can add additional value to the manuscript.
>> Same as earlier: In our tests it traded off global source conservation with misfit. As this did not yield promising results, we did not investigate this further and await an implementation for local conservation. (OOS)
15. Figure 8
In the gulfstream high-order comparison plot, please explain why torc-icos and icos-torc grid combinations yield a much lower RBF reconstruction error as opposed to the bicubic or HSBB interpolants in SCRIP and YAC respectively?
>> As we do not have the full reference benchmark data including the intermediate steps, we do not have the means to compare against the SCRIP and YAC results. Therefore, we cannot compare to determine the cause. In theory we could perform the bicubic mapping. HSBB did not compile (in the runner program). Regardless, as we do not have access to the full reference post-processing, this would not yield comparable results.
16. Figure 8
I was under the assumption that the normalization was applied for all preCICE schemes in the study. But the results in Figure 8 do not hint at this. So why is the normalization not used here?
>> No, no normalizations were applied. We only consider consistent mappings. The scaled-consistent approach was used for mask mapping.
Comment: For non-conservative schemes, it makes no sense, nor does it add any value to measure the conservation error. Please either use normalized/scaled projections or just define it as non-conservative, and not worry about the net bias introduced in preserving the global integrals. In an ESM, whether an algorithm introduces 1E-4 or 1E−8 conservation error, they are still both non-conservative. Please remove these conservation error results from the manuscript for all non-conservative methods.
>> The aim was to provide a qualitative comparison to the reference. As these metrics were also mentioned there for non-conservative schemes, we would keep our figures.
17. Figure 9 and 10
Comparing Figure 9 and 10 misfits, it is clear that the RBF reconstruction performs much better on smooth solutions and is only as accurate as a nearest-neighbor solution when applied to a case with strong gradients. Please highlight this and provide comments on the behavior or approaches to make the high-order scheme perform better in such scenarios.
>> "The overall behaviour can be explained by the high smoothness of all test functions other than gulfstream, for which RBF is known to perform well (Schneider and Uekermann, 2025a)." highlights it in our eyes already. Given the general purpose of preCICE, approaches to make the high-order scheme will be problem dependent. As such, providing those here will be OOS.
18. L279-282: ”An example of such transfer is the RBF mapping method, widely used in fluid–structure interaction (Chourdakis et al., 2022). In our tests, it outperformed ESM- specific second-order methods by an average of two orders of magnitude for smooth test functions while also showing robustness: The same setup worked across all considered ESM meshes.”
Given the results presented, these statements should be modified to reflect the overall conclusions. Smooth analytical functions make excellent candidates to measure properties of the remapping algorithm. However, I strongly encourage the authors to measure convergence rates, dissipation characteristics, effect of the radius parameter in the scheme, and then provide a comparison against the other schemes in ESMF, YAC, and SCRIP. This provides better validation of the quasi-interpolation algorithm and its accuracy behavior for both smooth and non-smooth solutions.
>> We will weaken the statement. We are aware of the benefits of the MIRA benchmark. However, as the aim of this paper was solely to reproduce the results of Valcke et al., this will be OOS.
Comment: Additionally, the authors do not provide any comparison or even hint at a discussion about the performance implications of solving a large number of linear problems at every target point site. How will this compare against the generation and application of linear maps created out of the ESMF, YAC, and SCRIP implementations? Please dedicate a section to discuss the performance of the remap scheme and provide a plot of time to remap vs accuracy against, say, both the vortex and Gulfstream solutions. If possible, comparing this efficacy chart with those generated for ESMF, YAC, and SCRIP would be a nice contribution to the community.
>> Assuming the large number of linear problems refers to the RBF mappings, please note that we do not use the RBF implementation as presented in Chourdakis et al. (2022), but the partition-of-unity approach of [a1], which is orders of magnitude more efficient and complexity-wise comparable to a global sparse matrix-vector product. We will refer to [a1], which provides detailed performance analysis. Here, OOS.
Citation: https://doi.org/10.5194/egusphere-2025-5618-AC2
-
AC2: 'Reply on RC2', Alex Hocks, 30 Mar 2026
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 228 | 103 | 24 | 355 | 16 | 18 |
- HTML: 228
- PDF: 103
- XML: 24
- Total: 355
- BibTeX: 16
- EndNote: 18
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Summary
The manuscript evaluates the coupling library preCICE (v3.3.0) using the Earth system model (ESM) regridding benchmark of Valcke et al. (2022). The authors adapt this benchmark, originally developed for domain-specific ESM coupling software, to preCICE by introducing additional preprocessing and postprocessing steps. Three remapping methods available in preCICE - nearest neighbour, linear interpolation, and a radial basis function (RBF)–based approach - are assessed and compared against published benchmark results. The study shows that the tested preCICE remapping methods can achieve interpolation accuracy comparable to the tools included in the original benchmark for this specific offline regridding task.
Scientific significance for the Earth system modelling community
The manuscript is of interest to the ESM community as it explores whether a general-purpose, multi-physics coupling framework can reproduce results from an established ESM regridding benchmark. It demonstrates that a subset of remapping methods commonly required in ESM workflows is available in preCICE and can yield competitive accuracy. However, the scientific significance is limited by the narrow scope of the evaluation: only offline remapping accuracy for a subset of interpolation methods required by ESM setups is assessed, while other core ESM coupling functionalities and critical performance and scalability characteristics are not examined.
Recommendation for publication
The manuscript presents a technically sound and transparent benchmark study that fits the scope of Geoscientific Model Development. However, the conclusions substantially overgeneralize the demonstrated results. I recommend publication only after major revisions.
General comments
The work presented in this manuscript primarily evaluates the quality of remapping methods available in preCICE in the context of ESM. Several conclusions drawn from this evaluation appear overly general and, in places, exaggerated with respect to preCICE’s overall coupling capabilities for ESM setups. A more critical and focused discussion would be more appropriate. Alternatively, the scope of the paper could be broadened by including an evaluation of additional coupling functionality that is handled differently in preCICE compared to domain-specific ESM couplers.
A significant omission is the lack of performance and scalability analysis. In particular, runtime and scaling data - including measurements of so-called “ping-pong exchanges” - would considerably strengthen the evaluation. For domain-specific coupling software, “ping-pong exchanges” were already assessed in another referenced benchmark [4], which explains their absence in Valcke et al. (2022). For preCICE, especially for the RBF-based mapping, such measurements would be highly relevant given its potential computational cost.
Section 1 (Introduction)
The introduction suggests that preCICE represents a general-purpose coupling solution that could serve as a coupling library for the ESM community if extended by ESM-specific optimizations. This appears to be an oversimplification and does not sufficiently acknowledge the broader range of functionality provided by domain-specific ESM coupling software beyond accuracy and efficiency considerations.
In addition to the benchmark by Valcke et al. (2022), the MIRA protocol [5] constitutes another relevant benchmark for regridding quality and could be mentioned for completeness.
Section 2.2.1 (Library)
Within the ESM community, a clear distinction is made between online and offline generation of remapping weights. It would therefore be useful to clarify which of these approaches preCICE supports in practice and how they would be used in realistic ESM configurations. In the case of online generation, performance and scaling characteristics are of particular interest.
In typical ESM setups, remapping weights are either read from file or computed online during model initialization and remain fixed throughout the simulation, enabling the exchange to be implemented as a distributed sparse matrix–vector multiplication. Based on Chourdakis et al. (2022), this does not appear to be the case for the RBF implementation in preCICE. This is important information and should be stated explicitly. Furthermore, the performance results presented there suggest that the RBF approach may be prohibitively expensive for high-resolution ESM simulations and should be discussed accordingly.
Section 4 (Results)
The comparison of global conservation properties for interpolation methods that are not designed to be conservative is of limited value. For this reason, the original benchmark did not include such measures for these methods. Metrics such as mean and maximum misfit would be more appropriate in this context.
Specific comments
Line 3–4: "a general-purpose coupling library not limited to ESM"
The term “general-purpose” already implies not being limited to ESM. Additionally, describing other couplers as “limited” appears unnecessarily negative and suggests functional equivalence that does not currently exist.
Line 7: “yields significantly lower error”
lower than which reference or method?
Line 10: "SEA"
The abbreviation “SEA” seems at least for me uncommon; “OCE” or “OCN” are more typical for ocean components.
Line 12: Consider replacing “dedicated” with “domain-specific”.
Line 13–15: ordering of software
Is there any reason for this ordering? Lexicographic ordering would appear more neutral.
Line 16–17: “already used in ESM”, "limited"
Claims regarding existing use in ESM and limitations of other couplers overstate the general applicability of preCICE beyond the specific setups considered (Abele et al. 2025).
Line 20: “flexibility of the coupling approach”
This is vague and should be specified more precisely.
Line 23–25:
Listing these as potential benefits implies that existing ESM coupling software lacks these properties, which is debatable.
Line 25 “advanced numerical [..] methods”
Implicit coupling support is largely irrelevant for current ESM runs, as most component models do not support implicit coupling by design.
Line 25 “advanced [..] HPC methods”
Large-scale coupled ESM simulations using domain-specific couplers have already demonstrated extreme scalability (e.g. [6], [7]) some some of the largest HPC systems of the world. Comparable demonstrations for preCICE are currently lacking.
Line 26: "the absence of ESM-specific optimizations in terms of accuracy and efficiency"
The distinction between generic and domain-specific couplers is not limited to accuracy and efficiency; additional functionality is often crucial.
Line 34: "VTK"
Add a reference or footnote for VTK. Since the VTK format is listed as an important dependency, it could be of interest to the reader to justify the choice of this file format section 2.4.
Line 46–47: "constant data should remain constant"
In addition to conservation, monotonicity (no new extrema) and smoothness (continuously differentiable) are important remapping properties.
Depending on the physical property to be exchanged and the grid configuration, you may want your remapping to have one or the other property. The first property is often achieved using a "first order" method and the second one with the "second order" method. Since, in ESM remapping weights are usually not recomputed during a run, most of the time these two properties exclude themselves. The RBF implementation in preCICE seem to fulfil both properties, however as mentioned above it may have its own significant disadvantage.
Line 49: "In ESM,..."
Consider starting a new paragraph?
Line 51: "To this end, meshes need to be enriched by connectivity."
This statement would benefit from additional clarification. In the benchmark, a mesh is defined by vertices, edges connecting these vertices, and cells formed by the edges. While most coupling software implicitly assumes that all edges follow great circles, this assumption does not hold for certain grid types commonly used in ESM, such as regular Gaussian grids, where edges follow circles of constant latitude or longitude. Among the coupling solutions considered in the benchmark, only YAC explicitly distinguishes between these edge types, which can affect cell area computations and, consequently, remapping accuracy [2]. Furthermore, although intensive quantities are provided at cell centers in the benchmark, connectivity information is still required by some remapping algorithms used for intensive fields, and is essential for all conservative remapping of extensive quantities. Clarifying these aspects would help readers better understand why and how connectivity information is required in this context.
Line 51: reference for conservative remapping ESM
Add a standard reference for conservative remapping in ESM is. Jones, 1999 [8]
Line 51: "mapping is considered conservative"
There is also the terms of local and global conservation. For numerical weather predication local conservation ensures high accuracy locally. However, for long running climate simulations global conservation is very important. If grid combinations are chosen carefully, local conservation can automatically also lead to global conservation.
Formula 4:
For conservative interpolation, the ideal reference solution would be obtained by analytically integrating the test function over each cell, accounting for the exact cell geometry, and then normalizing by the cell area. In the benchmark, however, the source and reference target fields appear to be constructed by evaluating the analytical test function at the cell center and implicitly assuming this value to represent the cell-average. This approximation is likely a major contributor to the observed differences in global conservation between source and target fields, rather than the remapping procedure itself.
Line 110: "we use the WGS84 model"
Most ESM components assume a spherical Earth; using WGS84 may not be appropriate here.
Line 115–116: "Cell areas are computed from the nodal-based form."
Clarify whether planar or spherical cell areas were computed.
Line 122:
The sse7 grid is a reduced Gaussian grid composed exclusively of quadrilateral cells. Owing to the grid’s structure, cell connectivity cannot be straightforwardly inferred. Moreover, as most coupling frameworks do not explicitly support edges following circles of constant latitude, a purely quadrilateral representation would lead to unintended gaps in the mesh. To avoid this issue, three additional vertices were introduced into the grid definition.
Line 127-128: “To use preCICE for coupling, we need to convert these into 3D Cartesian representations using x/y/z coordinates.”
Remark: This is also commonly done internally by domain-specific implementations (using a unit sphere).
Line 138: "The couplers used in the reference are SCRIP ..."
SCRIP is a library for computing remapping weights and not a coupler (XIOS is until now an IO-server library).
How about: "The coupling software used in the reference are...."
Table 1:
The naming of the columns is misleading, because it is not obvious that columns three and four refer to the method names in the benchmark.
Table 1 column 4:
In the benchmark, these method names were used only in the appendix and primarily reflect the terminology employed by SCRIP for the respective categories. As such, they are potentially misleading, since different coupling software used different algorithms within the same category depending on availability. This is particularly relevant for the “higher-order” category, where the implemented methods differed substantially between tools.
Specifically, “distwgt-1” corresponds to a one-nearest-neighbour approach and was identical across all implementations. The label “distwgt” merely describes the weighting scheme that would be applied if more than one neighbour were used; for the one-nearest-neighbour case, no weighting is actually performed. The “bilinear” category effectively represents first-order interpolation in all cases; for YAC this was combined with inverse-distance weighting, although a different configuration was employed in a later benchmark, leading to significantly improved results (see Fig. 16 in [1]). Finally, the “bicubic” category encompassed fundamentally different methods: bicubic interpolation in SCRIP, patch recovery in ESMF, and HCSBB in YAC.
Line 161-162: “Moreover, similarly to Valcke et al. (2022), we need to transfer land-ocean masks from the SEA to the ATM meshes in a pre-processing step”
Maybe: “Moreover, similar to Valcke et al. (2022), we have to generate a land-sea mask for the ATM mesh by computing the overlap between both meshes.”
Line 162-163: "To increase the usability of the benchmark..."
Due to differences in cell shape representations and the numerical accuracy of the implemented methods, the various software packages in the benchmark may compute different grid overlaps. Consequently, the corresponding masks are generated separately for each software. The procedure for generating these masks was therefore explicitly described in benchmark. In the specific case of the torc grid, a fixed mask is usually provided alongside the grid data.
Line 168: "write the results to VTK"
Maybe: "write the results to a VTK-formated file"?
Line 213: "parameter"
What parameter? The support radius?
Line 214: "of the Earth radius"
Remark: most coupling software actually work on the unit sphere (radius 1.0), which makes a couple of computations much easier.
Line 215-216: "Alternatively, in future studies, we could make use of an automatic parameter optimization, which is currently developed for preCICE."
Remark: It may be worth considering whether the support radius could be determined adaptively based on a measure of the average distance between source points in the neighbourhood of a target point. Such an approach could yield more robust results for source grids with spatially varying resolution. A similar strategy is employed in the RBF implementation of YAC.
Section 3.7:
In contrast to what is suggested in the manuscript, domain-specific software (SCRIP and YAC) is not able to handle the torc grid due to different error handling. The grid itself is valid and does not suffer from missing or invalid cells, its constructors were just “very creative” and did not just cause headaches for you. ;-)
The torc grid is used by an ocean model, hence you can and have to ignore all land cells. Therefore, this grid comes with its specific land-sea mask. Structurally, the grid is curvilinear, with vertices stored in a two-dimensional array and connectivity defined implicitly. To locally increase resolution in regions of interest (e.g. the Mediterranean Sea), unused land cells were relocated, which results in degenerated neighbouring cells. Consequently, this grid can only be processed reliably if all land cells defined by the provided mask are removed prior to further analysis or remapping.
Line 241: "who tested the three couplers"
Maybe: "who tested the three couplers for the non-conservative case:" (because actually there were four tools being tested)
Line 248-249: "We presume that this is due to the scaling of the surface areas with the water fraction in post-processing as explained in Section 3.6"
Or due to the test fields being too smooth and uniform.
Figure 6:
The benchmark demonstrated that, for the one-nearest-neighbour method, all regridding software produced nearly identical results in terms of mean, maximum, and RMS misfit. For this specific case, any substantial deviation would likely indicate an implementation issue. It is therefore unclear how the differences observed in global target conservation arise. (I still do not think that global target conservation is a valid measure for these methods).
Line 257-258: "For gulfstream, we obtain comparable results to the reference."
This could also be an indication for "over-smoothing", which could be a problem for fields used in actual simulations. The benchmark contained an additional measurement, which evaluated this and might be interesting to see here.
Line 265: "very similarly than the misfit metric"
Do you mean: "very similarly than the mean-misfit metric"?
In the benchmark the comparison between mean and max misfit provided quite some interesting insights. For some grid configurations these also differed significantly between the implementations.
Line 277: "demonstrating that it can successfully handle ESM mapping problem"
Claims regarding successful handling of ESM mapping problems are overstated given the absence of conservative remapping and performance evaluation.
Line 279: "An example of such transfer is the RBF mapping method"
Actually, YAC already contains an RBF based method (see [3]). However, to my knowledge it did not yet found a user. The benchmark only evaluated methods that were available in most tested software. This is why other methods and configuration options were ignored.
Line 280-281: "it outperformed ESM-specific second-order methods by in average two orders of magnitude for smooth test function"
Since the benchmark compared similar methods that were already successfully used in the ESM context, using simplified test functions did not seem to cause issues. However, with the introduction the RBF-method, this may have to be reevaluated, because good performance for the test functions may not automatically yield the same for actual data.
Line 285-286: "as it would require a carefully refined benchmark definition."
Especially for Numerical Weather Prediction performance measurements are important. Depending on the overall performance, it may also be of interest for climate simulations. It would be very interesting to see some basic runtime and scaling measurements, similar to the ones described in the original benchmark (see section 8.)
[1]: https://cerfacs.fr/wp-content/uploads/2024/12/TR-CMGC-24-182_yac_in_oasis.pdf
[2]: https://doi.org/10.5194/gmd-17-415-2024
[3]: https://dkrz-sw.gitlab-pages.dkrz.de/yac/d1/d79/interp_method_rbf.html
[4]: https://raw.githubusercontent.com/IS-ENES3/IS-ENES-Website/main/pdf_documents/IS-ENES2_D10.3_FV.pdf
[5]: https://doi.org/10.5194/gmd-15-6601-2022
[6]: https://doi.org/10.1145/3712285.3771789
[7]: https://awards.acm.org/bell-climate
[8]: https://doi.org/10.1175/1520-0493(1999)127<2204:FASOCR>2.0.CO;2