Dear Dr. Barge and co-authors,

Thank you for submitting the revised version of your manuscript, entitled “Deploying Machine Learning components coupled to Earth System Models with OASIS3-MCT (v6) and Eophis (v1.1)”, and for providing detailed responses to the reviewers.

The relationship between Eophis and OASIS3-MCT is now more clearly explained, the ESM–OASIS3-MCT–Eophis workflow is presented more sequentially, and the descriptions of the Tunnel, Router, time-stepping mechanism, halo reconstruction, and asynchronous execution have been strengthened. The newly added scalability analysis also provides useful context for interpreting the computational-performance results.

I consider the manuscript scientifically relevant and suitable for publication in Geoscientific Model Development. However, several unclear issues should be resolved before the manuscript can be accepted. I therefore invite you to submit a revision addressing the following points.

1. Complete and verify the code and data availability statement
• The Code and Data Availability section currently contains an unresolved placeholder:
“Same material for ORCA1 test case coupled with Storto et al. (2024) is shared at … (???)”
Please replace this placeholder with the complete and correct repository citation and reference. If the repository is not yet publicly available, please clearly state its expected availability and ensure that all material required to reproduce the reported experiments is accessible before final publication.
• Please also reconcile the apparent software-version inconsistency. The manuscript title and availability statement refer to Eophis v1.1, whereas the log presented in Figure A1 displays Eophis 1.0.2. Please clarify which version was used for the benchmark experiments and ensure consistency among the title, methods, figures, archived code, and reproducibility material. If the simulations were performed using an earlier version, please explain whether the changes introduced in v1.1 affect any reported results.
• Reconcile the duplicated and mutually inconsistent atmospheric-forcing statements: one sentence attributes the forcing to ERA5 (ECMWF/CDS), while the following sentence attributes it to JRA-55 via the Geoscience Data Exchange (GDEX). Please retain the correct source, remove the redundant sentence, and correct the typo “Atmopsheric.”

2. Distinguish wall-clock performance from total computational-resource cost
The benchmark results demonstrate that asynchronous execution and flexible resource allocation can substantially reduce—or hide—the additional wall-clock time associated with the Python component. However, this improvement is achieved by allocating additional CPU or GPU resources.
The manuscript should therefore distinguish more carefully between:
• wall-clock or time-to-solution overhead;
• additional CPU/GPU resources;
• total computational cost, such as core-hours, node-hours, or GPU-hours.
Statements such as “minimal overhead,” “without affecting time-to-solution,” “negligible extra cost,” and claims that the Eophis implementation performs better than wrapper-based methods should be qualified accordingly.
For example, the main conclusion could be expressed as follows:
“Asynchronous coupling can largely hide the Python-related wall-clock overhead when sufficient additional resources are allocated, although the total computational-resource requirement increases.”
Please revise the Abstract, Sections 4 and 6, and any other relevant passages to avoid equating a small wall-clock penalty with negligible total computational cost.

3. Provide sufficient information for reproducing the performance benchmarks
Because computational scalability is a central component of the manuscript, the benchmark configuration should be documented more comprehensively. Please provide, either in the main text, a table, or the supplementary/repository documentation, the following information:
• HPC system and node architecture;
• CPU and GPU models;
• number of CPU cores and GPUs per node;
• MPI implementation and compiler versions;
• Python, TensorFlow, CUDA, and relevant library versions;
• OpenMP-thread configuration, if applicable;
• NEMO domain decomposition;
• mapping of MPI processes to physical cores and nodes;
• placement of the NEMO and Python processes;
• relationship between the number of “Python processes” and the number of GPUs in the GPU experiments;
• number of repeated benchmark runs;
• averaging procedure and run-to-run variability of SYPD.
Please also use the terms “processes,” “CPU cores,” “nodes,” “GPUs,” and “resources” consistently, as these are not interchangeable.

4. Add numerical verification of the coupling implementation
The manuscript evaluates computational performance but provides limited evidence that the various coupling implementations produce numerically consistent results.
Please provide a concise verification showing, where applicable, that:
• Eophis-coupled Python calculations agree with standalone Python calculations;
• synchronous and asynchronous configurations produce identical or acceptably close results;
• the ORCA1-E, ORCA1-F, and ORCA1-I implementations produce consistent neural-network outputs;
• halo reconstruction is correct at MPI-partition and global-domain boundaries.
This verification need not constitute a full scientific validation of the parameterizations. A concise report of maximum absolute or relative differences, numerical tolerances, or relevant unit/integration tests would be sufficient. Please also clarify explicitly whether the asynchronous method uses data from the same model time step and whether it introduces any temporal lag.

5. Moderate claims concerning generality and comparative performance
The framework is designed to be applicable to other OASIS3-MCT-enabled components, but the present experimental evaluation is limited primarily to NEMO. Statements implying that the method has been demonstrated for any global or regional ESM component should therefore be moderated.
A more precise formulation would be:
“The framework is designed to be applicable to other global and regional model components equipped with OASIS3-MCT, although the present evaluation is limited to NEMO.”
Similarly, the comparison with Fortran-wrapper approaches is based on a specific ORCA1 benchmark and on different resource allocations. Please restrict comparative conclusions to the experiments actually conducted. For example:
“In the ORCA1 benchmark, Eophis achieved comparable or higher wall-clock performance than the tested wrapper-based implementations when additional Python resources were allocated.”

6. Clarification of Figure 2
Reviewer 2 suggested distinguishing the configuration phase from the execution phase and, if possible, presenting a timeline showing where Eophis operates in the coupling workflow. Although the revised caption and Section 3.1 provide a clearer textual explanation, Figure 2 still combines the structural components and runtime workflow in a single schematic. Please consider revising the figure to distinguish explicitly between (i) the configuration stage, including Tunnel, grid, exchange, and namelist setup, and (ii) the execution stage, including field reception, routing, Python-function execution, and return of the results. Alternatively, please explain clearly why the current representation is preferable.

7. Clarification of the scope of the cost analysis
Reviewer 2 specifically suggested that the manuscript briefly address the relative price and energy consumption of CPU- and GPU-based execution. In your response, you state that Durand et al. (2027) provides a dedicated analysis of these topics and that the new Appendix B partly addresses cost considerations.

Please revise this response and the corresponding discussion in the manuscript. Durand et al. identifies GPU accessibility, computational cost, and carbon footprint as important considerations for the adoption of learning-based ocean models. However, it does not provide a quantitative comparison of CPU and GPU monetary costs, power consumption, or energy-to-solution. Similarly, Appendix B primarily presents an analytical interpretation of runtime and scalability rather than an assessment of financial cost, energy consumption, total resource consumption, or carbon emissions. Please consider renaming or describing it as a runtime and scalability analysis, unless an explicit resource-cost metric is added.

A new hardware-energy benchmark is not required for the present revision. However, please:
1. avoid characterizing Durand et al. as providing a dedicated quantitative CPU–GPU cost or energy analysis;
2. add a concise statement in the manuscript acknowledging that the present benchmarks evaluate wall-clock performance and resource allocation, but not monetary or energy efficiency;
3. distinguish clearly among wall-clock overhead, total computational-resource use, financial cost, and energy consumption;
4. consider renaming Appendix B as “Runtime and scalability analysis”, unless an explicit resource- or energy-cost metric is added; and
5. verify and correct the bibliographic details of Durand et al. The cited work is a non-peer reviewed EarthArXiv preprint (https://doi.org/10.31223/X5HB6S) dated 2026, whereas your response cites it as 2027; please correct the year, indicate its preprint status, and update the citation if a peer-reviewed version becomes available before publication.

8. Final technical and editorial corrections
Please carefully proofread the manuscript. In particular:
• Figure 8 refers to eORCA075.L75, whereas the experiment appears to use eORCA025.L75.
• “ORCA-I” should be standardized as “ORCA1-I.”
• Correct the incomplete reference marked “(???)”.
• Correct duplicated DOI prefixes such as https://doi.org/https://doi.org/....
• Correct “Journal of Open Source article” to the proper journal title.
• Correct “Nature Reviews Earth amp; Environment.”
• Check the spelling and bibliographic details of all software and reference authors.
• Correct grammatical expressions including “allows to deploy,” “If the Fortran code send,” “fields sendings and receptions,” “outcoming fields,” “from these information,” “the 20 first levels,” “take into account of,” and “implmentations.”
• Arrange the institutional affiliations in a consistent numerical order.
• Please use a single, consistent designation for each component throughout the manuscript. In particular, terms such as “ESM,” “geoscientific model,” “geophysical model,” “Fortran model,” and “physical model” appear to refer to the same component. Similar inconsistencies occur for “Python script,” “ML Python script,” “Python component,” and “ML component,” as well as for “coupling fields,” “exchanged fields,” and “input fields.”

Please submit a revised manuscript together with a detailed point-by-point response explaining how each of the above issues has been addressed. Please also provide a marked-up version highlighting the changes.

Thank you again for your careful revision and for this valuable contribution to the development of reproducible hybrid Earth system modelling.

Sincerely,
Jinkyu Hong

1. Please check the DOI for the ORCA1 Zenodo archive, as the DOI given in the Code and Data Availability section differs from that listed in the references. Please also update the citation for Durand et al. using the most current bibliographic information available.
2. I believe that numerical equivalence between the synchronous and asynchronous implementations is important for supporting the proposed approach, and please provide a simple quantitative comparison for at least one representative case. This would be preferable to relying only on the statement that equivalence was verified during earlier tests.
3. I think that it is better to moderate the statement that the OASIS3-MCT/Eophis implementation is “optimal” in terms of time-to-solution, since the comparison is based on a limited set of benchmark cases and alternative implementations. A statement explicitly restricted to the ORCA1 benchmark would better reflect the evidence presented.
4. Please also perform one final proofreading pass to correct the remaining grammatical and typographical issues.